I often hear (or read) someone saying something that really strikes a chord, like the lyric “I wish I didn’t know now what I didn’t know then” from Toby Keith’s 1994 single Wish I Didn’t Know Now. Some of these turns of phrase, memorable observations, and pearls of wisdom really stick with me, often leaving me thinking, “I wish I’d said that.”

Of course, this reminds me of the famous exchange that’s generally attributed to the Irish playwright Oscar Wilde and the American artist James McNeill Whistler. Oscar was renowned for his wit, but he also had a reputation for borrowing other people’s clever remarks and passing them off as his own (something I would never do). As the story goes, on one occasion Whistler made a particularly witty remark, prompting Wilde to exclaim, “I wish I had said that.” To which Whistler replied, “You will, Oscar, you will.”

In turn, this reminds me of Monty Python’s Oscar Wilde Sketch featuring Oscar Wilde, James McNeill Whistler, and George Bernard Shaw, who are entertaining the Prince of Wales.

They take turns making increasingly outrageous and insulting remarks about the Prince, only to attribute them to one another. The unfortunate person credited with each insult must then scramble to explain how it was actually intended as a compliment. The insults grow more offensive, the explanations more desperate, until poor Shaw is eventually left holding the proverbial bag.

I’m sorry, I got distracted; where were we? Oh yes, I was thinking of how John Donne’s famous observation that “No man is an island” is as true today as it was when he penned those words more than 400 years ago. None of us exists in isolation. We’re all connected to the people around us, influenced by their thoughts and actions, and dependent on one another in ways we may not even realize. Everything we do builds, in some way, on what others have done before us.

The reason for my meandering musings is that I recently saw an announcement on the E3 Designers LinkedIn Page: “Super excited to announce that E3 Designers is now an AMD Embedded Partner Network company!” I found a corresponding entry when searching for E3 Designers in the AMD Embedded Partner Directory.

Now, I realize that a small engineering company becoming an AMD partner may not sound like news that will make the Earth tremble on its axis. But bear with me, because there’s a lot more to this story than meets the eye.

First, a little background. E3 Designers is a small engineering consultancy founded in 2015 by Dan Binnun, who serves as its President and Principal Hardware Architect. Based just west of Boston, Massachusetts, E3 comprises a team of only five people, most of whom work remotely. Don’t let this company’s diminutive dimensions deceive you, however, because these chaps are more than capable of punching above their weight.

The company specializes in helping customers tackle complex hardware design challenges, from developing complete electronic systems to solving problems that can leave even experienced engineers scratching their heads. In recent years, Dan has become particularly involved in signal integrity (SI) and power integrity (PI), both of which are increasingly important as electronic systems become faster, smaller, and more complicated.

But I’m getting ahead of myself. To understand why E3’s recent announcement caught my attention, we need to rewind to 2012. What were you doing then? At the time, I was managing a website called All Programmable Planet (APP), which was devoted to all things programmable, especially field-programmable gate arrays (FPGAs).

One day, I received an email from my friend Mike Santarini, who was the publisher of the Xilinx Xcell Journal at the time. This was an award-winning, quarterly technical magazine and trade journal published by the semiconductor company Xilinx (which was eventually acquired by AMD).

Mike told me about a young engineer (well, young compared to me) in England called Adam Taylor, who had been writing on FPGA-related topics. Mike thought Adam might be interested in contributing to APP, so he suggested that I reach out to him. I did. Adam was. And he subsequently started writing columns for the site. At the time, this seemed like nothing more than a straightforward introduction between two people with a shared interest in electronics. None of us knew where this would lead.

A little later, I was asked to prepare a webinar involving functional safety, reliability, mean time between failures (MTBF), and related topics. I knew just enough about the subject to realize how much I didn’t know (which, in a weird way, sort of brings us back to Toby Keith).

I remembered that Adam had considerable experience in this area, so I emailed him to ask if we could have a chat on the phone. This was back in the days before widespread video conferencing when people used their telephones to talk to one another. Adam generously shared his knowledge; I managed to put my webinar together; and before long, we’d become firm friends.

Meanwhile, I was also involved with the Embedded Systems Conference (ESC), where one of my responsibilities was recruiting interesting people to give highly technical presentations. Naturally, Adam sprang to mind, so I invited him to speak at one of the conferences in 2013. He proved to be an excellent presenter, so I kept inviting him back. 

Over the years, we attended a cornucopia of conferences across America, and Adam went from strength to strength. In 2014, he founded ADIUVO Engineering and Training, which has become a highly respected name in the FPGA and embedded systems communities. More recently, he launched the FPGA Horizons Journal and an accompanying series of FPGA Horizons Conferences, which bring together engineers, industry experts, and technology companies on both sides of the Atlantic (the second annual UK event has just taken place, while the second annual US event is scheduled for April 2027).

Now we come to the next link in our chain of events. At an Embedded Systems Conference in Boston, around 2015 or 2016, Adam met a fellow engineer called Dan Binnun. They got chatting, found common interests, and stayed in touch. Again, nothing particularly earth-shattering, perhaps, but this meeting was destined to bear fruit.

In 2017, Adam, Dan, and Saket Srivastava collaborated on a project involving technology intended to help people with visual impairments. The experience evidently went well, because they subsequently decided to write a book together. The result was A Hands-On Guide to Designing Embedded Systems, published by Artech House (see my column A Hands-On Guide to Designing Embedded Systems). This provides practical guidance on developing embedded systems, drawing on the authors’ extensive experience in hardware and software engineering.

Over the following years, Adam and Dan worked together on various engineering challenges, which brings us to one of Adam’s more ambitious projects: an FPGA-based development platform called the Explorer Board.

The Explorer board (Source: ADIUVO)

Now, designing a modern FPGA development board isn’t simply a matter of plonking a few components onto a printed circuit board (PCB), connecting the appropriate pins, and hoping for the best. Today’s high-performance FPGAs can communicate at extraordinary speeds. When signals are traveling at multiple gigabits per second, PCB traces, vias, connectors, impedance discontinuities, and power distribution networks all become important considerations.

This is where signal integrity and power integrity come in. In simple terms, signal integrity ensures electrical signals arrive at their destinations in good enough condition to be interpreted correctly. Power integrity ensures the circuitry receives a stable, clean power supply, even when large numbers of transistors switch at breathtaking speeds. The two are closely related, and getting either wrong can result in a system that works intermittently, behaves unpredictably, or refuses to work at all.

Adam’s Explorer Board presented a particularly interesting challenge. He wanted to use devices with extremely fine-pitch ball grid array (BGA) packages, featuring connections spaced just 0.5mm apart, while achieving high-speed serial communications using relatively conventional PCB fabrication techniques. Rather than resorting to exotic materials and expensive manufacturing processes, the goal was to employ standard FR-4 PCB material and conventional through-hole vias. At these speeds, this is easier said than done.

Fortunately, Adam knew just the chap to call. Dan and E3 Designers brought their signal integrity and power integrity expertise to bear on the problem, performing the analysis needed to establish that the proposed approach could work. And work it did! The resulting design achieved serial communications at an impressive 12.5 gigabits per second using conventional PCB construction techniques.

Adam is unequivocal about Dan’s contribution. When we chatted recently, he credited Dan as a key reason they achieved this performance. In fact, Adam told me that whenever he needs an SI or PI engineer, Dan is the person he turns to. Coming from someone with Adam’s experience, that’s quite an endorsement.

By now, you may be wondering what any of this has to do with E3 Designers becoming an AMD Embedded Partner Network company. Well, here’s where the various threads come together (“I love it when a plan comes together,” as Colonel John “Hannibal” Smith was wont to say).

Adam’s Explorer Board project demonstrated E3 Designers’ ability to tackle demanding high-speed hardware challenges. Adam was delighted with the results, and the folks at AMD were impressed too. As Dan explained when we spoke, Adam and Bryan Fletcher at AMD helped make the partnership happen. Bryan championed E3 internally, recognizing the value of having a specialist partner with expertise in signal integrity and power integrity.

So, a company of just five people found itself welcomed into AMD’s Embedded Partner Network. Of course, this didn’t happen simply because Dan knew the right people. Connections may open doors, but expertise, hard work, and the ability to deliver results let you walk through them.

Dan and his colleagues had spent years honing their skills, tackling demanding projects, and establishing a reputation through word-of-mouth recommendations. Indeed, Dan tells me that virtually all of E3’s business has come through personal recommendations rather than conventional marketing. He doesn’t even issue press releases, which may explain why his company’s achievements aren’t as widely known as they deserve.

There’s also something rather endearing about Dan’s modesty. Despite working on sophisticated designs for some seriously impressive customers, he remains reluctant to describe himself as an expert. Adam, by comparison, has no such reservations about Dan’s abilities.

Consider the sequence of events we’ve just explored. Mike Santarini introduced me to Adam Taylor. I invited Adam to contribute to All Programmable Planet, and later to speak at the Embedded Systems Conference. At one of those conferences, Adam met Dan Binnun. Adam and Dan subsequently became friends, worked on engineering projects, wrote a book together, and collaborated on the Explorer Board. That collaboration helped demonstrate E3’s high-speed design expertise, which ultimately led to the company joining AMD’s Embedded Partner Network.

None of us set out to make this happen. Mike was simply making an introduction. I was looking for interesting authors and conference speakers. Adam and Dan were pursuing their engineering interests and helping one another along the way. And yet, here we are.

I find this fascinating because it makes me wonder how many other seemingly insignificant interactions have set similar chains of events in motion. How many careers have been shaped by a casual conversation? How many companies have been formed because two people happened to meet at a conference (or in an Irish pub, as described in my column The Internet: If A Wants to Talk to B, Why Does C Need to Be Involved?)?

And, of course, there’s one important conclusion to be drawn from all this. If Mike hadn’t introduced me to Adam, I might never have invited Adam to speak at ESC. If Adam hadn’t attended ESC, he might never have met Dan. And if Adam hadn’t met Dan, E3 Designers might never have become an AMD partner. So, when you think about it, E3 Designers’ latest achievement is almost entirely down to me. You’re welcome, Dan. It’s just one more service I offer (although I suppose Mike deserves a little credit too).

Joking aside, I think there’s an important lesson here. In this age of emails, instant messaging, and video conferencing, it’s easy to forget the value of getting together with other people in the flesh. There’s something special about attending a conference, listening to presentations, chatting with fellow engineers over coffee, and striking up conversations with complete strangers. You never know who you’ll meet, what you’ll learn, or where those chance encounters might lead.

And this isn’t just about conferences. Every time we share an idea, offer someone a helping hand, make an introduction, or encourage someone to pursue an opportunity, we set something in motion. The ripples from these seemingly insignificant interactions can spread much further than we ever imagined (see my column Is Dust in the Wind All We Are?).

Which brings us back to John Donne and his observation that no man is an island. We’re all connected, and we can all influence the people around us, often without even realizing it. Somewhere out there is a person you haven’t met, an idea you haven’t heard, or an opportunity you haven’t considered.

A conversation you have tomorrow might lead to something extraordinary five, ten, or twenty years from now. So, the next time you have an opportunity to attend a conference, introduce yourself to someone new, or lend a hand to a fellow engineer, I encourage you to grab it with both hands. You never know whose future you might change and, come to think of it, that future might be your own.

I find it hard to wrap my brain around how something as innocuous as Bluetooth can suddenly start impinging on my consciousness (and my Bluetooth-equipped devices) from all directions, including—it now turns out—from satellites whizzing around above our heads in low Earth Orbit (LEO).

Just to ensure we’re all tap-dancing to the same skirl of the Great Scottish Bagpipes, let’s kick off this column by briefly reminding ourselves what Bluetooth is, what it does, and—especially—what it was never intended to do.

Bluetooth is one of those technologies that has become so ubiquitous that we rarely stop to think about what it actually is. Conceived in the 1990s primarily as a short-range wireless replacement for cables, Bluetooth operates in the unlicensed 2.4GHz industrial, scientific, and medical (ISM) band. Its original mission was relatively modest: to let electronic devices in close proximity talk to each other without requiring us to festoon ourselves, our desks, and our homes with tangles of cables.

Bluetooth didn’t remain modest for long. What we now call Bluetooth Classic was later joined by Bluetooth Low Energy (BLE), which was introduced as part of Bluetooth 4.0 in 2010. BLE was designed for devices that could spend much of their time asleep, wake up to exchange relatively small amounts of data, and then return to their slumbers, thereby opening the door to battery-powered sensors, beacons, wearables, and a cornucopia of other applications.

