A Brief History of Everything Wireless Blog: Back to the Hardware part 1: the earliest Edge

Back to the Hardware part 1: the earliest Edge

2023-12-21 [Petri]

After the COVID hit, a lot happened in my work context, and although I have been following the multitude of ongoing developments in the tech space with interest, I didn't have the spare bandwidth to write about them.

That's why there has been a long break with blog entries.

For a company that had its main customer base in the travel industry, COVID quarantine was extremely tough for Datumize: we did manage to push through, but with only one major project. Hence we ended up being taken over, and the realignment that followed took a lot of effort as well.

Datumize had to pivot hard to survive the COVID crisis, and as my last major assignment, I played an essential role in winning an IoT/Edge Computing project which finally reached its deployment phase now under the new management.

Despite of actively helping the project to get past some unexpected issues (more of them later), the role overlap between me and the new owner's management structure finally led to the inevitable outcome. A bit prematurely, in my opinion, considering what was the status of the ongoing rollout, but it was their choice, not mine.

So it is RIP Datumize: it was a worthy attempt by a very capable team into IoT/Edge Computing/Big Data, killed by a virus from China.

But from the technology perspective, my "swan song" project in the Datumize context turned out to be something that connected me with my former, dear areas of interest of both hardware design and 3D-printing. Therefore in this and in the upcoming continuation entries I will give some insight into the developments in these two areas, from a perspective of someone who has been hands-on and off of this area over the past couple of decades.

First the problem statement:

As we try to gain better understanding of our existing systems through digitalization, we are often facing a major dilemma: our aging technology is still performing its daily job perfectly adequately, but it hails from an era when connectivity was not part of the plan. Instead, it was aimed to do just one function, as an isolated island, and do it well.

It has been churning in the corner for the past N years, held together with whatever patches were available, and in the worst case, even the manufacturer has gone out of business.

But the show still goes on.

So if you want to gain a wider access to the real-time information of such a system, there is no "standard" way, no simple plug&play data interface, or even an upgrade that would provide you with one. If you want to make your system "Internet-aware", you need to glue something modern to it.

Our client's case was a model example of this: hundreds of old but fully functional devices work fine on the field, and although their manufacturers are still totally in business, switching to the very newest, networked versions of these devices on such a scale would cost tens, if not hundreds of millions of euros.

So if it works, don't fix it via an expensive replacement, enhance it instead.

In order to be able to serve the customer requirements in the proposed project, we needed a cheap, robust IoT/Edge Computing device with the necessary flexibility in terms of interfacing to the outside world.

Going the mini-PC way was one alternative, but it becomes complex when you add the more esoteric connectivity requirements, like CAN or RS485. Any specifically Industrial-oriented devices that we found were from niche players and thus had many questions around product longevity. Even ordering a batch of hundreds of them came with a lead-in time of 6+ months.

Worst of all, some had very unique SW environments, that would require learning niche IDE platform that probably would not be viable in the longer run. Engineers also do not want to learn stuff that is totally isolated from mainstream. That does not advance your career in the long run.

And the last demanding issue around our application environment was the fact that the power to the destination setups was automatically turned off every night. So you needed a "mini-UPS" with fully managed shutdown integration to make sure that we did not end up trashing the file system on the device due to the abrupt power fail.

Traditional UPS devices would be heavily over-specced and costly in this case, as our minuscule processing capacity only needed a few tens of seconds of power backup to shut down gracefully, not tens of minutes. Also, they come with batteries, with a limited cycle count and degradation over time.

All these requirements gave me a reason to dive back into the world of electronics design to see if something could be cooked up as a supporting wrapper around readily available standard computing resources. And it turned out to be a very rewarding and fruitful experience.

First of all, creating hardware solutions today is easier than ever. You have powerful, free tools for producing the design, and an amazing spectrum of low-cost programmable chips that can perform a wonder after wonder. And even during this project, the newest chips that arrived on the market and could have been used in the design, had a 90% price reduction compared to the one that I used. So redesigning now would make things even cheaper.

Finally, there's a worldwide network of companies that turn your plans into a working printed circuit board (PCB) with all components in place: just tell what you need and a fully built test version comes in a couple of days. You can source the components yourself or do a full turn-key, or anything in between.

As for the actual data processing context, you get cheap, software-wise "standardized" Linux computing power off the shelf...except in the unexpected times of COVID with its side effects on global supply chains, as we got hit by the worldwide COVID-induced component availability issues, but more on that later.

Personally, I did my first electronics projects starting from the ripe age of 12, ranging from simple radio transmitters to electronic timers for dynamite detonation: living in the Finnish countryside with lots of farmers’ kids around had its benefits – my friends brought the highly volatile goods called “dynamite” and “detonators”, and I made them go BOOM.

The potential dangers of those endeavors sure forced you to do a thorough testing of your circuitry prior to plugging it into the detonator's wiring...

Later in life, in one of my first real jobs, we got a request for a simple protocol converter for an RS232-connection: an industrial device was sending real-time production data, but the receiving computer needed it in a slightly different format.

An early case of Edge Computing.

To get this done, we needed a standalone box, and as I had been programming in assembler for the Apple II prior to that in another low-level project, I chose the same CPU, the venerable 6502. With whopping 64 kilobytes of total addressable memory space.

My then employer at a time was a startup set up by four poor university students (including myself), so we had no funds for fancy things like commercial assemblers.

So I wrote one, in C, on our Unix platform.

I do not remember which PCB layout editor I used at the time, but whatever it was, it was a free version. You could create the wiring for one side of the PCB only, and you had to print it out with a laser printer on a transparent plastic sheet. Then you bought copper-layered fiberglass piece, sprayed it with an UV-sensitive mask, and used a UV lamp that I bought from God knows where to etch the layout on the PCB.

Thereafter you applied a chemical bath to eat out the UV-exposed parts of copper, painstakingly hand-drilled all the necessary holes on the PCB, and started soldering components on it.

The same UV lamp was later used to erase the necessary memory chips. No electrically erasable programmable read-only memory (EEPROM) existed at the time, except in labs, so the memory chips had a window that exposed the silicon (see the image), and its contents was reset by the angry photons from the UV lamp.

Naturally, thanks to the limited budget, the circuitry for the EPROM programmer that was needed to get your code on these chips had to be hand-made as well. No money for fancy programmers in startups of the time: if I recall correctly, it was a concoction that interfaced to a PC via the parallel printer port, copied from schematics published in some magazine, most likely Elektor.

To everyone’s amazement, including yours truly, my first attempt on the circuit turned out to be fully functional. I found a spiffy-looking aluminum case from the same shop that sold me the all of the components, gave a handmade sketch to a small company specialized in machining metal parts to get the holes for connectors for the case, and finally assembled it all.

The customer was happy, and that device solved their problem for at least a decade, until the destination computer become obsolete and was replaced by a model that did not need the conversion anymore.

So to do all this in the past required playing with chemicals, potentially harmful UV light, lots of mechanical work, and, due to lack of funds, lots of DIY.

Those were the days…

Then the microcontroller revolution started: these are low-power consumption microprocessors with in-built peripherals, and what you could achieve with your circuitry just became 10x more powerful and 1/10th of the size.

The story continues here.

Permalink: https://bhoew.com/blog/en/143

Show latest Earlier entries