sfx2000

In a pinch that works, but one really shouldn't be touching this file by hand, it's really there for the glibc resolver... network manager (nmtui from the shell, or one can do nmcli) is really your friend here... it'll work directly with systemd-resolve to ensure that the resolvers are set correctly. Also might want to check your Router/Gateway if that's the DHCP server, as that whole handshake should include the ip addr, the gw addr, and the dns server for the LAN side...

Check usb_modeswitch - many USB 3G/4G dongles initialize as a mass storage device (check lsusb and dmesg)... they do that for Windows and sometimes Mac for users to install the carrier's connection manager software and drivers for the dongle. https://linux.die.net/man/1/usb_modeswitch Each dongle is a bit different - some support serial over USB only, some provide an ethernet interface once the mode is switched over...

Check the MAC address of eth0 - is it steady? One of the common issues with the DesignWare MAC/GMAC on AllWinner and other SoC's that use the same IP block, is that they have a random MAC address - with IPv6, this obviously will have some challenges. Check the ethaddr in uboot - you can set a value there... it's supposed to be a fixed address after first boot, but many of the DWMAC/GMAC implementations let it float...

There's a couple of ways to do this - with your use case, have you looked at ESP32/ESP8266? They have a softAP mode that is intrinsic to the module there, and it's lower cost than the device you're looking at.

++ board bring up is easier with Armbian compared to many other environments

All three are good... TL:DR perhaps - if one is used to debian/ubuntu as a development environment, Armbian is the better choice - if one is coming from buildroot on embedded linux, OpenWRT is a good place to be there. 1) debain armhf - as long as a supported board, you might be ok - still, you might want a cross-dev environment to actually build runnable binaries, so you're looking at a number of options there... a minimal armhf is going to be the same pretty much anywhere - and one still might have to sort bootloader and devicetree's - bringing up a new board on straight debian is a fair amount of effort. 2) armbian - takes care of most of the cross-dev, as armbian has a great build environment and a clean way of patching existing code - and you have choices on the userland - ubuntu or debian, which has certain benefits. As with any environment, it does take some time to learn the specifics, but it's not a bad place at all... 3) Openwrt - embedded, and it's multiple architectures, not just armv7/armv8 - mips, x86, ppc, those are supported in OpenWRT. Again, like I mentioned above, takes time to ramp up to speed on the peculiars of OpenWRT, and it does have some differences for developers that one must be aware of, for example, rather than glibc, they use musl... they do more of a package paradigm, but it's template driven, and fairly easy once one gets the hang of it. Armbian vs. OpenWRT - it's really two different sets of problems that are being solved - and both do a good job at solving them. What I would suggest is download both - and do a basic build on a platform that is supported by both - EspressoBIN is a good one, as that board has support in Armbian and OpenWRT.

Chip antennas aren't all that bad - most are at best unity gain - or 0 dB - e.g. power in is power out... And that isn't a bad place to be, as the pattern at the antenna isn't very particular about orientation. The major challenge is the RF front-end efficiency - and some are better than others - it's how the WiFi chip or System on Package is implemented on the board. @root - your observed numbers are consistent with expected results on the Tinker - it's not a great chip on the WiFi module side, but the realtek drivers are known and somewhat stable.

Bump your cost limit up to 1000/1200 and you have a lot of great choices for something that'll get you by for more than a year or so, and perhaps also more robust construction... Dell Latitude, HP Probook, Lenovo Thinkpad are good choices - even the entry level Macbook Pro (non-touchbar) - go with a business class laptop, and they'll last long after they're obsolete... These days = Core i5, 8GB RAM, 256GB SSD is pretty much the minimum. Don't forget about offerings from Asus, Acer, and MSI - some can be quite good - just watch out for the gamer oriented ones, sometimes a decent value, sometimes not...

Well - benchmarks are going to try to measure something specific... Toss in UnixBench across the boards -- https://github.com/sfx2000/byte-unixbench.git