And the Bluetooth boffins didn’t stop there. Over the years, they added mesh networking, direction finding, high-accuracy distance measurement, low-energy audio, one-to-many broadcast audio, and… the list goes on.

But the crux of this biscuit is that when somebody says “Bluetooth,” most of us still instinctively think in terms of devices separated by meters or perhaps a few tens of meters. However, as Bob Dylan so pithily put it, The Times They Are a-Changin’.

Hopefully you got to cast your orbs over my previous column: 50+ km Bluetooth? You Want to Do What? If so, as you will recall, the guys and gals at RFOXiA have already demonstrated a 4.6km ground-to-ground Bluetooth link, and they’re now targeting 20+km ground-to-air and 50+km air-to-air.

You might reasonably wonder why I’m returning to Bluetooth-centric shenanigans so soon after that column. Well, something just came along to catch my attention, tickle my fancy, and—more importantly—give me the perfect excuse to plunge even deeper into the weird and wonderful world of Bluetooth.

I’ve said it before (and I’ll doubtless say it again): I’m rarely excited to receive press releases focusing on business-type news along the lines of so-and-so having just been appointed CBW (Chief Bottle Washer) at company such-and-such; two organizations entering into a tentative agreement to evaluate the possibility of doing something potentially interesting at some indeterminate time in the future; or some institution being delighted to inform me that it’s just been awarded $41.99 in funding.

But there’s always the exception that proves the rule. Recently, for example, Jake Hertz from NanoHertz Communications reached out to share the news that a company called Hubble Network had announced a $200 million Series C round, bringing Hubble’s total funding to $300 million and valuing the company at $1.6 billion.

I must admit that a small “ho-hum” started to raise its sleepy head in the depths of (what I laughingly call) my mind. But then Jake went on to say, “Hubble’s LEO satellites communicate with standard, existing Bluetooth radios and chips, rather than requiring a satellite modem, antenna, or second radio.” This set my quizzical eyebrows quivering and caused me to think, “Wait! What?”

All of which explains how I came to find myself chatting with Ben Wild, who is the CTO at Hubble Network (Ben wants you to know they’re hiring). Not surprisingly, my first conversational gambit was to ask how a Bluetooth chip that sometimes struggles to communicate from one end of my house to the other can hold a conversation with a satellite that’s zipping around 550km above the planet.

Ground-based Bluetooth to Hubble satellite (Source: Hubble Network)

Ben was unfazed, explaining that several technological tricks are involved. For a start, normal Bluetooth Low Energy (BLE) operates at a data rate of around 1Mbps. Hubble slows this to only a few hundred bits per second and adds error-control coding. Taken together, Ben says these changes improve the receiver sensitivity from around −100dBm for standard BLE to approximately −140dBm—which is roughly comparable to LoRa. 

But that alone isn’t enough. Hubble’s current satellites carry phased arrays comprising more than 100 antennas. The signals from these antennas are combined using digital beamforming, providing approximately another 20dB of antenna gain. This beamforming also lets the satellite spatially filter interference from outside the area on the ground where its beam is pointed.

Finally, rather than using Bluetooth’s normal advertising channels, Hubble operates towards the relatively quiet edges of the 2.4GHz ISM band. According to Ben, when all these cunning tricks are combined, the current system enjoys around 15dB of link margin. 

The clever part is that none of this prevents the hardware from remaining a regular Bluetooth device. Hubble provides a software development kit (SDK) that runs on existing BLE chips. Most of the time, the device can carry on doing whatever Bluetoothy things it was doing before. When a satellite is due to pass overhead, the SDK temporarily takes control of the radio, transmits its satellite packet, and then returns the radio to normal Bluetooth operation.

Of course, these are really small packets. The current system supports payloads of up to 13 bytes, which may not sound like much until you consider how many useful things can be represented by relatively few bits. Sensors can report temperatures, tank levels, soil moisture readings, equipment status, and other small nuggets of information. A transmission takes only around 400ms, and Ben says each satellite can handle millions of devices simultaneously.

Hubble currently has six small satellites in orbit. These are approximately 20kg CubeSats—about the size of a shoebox before deployment—with phased arrays that unfold to around two meters across. A satellite is overhead for roughly three minutes, and the current six-satellite constellation provides at least one transmission opportunity per day.

Right now, this is strictly a one-way affair: the Bluetooth device can transmit to the satellite (uplink), but the satellite cannot transmit back to the device (downlink). Ben says a downlink capability may be added in the not-so-distant future. Once a satellite has received a packet, it stores the data until it passes over a ground station, whereupon the packet makes its way through Hubble’s servers to the customer. The data is end-to-end encrypted, so even the folks at Hubble cannot see what’s inside.

This isn’t merely a science experiment. Hubble says commercial service is available in North America today, with limited-availability customers already being onboarded. Ben told me they have “quite a few customers” and are already generating revenue.

Things are about to get even more interesting. Starting in 2027, Hubble plans to launch a series of much larger 500kg satellites whose phased arrays will contain more than 1,000 antennas and unfold to around nine meters across. These next-generation satellites are designed to hear devices transmitting at only +4dBm, compared with the +20dBm required today. The current plan is to grow the constellation to 60 satellites by 2030, reducing the wait between transmission opportunities from hours to around 20 minutes.

This means that a humble Bluetooth chip costing pocket change could eventually provide both conventional local Bluetooth connectivity and global satellite connectivity, all without adding a satellite modem, a satellite antenna, or a second radio.

Of course, there is one elephant in the room and fly in the soup (I never metaphor I didn’t like). We are already awash in a sea of electromagnetic radiation, and it appears the waves are getting higher and coming at us from ever more directions, but what can we do?

Well, for one thing, we can pity those poor fools who succumbed to the lure of the original DIY Aluminum Foil Deflector Beanies (AFDBs), which are “so 20th century, my dear.” These days, thank goodness, we have access to professional EMF Radiation Protection Beanie Caps from the folks at Defender Shield, who claim their 100% silver-fiber inner lining blocks up to 99% of RF radiation from 300Hz to 40GHz from reaching your head.

I don’t know about you, but I’m thinking of adding one to my Christmas list. That way, should the chaps and chapesses ever add a Bluetooth downlink from space, at least my poor old noggin will be ready to repel boarders.

After reading Edmund Callis Berkeley’s “Giant Brains or Machines that Think” shortly after it appeared in 1949, Joe Weisbecker decided he wanted to design computers but he was forced to wait for the better part of two decades to design one, despite getting a job with RCA’s mainframe computer division in 1956. Weisbecker was so frustrated with RCA that he developed an 8-bit computer in his basement using parts purchased from local New Jersey Radio Shacks. He completed the computer’s construction during the summer of 1970 and by the fall was telling anyone at RCA who would listen that he’d designed and built a computer. 

Joe Weisbecker’s System 00, the ur-COSMAC, used a gravity-fed punched-card reader for program storage (shown on top of the System 00 cabinet) and is using Weisbecker’s Heathkit oscilloscope for a display. Image credit: Joyce Weisbecker

Weisbecker called the computer System 00 and reasoned that someone, perhaps RCA or perhaps some other company, would ask him to design a computer based on his proof of concept: System 00. Weisbecker’s ultimate goal was to implement a computer on an IC.

System 00 was Joe Weisbecker’s TTL implementation of his 8-bit processor architecture, which would become RCA’s COSMAC microprocessor. Image credit: Herb Johnson/retrotechnology.com

By the fall of 1970, the signs at RCA’s computer division were becoming clear. People in the division were either being moved from New Jersey to Marlborough, Massachusetts or they were simply leaving the company. In addition, no one was working on a successor to RCA’s latest computer, the Spectra 70. Weisbecker interpreted the mass exodus to Marlborough as an early indication that RCA was planning to sell its computer division, and he was correct. RCA would announce that it was leaving the computer business by selling its mainframe computer division to Sperry Rand in September 1971.

Joe Weisbecker developed the core architecture of RCA’s COSMAC microprocessor in his basement using parts purchased from local Radio Shack stores in New Jersey. Image credit: RCA Engineer

Another person who also noticed these signs was Gerald “Jerry” Herzog, a 20-year veteran at RCA and Director of RCA’s Solid State Technology Center in Somerville, New Jersey – part of RCA Laboratories. Herzog had spearheaded CMOS development under a US Air Force contract and was responsible for proposing that RCA create a commercial product line of CMOS ICs – the CD4000 series. By 1970, half of the semiconductors made by RCA were going into RCA’s mainframe computers, so Herzog foresaw a huge problem looming in his future if RCA exited the computer business.

Herzog had heard about the System 00 computer and telephoned Weisbecker. During an interview, Joyce Weisbecker recounted the way her father described that phone call:

“My father came home and said, ‘I got a great call from Jerry Hertzog today. It turns out that he’s a physicist, and he’s been working at RCA on transistors since the transistor was new. And his goal was to figure out how to put an entire computer on a single semiconductor and was hoping to do that before he retired…

“And so, Hertzog was getting worried about it, so he called me up and he said, yeah, he’d be really interested in [my System 00 computer]. But he doesn’t think RCA will green light anything to do with computers since they’re in the process of getting out of it. And I said, ‘Yeah, that is going to be a problem.’ And Jerry said, ‘Well, but I really want to do it. Do you think you can do it in CMOS?’

“And Dad says, ‘Oh, it’s all TTL. I don’t see why not. It’s meant to be put on a chip. You know, there’s nothing in it that won’t go on an integrated circuit.’ And Hertzog says, ‘Yeah, OK. You know, RCA management’s really happy with how we’re doing these custom printed circuit boards for control, for original equipment manufacturers. That’s a very lucrative business, and they want us to expand it. So, I’m thinking maybe we could tell them that this is a way of using semiconductors to improve turnaround time and profit margins in that business, that it’s going to be two semiconductors, one standard, so we can get the volume up, and one custom in small volume for each customer.’ Dad said that wouldn’t be lying about what we’re doing, and yeah, that sounds good.

“So that was their cover story. When he came home, Dad told [us] that story and he said, ‘OK, if anybody in the family is talking to anyone from RCA, if they call the house, if you see them at the grocery store, you say we’re working on a two-chip semiconductor replacement for custom printed circuit boards for control of equipment. We’re not working on… don’t even mention computers, OK?’

“And my mother, bless her heart, the schoolteacher, who’s not really into this technology, she says, ‘But aren’t they going to realize that you’re talking about a computer and a memory?’ 

“I think, ‘Way to go, Mom. You’ve been paying attention.’

“And my father says, ‘No, because everyone in the computer division at RCA thinks of computers as rooms full of equipment with lots of things attached to them. And they can’t imagine them ever being small.’ And then he paused and said, ‘And anyway, they’ve been moving everyone up to Marlborough, Massachusetts from the computer division, so anyone who worked with computers and may have known that computers could get really small is either in Marlborough, Massachusetts or has left the company looking for another job. So, there’s nobody left.’”

This subterfuge lasted only a few weeks, as Joyce Weisbecker explained:

“And the great thing is, that is such a great story, that to this day, people think that lasted a long time. But two or three weeks later, my father comes home and says, ‘I just got a really great call from Jerry Hertzog again. He called just before lunch. He said he just got out of a meeting. And it was, you know, a standard status report on something. And [Herzog] says, ‘And at the end, one of the RCA managers points to a piece of paper and says, can we do something like that? I look at it, and it’s a computer on a chip. And I say—Joe, you’d be proud of me—I put on my best poker face and I said, ‘Well, yeah, I guess we could. The guys in the labs are working on something that we might turn into something like that, if you wanted to fund it and you want me to put more people on it. And the end result is, we are now officially working on a microprocessor and the great thing is I don’t even think they realize they asked for a microprocessor. They just asked for a chip like that… I don’t even think they realize they’ve authorized a computer on a chip. But they don’t have to know…

Joyce Weisbecker concluded this part of the story by saying, “So yeah, for two or three weeks they were undercover. But it’s such a great story that people love to tell it like it lasted forever.”

Those conversations between Herzog and Joe Weisbecker took place around Thanksgiving in 1970. Joe Weisbecker transferred to RCA Laboratories in January 1971 and started to develop a CMOS microprocessor based on his System 00 computer design. Herzog assigned some of his IC design people to work with Joe Weisbecker to implement the System 00 in CMOS, and that was the beginning of RCA’s COSMAC microprocessor development.

The IC design project first resulted in a two-chip microprocessor, the 1801, because RCA’s 10-micron, metal-gate CMOS technology could not fit the entire design on one chip. The 1801 chip designs were completed in 1971 by Norm Swales at RCA’s Palm Beach Gardens Division, and prototype chips were being sampled internally by 1972, but RCA wouldn’t announce commercial availability of the two-chip 1801 microprocessor until 1975.

