This article was published on our Patreon site and was available to backers in May of 2022. It is re-published here as part of the drip from what backers have access to and what non-backers have access to.
I dont often write about hardware on this page, but as we near code-freeze to the IDE and development tools- my thoughts return back to our original project, namely the Quartex Media Desktop (codename: Amibian.js).
Just to underline: You dont need a SBC (single board computer) to work with Quartex Pascal. JavaScript runs anywhere, which is the point of making a development toolchain like this to begin with. This article is about working with IoT and embedded devices, which is completely optional.
Since I have written about Quartex Media Desktop before, hopefully everyone understands the value and power that brings. So instead of going into a pitch about that, let’s instead define a use-case where getting a dedicated IoT board makes sense. (Note: If you are not familiar with the Quartex Media Desktop, below is a video that demonstrates the prototype).
The ticket booth scenario
Let us for sake of argument say that you get hired by a large company to deliver a ticket system. The company provides you with a touch display and casing (booth) to house whatever hardware you request to finish this project. Your job is to sort out operating system, back-end technology, commercial dependencies like software licenses -and further, to implement the ecosystem that the customer will see and interact with.
This is where things start to get interesting, because such a ticket system has to scale. There wont just be one such device in use, but rather hundreds – if not thousands nation wide. As a growing business the company hopes to take the product internationally, which could result in hundreds of thousands of devices being deployed around the world.
There are many factors to take into account here. In a distributed system that needs to scale, most of the pressure will be on the back-end (server) side of things. I would not attempt to simply “roll my own” back-end for a project of this magnitude, but instead make full use of Docker and Kubernetes to deal with the scaling aspect, while I would write the QTX server to make full use of available CPU cores and process clustering.
Define your products life-cycle
While the back-end will by far be the most complex piece to engineer, it ultimately holds less surprises. Like i mentioned above, technologies like Docker and Kubernetes pretty much solves everything with regards to scaling and meeting demand. What is more important for our ticket booth system, is to make sure we pick an SBC that performs well, and that will continue to perform well as our software grows in complexity.
This period of time is simply called the a products life cycle, with the EOL (end of life) marking the date where a company must upgrade their hardware. What duration we end up with ultimately boils down to growth in complexity, the amount of data that must be represented, and underlying non-visual complexity. For sake of argument, let us define a lifecycle of 3 years. Personally I would try to find devices that can deliver 5 years, but the difference in cost can be very high between the two.
Right out of the gates the Raspberry PI falls short. The first thing on my mind would be to find an SBC that can handle temperatures well, especially cold weather. If you plan to deploy the device to a region with cold winters then you can forget about the Raspberry Pi. You will need insulation in your booth, but for devices not designed for -30 degrees celsius, you also need an expensive regulator and heating elements. It will be more affordable to pick an SBC that can operate at -35c degrees celsius, and instead make sure you have good insulation. With active cooling the board will make sure the insulation doesn’t cause over heating in warm weather.
But for performance, which is ultimately where your code comes in, the Raspberry Pi is not quite up for the job. Sure, it will run Amibian.js just fine, but the performance will always lack “bite” to deal with demanding tasks, especially graphics intensive applications. A ticket booth system will obviously not be “intensive” compared to say, running Quake in the browser – but you dont want something as simple as a few video elements to potentially ruin the customer experience.
Define your low-end mark
Running Quartex Media Desktop (read: amibian.js) doesn’t require that much CPU power for the core system. The system is based on 5 node.js services where only 3 of them are critical for operation, the other 2 are optional. These services can either be installed separately on their own SBC (hardware cluster) or collectively on a single SBC. The node.js services use exceptionally little memory and they are just as fast as any service written in native languages like Delphi (or .Net C# for that matter).
When running a kiosk system with Amibian.js, you adapt the Linux setup to only run your software. You dont actually boot into the Linux desktop, instead you boot into Chrome in it’s own X-window session. Chrome will then run fullscreen in Kiosk mode and load the desktop from localhost. Once loaded into the browser the desktop connects back to localhost via websocket, and use Ragnarok messages to invoke API functions, perform file operations and run programs.
So the boot sequence for our SBC will look something like this:
- Bootstrap loads kernel
- Kernel loads Linux drivers, services and initialize
- PM2 loads our node.js services and starts them
- Our Node.js services use ZConfig to find each other
- Each of our services register with the Amibian.js core service
- Chrome is started in Kiosk mode with URL set to localhost where the Amibian.js core service hosts a webserver supporting websocket
- Desktop connects back via websocket. All API calls happens via Ragnarok messages over websocket. The core service automatically routes API messages to whatever service is registered to deal with them, and likewise routes the response back to the desktop instance that issues them. In many ways the services act as distributed library files.
So if you install Amibian.js on a single SBC, the experience is indistinguishable from booting a normal, native Linux desktop.
The thing you want to factor in, is the graphical performance of the SBC. While you can run the services on any cheap board, the one hosting the desktop display must by necessity have enough muscle to render the display without issues. This means first and foremost a beefy GPU, but also a processor and RAM enough to delegate everything. A browser is perhaps the single most demanding piece of software in existence today.
As a bare minimum I would recommend:
- 4 GB of memory
- ARM v7 (Quad core A73 at 2.4 GHz)
- SATA interface and boot support
- eMMc boot support
- RF / Bluetooth support
The Raspberry PI v4 does hit these marks, or at least it can easily be expanded to cover this list. But keep in mind that this defines our lowest point. This is the absolute minimum that I would recommend for using Amibian.js as your software delivery platform.
As of writing the prices for SBC’s have gone through the roof, and even a Raspberry PI v4 with 4Gb of ram retails for over $100. Which is ridiculous, it’s not worth that by any means unless you have some very narrow educational criteria hanging over you.
A much better buy, one that I picked out two years ago, is the ODroid N2. Not only does it check all the criteria, it actually has 2 extra CPU cores (based on the little-big architecture, where you have 4 powerful CPU cores, and 2 weaker cores). Not long ago the ODroid N2 was replaced with the ODroid N2+ which is roughly 30% faster than the original N2 yet retails at the same price. You can pick up this device for $83 at Hardkernel. And it’s worth every penny for general purpose development. It also acts as one hell of a games system if you want to give your kids a system to play Playstation 1, Sega Saturn and Gameboy Advance type retro games on.
But would I pick the N2+ for a ticket booth with a 5 year lifecycle?
The new breed of SBC’s
Most SBC’s are based on tech created for the mobile phone marked. Meaning that mobile phones drive the development of these SoC’s (system on a chip). The companies that deliver these SoCs want to capitalize on the production infrastructure they have setup, so after the contract for a phone expires, they usually offer the same SoC to embedded and IoT companies – which builds an SBC around them.
There is usually a 5 year delay between a SoC being used in a phone, and the time it becomes available as a fancy new SBC in the IoT sphere. A good example of this is the Snapdragon 880 series which powers expensive phones like Samsung Galaxy Note 9. The 880 series delivers performance comparable to an Intel i5 (first generation), which is incredible value for money.
The coolest board right now is the newly released Firefly SBC. This is not based on the Snapdragon, but rather a brand new RockChip CPU design – but it delivers performance better than Snapdragon 880. It is fitted with a powerful GPU that can handle 8k video and display modes, and you can buy a model with up to 32Gb of RAM (!) – which is a first for SBC’s I believe. I have never seen an IoT SBC with more than 8Gb.
Since manufacturing parts are scarce right now, I was not surprised to see that it retails at well over $200. But when you consider that a Snapdragon 880 development board sells for $2000 – I wouldn’t think twice about giving the Firefly a testdrive. And yes, it ticks all the boxes in our list (it’s way ahead of our minimum). First of all It’s based on ARM v8 (a whole generation ahead of our lowest mark), it has NPU chip which is used to run A.I models, it’s data transfer speeds is astronomical compared to our lowest specs – and you can fit it to an ATX motherboard and use standard PC cases if needed.
So if I was to pick a board right now for our 5 year lifecycle, I would go for the Firefly. If we lower the lifecycle to 3 years, the ODroid N2+ is just impossible to beat. I should underline that GPU support for X has been an issue for the ODroid N2, but that was solved via the Bifrost driver update a while back. But I would make absolutely sure and test it early if you plan on using it.
An alternative to the Firefly board, is Radxa: Rock 5b. This is based on the same RockChip RK3588 SoC that the Firefly uses. Price is significantly lower, especially if you pre-order, but to stay below the $200 mark you are limited to the 16Gb model.
So right now we are in that sweet 5 year spot where the previous generation of SoC’s are being repurposed for IoT devices. Although the RockChip 3588 is the exception rather than the rule. It is either way miles ahead of all the other board out there – and I would not buy anything below this is performance, unless your menu system will only see moderate improvements in the years to come.
Never buy boards for today, always try to think 5 years into the future.
Why not use X86?
You are probably wondering why ARM is the preferred platform in my articles, why not opt for a cheap and affordable x86 board? Intel in particular has dropped it’s prices and there is a lot of good SBC’s that are powered by overclocked Atom CPU’s out there.
Well, there is nothing in the way of using x86, at least at first glance.
A while back there was a movement in the US called “the right to repair” movement. They actually took Apple to court because Apple has consistently gone out of their way to stop people repairing their own machines. Apple even went as far as to fill machines with glue, just to make absolutely sure that nobody could repair, optimize or alter their own devices.
During that trial, which Apple lost, a lot of information was presented about ordinary x86 hardware, information that shocked a lot of people (myself included). Where everything from the firmware to the actual, physical hardware is rigged in in their favor. Microsoft especially has made it damn near impossible to buy a PC without Windows. There are some that allow you to install Ubuntu and pick between the two, but the whole marked is so heavily dominated by third parties that I dont see this changing any time soon.
When you add to this the facts that surfaced about Intel’s SoC’s, namely that they have several back-doors in the SoC design, bolted into the very hardware, that allows them to access your computer remotely – typically in concert with government agencies, suddenly x86 becomes a security risk because these back-doors were first discovered by hackers.
My reluctance for x86 has nothing to do with my personal activities, my digital life hardly warrants interest enough for any remote system incursion, be it the government or Intel. The point here is the principle of the matter, what people do with their computers is nobody’s business. And companies using “financial incentives” to dominate a marked that should be based on fair competition, is not something I will support of condone. Tese tech giants have even gone so far as to have legislation changed to suit their criteria. You dont have to be a rocket scientist to see where this is going, and what that means for consumers.
I should add, this is the real reason why Apple decided to create their own hardware. They have sold their new SoC as being about performance, but it’s actually about getting away from the legislation surrounding x86, parts and repair laws (especially here in Europe). By bolting as much as possible into a single part (SoC) they can ensure that customers are 100% dependent on them, and have to buy a new device. After all, If there are no parts to buy, you cant argue for any rights to repair either.
That’s the kind of people you are helping to fund when you buy their products. I haven’t bought an Apple device in over a decade, and I never will. Nor will i ever buy an Intel PC.
Bricked x86 SBCs
A good example of how controlled the the x86 marked has become – is to have a look at the x86 based UP board. Out of the box this is a good value for money board with the same form-factor and ports as a Raspberry PI. It used to sell for around $120 and is more than capable or running Amibian.js and tick all our boxes. It even has an on-board eMMc drive.
The problem is that their Firmware is bricked to only run two operating systems, namely Windows 10 or Ubuntu. When I asked them how I could boot other operating systems, such as Aros, Android or Haiku (a modern, open source re-implementation of BeOS), they simply dismissed me and referred to their documentation. There is nothing in the way technically for the board to run these alternatives, they would even run exceptionally well – but it boils down to financial incentives: they get paid by Microsoft for each license installed.
So to be perfectly honest: Companies dictating what type of OS you are “allowed” to run on your own device are persona non grata in my book. I simply ignore them and never buy anything from them.
Besides, with so much power and freedom in ARM these days – why on earth would you want to use an x86? The power consumption alone should be enough to say no thank you!
Next article
In this article we went through some of the boards available out there, and had a peek at thinking in life-cycles. I am going to continue writing about this scenario, and in my next article we will have a look at PM2, the process manager we use to run our node.js services in the background when your device starts!