Yep - think we're both on the same page there... It's incredibly complex, and I think my friend was trying to simplify things for my benefit... I was a simple EE with a background on analog RF, he was on his post-grad on applied mathematics. He was involved back when Ventner was doing the whole shotgun approach to DNA sequencing for the Human Genome Project - and I saw things similar to Shannon with information theory working on wireless comms... Quite a few interesting discussions over drinks... Yep - and that's a complex topic well beyond the forums here perhaps - but as a commercial product, just interesting to note that companies that used to just related personal memories of family trees now do the DNA thing - and I mentioned previously linkage to cold cases, it can also be disruptive to families, aka "who's your daddy" kind of disruptions... Once samples are submitted - it's basically out of one's control, and IMHO, it's the worse kind of privacy exposure in a commerce environment.

I agree... Hehe - so the real question is - "Who's your daddy?" in American vernacular... gingers vs. blondes - blue eyes vs brown... Thing is with commercial DNA testing, once one's DNA is in the database, folks are using Big Data techniques and AI/ML to find all sorts of things - many of these are positive towards discovering disease trends, genetic concerns, and the like... and more than a few cold case crimes have been solved by groups combing thru the commercial DNA databases... There's more than a few startups promising connections/etc... - and 1 out of 10 might be a viable business - the rest, once investors pick thru the bones, the data is the big prize, and will be sold to the highest bidder. FWIW - chatting with a friend of mine who works in that field - DNA sequencing is much like Sudoku - patterns are predictable otherwise life fails - so folks look at pareto vs markov chains to find the differences.

That's a bit harsh Heck, most of these SBC's are simple toys - but it's what we do with them that is really the important part - and some of the boards have more flexibility and capability than what the RPF offers in their line. The issues with the Pi are mostly wrapped about VC4 and its design - VC4 is common to all the Pi's, it 40nm, and it's limited to single channel, and 1GB (that, and the binary closed source blob that is VcOS/ThreadX)- I seriously doubt that Broadcom is going to do anything with VC4 like a die-shrink, so either RPf/Broadcom moves forward with VC5 on a smaller node, or RPf has kind of run their course... HW is one thing, but also they're still shipping ARMv6 stuff (Pi Zero/Zero W) and want to keep a single distro, which holds back the Pi3's (and perhaps Pi2')... Their last couple of board releases are actually very well engineered (Pi Zero W and Pi3 B+ 1.3) - I think they learned quite a bit with the Pi3 and WiFi, and having to do global wireless certs brought their hardware forward. Layouts are better, and they're doing a good job on the BOM front, keeping costs low - and just look at the board - the number of passives (caps/resistors/inductors) says a lot about the design team - the lastest boards look pretty good That RPf shipped Pi Zero W - they kept the BCM2835 ARMv6 well past the use by date - similar to what Apple did with Ipad2 and variants (iPad Mini/iPod Touch 5G) - which hurt the SW side as those devices drug out compatibility requirements well past the useful dates as ARM and Apple accelerated performance.. https://allenpike.com/2014/the-ipad-zombie/ The Pi Zero W is the Raspberry Pi Zombie... and it holds back an entire platform that is Raspberry Pi... none the less - they ship a lot of those board and Pi3 B+'s as well... I'll agree - Pi is not industrial grade components, but with their OEM partners (Sony and Embest), good manufacturing and good software QA for the most part... There's been some exceptions with first-run boards, and that's happened more than once. FWIW - totally concur on the mess that was the official PoE hat - I don't think it was a good design, and even shipped, it had problems... seemed kinda rushed, and perhaps it was an answer to a question that had already been answered.

Take a look at /etc/cron.daily/armbian-ram-logging - might want to comment that line as well... In any event - the services and crontab entries for ramlogging at well intentioned to keep pressure off the flash, so step carefully...

With Tinker - check your power - if going over the MicroUSB, Tinker is very sensitive to poor quality cables and less than sufficient power supply current. Search around the forums, and there's good tips on getting Tinker stable with power -- @TonyMac32 has done a lot of work there documenting the challenges of this particular board.

That is your key feature - the Bluetooth aspect... assuming that the IoT device has BT in the first place... Not all do... in any case - the "solutions" I pointed out - nothing says it has to be an openAP - there's a number of ways to pre-provision a secure and random PW, and go from there... and to the end user, present a QR code that is printed on the device that they can scan with your app...