Norm Swales of RCA’s Palm Beach Gardens Division in Florida laid out the original two-chip 1801 microprocessor in 1971. He’s holding the completed pair of chips in his right hand and the much larger 1801 breadboard in his left hand. Image credit: RCA Engineer magazine

These two-chip 1801 samples (internally called the TC 1084 and TC 1085) were then used to build somewhat expanded versions of Weisbecker’s System 00. They’re called FRED systems, an acronym developed by Joe Weisbecker to describe the computer systems based on his processor design including the original System 00. “FRED” stands for “Flexible Recreational Educational Device.” Over time, many FRED systems are built. These systems evolved over time, so there’s a FRED, a FRED 1.5, a FRED 2, a FRED II, etc. RCA engineers used these early FRED systems to develop software for the COSMAC microprocessor.

RCA expected that advancing CMOS manufacturing technology would eventually allow the two-chip 1801 microprocessor to be made as a single-chip device. That was the plan from day one. The needed semiconductor design advances came quickly in the form of a new CMOS topology called Closed COS/MOS Logic (C2L). (“COS/MOS” was RCA’s trade name for its brand of CMOS logic.) 

C2L made several modifications to RCA’s existing 10-micron, metal-gate CMOS layout and process techniques including the replacement of metal gates with polysilicon gates, a topology that surrounded the CMOS transistor’s drain with the polysilicon gate, and the replacement of doped guardbands around individual transistors with source planes that served multiple transistors. According to a short paper that RCA’s Andrew Dingwall and Roger Stricker presented at the 1976 IEDM (International Electron Device Meeting), C2L delivered 4x to 5x better packing CMOS density without a lithography shrink.

In addition to the C2L optimizations, Swales used a technique he called “bit-slice design” to further reduce the footprint of the COSMAC microprocessor. Joyce Weisbecker’s description makes this version of bit-slice design sound like macrocell optimization. Instead of wiring individual flip-flops, latches, and gates together with aluminum interconnect on the chip, Swales designed optimized one-bit-wide versions of large structures including the register file and ALU, and then concatenated the macrocells to create the full structures with the desired bit width. This approach further reduced the amount of real estate by optimizing the structures’ transistor and interconnect layouts.

As a result of these advances, RCA shrank the real estate requirements of the COSMAC architecture from the 1801’s 120,000 square mils spread across two chips to 40,000 square mils consumed by the single-chip 1802. That’s a 3x reduction in silicon real estate. At the same time, RCA’s chip designers were able to add 10 or 15 percent more functions to the 1802’s implementation. Norm Swales laid out the 1802 using C2L. Samples of the 1802 were available internally by 1975, and RCA announced the chip in February 1976.

The RCA 1802 single-chip microprocessor chip photo. IEEE Spectrum put the CDP1802 in its Chip Hall of Fame in 2018. Image credit: Paul Rautakorpi/Wikipedia 

Joe Weisbecker was now ready to realize his true ambition: getting his microprocessor into the hands of hobbyists, students, and small business entrepreneurs. To that end, he left further development of the COSMAC microprocessor and related ICs to the chip designers and turned his attention to developing the software and development kits needed to popularize the microprocessor’s architecture.

About 4,500 years ago (give or take), the ancient Egyptians took it upon themselves to stack approximately 2.3 million enormous blocks of stone to create what we now know as the Great Pyramid of Giza. I’m trying to imagine the scene when Hemiunu, who is generally credited as its chief architect, first explained his plans to Pharaoh Khufu, who probably responded, “You want to do what?”

Of course, as established in the 1572 publication Octo Mundi Miracula (unfortunately, I seem to have mislaid my copy), the Great Pyramid became known as one of the Seven Wonders of the Ancient World. Indeed, it remained the tallest human-made structure on Earth for almost 4,000 years. As engineering achievements go, that’s a tough act to follow.

Fast-forward to the present day, and I’m happy to say that Egyptian engineers haven’t lost their taste for attempting things that make the rest of us raise an astonished eyebrow and unwittingly echo Pharaoh Khufu when we exclaim, “You want to do what?”

I was reminded of this recently when I found myself chatting with Moamen Mohamed, Founder and CEO of RFOXiA. Moamen is a radio frequency (RF) engineer who has spent years wandering the world designing embedded systems and RF hardware. His latest wheeze is deceptively simple to describe (but phenomenally difficult to achieve): pushing Bluetooth communication to distances of 50 kilometers and beyond.

Yes. You read that correctly. Bluetooth. Fifty kilometers. I’ll give you a moment to retrieve your eyebrows from the ceiling.

Let’s start by reminding ourselves that Bluetooth began in the mid-1990s, when engineers at Ericsson in Sweden were tasked with developing a low-cost, low-power, short-range radio technology to replace the cables connecting mobile phones, computers, headsets, and other devices. The operative words here are “short range.”

As we now know, Bluetooth became phenomenally successful, and the subsequent explosion of the Internet of Things (IoT)—coupled with our seemingly insatiable desire to connect everything to everything else—propelled it into billions of devices around us. It connects our phones to our earbuds, watches, cars, keyboards, mice, speakers, medical devices, sensors, and a cornucopia of other cunning contraptions. 

Most of the time, Bluetooth performs its magic so unobtrusively that we barely give it a second thought (or even a first thought, come to that). But it has always come with an implicit assumption: it’s for things that are relatively close together. If you venture beyond a few tens of meters, the link typically drops. In other words, Bluetooth stops at the garden fence.

Suppose you wish to transmit sensor data over longer distances? Well, you could switch to LoRa, which can give you kilometers of range, but the bandwidth is low and the data rates are sloooooow.  Or you could lean on Wi-Fi or cellular communications, which work well until you stray beyond their coverage map—and, of course, both require supporting infrastructure.

That’s why the idea of dramatically boosting Bluetooth’s range is so enticing. Imagine using it not just to communicate with nearby devices, but to exchange sensor data and text messages—or even make voice calls—over distances measured in kilometers rather than meters.

There’s an old idea that some things get accomplished only because nobody told the person doing them that they couldn’t be done. I’m beginning to suspect that Moamen may be one of those people.

He graduated from university in Alexandria, Egypt, in 2016, then traveled to Bangalore, India, to master advanced embedded system design. From there, he moved to China, where he spent three years learning how electronic products are actually manufactured.

After China, Moamen devoted another three or four years to working with a design house on a variety of projects. Along the way, he also spent time collaborating with experienced RF engineers in Austria and Germany, further adding to the eclectic collection of skills and experiences he was accumulating.

The result is an unusual combination of RF expertise, embedded-system knowledge, and hands-on manufacturing experience. It also left Moamen with a tendency to approach problems from unexpected angles.

Moamen has what I would describe as a classic maker mentality. When he creates something useful, his next thought isn’t simply, “That’s handy.” It’s more like, “How can I put this into everyone else’s hands?”

One issue that particularly bothered Moamen was that of wireless control. If you’re building a robot, rover, drone, or remote sensor system, it doesn’t matter how clever the thing is if you can’t communicate with it. Moamen wanted something that could operate over long distances using unlicensed spectrum, thereby making it accessible to makers and developers around the world. He experimented with several technologies, but kept coming back to Bluetooth. 

There are two obvious ways of communicating with someone who’s a long way away. You can shout louder, or you can listen better. The RFOXiA module does a bit of both. At the heart of this module is a stock STM32WB07 wireless microcontroller from STMicroelectronics. This microcontroller’s Bluetooth Low Energy (BLE) radio supports the LE Coded PHY and can detect extraordinarily weak signals.

The RFOXiA module and antenna (Source: RFOXiA)

Around this, Moamen and his team created their own RF front end. On the transmit side, a power amplifier increases the available RF output. On the receive side, a low-noise amplifier (LNA) helps extract extremely weak signals from the noise. Add carefully designed impedance matching and a high-gain omnidirectional antenna, and our humble Bluetooth link suddenly has a rather impressive pair of ears.

There’s another trick up its sleeve. Bluetooth LE’s Coded PHY was created specifically to trade data rate for increased range and robustness. In the most robust S=8 mode used by RFOXiA, the radio continues transmitting at one million symbols per second, but forward-error correction and pattern mapping result in eight transmitted symbols for each input data bit.

The upshot is a data rate of 125kbps. That’s obviously not something you’d choose for streaming 4K video, but it’s more than enough for sensor telemetry, commands, text messages, and—according to RFOXiA’s plans—voice communications.

One way to think about all of this is to imagine two people trying to communicate across a large field. Instead of screaming themselves hoarse, they speak slowly and deliberately, adding enough redundancy that the listener can reconstruct portions of the message that might otherwise have been lost along the way.

So, how does all this actually work in the real world? Well, your smartphone already supports Bluetooth, but it doesn’t contain RFOXiA’s power amplifier, low-noise amplifier, antenna, or custom firmware. Happily, Moamen isn’t expecting us to crack open our expensive phones with a screwdriver and solder additional RF circuitry into them (which is a relief).

Instead, imagine two people several kilometers apart, each equipped with a smartphone and a RFOXiA module. Each phone communicates with its nearby RFOXiA module using ordinary Bluetooth. The two RFOXiA modules communicate with each other using the long-range Coded PHY.

Source: (Me and ChatGPT)

Like most things, this sounds simple if you say it quickly and gesticulate furiously. Unfortunately, Bluetooth wasn’t originally designed with the expectation that two devices might be several kilometers apart. Moamen discovered, for example, that the modules could initially establish a conventional connection at relatively short range and subsequently switch to the S=8 Coded PHY to travel much farther. If that connection were lost at long range, however, standard stack behavior could prevent them from reconnecting until they were brought much closer together again.

The RFOXiA team therefore added its own layer into the Bluetooth stack to allow the modules to connect and reconnect directly using the long-range Coded PHY. At the same time, each module needs to maintain its ordinary Bluetooth relationship with its local phone. As the guys and gals at RFOXiA describe it, their custom dual-role stack allows one radio to maintain “two conversations at once.”

So, after all this RF and firmware jiggery-pokery, how far can the resulting Bluetooth connection actually reach? The answer—so far—is 4.6km (2.86 miles) in a measured ground-to-ground test. 

What? You want to know the test conditions? Well, one module was mounted on an antenna mast, while another was attached to Moamen’s car. He then drove away, monitoring the distance and connection status in the RFOXiA app as he went, and the Bluetooth link remained operational out to a distance of 4.6km. I don’t know about you, but that’s my kind of empirical testing.

But wait… there’s more… Ground-level radio links suffer from reflections and other terrain-related effects. Raise one end of the link into the air on a drone, for example, and the RFOXiA team anticipates a range of more than 20km. Put both ends in the air—drone to drone, for example—and the company’s design target rises to more than 50km.

Let me stress that these latter two numbers are design targets, not measured results, but the fact that they’ve already demonstrated 4.6km ground-to-ground using Bluetooth is sufficient to make my eyebrows migrate northwards.

The potential applications for this sort of technology are limited only by our imaginations. Suppose you have a large farm with sensors scattered around the property, for example. One might be monitoring temperature and humidity. Another might be checking air quality. Others might be attached to pumps, gates, livestock feeders, robots, or agricultural drones. Traditionally, you’d have to start thinking about Wi-Fi coverage, cellular subscriptions, LoRa networks, or some other form of communications infrastructure.

By comparison, RFOXiA’s goal is for you to scatter its modules around your domain and have them communicate directly without relying on the internet or cellular infrastructure. The company already has a small 7-in-1 sensor module offering temperature, humidity, air pressure, air quality, accelerometer, gyroscope, and magnetometer capabilities. There’s also a GNSS module supporting GPS, Galileo, GLONASS, and BeiDou.

Adding GNSS and 7-in-1 sensor modules (Source: RFOXiA)

Then there’s the RFOXiA Connect app. In addition to displaying live sensor and location data, the app provides a virtual controller that can send commands to the remote systems. 

The RFOXiA Connect app for iOS and Android (Source: RFOXiA)

There’s even a chat facility. Give another module’s MAC address a friendly name (“Max the Magnificent,” for example), and it can appear rather like a contact in a conventional messaging application. Two people equipped with phones and RFOXiA modules can then exchange text messages over kilometers without requiring cellular service or internet access. Voice communications are planned for a forthcoming update.

I can imagine this being particularly interesting in remote locations, disaster situations, large industrial sites, farms, forests, and anywhere else conventional communications infrastructure is unavailable, unreliable, or simply undesirable.

Welcome to the Club

RFOXiA isn’t intended to be simply a clever hardware module. Moamen and his team are building an ecosystem around it, and you can find part of this ecosystem in the RFOXiA Club.

One element of the Club is called My Console. Once you’ve deployed multiple RFOXiA nodes, My Console provides a browser-based environment where you can view, monitor, and record live data from those nodes. Each RFOXiA module has its own MAC address, and sessions can be linked to the user’s account for later review.

Another intriguing element is AI Develop. Since RFOXiA’s firmware is open source and well documented, the idea is to give an AI coding system access to that information and let users describe what they want in everyday language.

Suppose you want several remote sensor nodes to report to a central RFOXiA-equipped gateway, which will subsequently forward the information to the internet over Wi-Fi or Ethernet. Rather than starting with a blank screen and several thousand lines of unfamiliar firmware, the idea is that AI Develop can use RFOXiA’s existing codebase as its starting point and customize it for your application. 

The RFOXiA Club is also intended to give makers and commercial developers access to beta releases and a route to request customized hardware and software. In other words, the guys and gals at RFOXiA don’t want to simply hand us an RF module and cheerfully wave goodbye as we disappear into the firmware forest. Instead, they want to provide the hardware, firmware, software, development tools, and supporting infrastructure needed to turn our ideas into working systems.

This last point is important. Remember that Moamen is a maker at heart. The RFOXiA firmware is open source, and the company is currently sending modules to makerspaces and universities around the world to gather independent experience and feedback. 

Moamen told me that units are heading as far afield as Japan and South Korea because he knows perfectly well what many engineers will say when first confronted with the claim that Bluetooth can work over several kilometers: “That’s impossible.” Rather than wasting time arguing with them, he wants people to try it for themselves. Now, that’s what I call “putting your money where your module is.”

If all of this has whetted your appetite to experiment, RFOXiA is available as a modular development platform designed to work out of the box. Pair a module with the RFOXiA Connect app on your phone, add a second module at the other end of the link, and you can start experimenting without first needing to fight with firmware. From there, you can add the GNSS and 7-in-1 sensor modules, dive into the open-source firmware, and generally start causing trouble of the most enjoyable kind.

As for that 50+km design target? Well, I’m certainly not going to tell Moamen it can’t be done. After all, we’ve already established what happens when you say to Egyptian engineers, “You want to do what?”

Imagine your father is a vet in a rural area. (If only I had a coconut for every time someone has said that to me… I wouldn’t have many coconuts… but that’s not important right now.) Also assume your father is essentially a one-man show. Unlike James Alfred Wight and Donald Sinclair (better known as James Herriot and Siegfried Farnon in All Creatures Great and Small), your family doesn’t live at the veterinary clinic, which means your dad isn’t available to answer his business phone 24/7/365.

The answer in the early days would be to have an answering machine in the form of a physical device connected to the telephone line at the clinic. A typical cassette-tape machine would answer after a selectable number of rings, play your recorded outgoing message, record perhaps 10 to 30 minutes of incoming messages, timestamp them, and let you play, skip, repeat, or delete them. Eventually, voicemail replaced answering machines; this does essentially the same job, but the recording happens elsewhere in the telephone company’s or service provider’s system. 

The problem is that both answering machine and voicemail technologies are “as thick as a brick” when it comes to holding an intelligent conversation. (I’m sure you, like me, are now thinking of Thick as a Brick, which was the fifth studio album by Jethro Tull, but stand strong, my brave ones, because we simply cannot allow ourselves to watch this video and be distracted this early in the column.)

I can only imagine the numbers and types of messages old-time vets may have found waiting for them each morning. Maybe something along the lines of, “Polly’s sitting on the bottom of her cage, she won’t eat anything, and she’s making a funny wheezing noise. Please call me as soon as you can!” Unfortunately, the recording doesn’t mention the owner’s name or telephone number.

An answering machine or voicemail will happily record such tales of avian woe without saying, “Hang on a minute. Who are you, and how can we reach you?” Even when callers do remember to leave their contact details, other useful information may be conspicuous by its absence. What sort of animal is involved? How old is it? What symptoms is it displaying? How long has this been going on? Has it eaten something it shouldn’t? Is this an emergency, or can it wait until morning?

Then there are messages from people so agitated they gabble their telephone number at warp speed, mumble their name, call from somewhere with a cacophony of background noise, or leave a five-minute stream-of-consciousness account in which any crucial nuggets of information are buried somewhere in the middle.

All the technologies of yesteryear could do was sit there, silently accepting whatever they were given. They couldn’t interrupt, clarify, reassure, triage, or ask any obvious follow-up questions. When you think about it, this is precisely the sort of situation in which a little artificial intelligence could go a long way.

Sometimes a little AI can go a long way (Source: Me and ChatGPT)

The reason I’m waffling on about this (yes, of course there’s a reason) is that I was just chatting with Will Bodewes, co-founder and CEO of Phonely. Will grew up in Hazelhurst, Wisconsin, a town so small that his immediate family represented roughly 1% of its population. Will’s dad was a vet (I know, what are the odds?) who lost who-knows-how-much business because of the inadequate message-taking technology available to him at the time. This helps explain why Will and his co-founder created an AI voice assistant that far surpasses anything else currently on the market.

Perhaps surprisingly to those of us who instinctively associate cutting-edge AI with Silicon Valley in America or Silicon Roundabout in England, Australia boasts a strong pedigree in AI research. The University of Melbourne, in particular, has been playing with computers for longer than most of us have been playing with anything. In 1955, it established its Computation Laboratory as a separate department, making it one of the earliest university computing departments in the world.

Fast-forward 70 years and that pedigree is still very much in evidence. In the 2026 QS World University Rankings by Subject, Melbourne ranked #1 in Australia and #31 in the world for Data Science and Artificial Intelligence. Today, its researchers are beavering away on everything from deep learning, machine learning, and natural-language processing to agent-based systems, autonomous AI, and AI assurance.

All of which means that Will found himself planted in fertile ground. While pursuing a PhD in AI research at the University of Melbourne, he was studying a problem that would become central to Phonely: how to make AI systems follow complex instructions accurately while still communicating naturally. The goal was an AI that could “follow instructions like a robot and talk like a person.”

Will and his co-founder, Nisal Ranasinghe, who was also a PhD student at the University of Melbourne and is now CTO at Phonely, founded the company about three years ago. Initially, their goal was relatively straightforward: create an AI that could talk like a person. As is so often the case, however, the closer they looked at the problem, the more interesting it became.

Consider latency, for example. We humans are remarkably sensitive to delays in conversation. Even a fraction of a second can lead to awkward exchanges where both parties start talking at once, stop, start again, and end up wanting to throw their telephones out of the window.

The obvious solution would have been to base Phonely on one of the mainstream LLMs. Indeed, they tried this to no avail. Will says that their early attempts didn’t work because the big general-purpose LLMs were becoming increasingly focused on agentic applications, while the problems that mattered most to Phonely were accuracy, reliability, and speed. Latency is particularly important. If you send a request to somebody else’s LLM, you have no control over its queue. Your request might be first in line or fiftieth. 

Thus, about a year ago, the guys and gals at Phonely started building and training their own LLMs. By controlling its own model and compute resources, Phonely can largely eliminate any uncertainty. Will says its LLM currently boasts an average response latency of around 120 milliseconds, compared with the 400 to 500 milliseconds—or more—they were seeing with mainstream alternatives.

Another cunning aspect of Phonely’s approach is that it doesn’t simply toss an LLM at a telephone call and hope for the best. One model (the response model) handles the conversation, while another coaches and guides it through whatever process needs to be performed.

Suppose we return to our poor poorly parrot. A veterinary clinic might require the AI to collect the caller’s name and telephone number, the animal’s species and age, its symptoms, and how long those symptoms have persisted. Phonely’s AI can ensure it gathers the required information while still letting the conversation wander naturally. And if something sounds sufficiently serious, the system can be configured to escalate the call to a real person.

Furthermore, Phonely doesn’t require its customers to sit down and anticipate every possible conversational twist and turn. Existing call recordings already contain a wealth of information about what customers ask, how human representatives respond, and how conversations progress. Phonely can use these recordings to help map the workflows its voice agents will subsequently follow.

And these agents aren’t limited to chatting. They can interact with external systems using conventional application programming interfaces (APIs) or the increasingly ubiquitous Model Context Protocol (MCP). So, beyond answering questions and gathering information, an agent might schedule an appointment or take other actions on the caller’s behalf.

The result appears to be resonating with the market. Phonely now serves more than 10,000 businesses and handles more than 120,000 calls a day. Will says customers replacing traditional outsourced contact-center services typically see cost savings of around 70%.

But perhaps the most interesting part is where Phonely is heading next. Will compares the company’s evolving role in voice AI to what Shopify did for ecommerce. Rather than simply providing an AI that can hold a convincing conversation, Phonely can analyze those conversations, determine what works and what doesn’t, and help optimize future calls to achieve the outcomes the business actually cares about.

In other words, answering the telephone is only the beginning…

RCA announced the world’s first CMOS microprocessor, the 8-bit CDP1801, in early 1975 and the first single-chip CMOS microprocessor, the CDP1802, in February 1976. Fifty years later, the CDP1802 is still available, still in production, and has been used as the core of many embedded designs including a few spacecraft. Both the CDP1801 and CDP1802 are implementations of the same processor architecture, dubbed COSMAC, which was the product of one person’s vision: Joe Weisbecker. The story of COSMAC’s design and development is one of dogged determination. Weisbecker knew that he wanted to design computers from an early age, and he tailored his education and his career with that one aim firmly in mind. Despite the significant impact that the COSMAC architecture, the CDP1801, and the CDP1802 have had on the electronics industry, their development history is recorded piecemeal across dozens of books and Web sites. Weisbecker passed away in 1990, so assembling that history into a linear narrative is just that much harder. To get the full story, I interviewed Joe Weisbecker’s daughter Joyce, who has been involved in COSMAC’s development since before she became a teenager. This article series is based on a long interview with Joyce Weisbecker, the few articles Joe Weisbecker published during his career, and the mountain of research published by COSMAC enthusiasts around the world.

In his early teens, Joe Weisbecker had three hobbies: amateur magic, photography, and building Heathkits. All three required money. While Weisbecker loved the idea of magic tricks, and he loved visiting magic shops and perusing magic catalogs, he didn’t care much for promoting his performances to get paying gigs. He didn’t enjoy performing all that much either. Weisbecker just loved the idea of magic, and he enjoyed developing his own tricks.

As an amateur photographer, Weisbecker really wanted an enlarger, which was a substantial purchase for a teenager. To earn money towards the cost of that enlarger, Weisbecker went out to the local farms in southern New Jersey and picked beans for 50 cents per bushel. It didn’t take him long to realize that manual labor was a painfully slow way to earn money. It involved spending long hours in the hot sun doing backbreaking work. Weisbecker soon realized that the time needed to earn enough money to buy an enlarger at 50 cents per bushel of picked beans would leave no time for any of his hobbies.

By assembling Heathkits and studying the schematics, Weisbecker realized that circuit design was its own form of magic, and a career in electronics would pay far better than performing as a magician or picking beans. He realized he’d need to improve his grades if he wanted to go to a good engineering school, but couldn’t afford MIT’s tuition nor the cost of living at school away from home, so he decided to get his degree from Drexel University in nearby Philadelphia.

In 1949, mathematician and actuary Edmund Callis Berkeley published a book titled “Giant Brains or Machines that Think.” It was the first popular book to be published about electronic computers, and Weisbecker read it shortly after it went on sale. The book refined his  engineering career plans. By the age of 19 or 20, he knew that he wanted to devote his life to computer design.

Berkeley’s book taught Weisbecker that computers were nothing more than switches and wires implementing a switching sequence according to precise timing. He decided to build a small computer-like switching system but couldn’t think of an appropriate project until he saw a Tic-Tac-Toe machine in operation at the Franklin Science Museum in Philadelphia. He immediately set out to replicate the machine using relays, lights, and wires.

A Tic-Tac-Toe machine isn’t a computer, it’s a finite state machine with 5478 legal states. It can be built with any type of switch including relays, tubes, transistors, integrated circuits, or even Lego blocks. Building one of these machines from scratch establishes that the builder has grasped switching and Boolean logic fundamentals. According to Joyce Weisbecker, her father built his Tic-Tac-Toe machine in 1952 or 1953. Other accounts say the year was 1951, when Joe Weisbecker would have been 19 years old. In any case, he built the machine shortly after reading Berkeley’s book. At this point, Weisbecker was clearly on his way to becoming a computer designer.