That's true - with the onboard RAM it does simplify things, and the eLQFP package is "maker" friendly - easier than BGA for assembly... too bad AllWinner couldn't have found a place to drop in some flash on the SoC die, or do a pop package with a decent about of flash... In my opinion - MCU's are a good starting place for someone's first design and layout - MicroChip's PIC32 line is really good, and there's a lot of great examples to look at... I mentioned the ESP's earlier, but they tend to be SOM's, I haven't tried to obtain just the Espressif chip, as the modules are so dang cheap.... hackaday has their supercon badge, which is a complete microcomputer based on PIC32 - and all their files are open-source (MIT license, IIRC) - CAD, Schematics, Firmware... Getting back to OP @muhammad murtaza - check the schools line up of courses - you might have good luck there with courses that can take you further down your desired project goal.

Long story short - it's a chained series of events that gets one to here... in systemd... (nice that these are in systemd - I have no skin in the whole systemd discussion other than to recognize that it's there) armbian-ramlog.service armbian-zram-config.service One can disable them easily enough by just doing systemctl... the crontab tip is good... To get zram back - install zram-config, and for the log stuff once the ramlog is disable (along with the crontab entry), look at logrotate...

Yeah, I would agree - one you get into this level of capability - one is firmly in the Intel NUC space - whether Intel or others that use the same form factor... Nice board however... the dual NIC's would make it interesting for networking purposes...

FWIW - Pi Zero W is the same as all other Pi's when running Raspbian - while is armv6, it is armhf - so if your code runs on Pi3, should run on Pi Zero W if you do it right as they have the exact same WiFI-BT chip... Pi3B+ might be a bit different, as it uses a slightly newer Broadcom WiFi/BT device, but if you're not too close to things, same code should work for it. This might help... Don't need an app - just a browser... they're trying to solve the same problem.. https://github.com/schollz/raspberry-pi-turnkey Part of your challenge - once past the Pi ecosystem - there are many different WiFi and BT solutions in the SBC space - some work ok, and some have significant challenges... but most of them, BT is likely not the priority over working WiFi... Here's similar code for ESP8266 in it's Arduino personality... The ESP8266 is very popular in the IoT space https://github.com/tzapu/WiFiManager Enjoy!

I would start out with baby steps - get something like FriendlyARM's NanoPI DUO - it's breadboard friendly, and as a system on module, with clearly defined interfaces - you can start there... Alternate would be any of the Arduino's (and clones) or the ESP8266/ESP32 boards if one wants to explore WiFi and IOT type of technology - it's a rich community there, and more importantly - many community board layouts/schematics with CAD files for PCB layout - it's not a bad place to start. Looking forward - what's the long term goal - if you're looking at SW - then just get a community board, and proceed - if you're looking at doing HW - well, look at current example, and like the ESP8266/ESP32, there's a lot of work that has already been done, and you can compare what works to the theory taught in your courses...

I suppose another way of saying things - Fast, Good, Cheap - pick any two... This isn't going to win fans here perhaps - but shop around - Intel PC on a Stick running Ubuntu... $35 shipped in US from Amazon - and that Baytrail chip sku does support AES-NI...

Tinker looks bad on those numbers - it's better than they suggest... just that UnixBench, by default, it is going to run for about 21 minutes, and that's a strong load for any thermal issues - and Tinker has a fair amount of that - like mentioned - 15W of load in a 5W basket - Pi3B+ just does better there, as would any similar chip... The big core A12/A17 on Tinker does show and indicate the challenges with big.LITTLE where we have mixed cores - and we've seen this with Android, and excessive throttling there on certain handsets running Android. The problem with Tinker is that it's power hungry and runs hot, it's big core only - so under sustained load with a typical install - e.g. Asus provided heatsink, and a decent MicroUSB power supply that can drive the board most times - it does tend to suffer a bit, it becomes heat soaked, and hopelessly throttled - and the numbers above show this... To get best performance out of Tinker - one does have to look at driving power thru the 40-pin interface with a bench quality power supply, and active cooling for the chip - properly powered and cooled, it's a good challenger for Intel's Baytrail/Braswell chips - look at chromebooks, where the RK chip does a decent job...