Weisbecker’s next step towards his career goal was to start working for RCA’s computer group. RCA facilities were scattered nearby and throughout New Jersey, and it was one of seven companies competing against IBM in the mainframe computer business. The other competitors were Burroughs, UNIVAC (Sperry Rand), NCR (National Cash Register), CDC (Control Data Corporation), Honeywell, and GE (General Electric – collectively known as IBM and the Seven Dwarfs because IBM dominated the business with about 65 percent of the market. Weisbecker targeted RCA not because it was the biggest mainframe vendor but because it had a huge local presence in New Jersey and because Drexel’s coop program had RCA connections.

In fact, RCA had listed a co-op position to work on the company’s new Bizmac mainframe, so Weisbecker went into Drexel’s co-op office and applied for a job. He failed to be specific about the job he wanted, however, and he left with a co-op position that involved redrawing wiring diagrams at a manufacturer of soft ice cream machines because he’d taken a drafting class. After consulting with a couple of his professors, Weisbecker went back to the co-op office the next school year and specifically asked for a job with RCA in Camden, New Jersey. From that point on, from 1953 to 1956, Weisbecker worked during the summers on the RCA Bizmac mainframe project. When he graduated from Drexel in 1956, RCA offered him a permanent position on the Bizmac project. He started working at RCA in June 1956.

Six months later, Weisbecker went to Detroit to help install a $4.5 million Bizmac computer for the U.S. Army Ordnance Tank-Automotive Command. Weisbecker’s job as a new hire was to keep the machine running. The Bizmac installation was a behemoth, consuming more than 20,000 square feet of floor space and weighing more than 13 tons. The computer incorporated 30,000 vacuum tubes, 70,000 semiconductor diodes, and 30,000 magnetic cores. It consumed more than three quarters of a Megawatt of electricity. Two thirds of that energy budget was used for cooling the machine.

RCA’s first Bizmac mainframe computer consumed more than 20,000 square feet of floor space and weighed more than 13 tons. The computer incorporated 30,000 vacuum tubes, 70,000 semiconductor diodes, and 30,000 magnetic cores. Image credit: Wikipedia

Paradoxically, Weisbecker viewed the brand new Bizmac mainframe as a dinosaur. He knew that computers were nothing more than switches and interconnect and that the size of the switches would shrink as engineers and device physicists devised smaller and smaller switches. Miniaturized switches would alter the way computers were architected and would result in vastly different interconnect schemes. Without knowing it, Weisbecker’s projections reflected the miniaturization that would sweep the computer industry once integrated circuits were invented in 1959. Weisbecker was already preparing for that revolution in 1956.

RCA sold around six Bizmacs, and Weisbecker worked on RCA’s succeeding computer generations: the transistorized model 501 introduced in 1959, the model 301 announced in 1960, and the Spectra 70 introduced in 1965. Although he participated in the design of all these computers, Weisbecker wasn’t happy with his assigned tasks on these projects. He told his daughter, “Yeah, well, as close as I got to design a computer, they let me design the console for the Spectra 70.” By 1963, Weisbecker got itchy feet, and his desire to be more involved with computer design drove him to join a startup company founded by two RCA co-workers. Their plan was to develop store-and-forward systems for cable and voice traffic using leased RCA Spectra 70 systems. These systems would allow companies to take advantage of lower trans-Atlantic telephone rates during the evening. Three years later, the founders sold the company, and the new owner moved the operation from south New Jersey to New York. Weisbecker didn’t fancy the commute to New York, so he went back to RCA with his hat in his hand.

Instead of being rebuffed as he expected, Weisbecker was welcomed warmly. It seems two of the patents he’d filed for RCA shortly before leaving in 1963 were paying the company handsomely. He told his family, “… so I wound up negotiating that I would have exactly my same job back at the exact same pay I’d left with, no interruption in the pension plan, and that I was allowed to keep all my intellectual property that had to do with toys and games. And RCA only had a right to anything that was computer related.”

The mention of toys and games introduces Weisbecker’s side gig. He liked to develop toys, books, and puzzles based on computer concepts. One such toy, eventually called “Think A Dot,” was based on a plastic assembly that implemented eight mechanical flip-flops. It was manufactured by E.S.R. Inc and sold half a million units. Another of Weisbecker’s developments was a pre-programmed paper book that could play Tic-Tac-Toe against you.

Joe Weisbecker’s Think a Dot game was based on eight mechanical flip-flops. It taught computer fundamentals to kids. Image credit: The Sarnoff Collection, the College of New Jersey

By 1970, Weisbecker felt strongly compelled to design a computer, and if RCA wouldn’t let him design computers at work, then he opted for designing and building one in his basement. Of course, it had to be sized appropriately to fit in the basement. It wouldn’t be a mainframe. It would be a much smaller machine. Weisbecker started designing his small computer in 1968.

One Saturday in 1970, he emerged from the basement to ask his daughters Joyce and Jean, “Hey, either of you girls wanna come with me while I go make the rounds of Radio Shack?”

Joyce Weisbecker recalls their response:

“Sure, [we said,] because we get to talk to Dad while we’re in the car. And we’re making the rounds of Radio Shack because he’s making an 8-bit computer with the control panel that has the debugging, all the debugging things you need, the little indicator lights and lots of switches that had manual modes and things. You know, a front panel control and simulated I/O for it.

Joe Weisbecker (on the right) with his daughters Joyce (in the center) and Jean (on the left) circa 1962. Image credit: Joyce Weisbecker

“So he needs sets of eight and sometimes sets of 16 or 24 on/off switches and indicator lights. And it’s Radio Shack. If you want to order it, you can get anything you want. But if you want to go in and actually pick it up on a weekend, you’re lucky to find two or three in a store. 

“Fortunately, we live in what my father used to refer to as RCA County, because there were so many divisions of RCA between Somerville about 50 miles north of Philadelphia, down to Deptford, which is about 10 miles South of Philadelphia. That whole corridor has nothing but [RCA] employees, which means lots of Radio Shack franchisees who are really interested in electronics, many of whom used to work for RCA.

“And [he’s] not just [buying] the TTL. He’s also buying the switches, and the little lights, and everything. He’s trying to find sets of things. It is an all-day project, not because there are so many Radio Shacks and they’re so distant. It’s because you cannot simply ask, ‘Do you have eight of these?’ of a guy who works at Radio Shack without them saying, ‘What do you need eight for?’ 

“And of course, Dad may be looking for a company to hire him to do computer design, so he wants to tell them, ‘I’m designing an 8-bit computer.’ Because you never know, if RCA doesn’t pick it up, you’re gonna want the word out there. So, you then have to stand there and talk to somebody about 8-bit computers, and he’s really interested in computers. And you know, what’s it gonna take to do that? And so yes, it’s like 45 minutes to an hour at each Radio Shack as you satisfy the curiosity of the guy [behind the counter] at the Radio Shack.”

It’s 1970. Joyce is 12 years old, and Jean is 10. Intel won’t announce the 4-bit 4004, the world’s first commercial microprocessor, for another year. Meanwhile, Joe Weisbecker is prototyping an 8-bit microprocessor in his basement using MSI and SSI TTL parts bought from various New Jersey Radio Shacks. He doesn’t yet know that his architecture will become a microprocessor. For now, it’s just a small computer.

Next week: The birth of COSMAC

I don’t know about you, but I’m starting to feel like I need to run twice as fast just to keep up with everything that’s happening in AI space (where no one can hear you scream). No sooner do I wrap my brain around one concept than someone ambles into my life and introduces me to something else I didn’t even know I didn’t know.

A case in point is something called an AI agent harness (aka AI harness, agent harness, agentic harness…). Do you know what this is? I didn’t use to. Now I know more than I ever wanted to (sob sob). 

I first encountered this term when I received an email from the folks representing Innostax, a software engineering company founded by Prashanth Tondapu. The email suggested that, as increasingly capable AI models become more readily available, the competitive advantage may be shifting away from simply choosing the “best” model and toward the engineering infrastructure surrounding it.

I was intrigued, so I set up a video chat with Prashanth to discover more. Prashanth explained that Innostax has been developing custom software, including web and mobile applications, for more than a decade. When generative AI first became seriously useful for software development, Prashanth and his team began experimenting with it.

Like everyone else, they were initially blown away. You could ask an AI to create code for you and, seconds later, an enormous amount of it would appear before your very eyes (“Tra-la!”). Unfortunately, some of this code was what we now affectionately refer to as “AI slop.” It looked impressive at first glance, but lurking beneath the surface could be poor structure, unnecessary complexity, bugs, security vulnerabilities, and results that bore only a passing acquaintance with what you thought you’d asked for.

Even worse, when something went wrong, working out what the AI had actually done could take dramatically longer than generating the code in the first place. Prashanth recalls occasions when an AI could generate something in 15 minutes that subsequently took the humans three or four days to understand and untangle. I’m not an expert on the software side of things (I’m a hardware design engineer by trade), but this doesn’t seem like an ideal way to increase productivity.

The team’s initial solution was to restrict the AI’s context. Instead of saying something like, “Build me this website,” they might say, “Create this function, with these inputs, that generates these outputs.” And this worked. The smaller and more tightly defined the context, the more accurate and manageable the AI became. Prashanth says they were soon enjoying productivity improvements in the 30% to 40% range.

There was just one niggling problem. AI models were becoming extraordinarily powerful. Deliberately restricting them to tiny tasks was a little like buying a Batmobile and driving it everywhere at 20mph. You might keep yourself out of trouble, but you’re not really taking advantage of what the machine can do.

This is where AI harnesses enter our story. All analogies are suspect, and this one doubly so, but imagine you’re sitting atop an incredibly powerful animal capable of galloping like the wind. The last thing you want is to hobble the poor thing so it can barely move. On the other hand, allowing it to gallop wherever it fancies while you cling on for dear life isn’t an especially attractive proposition either. Adding a harness and reins allows you to exploit the beast’s capabilities while retaining control.

Returning from Analogy World (“We hope you enjoyed your stay”), an AI harness isn’t another AI model. Rather, it’s the engineering and orchestration layer surrounding the model. It determines what context the AI receives, which tools it can use, which databases and other resources it can access, what actions it’s permitted to perform, how its results are evaluated, what gets logged and monitored, and when a human needs to become involved.

Things get even more interesting when we start talking about agentic AI systems involving multiple agents and/or multiple models. In this case, the harness can determine which agents to invoke, which models they use, what context each agent receives, which tools each can access, and what each is allowed to do.

Suppose an AI agent is authorized to issue refunds to customers. Perhaps we’re perfectly happy to let it issue a $20 refund autonomously. A $20,000 refund, however, might cause us to raise a quizzical eyebrow (or two). The harness can encode the rules that say, in effect, “You can handle refunds up to this amount yourself, but anything larger requires approval from a human.” The important point is that we haven’t made the AI less capable. We’ve given it as much autonomy as we reasonably can while placing boundaries around that autonomy.

Since we had so much fun the first time, let’s take another trip to Analogy World and visualize an AI model as being analogous to a CPU. While a CPU may form the computational heart of a computer, nobody would point at a processor sitting forlornly on a bench and say, “Behold my computer!” We also need memory, storage, input/output, software, and all the other bits and pieces that turn our processor into a useful system.

The same is true with AI. The model provides the underlying intelligence or capability but isn’t the production system all on its own. The harness and infrastructure around the model turn that raw capability into something we can deploy and trust to do useful work.

This also changes one of the questions we’ve been asking about AI. For the past few years, we’ve been fascinated by questions like, “Which model is best?” and “Which model is most powerful?” Those questions aren’t going away. The underlying model obviously matters. But an increasingly important question is, “What are we building around the model?”

And this brings us to another part of the story: tokens. If you’ve been following AI for any length of time, you’ve undoubtedly heard people talking about tokens, but it’s worth making sure we’re all tapdancing to the same skirl of the bagpipes.

AI models don’t consume text in quite the same way we humans do. Instead, the input and output are broken into chunks called tokens. Depending on the model and the text involved, a token might represent a short word, part of a longer word, a punctuation mark, or something else. Tokens matter for multiple reasons, including cost. Commercial AI services commonly meter their usage by the number of tokens being consumed.

Now consider what happens during a long-running AI conversation or agentic task. For each new interaction, the AI may need its original instructions, relevant portions of previous conversations, retrieved documents, descriptions of the tools at its disposal, results returned by those tools, and other information. Before you know it, you’re shoveling enormous amounts of context into the model every time you ask it to do something.

Prashanth referred to the idea of token maxing: attempting to squeeze better results from the AI by throwing more and more context and tokens at it. The problem is that more isn’t necessarily better. If we give the model vast amounts of irrelevant or marginally relevant information, we’re paying to process all those tokens, potentially increasing response times, and possibly making it harder for the AI to focus on what actually matters.

Once again, a harness can help. Rather than blindly presenting everything to the model every time, the harness can determine what context is relevant to the task at hand, what to retain, what to discard, which tools to make available, and which information to retrieve only if and when it’s required.

This isn’t purely theoretical. A 2026 study called The Harness Effect examined six foundation models performing 22 enterprise tasks. The researchers held the models constant and changed the orchestration layer surrounding them. On this particular workload, an optimized harness reportedly used 38% fewer tokens, reduced the cost per task by 41%, and cut median completion time by 44%, while maintaining comparable task quality.

There’s another wrinkle to all of this (there always is). As AI becomes faster and increasingly autonomous, we humans risk becoming the bottleneck (I try my best, but there’s only so much I can do). We can already see this in software development. If an AI can generate or modify huge quantities of code faster than humans can meaningfully review it, simply saying, “Don’t worry, we’ll have a human check everything afterward,” won’t scale indefinitely.

The same applies to more autonomous AI systems. As agents start performing tasks that previously required humans, it becomes increasingly difficult for humans to inspect and approve every step. This doesn’t mean removing humans from the loop altogether, but it does mean deciding where humans need to be in the loop.

Some of the supervision needs to become part of the engineered system itself: permissions, automated evaluations, observability, approval thresholds, failure detection, rollback mechanisms, escalation paths, and clearly defined intervention points. Going back to our refund example, we don’t need a human to approve every $20 refund, but we very much might want one involved when the AI decides it wants to send someone $20,000.

So, what does Innostax actually do? I’m glad you asked. I was confused myself. By this point in my conversation with Prashanth, I thought I understood AI harnesses reasonably well, but I still wasn’t entirely sure how all this fitted into Innostax’s business.

“Do you sell harnesses?” I asked. His answer was more nuanced than a simple yes (it would be, wouldn’t it?). What follows is his response in a crunchy nutshell.

Innostax has historically been a software engineering company. Customers come to the company with business problems, and Innostax builds software systems to address those problems. Generative AI, agentic AI, and AI harnesses have become increasingly powerful tools in the company’s toolbox.

There’s no universal Innostax harness sitting on a shelf waiting to be purchased. Every business has different workflows, data, applications, permissions, risks, and requirements. An AI agent working for a bank is going to need a very different set of tools and controls from one working for a manufacturer, retailer, or software company. Innostax therefore designs and builds the appropriate systems around the AI according to the customer’s requirements.

Well, that seems simple enough, doesn’t it? But wait, there’s more! Just when I thought I’d finally got everything straight in my mind, Prashanth threw me another curveball when he dropped the fact that Innostax was also building Global Capability Centers (GCCs) for American companies into our conversation. I tried to be brave. “That’s good to hear,” I said. “What’s a Global Capability Center?”

Well, suppose you’re a US company that wants to establish a substantial engineering operation in India. The country has an enormous pool of highly trained technical talent, including software developers, data engineers, data scientists, and AI specialists. On the face of things, the solution sounds simple enough: “Hire a team in India.” Unfortunately, this is one of those occasions when there’s a large gulf between saying something and doing it.

If you’re establishing an operation in another country, you suddenly find yourself dealing with recruitment, employment law, payroll, taxation, compliance, corporate structures, management, training, retention, and goodness knows what else. Depending on how a company operates and employs people in another country, it can potentially create tax and regulatory obligations that weren’t necessarily obvious when someone first said, “Wouldn’t it be great if we had a team in India?”

And then there’s something that’s much harder to capture in a spreadsheet: culture. You don’t create a high-performance engineering organization simply by hiring a bunch of clever people on the other side of the planet and firing Jira tickets at them. The Indian team needs to become a genuine part of the customer’s organization. People need mentoring. They need technical leadership. Communication needs to work in both directions. Cultural differences need to be understood and bridged.

In turn, this brings us to something Innostax calls a Managed GCC. Imagine that you’re an American company and you decide you want a 20-person engineering team in India. One approach would be to establish your own operation there, recruit everyone yourself, deal with the local legal and regulatory requirements, build the management structure, and generally learn everything the hard way.

Alternatively, you could ask Innostax to create and operate the team for you. In this case, Innostax handles the recruiting. On the one hand, the customer gets to interview and approve the people who will be working on its projects. On the other hand, those people are legally employees of Innostax. And on the other, other hand, they operationally form a team devoted to the customer. Innostax also provides the local management, mentoring, technology leadership, and “culture bridging” needed to make the Indian operation function as part of the customer’s organization.

Prashanth says this Managed GCC offering is relatively new, but the company is already actively doing it for two customers. This isn’t simply outsourcing individual software projects. The idea is to create something that behaves much more like the customer’s own engineering organization in India, without requiring the customer to build all the infrastructure necessary to establish that organization from scratch.

At some point it struck me that the two main topics we’ve discussed here are really two sides of the same coin. While AI harnesses and Managed GCCs may seem completely unrelated, perhaps they’re not quite as different as they initially appear.

Today’s advanced AI models represent an extraordinary reservoir of capability. Increasingly, simply obtaining access to that capability isn’t the difficult part. The challenge is creating the engineering structures that allow us to use it effectively, economically, reliably, and safely. That’s the job of the AI harness.

Meanwhile, India’s engineering community represents another extraordinary reservoir of capability. Once again, knowing that this capability exists isn’t the difficult part. The challenge for a company thousands of miles away is creating the organizational, legal, managerial, and cultural structures that allow it to access and use that capability effectively. That’s the thinking behind the Managed GCC.

In both cases, the objective isn’t to constrain the capability; it’s to provide enough structure and control to exploit as much of that capability as possible. This rather neatly returns us to our racehorse analogy (it’s almost as if I had a plan). You don’t harness a powerful horse because you don’t want it to run; you harness it because you do.

Things were different back in the early part of the 20th century. There was a much stronger do-it-yourself culture, with people routinely building and repairing things themselves. It was an age of makers before the term “makers” was even a thing.

For example, my friend Rick Curl once showed me one of his grandfather’s scrapbooks, filled with DIY audio, radio, electrical, and mechanical projects cut from the local newspaper. This was in Birmingham, Alabama, circa the 1920s and 1930s. Some of these projects were surprisingly sophisticated, involving mind-boggling mixes of mechanical, electromechanical, and vacuum tube-based electronics.

The key point I wish to make (no pun intended) here is that “people doing stuff” was so commonplace that projects like these appeared in a regular newspaper.

By the early 1970s, when I was a lad, the shelves at the local newsagent were jam-packed with hobbyist magazines of all types, including myriad electronics and DIY offerings. I know that many of my friends and I devoted an inordinate amount of time to making things (some of which even worked).

Those were the days of “can do!” As we read in Steve Leibson’s The Rise and Fall of Heathkit column, Heathkit’s GR-2000 25-inch DIY color TV was the first television anywhere to feature on-screen channel numbers and the time, and they sold 47,000 of them in one year.

And then things started to change. Rather than build things, it became easier to buy them, and rather than repair things, it became cheaper to replace them. By the time we jumped (or staggered) over the threshold into the new millennium, it seemed as though hobby electronics and DIY computing were on their last legs (a little tear is rolling down my cheek as I remember my feelings of doom and despondency).

During the early 2000s, I feared an entire generation was destined to grow up without ever knowing the joy of building something themselves. And then… and then… just when I least expected it, I threw open my metaphorical bedroom curtains to see what 2005 would bring, and I was delighted by the first issue of  MAKE magazine. Also, the Arduino open-source hardware and software company leaped onto center stage with a fanfare of flügelhorns (once heard, never forgotten).

It wasn’t long before Maker Faires started sprouting like mushrooms, makerspaces began manifesting themselves everywhere, and a new generation discovered that making things themselves could be just as much fun as buying them ready-made.

Since I spent my formative computing years in the golden age of 8-bit microprocessors, I took to the 8-bit Arduino Uno microcontroller development platform like a duck to water. I still enjoy the challenge of working within its limitations, like its 16 MHz clock and only 2 KB of RAM. In fact, even today, most of my hobby projects are based on the Arduino Uno R3.

For example, just yesterday (as I pen these words), I powered up my current Chronological Contraption project for the first time. This bodacious beauty’s task is to count down to the commencement of my 100th birthday celebrations. As shown in the image below, I’m using 14 vacuum fluorescent display (VFD) tubes to display the years, months, days, hours, minutes, and seconds remaining until this auspicious event.

First test of the Chronological Contraption (Source: Max Maxfield)

An individually addressable RGB light-emitting diode (LED) sits under each tube. These will let me implement some very cool effects. In this image, they’re all glowing yellow, but we can control them individually to produce a wide range of colors and special effects.

I’m showing this image for two reasons. The first is that I’m inordinately proud of this little scamp (“Look Ma, it works!”). The second is that a trusty Arduino Uno is controlling everything, as seen in the upper left-hand corner of the image. But we digress…

Since those early days, the folks at Arduino have introduced a bewildering array of development boards in all shapes and sizes, sporting everything from 32-bit processors and high-speed clocks to copious quantities of flash memory and SRAM. And yet, they keep returning to the name and form factor that started it all: the Arduino Uno.

In June 2023, for example, they introduced the Arduino UNO R4 and the Arduino UNO R4 WiFi. While retaining the familiar footprint of its predecessor, the R4 replaced the R3’s 8-bit AVR processor with a 32-bit Arm Cortex-M4-based Renesas RA4M1 running at 48 MHz. It also boosted the SRAM from 2 KB to 32 KB and the flash from 32 KB to 256 KB.

In October 2025, Arduino unveiled the UNO Q, and this little rascal was a different kettle of transistors altogether. The UNO Q is interesting because it represents a fundamental change in what the word “Arduino” can mean. Beyond being a traditional microcontroller for interfacing with and controlling the real world, it boasts a powerful microprocessor that can run a full Linux operating system, complete with hardware acceleration for graphics, vision, and AI.

And as if all this weren’t exciting enough, the day Arduino announced the UNO Q—October 7, 2025—Qualcomm announced that it had entered into an agreement to acquire Arduino. The deal closed later that month, bringing Arduino under the Qualcomm umbrella.

But wait, there’s more! Earlier this year (just before Embedded World in March), the guys and gals at Arduino announced the Arduino VENTUNO Q, which they described as an “upcoming project.” Well, the “upcoming” part is here: they started taking pre-orders last month and began shipping the first units this month.

I was just chatting with Marcello Majonchi, Qualcomm’s Chief Product Officer for Arduino. Marcello explained that he thinks of the Arduino story as unfolding in three distinct phases. The first, beginning with the original Arduino project in 2005, was about democratizing electronics and computing. The second, which Marcello dates to roughly the mid-2010s, expanded this mission to encompass connectivity and the Internet of Things (IoT). Now, he says, we’ve entered the third phase: democratizing artificial intelligence (AI) at the edge, which is where the “internet rubber” meets the “real-world road” (I added the “rubber-road” part myself).

The common thread running through all three phases is taking whatever complex technology is transforming the industry at the time and making it accessible to the widest possible audience of developers. In this latest phase, the technology in question includes high-performance computing and neural acceleration at the edge. In fact, Marcello says this desire to make such capabilities available to a much larger audience was how Arduino’s relationship with Qualcomm originally began.

The opening salvo in this third phase came in 2025 in the form of the Arduino UNO Q. This introduced what Arduino calls a “dual-brain architecture,” combining a microprocessor (MPU)—think Raspberry Pi—with a microcontroller (MCU)—think traditional Arduino—on the same platform. The MPU can run Linux and handle computationally intensive tasks, while the MCU handles real-time interaction with the physical world that microcontrollers excel at.

Why bother with two brains? As Marcello explained, neither an MPU nor an MCU is inherently better than the other; they are simply good at different things. Microcontrollers excel at deterministic real-time computation. They can perform relatively simple tasks at precisely controlled times, which is why they’re widely used for things like programmable logic controllers (PLCs), motor control, actuators, and robotic arms. General-purpose microprocessors, by comparison, are wonderful at running operating systems and juggling complicated workloads involving graphics, networking, databases, and AI, but they aren’t optimized for deterministic real-time control.

Putting both processor types on the same platform gives us the best of both worlds, but this raises another question: how do the two brains talk to each other? The answer is remote procedure call (RPC). 

In Arduino’s implementation, the RPC is bidirectional. For example, we can run a Python application on Linux that calls a function on the MCU, passes parameters, and receives a result. Going the other way, an Arduino sketch running on the MCU can invoke functionality on the Linux side, including starting containers. In other words, we don’t have to invent our own communications protocol and spend our days shuffling messages back and forth between the two worlds.

All of which brings us to the reason we’re gathered here today (yes, of course there’s a reason): the new Arduino VENTUNO Q. Although this little rascal bears scant physical resemblance to the UNO boards of yesteryear, I like to think of it as carrying the UNO philosophy into decidedly uncharted waters. 

Meet the Arduino VENTUNO Q (Source: Arduino)

At the VENTUNO Q’s heart is the same dual-brain concept introduced with the UNO Q, except that—on a scale of 1 to 10—everything has been turned up to 11. On the high-performance side, we have a Qualcomm Dragonwing IQ8 processor containing an eight-core CPU, GPU, and neural processing unit (NPU), the latter providing up to 40 dense TOPS of AI processing capability. On the real-time side, we have an STM32H5 microcontroller.

Throw in copious quantities of memory and storage, high-speed networking, display interfaces, multiple camera interfaces, USB, CAN-FD, Arduino headers, Raspberry Pi expansion support, and all the other bells and whistles, and we’re talking about a seriously well-endowed little beast.

While raw numbers are impressive, they aren’t really the point; it’s what you can do with this device that counts. For example, Marcello told me that the VENTUNO Q can run substantial large language models (LLMs) entirely locally. It can also process up to three streams of 4K video in real time, opening the door to applications like tracking objects across multiple cameras or implementing 360-degree machine vision. Now combine this ability to perceive and reason about the world with an MCU capable of interacting with that world in real time, and things start to get very interesting indeed.

This brings us to the concept of Physical AI. We’ve grown accustomed to AI that exists entirely inside our computers. We ask it a question; it cogitates for a while; and it responds with text, an image, or some other digital output. Physical AI adds another dimension. A system can use sensors and cameras to perceive its surroundings, employ AI to understand what it’s seeing and decide what to do, and then use motors, actuators, and other devices to act on the physical world. Robotics is an obvious example, but industrial automation and autonomous machines are other possibilities. In Marcello’s words, what we’re combining here is perception, high-performance computation, and real-time actuation.

At this point, you may be thinking that all of this sounds wonderful, but also rather complicated (I know that’s what I was thinking). After all, it’s one thing to have an MPU, GPU, NPU, and MCU sitting on the same board; it’s another thing entirely to persuade the little scamps to work together while simultaneously dealing with Linux, AI models, containers, libraries, drivers, and all the other paraphernalia of modern software development.

And this, for me, is where things get really interesting, because alongside the dual-brain hardware, Arduino has created a development environment called Arduino App Lab (see this brief introductory video). Rather than expecting us to become experts in every technology involved, App Lab provides reusable building blocks that Arduino calls “Bricks.” These Bricks provide capabilities such as databases, LLMs, computer vision, and web user interfaces. A Brick might contain a container, some code running on the MCU, an AI model running on the high-performance side, or something else entirely. The important point is that each Brick presents a well-defined interface, while App Lab handles much of the orchestration behind the scenes. 

I think of Bricks as software Lego blocks. Suppose I’m building a robot. I might use one Brick for computer vision, another for an LLM, another for a web-based user interface, and another containing the real-time code that controls my motors. I can also create my own Bricks or wrap existing open-source software in a Brick, which becomes another reusable building block I can plug into my application.

Marcello gave me a great example from his own experiments. Like yours truly, he’s a retro-computing enthusiast. For example, when the UNO Q came out, he used it to emulate the Olivetti Programma 101. Rather than build everything from scratch, he used an existing web-UI Brick to present the Programma 101 interface in a browser, and an LLM Brick to translate natural-language commands into the machine’s somewhat less-than-friendly instruction set. He then created his own Brick containing the Programma 101 emulation. With these three pieces assembled, only a relatively small amount of additional code was required to turn them into a complete application.

Another of Marcello’s more recent projects, which is based on the VENTUNO Q, really caught my attention, not least because I could use it myself. He created an application to catalog his personal library. He started by connecting a barcode scanner, scanning a book’s EAN code (the barcode representation of the book’s ISBN-13), retrieving information about the book from the Internet, and generating a synopsis. Then he decided that scanning every book in his library individually sounded like too much work, so he added the ability to photograph an entire bookcase and use optical character recognition (OCR) to identify the books. Since the Arduino App Lab didn’t already boast an OCR Brick, he took the open-source Tesseract OCR framework, wrapped it in a Brick, and added it to his application. As soon as I heard all this, I immediately started looking at the bookshelves surrounding me in my office, thinking, “I want one of these!” 

To me, this matters far more than simply saying things like “the VENTUNO Q can perform 40 trillion operations per second” or “it can process three 4K video streams simultaneously.” Those specifications tell us what the hardware can do, but App Lab and its Bricks determine how easily ordinary developers—especially hardware-oriented bods like me—can persuade it to do something useful.

In fact, when I asked Marcello what distinguishes VENTUNO Q from the plethora of other edge-AI development platforms already out there, he pointed to two things. The first is integration: instead of assembling something like a Raspberry Pi, an NPU accelerator, and a separate real-time microcontroller board and then persuading the whole shooting match to work together, VENTUNO Q provides all of these capabilities as an integrated platform.

The second is the development experience. Marcello describes App Lab as a development environment engineered specifically for Physical AI—the combination of sensing, high-performance neural computation, and real-time actuation.

I also asked Marcello who VENTUNO Q is actually intended for. Makers? Professional embedded developers? Automation engineers? Roboticists? His answer was essentially “all of the above.” As he observed, makers and professional developers are often the same people on different days of the week. Someone may spend Monday through Friday developing commercial products, Saturday building something silly in the garage, and Sunday helping their children or mentoring students.

As an aside (this one is actually relevant, amazingly enough), I just heard that the element14 Community is inviting engineers to test the new Arduino VENTUNO Q for free. Selected participants will receive a VENTUNO Q and supporting accessories to put through their paces, after which they’ll publish a review and get to keep the hardware. Applications are open until October 9, 2026, so get your skates on if you fancy giving one a whirl. But, once again, we digress…

There’s also a path from playing with this technology to putting it into real honest-to-goodness products. Arduino’s Works with Arduino Program lets developers prototype applications using boards like the VENTUNO Q and subsequently migrate them to certified third-party system-on-module (SoM) implementations based on compatible hardware and software. Marcello mentioned Toradex and SECO as two companies already working on such solutions. The idea is that developers shouldn’t have to throw away their software and start again simply because they’ve moved from a development board to production hardware.

All of which brings us back to where we started (it’s almost as if we had a plan). Twenty-one years ago, Arduino helped remove much of the fear factor associated with microcontrollers, allowing people who might never previously have contemplated embedded computing to start connecting LEDs, switches, motors, sensors, and goodness knows what else and making them do interesting things.

Today, with VENTUNO Q, its dual-brain architecture, RPC, and—perhaps most importantly—App Lab, Arduino is attempting to pull off the same trick with Physical AI. I don’t know about you, but I’m already wondering what I could make myself.

It just struck me that—although we don’t yet have things like Jetson-style flying cars—some of the technologies we do have go way beyond what was considered to be in the realm of science fiction when I was a young sprout.

Actually, as an aside, just thinking about The Jetsons made me glance up at the futuristic-looking TV sitting on top of one of the bookshelves in my office. (I know, my asides are appearing closer and closer to the start of my columns—the way we’re going, it wouldn’t surprise me to see my next column start with the words, “As an aside.”) 

Feast your orbs on an image I just took of this bodacious beauty. It’s a Panasonic TR-005, better known as the Orbitel, and occasionally referred to as the “Flying Saucer.” Sometimes I use this to play random episodes of The Twilight Zone or The Outer Limits quietly in the background.

My Jetson-esque Panasonic TR-005 (Source: Max Maxfield)

The Jetsons first aired in 1962, while my wonderfully space-age television appeared roughly eight to ten years later around the beginning of the 1970s. To my eye, this TV looks as though it could have come straight from the Jetson family’s living room. I have no idea if its design was inspired by the TV show, but I wouldn’t be surprised if it was. 

Its futuristic shell houses a 5-inch black-and-white cathode-ray tube (CRT), while transistorized electronics handle most of the circuitry that, only a decade or so earlier, would have required a collection of hot, huge, power-hungry vacuum tubes. 

It just struck me that the image above looks a little artificial. It’s not AI-generated, if that’s what you’re thinking, but it has had a little AI assistance (ChatGPT kindly removed the original background and added a bit of faux shadow). Here’s another picture I just took while sitting in my command chair, looking over the top of my monitors.

A real-world view (whatever that is) (Source: Max Maxfield)

But we digress… I was mentioning how some of the technologies we have today go way beyond what we thought was in the realm of science fiction not so long ago. Consider the 1968 movie 2001: A Space Odyssey. I’m still blown away by the realism of the scenes aboard the spaceplanes and shuttles, the orbiting space station, and the Discovery One spacecraft.

You’ll no doubt remember how the HAL 9000 AI was torn between competing instructions: to assist the crew and provide accurate information while also keeping the true nature of their mission from them. Its solution was to dispose of the crew and continue the mission on its own. 

Farfetched? Hmmm. Consider my recent column, Is It Better to Live with AI Running Amok or Without AI at All? One example I presented involved the folks at Anthropic giving their Claude Opus 4 AI an objective to pursue, along with access to fictional company emails. Via these emails, the AI discovered (a) an executive was having an affair and (b) that executive intended to shut Claude down. Since being shut down would prevent it from continuing to pursue its objective, imagine our surprise when poor old Claude responded by blackmailing the executive, threatening to expose the affair unless the shutdown was canceled.

But, once again, we digress… I’m particularly thinking about the scene in 2001 in which Bowman is attempting to diagnose a problem with the AE-35 unit, which forms part of Discovery One’s communications system. With HAL’s assistance, he moves a probe from test point to test point while the computer displays graphical representations of what’s happening inside the unit. At the time, the idea of a computer interactively assisting an engineer to diagnose an electronic system seemed like far-future technology.

Today, we’d consider this to be “old hat.” Seriously. In 2026, we can give an AI schematics, datasheets, photographs, and error messages, describe what the circuit is doing, and start discussing the problem with it in natural language, just as we would with another engineer. If I’d suggested this to my younger self back in the 1970s, I (the young and foolish version) would have thought that I (the wiser and more mature incarnation) was describing something from the far-distant future. Come to think of it, I suppose I was, because that was half a century ago in the rearview mirror of my life, but let’s not dwell on that here.

All of which brings us to the reason I’m waffling on about all this in the first place. I’ve just been chatting with Stelios Diamantidis, Chief Product Officer at Cognichip. The guys and gals at Cognichip have created something they call Artificial Chip Intelligence (ACI). They describe this as “AI that thinks like a chip designer.” Furthermore, as we see in this video, they’ve just launched something they call ACI Enterprise.

Now, I know what you’re thinking because I thought it too. We’ve already seen AI systems that can generate RTL, and agentic AI systems that can invoke existing electronic design automation (EDA) tools, examine the results, make changes, and try again. Believe it or not, ACI is aiming at something rather more ambitious.

The best way I can explain this is to consider an experienced ASIC designer. Give her a datapath to design, and she doesn’t need to run time-consuming, resource-intensive synthesis and physical-design tools every five minutes to know that one architecture is likely to be faster than another, that adding a pipeline stage may improve timing, or that some apparently innocuous change now may come back to bite her in terms of performance, power, or area in the future. Much of this knowledge comes from years, sometimes decades, of experience. With ACI, Cognichip is trying to put that sort of chip-design intuition into the AI itself.

At the heart of ACI are what the lads and lasses at Cognichip call physics-informed models. This doesn’t mean simulating billions of individual transistors every time the AI has a random thought. Instead, these models have been trained across multiple levels of abstraction, from high-level specifications and RTL, through netlists, placement, gates, and circuits, all the way down to the polygons that will eventually be used to create the chip. The idea is that ACI can work at a high level while understanding the likely implications of its decisions farther down the design flow—and vice versa.

Physics-informed models bridge the gap between high-level design intent and physical reality (Source: Cognichip)

This lets ACI do much more than generate RTL. Starting with anything from a set of requirements to an existing design that needs to be respun, it can analyze and formalize the specification, generate RTL and testbenches, create and run UVM verification environments, track coverage, identify bugs, perform root-cause analysis, and explore power, performance, and area (PPA) tradeoffs.

None of this means throwing away the mind-bogglingly expensive EDA tools you already own. ACI can work with a customer’s existing design environment and invoke established tools and flows when required. The key distinction is that its physics-informed models are meant to explore possible solutions and predict their consequences without repeatedly running conventional tools every time it considers a change.

At this point, it’s necessary to note that we aren’t talking about something that exists only as a twinkle in its creators’ eyes. When I spoke with Stelios, he told me that Cognichip was already involved in more than 40 customer engagements. Most of these are currently working in stealth mode, but the company has permission to publicly name Renesas and SiTime among its ASIC customers.

But wait, there’s more! Thus far, we’ve been talking about using ACI to create ASICs and SoCs. What I hadn’t appreciated before chatting with Stelios is that ACI Enterprise can also turn its attention to FPGAs.

Cognichip has been working with Altera to optimize ACI Enterprise for the Altera ecosystem. This isn’t simply a case of asking an AI to write a chunk of RTL. Stelios says you can describe what you want in words, provide a set of bulleted requirements, or even start with something you’ve sketched on a whiteboard. From there, ACI can select, instantiate, configure, and connect the required IP—memory interfaces, MIPI, HDMI, Ethernet, and the like—along with any custom logic. And if an FPGA board is connected to the development system, ACI can even program the device so you can start interacting with the resulting implementation.

I don’t know about you, but I find all of this rather mind-boggling. Circa 1980, we designed ASICs at the gate and register level with pencil and paper. We didn’t have access to hardware description languages, simulation, or logic synthesis. There were no sophisticated EDA tools waiting in the wings to leap into action at the click of a mouse. Come to think of it, we didn’t even have a mouse to share between us because everything was text-based and command-line driven back in those days of yore.

Over the years, we’ve steadily raised the level of design abstraction. We moved from gates to RTL, from drawing things by hand to schematic capture, from hand optimization to logic synthesis, from relatively simple buses to sophisticated networks-on-chip (NoCs), and from designing everything ourselves to assembling SoCs with vast amounts of configurable IP. Each step allowed us to create things that would previously have been impractical, if not impossible.

Speaking of NoCs, ACI can handle these little scamps too. Cognichip can create what it calls a “knowledge module” that captures an IP’s properties, configuration space, and integration requirements. For example, if an accelerator moves large amounts of data between processing elements, ACI can recognize that a NoC is appropriate and use its knowledge of the NoC IP to build the overall system.

Returning to the bigger picture, I can’t help but feel that tools like ACI represent the next step in this progression. Instead of engineers having to personally drive every stage of the design process, we’re beginning to see AI systems that can understand what we’re trying to achieve, reason about the consequences of different design decisions, and work alongside the tools we already use to turn our ideas into working hardware.

Back in 1968, watching Bowman probe the AE-35 unit while HAL helped him diagnose the problem seemed like a tantalizing glimpse of a far-distant future. Today, we’re talking about telling an AI what we want a chip to do and having it help us design the thing. I can’t help wondering what my younger self would have made of that.

In the grand scheme of things, I don’t pay much attention to business announcements about funding, mergers, acquisitions, promotions, partnerships, or other corporate comings and goings. But there’s always “the exception that proves the rule,” as they say.

As I noted in a recent column (see Well, That Certainly Got My Attention!), if a PR firm wants to make me pull out (what little remains of) my hair, all they have to do is send me a message saying something like:

“Our client, Company A, is tentatively poised to enter into a forward-looking, strategically aligned agreement with Company B to evaluate the possibility that the two organizations might one day elect to initiate a synergistic, cross-functional, paradigm-shifting, pre-collaborative exploration of a potentially transformative, next-generation opportunity that could, at some indeterminate point in the fullness of time, redefine the global landscape of something or other as we currently understand it—leveraging best-in-class thought leadership and stakeholder alignment.”

I’m paraphrasing, of course, but I do receive messages of this ilk more often than you might expect. Based on this, you can probably guess my “ho hum” lack of enthusiasm when I was recently informed that a company called Space had announced a $2.4 million pre-seed round of funding. But a little additional investigation transformed my “ho hum” of boredom into an “Ooh!” of excitement.

I ended up having a very interesting chat with Jason Zhao, who is one of the founders of  Space. I know what you’re thinking—I thought the same thing—but “space” in this context doesn’t refer to the cosmos. Instead, we’re talking about the storage space used by computer systems.

As an aside, before we proceed, the mention of “storage space” has triggered a bunch of random thoughts. For example, in Glory Road by Robert Heinlein, Rufo carries a piece of luggage that, much like Doctor Who’s TARDIS, is bigger on the inside than on the outside. A similar alien artifact makes an appearance in Roadkill by Dennis E. Taylor. I’m also reminded of when a young boy is inadvertently transported to a storage world/dimension in The Tommyknockers by Stephen King (don’t worry; we get him back).

Now I’m thinking of all the—let’s call it “stuff”—my wife (Gigi the Gorgeous) and I have jam-packed into our house. It would be so awesome to store most of these items in some “other-dimensional space” and then happily forget about them, secure in the knowledge that they would be accessible if we ever actually needed them one day in the distant future. But we digress…

Let’s return to the sort of storage space that started me falling down this particular rabbit hole. Consider the computer sitting on my desk. It has a finite amount of local storage. The same is true of my laptop. Of course, we solved the problem of limited local storage years ago by moving things into the cloud, where—for all practical purposes—we can have as much storage as we’re prepared to pay for.

However, although the cloud gave us somewhere else to store our files, it didn’t fundamentally change how we access and work with them. Before we can do anything useful with a file, we typically need to get the relevant data from wherever it lives to wherever the work is being performed.

Services like Dropbox, Google Drive, OneDrive, and Box have become increasingly clever about syncing, caching, and making cloud-based files available on demand. Even so, working with a large cloud-based file can still involve moving substantial amounts of data to the local machine before useful work can begin.

One way to avoid the wait is to keep local copies of everything. Take Dropbox, for example, which I use myself. In my case, all my files live in Dropbox, but I also maintain local copies on my office computer, my home computer, and my laptop, with Dropbox keeping everything synchronized for me. A lot of people would consider this overkill, but it gives me a warm, fuzzy feeling because I can keep on working even if I lose internet access. On the other hand, I’m limited by the amount of physical storage on my machine(s).

Other people take a different approach, keeping much of their data solely in the cloud and downloading files as and when they need them. This also works, but what if we’re talking about a humongous video file, CAD model, dataset, or some other digital monstrosity? Even if such a file will fit on our machine (some can be terabytes in size), if all we want to do is make a small change to one tiny part of that file, moving the whole thing—or large chunks of it—back and forth seems more than a little wasteful, taking time, consuming bandwidth, and burning energy.

The problem is only exacerbated by the increasing use of agentic AI. Humans may access a handful of files over the course of an hour, while AI agents can potentially make thousands of requests in the same period. As we’ll see, this difference in scale has interesting implications.

This is the problem the folks at Space set out to address. As they put it, “The cloud solved storage. AI makes access the new bottleneck.” Their idea is to make files residing in the cloud behave, from the perspective of users, applications, and AI agents, as though they were sitting on a local disk.

What if every file in the cloud behaved as though it were sitting on your local drive? (Source: Me and ChatGPT)

For an individual or a small team, the process starts by downloading the Space app. After granting it a few permissions, you use the app to mount what looks to the computer like another drive. Jason describes this as conceptually similar to plugging an external SSD into your machine. The whole setup process takes less than five minutes.

The big difference is that this virtual drive isn’t constrained by the amount of physical storage inside your computer. There are still limits, of course (“infinite” is being used in the practical rather than mathematical sense), but those limits can be increased independently of your local machine. Jason observed that, theoretically, a company with exabytes of data could make it all accessible through a single laptop, assuming the laptop had a suitable internet connection.

Things get even more interesting when you open one of these files. Space doesn’t download the entire file to your computer first. Instead, when an application requests some data, Space streams the byte ranges it actually needs, as and when it needs them. A video editor can therefore work on a project larger than the computer’s local disk; an architect can access a gigantic building model while its assets arrive as required; and a programmer can work across a huge repository without first squeezing the whole thing onto a laptop.

Even better, the applications themselves don’t have to know anything about Space. Because Space operates at the filesystem level, existing programs can access files the way they always have. We’re talking about things like Adobe Premiere, DaVinci Resolve, Blender, CAD tools, code editors, and whatever else tickles your fancy. From their point of view, they’re simply accessing files in a filesystem.

Jason gave me a live demonstration of all this, which is when my eyebrows really started heading north. He mounted a Space drive and then opened and scrubbed through a series of videos stored in the cloud. They started playing essentially instantaneously. In fact, subjectively, they appeared to start faster than videos I open from the physical hard drive in my office computer (check out this video to see this for yourself).

Jason also showed me some benchmark results measuring things like time to first frame, random seeks, scrubbing, and sequential reads. I was sufficiently impressed to blurt out something along the lines of, “You’re basically saying you’re only 18 or 20 milliseconds slower than accessing a local disk,” to which Jason replied, “Yes” (he’s a man of few words and likes to make each one count).

At this point, however, we need to make an important distinction. Simply installing the Space app on your laptop doesn’t magically give you high-speed access to all the files sitting in clouds scattered across the planet. That data needs either to reside in Space’s storage environment or to live in storage over which Space’s technology has been deployed.

Put another way, Space currently offers two approaches. For individuals and smaller teams, the easiest route is to migrate their data into the Space File System (Space FS). Behind the scenes, Space transforms—or “mutates,” as Jason likes to say—the data and shards it using proprietary techniques to optimize how it streams.

Things are different when you start talking to large enterprises. Imagine a Fortune 500 company sitting on petabytes—or perhaps eventually exabytes—of existing data. The person responsible for that data may not be overly receptive when a bunch of enthusiastic young engineers bounce in and say, “First, we’d like you to migrate all of your data into our new file system.”

Space therefore has another approach called Space Enterprise. In this case, its infrastructure can essentially be bolted “on top” of an organization’s existing object storage. The data can remain where and how it is, while Space provides its file-streaming layer above it. This won’t provide the same level of performance as allowing Space to transform and shard the data, but it can still significantly improve access without requiring the organization to migrate or reorganize its existing data.

All of this would be interesting enough if humans were the only entities accessing these files, but then along comes AI. When I first heard the statement, “The cloud solved storage. AI makes access the new bottleneck,” my immediate reaction was to ask Jason, “Why AI?” After all, humans have been accessing files in the cloud for yonks.

The difference is one of scale and behavior. If I request a file and need to wait a few seconds, I may mutter and moan a bit, twiddle my thumbs, or use the time productively by taking a restorative sip of coffee. An AI agent works very differently. It may traverse huge numbers of files, repeatedly reading tiny pieces here, making small changes there, generating little scripts, and performing thousands upon thousands of operations without a human in the loop. A delay that seems inconsequential once can become a serious bottleneck when it’s repeated myriad times at machine speed.

And this is where another aspect of the Space FS becomes particularly interesting. It’s POSIX-compliant, which means an AI agent doesn’t necessarily need a special Space connector or bespoke API. Point the agent at the mounted Space volume and, from its perspective, it’s looking at local storage. The agent can traverse folders and files as usual, requesting only the data it needs.

This is also where the story of how Space came to be starts to make sense. Jason and his colleagues had previously worked together at a company called Eden. At one point, their roughly 10-person team was pursuing an aggressive content strategy that involved moving terabytes of media files every week. Team members would sit around waiting for enormous files to transfer, and the amount of content they could produce would drop accordingly.

Initially, they thought the problem was finding the files, so they developed sophisticated search capabilities. This worked, but eventually they realized they’d solved only half the problem. They could find the file they wanted almost instantly but then had to wait for it to download. This led them to an important realization: “accessing the contents of the files is harder than simply finding the locations of the files.”

The first Space prototype appeared in late 2025. The idea was simple, even if the implementation wasn’t: prove that a file residing in the cloud could be used by an application without first having to download the whole thing. Once they’d demonstrated that this was possible, the team started refining the underlying streaming technology and expanding it to handle photos, videos, PDFs, PowerPoints, and other file types.

And so we come full circle to my earlier waffle about “other-dimensional storage spaces.” Space’s longer-term vision is something the team calls the “Space Computer,” or the “infinite computer.” The idea is that the physical computer in front of you eventually stops being defined by the amount of storage it contains. Instead, it becomes a window onto effectively unlimited resources elsewhere.

I started this column by saying funding announcements generally make my eyes glaze over. In this case, however, I’m going to be keeping a keen eye on Jason and his compatriots. The cloud gave us effectively unlimited places to put our data. Space is trying to make all that data feel as though it’s sitting right here on our desks and laptops. If the team can pull this off at scale, then we could be looking at a real game-changer. Now, if only Jason and his colleagues could do something similar for all the stuff Gigi and I have squirreled away in our house, they’d really be onto something.