It's really hard to bring the first product to market - once that's done, the follow on products are probably easier, as much of the business infrastructure is already in place - and perhaps time to tune and tweak based on lessons learned from the first one. With startups - yep, investors do have a say, so choose them wisely - hopefully one that has previous experience, and connections that can help down the road, getting into their "deal flow" when possible. Going to SoC's - it's really hard to work with many of them - some for reasons like you mention, others for other reasons - for example, working with their existing partners in the OEM/ODM space, and yes, IP is always a concern - even to the point where one's own IP will be at risk - and then just the competitive risk, as soon as you ship a board at a certain pricepoint, someone else is going to clone it, and do it cheaper... Going with US chips - well, there's Broadcom and Qualcomm - which are tough to deal with and expensive - Marvell, if it's in their interest, they'll work with you, TI and Freescale/NXP - TI is ok, Freescale used to be easy, but with NXP in the picture, things changed.... Production in China - that can cut both ways - I've done business previously in Shenzen, and the gongkai process/culture does have its merits... that and the supply chain benefits along with everything else can bring down the NRE significantly, and production costs are obviously lower, even then one has to be very smart about who to work with there - some are better than others. What I can say about working with US vendors vs. the PRD - if price/cost is not an issue, I'd rather work with US vendors since I'm based in the US, it's just easier - it's the time differences for one, logistics, culture even - but that's a business item - one can get good product anywhere, and it's hard to beat the Shenzen area for products like single board computers and the like. FriendlyARM did a great run on their Allwinner series of board, IMHO, and like I mentioned above, once the business is sorted, and the first products launched, it becomes an iterative process - I'd add that Libre Computing (aka Shenzhen Libre Technology Co., Ltd) has made a good jump across different lowend Chinese SoC vendors (AllWinner/Rockchip/Amlogic) with a fair amount of success.

Just sharing... Old project - looked at Armada 3720 and TI's Sitara (AM3352) - both had fairly flexible interfaces for Gigabit Ethernet... Sitara was interesting as the MAC's could be implemented as switched interfaces.... Armada had faster/better interfaces... so the choice was simple.... Project did two runs of HW - first 20 P0 boards were "stretch" boards, second run (P1) was in the Pi format - mostly to reduce overall costs - think Pi board without HDMI/GPIO, microUSB as console, power on barrel connector where Pi's do audio in/out - swap the USB/Network connectors for 2 USB and 2 1GBit connectors, and you get the picture... With no WiFi, we were able to crowd everything on to a single sided board to reduce manf costs - including 2GB RAM and an 8GB eMMC - it was a clever design - and I'm still happy to have done it. What killed the project wasn't the Bill of Material - it was all the ancillary costs, because of agreements/constraints - basically everything else besides the board itself - building/running a business as a HW startup... We couldn't do manf in Shenzen, we had to do in US (contractual restraints), and then all the logistics... Regulatory - FCC Part 15B can be a killer in and of itself - to be legit, you gotta pass that one, and it's $80K just for that testing per run - 15B is unintentional RF radiators... luck was that the P1 boards did pass... GlobalScale's EspressoBIN offered more functionality at a lower price to the customer... we just couldn't touch that price and with a very narrow market, just didn't make sense to continue - we would never sell enough units to recoup expenses as an ongoing business... Our exit on the project - we sold the design to a white-box shop out of Japan that had Marvell in house already - older stuff based on Kirkwood and Orion - they were more interested in the BSP we developed rather than the HW itself - SW guys did do a back port over to Armada 38x for the SW side - they've since moved to Marvell ARMv8 - I'm not involved anymore on that one... Anyways - getting back on topic - the EspressoBIN is likely the best choice for a multiple port Gbe board at the $50USD price point - it's a good board, yes, it has quirks, but still is better than pretty much anything else at the moment at that price point...

cleanup... see above