DEV Community: fluidwire

Punched Cards Came From a Weaving Loom

fluidwire — Thu, 03 Sep 2026 21:14:24 +0000

Punched cards are the stock image of early computing: a technician feeding a deck into a mainframe, a room of card-punch operators, a dropped box of cards ruining someone's week. But the punched card did not come from computing at all. It came from the textile industry, and it arrived a full century and a half before the first computer.

In 1804 a French weaver named Joseph-Marie Jacquard demonstrated an attachment for the drawloom in Lyon. Figured silk — brocade, damask, anything with a picture woven into it rather than printed on it — required a second worker, the draw boy, sitting above the loom and lifting warp threads by hand in the right combination for every single pass of the shuttle. It was slow, it was error-prone, and every new pattern meant re-rigging the loom from scratch.

Jacquard's mechanism replaced the draw boy with a chain of stiff cards. Each card carried a grid of holes, and each hole corresponded to one hook attached to one warp thread. Where there was a hole, a rod passed through and the hook lifted. Where the card was solid, the rod was blocked and the thread stayed down. One card encoded one row of the image. The cards were laced together into a continuous loop that advanced automatically with every throw of the shuttle.

Why this was the important part

The weaving speed mattered commercially, but the structural idea mattered far more: the pattern was no longer part of the machine.

Before Jacquard, a loom set up to weave one design was a machine for weaving that design. Changing the output meant physically rebuilding the apparatus. After Jacquard, the loom was general-purpose and the cards were the specification. Swap the deck, get a completely different fabric, with no change to the hardware whatsoever.

That is the separation between a machine and the instructions it executes — the distinction we now call hardware and software — and it was demonstrated in a weaving shed in 1804 by someone who was not trying to invent computing.

The line from Lyon to IBM

The idea propagated fast, because everyone who saw it understood immediately that it was about more than cloth.

Charles Babbage owned a Jacquard-woven portrait of Jacquard himself — an image requiring roughly 24,000 cards to produce — and adopted punched cards as the input mechanism for his Analytical Engine, designed in the 1830s. Ada Lovelace's note on that machine makes the parallel explicit: the engine, she wrote, weaves algebraic patterns the way the loom weaves flowers and leaves.

Herman Hollerith turned the concept into a business. The 1880 US census took roughly eight years to tabulate by hand, and the country was growing fast enough that the 1890 count risked not finishing before the next one began. Hollerith's electromechanical tabulator read punched cards to sort and count population data, and the 1890 census was processed in a fraction of the time. His Tabulating Machine Company merged into what became IBM in 1924.

From there, punched cards ran business data processing, then early electronic computers, then FORTRAN and COBOL program entry, right up to the terminal displacing them in the 1970s. A single encoding format stayed in continuous industrial use for over a hundred and fifty years.

The same idea is in your firmware

Reduce a modern connected device to its essentials and the Jacquard structure is still there. A microcontroller is a fixed, general-purpose machine. Firmware is the deck of cards. The silicon does not change; the instructions in flash decide what the product actually is.

This is why an over-the-air update is possible at all. When a sensor node in the field gets new firmware, nobody visits the device — the machine stays exactly as it was and only the specification changes. The same ESP32 module can be a water-level monitor, a queue counter, or a cold-chain logger depending entirely on what is loaded onto it. That is a Jacquard loom with a radio.

It is also why the discipline around firmware matters so much in IoT work. Once the instructions are the product, versioning, rollback, and update integrity stop being housekeeping and become the core of the system. A loom with the wrong deck weaves the wrong cloth. A fleet with the wrong image bricks in the field.

Worth remembering locally

There is a practical reading here for anyone building hardware in the Philippines, where custom silicon is off the table and imported modules are the starting point for nearly every project. Jacquard did not invent a new loom. He built a control layer on top of an existing one, and the control layer was where all the value turned out to be.

That is broadly the right posture for local product work: the differentiator is rarely the board, it is the firmware, the protocol choices, and the cloud layer sitting behind them. A team that treats off-the-shelf hardware as a substrate and puts its effort into the instruction layer can ship something genuinely distinct without a fab.

If you are working through an IoT product, thesis prototype, or connected-device deployment, or you want to talk about how to structure firmware and updates for a fleet you will have to maintain, get in touch with us — we work across the whole stack, from the board to the dashboard.

Two hundred and twenty-two years on, the insight still holds: build the machine once, and put the intelligence in what you feed it.

Hello, World Started in 1972

fluidwire — Wed, 02 Sep 2026 21:13:11 +0000

Almost every programmer alive has typed the same first line of code. It printed nothing useful, solved no problem, and was never meant to be famous. Hello, World started in 1972 as a throwaway example in an internal Bell Labs document — and it has outlived nearly every language it was written for.

Where Hello World actually came from

The phrase first appears in Brian Kernighan's A Tutorial Introduction to the Language B, a Bell Labs technical memorandum from 1972. B was the predecessor to C, and Kernighan needed the smallest possible complete program to show readers what a compilable B program looked like — something short enough to fit on the page but real enough to run.

Six years later, Kernighan and Dennis Ritchie opened The C Programming Language (1978) with a C version of the same idea, along with a line that quietly set the convention for the next fifty years: the advice that the only way to learn a new language is to write programs in it, and that the first one should be this. C spread to Unix, Unix spread to everything, and the greeting went with it. Today it is the first page of essentially every language tutorial ever published — Python, Rust, Go, JavaScript, and every C dialect in between.

The point was never the greeting

Here is the part that gets lost when Hello World is treated as a joke or a rite of passage: it is a diagnostic, not a lesson.

When your machine prints those two words, you have proven, in one shot, that a surprising number of independent things are all working and all agreeing with each other:

your editor saved the file where you think it did
the compiler is installed, on your PATH, and accepts your syntax
the linker found the standard library
the resulting binary is the right format for your machine
the runtime started, reached main, and got output to your terminal

None of that is about printing text. It is an end-to-end test of the toolchain, run before you have written a single line of code worth debugging. That is why it survived: it is the cheapest possible way to separate "my logic is wrong" from "my environment is broken" — two problems that look identical at 2 a.m. and have nothing in common.

The embedded version is called Blink

In embedded systems and IoT development, the same ritual has a different name and a much higher stakes payoff. It is Blink: a few lines of firmware that toggle a single LED on and off.

Blink is Hello World for hardware, and it answers a longer list of questions than its desktop cousin. On a microcontroller there is no terminal, no operating system, and no one to tell you what went wrong. Flashing that LED proves:

the board is powered and the regulator is holding
the crystal or internal oscillator is running, so the clock configuration is valid
the toolchain produced a binary for the right architecture and the right memory map
the programmer or debug probe actually reached the chip and the flash write took
your pin mapping matches the schematic — the pin you named in code is the pin on the board
the firmware got past reset and startup code and into your main loop

A silent board tells you nothing about which of those failed. A blinking one eliminates all of them at once. On a custom PCB it is often the first evidence that the board you had fabricated is alive at all — which is why it is the very first thing we flash on every new prototype before any sensor, radio, or cloud code goes near it.

Why we still start every project this way

The discipline behind Hello World scales far past the first day of a project. The principle is: get one signal working end to end before you build anything on top of it.

On a connected-device build that means we do not write the data pipeline first. We prove the LED blinks. Then we prove one sensor reads a plausible number over I2C. Then we prove one message reaches the broker over MQTT. Then, and only then, do we build the dashboard on top. Each step is a Hello World for the layer above it, and each one narrows the search space when something eventually breaks — because something always does.

Skip those checkpoints and a failure at any layer looks like a failure at every layer. That is how a two-hour bug becomes a two-day bug. Teams working on a first IoT product, a thesis prototype, or a capstone build lose more time to this than to anything genuinely difficult.

If you are working through a connected-device build and want a second set of eyes on the hardware, the firmware, or the cloud side, our IoT and embedded development services cover the whole path from silicon to cloud — and you can tell us what you are building to get a straight answer on the approach before you commit to it.

Fifty-four years on, the shortest program ever written is still doing its original job: proving the ground is solid before you build on it.

Why the Power Symbol Is a 1 and a 0

fluidwire — Tue, 01 Sep 2026 21:13:17 +0000

The power symbol printed on almost every device you own is not an abstract pictogram. It is binary. A vertical line is a 1, meaning on. A circle is a 0, meaning off. That is the whole design: the two states of a switch, written in the two digits of the number system the machine runs on.

The convention is codified in IEC 60417, the international standard that defines graphical symbols for use on equipment — the icons stamped into plastic and silkscreened onto panels, meant to be understood without translation. The relevant entries are a small family, and the difference between them is where things get interesting.

Four symbols, not one

A plain vertical line means power on.
A plain circle means power off.
A line inside a broken circle means standby.
A line inside a closed circle means a push-push on/off toggle — one button that alternates between both states.

The first two belong on a rocker or a rotary switch, where the position of the control tells you which state you are in. The last two exist because modern equipment does not have that kind of switch. A single button cannot sit in a labelled position, so the symbol has to carry the ambiguity instead.

Look at your laptop, your monitor, your router, your TV. The icon is almost certainly a line inside a broken circle. That is the standby symbol. It is not claiming the device turns off. It is telling you, correctly, that pressing it moves the machine into a low-power state that is still a powered state.

Standby is a state, not an absence of one

This is where the trivia turns into engineering. A device in standby is still drawing current. It is holding RAM contents, keeping a real-time clock running, watching an infrared receiver or a network interface for a wake signal, and maintaining whatever the power-management controller needs to bring the rest of the system back up quickly. The reason your TV responds to the remote is that some part of it never stopped listening.

For mains-powered consumer equipment this shows up as standby draw — small per device, real in aggregate, and the reason efficiency regulations put caps on it. For anything running from a battery, it is the entire design problem.

Why this decides IoT battery life

Ask what a connected sensor actually does over a day. It wakes, takes a reading, maybe joins a network, transmits, and goes back to sleep. The active portion might total a few seconds. The other 86,000-odd seconds are spent in whatever "off" you chose — and that choice, not the radio, usually determines how long the battery lasts.

On an ESP32-class microcontroller the difference between sleep modes spans orders of magnitude. Light sleep keeps RAM and peripherals alive and resumes almost instantly, at a cost measured in milliamps. Deep sleep powers down most of the chip and wakes through a timer or an external pin, dropping to microamps, but the application restarts rather than resumes — so any state you care about has to be written somewhere that survives. Getting from a device that lasts a week to one that lasts three years is rarely about a bigger battery. It is about choosing the deepest sleep state the product can tolerate and then engineering around what that state destroys: reconnect time, lost RAM, buffered readings, clock drift.

The same reasoning applies to everything else on the board. A sensor that idles at 200 microamps because nobody added a load switch will quietly outweigh a well-tuned MCU. Quiescent current in the regulator, pull-ups that are always conducting, an LED left on to show the device is alive — these are the items that turn a modelled three-year battery life into a fourteen-month field failure. Measuring average current on real firmware, rather than adding up datasheet numbers, is the only way to know which state your product is actually in.

The design lesson in a symbol

The standby symbol is honest about something product teams often are not: there is usually no true off. Devices with a physical disconnect are increasingly rare, because the features people expect — instant wake, remote power-on, scheduled reporting, over-the-air updates — all require something to stay awake. The engineering question is never "is it off?" but "how little can it draw while still being able to come back?"

If you are specifying a connected product, that question belongs in the requirements document, not in firmware optimisation at the end. What must the device be able to wake for, how quickly, and how often? Answer that and the sleep strategy, the power budget, and the battery size follow. Answer it late and you are recalculating all three after the enclosure is tooled.

We design IoT and embedded systems from silicon to cloud, including the unglamorous power-budget work that decides whether a deployment survives its first year in the field. If you have a connected product in the planning stage or a fleet that is draining faster than the model said it would, tell us what you are building or take a look at how we work.

The First Spam Email Was Sent in 1978

fluidwire — Mon, 31 Aug 2026 21:13:19 +0000

The first spam email was sent on May 3, 1978, over the ARPANET — roughly fifteen years before anyone used the word "spam" to describe it.

Gary Thuerk, a marketing manager at Digital Equipment Corporation, sent an unsolicited message to about 393 ARPANET users on the US West Coast. It was an invitation to demonstrations of DEC's new DECSYSTEM-20 machines. At the time the network had only a few thousand users in total, so a single message to 393 of them reached a meaningful share of everybody online.

Complaints arrived the same day. Network administrators at DARPA, which funded ARPANET, made it clear that the network was for government and research use and that mass advertising was not welcome. Thuerk got the sales leads he was after and a reprimand along with them.

The word came much later

The message was not called spam. That name came out of a Monty Python sketch in which a café menu consists almost entirely of Spam, and a chorus of Vikings drowns out conversation by singing about it. In the 1980s, users of Usenet groups and text-based multiplayer worlds (MUDs) borrowed the term for anything that flooded a shared channel and made it unusable. By the mid-1990s it had attached itself permanently to unsolicited bulk email.

The sketch is a better metaphor than it first looks. The problem is not that the Spam is offensive. The problem is that it is loud enough to make everything else inaudible.

The network worked perfectly

This is the part worth sitting with. Nothing broke in 1978. The mail system did precisely what it was designed to do: accept a message and deliver it to every address on the list, quickly and reliably. ARPANET had no bug that day.

What it had was an absent constraint. Sending cost the sender essentially nothing, and the cost of receiving landed on 393 other people. Any shared channel with that asymmetry will eventually fill up, because there is nothing in the system pushing back on the sender. The internet spent the next forty years retrofitting that pushback — filters, reputation scoring, rate limits, authentication — onto a protocol that never assumed it would be needed.

The same problem, now with sensors

Anyone building connected hardware runs into this exact asymmetry, usually within a week of the first pilot deployment.

A device that publishes every reading at full rate feels like thoroughness. In practice it produces three costs that all land somewhere other than the device: bandwidth and cellular data that scale with fleet size, storage and query time on whoever is running the backend, and — most expensively — the attention of the people who are supposed to act on the data. A dashboard that updates constantly is a dashboard nobody watches. An alert that fires on every minor excursion is an alert the operations team learns to swipe away without reading.

That last failure is the one that quietly kills projects. Once a team has been trained by false positives to ignore notifications, the real event goes unnoticed too, and the system is worse than having no monitoring at all — because everyone believes they are covered.

Designing the constraint in

The fix is not to send less data arbitrarily. It is to decide, on the device, what is worth saying:

Filter and aggregate at the edge. A temperature sensor sampling every second does not need to transmit every second. Send a rolling average, plus anything that crosses a threshold. The raw resolution stays local, where it is cheap.

Report by exception, not by schedule. Publish when state changes meaningfully, with a slow heartbeat so the backend can distinguish "nothing to report" from "device is dead."

Buffer through outages. On patchy warehouse Wi-Fi or field cellular in the Philippines, a device that drops readings during a dropout is a device with holes in its history. Write to flash and reconcile on reconnect.

Set thresholds with the people who will be paged. An alert threshold is not a technical parameter. It is a promise about what deserves someone's attention at 2 a.m., and it should be negotiated with the person who will be woken up.

Give every alert an action. If nobody can name what they would do when a notification fires, that notification should be a log entry, not a page.

MQTT, the protocol behind most modern IoT deployments, was shaped by exactly these pressures — it was built in 1999 to monitor oil pipelines over expensive satellite links, where every byte had a price. That scarcity produced a design with a two-byte header, quality-of-service levels, and clean reconnect semantics. Constraints made it good.

The lesson from 1978

Thuerk's message is remembered as a marketing misstep, but the interesting failure is architectural. A network that makes sending free will fill with things nobody asked for, and no amount of good intentions among the senders will prevent it. The constraint has to be in the system.

When we design telemetry for a connected product, that is the question we start with — not "what could this device measure?" but "what will somebody actually do with this, and what does it cost them to receive it?" Devices that only speak when they have something worth saying are the ones people keep listening to.

If you are scoping an IoT deployment and want the alerting to still be trusted a year in, talk to us about your project or take a look at what we build.

Why Is It Called Silicon Valley? A 1971 Headline

fluidwire — Sun, 30 Aug 2026 21:13:06 +0000

Silicon Valley is now shorthand for software, venture capital, and app launches. But nobody in the region named it, and the name has nothing to do with software. It came from a reporter covering the electronics trade, and it describes a material.

A three-part series in a trade paper

In January 1971, a journalist named Don Hoefler began a series in Electronic News, a weekly trade paper for the electronics industry. The series was called "Silicon Valley USA," and it covered the semiconductor companies that had accumulated in the Santa Clara Valley south of San Francisco — Fairchild Semiconductor and the firms that had spun out of it, Intel among them.

The phrase was reportedly suggested to Hoefler by a businessman named Ralph Vaerst. Hoefler is the one who put it in print, and print is what made it stick. Within a few years the name had escaped the trade press entirely.

The valley had a name before that one. It was farmland — prune, apricot, and cherry orchards — and it was marketed as the Valley of Heart's Delight. That name lost to a chemical element in about a decade.

The name describes a substrate

"Silicon" in the phrase is not decorative. It is the substrate: the ultra-pure single-crystal wafer that transistors are etched into. The companies Hoefler was writing about made silicon devices. That was the entire industry he covered.

It is worth sitting with how far down the stack that name reaches. Silicon is the layer beneath the transistor, beneath the logic gate, beneath the microcontroller, beneath the firmware, beneath the network protocol, beneath the cloud service, beneath the app. The region got named for the very bottom of the stack — and then, over fifty years, the popular meaning of the name floated up to the very top of it.

Why the original meaning still matters for connected products

The drift from silicon to software is a fair description of where the money went, but it is a bad model for building an IoT product. A connected device is not a web app with an antenna. It is a physical thing with real constraints stacked underneath the code:

Power. A battery-backed sensor has a duty cycle, not an uptime target. Sleep-current in microamps decides whether the deployment lasts eighteen months or six weeks.
The board. Trace impedance, ground planes, antenna keep-out zones, and decoupling are not cosmetic. A layout mistake shows up as a device that works on the bench and drops packets in the field.
The silicon itself. Choosing a microcontroller commits you to a peripheral set, a toolchain, an errata sheet, and a supply chain. That decision is expensive to reverse after the enclosure is tooled.
Firmware. Interrupt latency, watchdog behaviour, and over-the-air update safety are where "it mostly works" turns into a truck roll.

Teams that treat hardware as a solved detail underneath the interesting software usually meet these constraints at the worst possible moment — after the pilot, during manufacturing.

The full-stack version of the same idea

The useful reading of Hoefler's phrase is that the interesting work spans the whole distance. A connected product is one system that happens to be written in several materials: a sensor, a board, firmware, a radio link, a backend, and a dashboard someone actually looks at. Cutting it into a "hardware project" and a "software project" is where most of the integration pain gets manufactured.

That span is what we build across at Fluidwire — embedded firmware and PCB and product engineering on one end, web services and dashboards on the other, treated as one design problem rather than two. For teams in the Philippines building connected devices, university thesis prototypes, or a first production run, that end-to-end view usually matters more than any single component choice.

Silicon to cloud is not a slogan we picked for the alliteration. It is the actual distance a working IoT product has to cover.

If you are scoping a connected product and want a second opinion on where the hard parts are, get in touch.

A Nanosecond Is 11.8 Inches Long

fluidwire — Sat, 29 Aug 2026 21:14:07 +0000

A nanosecond is 11.8 inches long. That is not a metaphor — it is a measurement, and Grace Hopper used to carry a bundle of them in her handbag.

Hopper, the computer scientist behind much of what became COBOL, spent a good part of her career explaining computers to people who did not build them. One question kept coming back: why does a satellite message take so long to arrive? The answer involved the speed of light, which is easy to state and almost impossible to feel. So she stopped explaining and started handing out props.

Each one was a piece of wire cut to 11.8 inches — roughly 30 centimetres. That is the farthest an electrical signal can travel in one billionth of a second. Hold it in your hand and the abstraction collapses: a nanosecond is not a duration, it is a distance. If a satellite sits 22,000 miles up, she would point out, you are asking a signal to cover an awful lot of those wires before anyone can answer you.

She scaled the demonstration up when she needed to. A microsecond, in her scheme, was a coil of wire 984 feet long. And when people asked her to justify a wasted second of compute time, she had a ready reply: a second is 186,000 miles of wire.

The number is smaller inside your circuit board

Light covers 29.98 cm in a vacuum in one nanosecond. Signals on a printed circuit board are slower. Propagation velocity in a typical FR-4 microstrip runs at around 60 to 70 percent of the speed of light, because the electromagnetic field is partly travelling through the board's dielectric rather than through air. In practice a signal covers something closer to 15 to 20 cm per nanosecond on a real trace, or a bit under 6 inches.

That correction matters more than the headline number, because it is the one you design against. A 6-inch trace costs you roughly a nanosecond. On a bus running at 100 MHz, one clock period is 10 nanoseconds and you will never notice. On a DDR interface or a gigabit link, a nanosecond is the entire timing budget.

Why length matching exists

Look at any densely routed board and you will find traces that meander in tight serpentine zigzags for no apparent reason. They are not decorative and they are not a routing mistake. They are the physical expression of Hopper's wire.

When a differential pair carries a signal, both halves have to arrive together. When a parallel bus carries sixteen bits, all sixteen have to land inside the same setup-and-hold window. The chips do not care how you achieve that — they care that the electrical distances are equal. So the router pads the short traces until every path is the same length, converting spare board area into matched delay. Length matching is arithmetic done with copper.

The same logic drives the rest of the discipline: keeping high-speed traces short, placing decoupling capacitors close to the pin they serve, putting a crystal next to its oscillator, giving a return current an unbroken ground plane to follow underneath. Every one of those rules is a statement about distance disguised as a layout guideline. Our PCB and hardware design work starts from exactly these constraints.

The debugging lesson

Here is the part that pays for itself. When an embedded system fails timing, the instinct is to blame the firmware. Engineers reread the interrupt handler, add delays, tweak the SPI clock divider, and rewrite a driver that was never wrong.

Hopper's ruler suggests looking elsewhere first. If a sensor bus is unreliable at 20 MHz but fine at 2 MHz, that is not a logic bug — that is a physics problem with a layout cause. Long unterminated traces, mismatched pair lengths, a ground plane split by a careless via fence, a pull-up too far from the line it holds up. The signal is doing exactly what it should. It simply cannot be in two places at once, and you asked it to be.

The habit worth building: before you open the debugger, look at the board and ask how far the signal has to go, and whether every path that must arrive together actually has the same distance to cover.

Where this bites in IoT work

Connected devices make the problem broader, because the wire keeps going after it leaves the board. A sensor node in a Philippine warehouse might sample a value in microseconds, buffer it in firmware, hand it to an ESP32 radio, cross a LoRa gateway, traverse a few thousand kilometres of fibre and land in a cloud broker. Every segment is Hopper's wire again, just longer.

That is why sensible IoT architectures decide early what has to be fast and what merely has to be eventual. A safety interlock cannot wait for a round trip to a data centre — it belongs in local firmware, close to the hardware, where the distances are inches. A daily telemetry rollup can happily take the long path. Confusing the two is how teams end up with a control loop that depends on Wi-Fi uptime.

Distance is a design input, not an afterthought. Hopper understood that in the 1960s, well before anyone was building connected sensors, and the wire in her handbag still measures the systems we build now.

If you are working through timing, layout or architecture questions on a connected product, talk to our engineering team — we work these problems from silicon to cloud.

The Priority Inversion Bug That Rebooted Mars Pathfinder

fluidwire — Fri, 28 Aug 2026 21:12:56 +0000

Mars Pathfinder landed on 4 July 1997 and worked. The airbags did their job, the lander opened, the Sojourner rover rolled onto the surface, and the images came back. Then, a few days into the mission, the lander started rebooting itself.

Not once. Repeatedly, and without an obvious pattern. Each reset threw away the data the spacecraft had been working on and cost mission time that could not be recovered. The hardware was fine. The code had been tested. And the fault was 190 million kilometres away.

What actually went wrong

Pathfinder ran the VxWorks real-time operating system on a small set of tasks that shared an "information bus" — a chunk of memory protected by a mutex, so only one task could touch it at a time. Three of those tasks matter here.

A high-priority bus management task moved data in and out of the shared bus on a strict schedule. A low-priority meteorological task (the ASI/MET instrument) occasionally published its data to that same bus, which meant it had to take the mutex. And in between sat a medium-priority communications task, which ran long and ran often.

The failure sequence: the low-priority weather task takes the mutex. Before it finishes, the high-priority bus manager wakes up, tries to take the same mutex, and blocks — correctly, because someone else holds it. Now the low-priority task needs to finish quickly so it can release the lock. Instead, the medium-priority comms task preempts it, because it outranks the weather task, and runs for a long time. The high-priority task is stuck waiting on a low-priority task that is not allowed to run.

That is priority inversion: a high-priority task is effectively blocked by a lower-priority one, with a middle-priority task doing the blocking. Meanwhile a watchdog timer was watching the bus manager. When the bus manager missed its deadline, the watchdog did exactly what a watchdog is supposed to do — it concluded the system had hung and reset the spacecraft.

The watchdog was not the bug. It was the only thing that noticed.

How JPL fixed it from Earth

The important part of this story is not the diagnosis, it is that a fix was possible at all.

JPL's software team, led by Glenn Reeves, had an identical unit on the ground. They reproduced the fault by running the same load, captured a trace, and found the inversion. VxWorks supported priority inheritance on mutexes — a scheme where a task holding a lock temporarily inherits the priority of the highest-priority task waiting on it, so it can finish and get out of the way. On Pathfinder, that flag was off.

Because the flight software had an onboard interpreter that could execute uploaded C, the team was able to send up a change that turned priority inheritance on for that mutex, on a spacecraft already on another planet. The resets stopped.

Why this matters if you build connected devices

It is tempting to file this under space-mission exotica. It is not. Every element of it shows up in ordinary embedded and IoT work.

The bug was in the interaction, not the code. No single task was written incorrectly. The fault only appeared when three tasks with three priorities contended for one lock under real timing load — which is precisely the condition your bench test does not reproduce. If your firmware uses an RTOS with shared resources, priority assignment is a design decision, not a detail to be tuned later.

Your watchdog is telling you something. A device that quietly reboots in the field looks, from a dashboard, like a device with flaky power or a bad radio. Instrument your resets: log the reason, log which task was running, and get that telemetry off the device. Pathfinder was debuggable because it reported enough to reconstruct what happened.

You are only as safe as your update path. The single most consequential engineering decision on Pathfinder was made before launch — building in the ability to change flight software remotely. A deployed fleet you cannot patch is a fleet you cannot rescue. Over-the-air firmware update is not a nice-to-have on a connected product; it is the difference between a bug and a recall. If you are scoping a connected product, our IoT and embedded services treat the update path as a first-class requirement rather than a later phase.

Reproduce before you patch. JPL did not guess. They had a replica and they made the failure happen on demand. For a commercial IoT deployment the equivalent is a hardware-in-the-loop rig that runs the same firmware under the same load as the field units.

The takeaway

The most famous embedded bug in history was a scheduling interaction between three well-written tasks, caught by a watchdog, diagnosed on a replica, and fixed by an uploaded patch. Nearly three decades of faster microcontrollers have not made priority inversion go away — an ESP32 running FreeRTOS with a shared I2C bus and a mutex can reproduce it on your desk this afternoon.

The lesson is that reliability in connected hardware comes from three habits: deliberate real-time design, telemetry that explains failures instead of just reporting them, and a tested remote update path. Get those right and a field bug is an inconvenience. Get them wrong and it is the end of the product.

Building an IoT or embedded product and want the firmware architecture right from the start? Get in touch with Fluidwire — we work from silicon to cloud.

The First IoT Device Was a Coke Machine

fluidwire — Thu, 27 Aug 2026 21:13:37 +0000

The first Internet of Things device was not a thermostat, a doorbell or a watch. It was a Coca-Cola vending machine on the third floor of Wean Hall at Carnegie Mellon University, and it went online in 1982 — seventeen years before anyone thought to call this category the Internet of Things.

Three flights of stairs

The computer science department's Coke machine sat on the third floor. The graduate student offices did not. Walking down to a machine that turned out to be empty was an ordinary annoyance, and a slightly worse one existed underneath it: even when the machine was stocked, a freshly loaded bottle had not been in the cooler long enough to be cold. You could make the trip, find the machine full, pay, and still lose.

David Nichols, Mike Kazar, Ivor Durham and John Zsarnay did what computer science graduate students do with an ordinary annoyance. They wired micro-switches into the machine's six dispensing columns, connected them to the department's PDP-10, and wrote a small server that reported the state of each column. Because the machine's lights indicated a column had been reloaded, the software could also track how long each column had been full — long enough to be cold, or not.

The status was queryable over the ARPANET. Anyone on the network — including people at other institutions, who had no plausible use for the information — could ask a vending machine in Pittsburgh whether it was worth the walk.

Why it counts as the first

It is tempting to file this as a campus prank, and it was partly that. But it satisfies every requirement of a connected device in the modern sense, and it is hard to find an earlier system that does.

There is a physical asset in the world whose state changes. There are sensors instrumenting that state directly, rather than a human reporting it. There is an embedded link from the sensors to a computer, a network protocol carrying the state off-site, and a remote client acting on data it did not gather itself. Nothing in that description would look out of place in a specification written this year.

What it did not have was the vocabulary. Kevin Ashton coined the phrase "Internet of Things" in 1999, in a presentation to Procter & Gamble about putting RFID tags on supply chain inventory. By then the pattern had been running unremarked for the better part of two decades.

The pattern has not changed

Strip out the PDP-10 and the ARPANET and the architecture is exactly what we deploy for clients today: a sensor on the physical thing, a microcontroller reading it, a network carrying the state somewhere useful, and a person or system consuming that state instead of guessing.

Modern versions of the same problem are more consequential than a warm bottle. A fuel tank at a remote site that gets checked with a dipstick once a week. A cold-chain freezer whose failure is discovered the following morning, along with the spoiled contents. A production line whose downtime is reconstructed from memory at the end of a shift. A water level that somebody drives out to read. In every case the fix is structurally identical to the Coke machine: measure it directly, publish it continuously, stop sending a person to look.

The hardware has become almost trivially cheap. An ESP32 costs a few hundred pesos, has Wi-Fi and Bluetooth on the die, and does more than that PDP-10 could. The engineering that still matters is everything around the sensor — what happens when the network drops (buffer locally, reconcile on reconnect), how the firmware gets updated once the device is installed somewhere inconvenient, what the power budget allows, and whether the thresholds and alerts are set so that people actually act on them rather than learning to ignore them.

The part that is easy to miss

The students did not build a dashboard because dashboards were valuable. They built it because they were tired of walking. The value of a connected device is almost never the data — it is the specific human action the data removes or triggers.

That is the useful test when scoping an IoT project. Not "what could we measure?" but "what does somebody currently walk over and check, guess at, or find out too late?" If there is no honest answer, the sensors will get installed, the dashboard will get built, and nobody will open it after the first month.

If there is an answer, the project usually pays for itself faster than anyone expects.

Fluidwire designs and builds connected systems for businesses in the Philippines — sensors, firmware, and the software that makes the data usable. Take a look at our IoT and web services, or tell us what you currently have to walk over and check.

Why Is It Called Bluetooth? A Viking King Named It

fluidwire — Wed, 26 Aug 2026 21:13:28 +0000

Bluetooth is named after a Viking king. Not a metaphor, not a backronym — an actual 10th-century Danish monarch, Harald "Bluetooth" Gormsson, whose runic initials are still printed on the logo of every pair of earbuds sold today. It was supposed to be a placeholder. Nobody got around to replacing it.

The codename that shipped

In 1997, Intel engineer Jim Kardach was working on a short-range radio project alongside teams at Ericsson and Nokia. All three companies had their own competing wireless efforts, and the whole point of the collaboration was to stop that — one specification, one radio, one certification programme, so that a headset from one vendor would talk to a phone from another.

Kardach had been reading Frans Gunnar Bengtsson's historical novel The Long Ships, set in the Viking age. Harald Gormsson, king of Denmark from around 958, is remembered for uniting the warring Danish tribes into a single kingdom and bringing Norway under the same rule — consolidation being the whole of his historical reputation. Kardach proposed the name as a working codename: a technology built to unite rival wireless standards, named after the king who united rival tribes.

The intent was that marketing would replace it before launch. The shortlist that was supposed to win included names like "PAN" (Personal Area Network), which ran into trademark problems. Deadlines arrived, the placeholder was already on every internal document, and Bluetooth went out to the world as the real name.

The logo is his initials

The nicest detail is the one almost nobody notices. The Bluetooth logo is not an abstract mark — it is a bind rune, two Younger Futhark runes overlaid into a single glyph. The runes are ᚼ (Hagall) and ᛒ (Bjarkan), standing for H and B: Harald Blåtand.

As for the nickname itself, the most common explanation is a dead or discoloured tooth. Another reading is that "blå" in Old Norse could mean dark rather than blue, and that "Bluetooth" may be a later, somewhat garbled rendering. The etymology is genuinely disputed. What is not disputed is that the engineers picked the name knowingly, and that the runes on the logo were deliberate.

Why the naming actually reflects the engineering

It would be easy to file this under trivia, but the origin story maps onto why the standard succeeded. Bluetooth won its slot not by being technically superior to every alternative but by being a unification play: a royalty-free specification, a single interoperability certification, and a radio design that could be manufactured once and sold worldwide. Interoperability was the product.

That legacy is why Bluetooth Low Energy now sits underneath so much of the connected-device landscape. BLE is what you reach for when a device needs to run for a year on a coin cell, talk to a phone with no infrastructure in between, and be commissioned by a non-technical user standing next to it. Wearables, asset tags, smart locks, medical peripherals, environmental sensors, and nearly every "hold your phone near the device to set it up" flow are BLE underneath.

Choosing the radio, not the brand

In practice, the interesting question in an IoT project is rarely "should we use Bluetooth" in the abstract. It is a power-and-range trade:

BLE — metres to tens of metres, very low power, phone as the gateway, excellent for commissioning and short-range telemetry. Weak when there is no phone or hub nearby.
Wi-Fi — building-scale, high bandwidth, needs existing infrastructure and a meaningfully larger power budget. Fine on mains, painful on batteries.
LoRa / LPWAN — kilometres, tiny data rates, years on a battery. Right for field telemetry, wrong for anything interactive.

Most connected products end up using more than one. A sensor might use BLE for setup and diagnostics and LoRa or Wi-Fi for the actual data path, because the constraints on those two jobs are completely different.

That is usually the first real conversation we have with clients here in the Philippines when a prototype needs to become a product: not which brand of radio, but what the power budget, range, and commissioning experience actually demand. If you are working through that trade-off on a connected device or a thesis prototype, get in touch — it is a much cheaper conversation to have before the PCB is laid out than after.

Meanwhile, the placeholder codename endures. A thousand-year-old Danish king is stamped, in runes, on roughly every consumer electronics device on earth.

Why Ctrl+Alt+Delete Takes Two Hands

fluidwire — Tue, 25 Aug 2026 21:13:54 +0000

Ctrl+Alt+Delete takes two hands, and that is not an accident of keyboard layout. It is a deliberate safety decision made in 1981 by one engineer, in about five minutes, for a machine that had not shipped yet -- and it remains one of the most useful design principles in embedded systems work today.

The problem: rebooting the first IBM PC was slow

David Bradley was one of the twelve engineers on the original IBM Personal Computer team in Boca Raton. Like everyone writing low-level code, he spent his days crashing the machine and restarting it. On the IBM PC that meant a cold boot: power off, power on, and then wait through the Power-On Self Test, which walked the full memory space checking every location. On a development machine being restarted dozens of times an hour, that wait was the bottleneck.

Bradley's fix was a warm boot -- a way to jump the processor back to the reset vector and skip most of the startup checks, without cutting power. The mechanism is simple and still recognisable to anyone who has written firmware: the BIOS keyboard interrupt handler watches for a specific key combination, writes a magic value into a known location in low memory, and jumps to the boot routine. The startup code reads that flag, sees the machine was already up, and skips the long memory test.

The design decision: make it hard to hit

The interesting part is not the reboot. It is the key choice.

A reset is a destructive action. On a development machine it costs you your work; on a shipped product it can cost a customer theirs. Bradley needed a combination that a person could not fire accidentally while typing, and he had a keyboard in front of him that made the answer obvious. On the IBM PC's Model F keyboard, Ctrl sat to the left of the A key and Alt sat to the left of the space bar -- both on the left hand. Delete lived on the numeric keypad, at the far right edge of the board. Reaching all three at once required both hands and an intentional, slightly awkward stretch.

That awkwardness was the feature. There is no plausible way to hit Ctrl+Alt+Delete while touch-typing a memo.

Bradley never intended it to reach users. It was an internal developer convenience, undocumented in the original manuals, and it leaked into the wider world the way most good shortcuts do -- by being useful. Years later, on a panel alongside Bill Gates, Bradley delivered the line he is still best known for: he may have invented it, but Bill Gates made it famous.

Why this still matters for connected devices

Every IoT product we build has at least one destructive action buried in it. A factory reset that erases provisioning credentials. A firmware rollback. A reset line that reboots the main MCU. A calibration wipe. Each one is a Ctrl+Alt+Delete, and each one needs the same question asked of it: how hard is this to trigger by mistake?

In practice, on real hardware, that question has a few standard answers:

Physical separation. Do not put the factory-reset button next to the pairing button on the enclosure, and do not put a reset pad where a mounting screw or an enclosure rib can press it. If both buttons must exist, require them held together -- the hardware version of Bradley's two-handed stretch.
Time as a gate. A long-press requirement (five or ten seconds) is cheap in firmware and eliminates almost every accidental trigger, because accidental presses are short.
Electrical robustness. A reset line with no pull-up and no filtering is a reset line waiting for an ESD event or a long cable run to fire it. Debounce in hardware where it matters, not only in software.
A watchdog is not a reset button. A watchdog timer exists to recover a hung system automatically. If it is firing in normal operation, that is a bug report, not a feature -- and it should be logged where the field team can see it.
Confirmation over the network. For a remotely triggered wipe or rollback, one API call should not be enough. Require a second confirming step, and make the destructive endpoint distinct from anything used routinely.

None of these are exotic. They are the kind of decisions that get made -- or quietly skipped -- in the first week of a hardware design, and they are cheap then and expensive later. A deployed sensor network that loses its credentials because a technician brushed a button during installation is not a user error. It is a firmware and enclosure design error, and it was preventable in 1981 terms.

The lesson, compressed

Good embedded design makes the common action easy and the irreversible action deliberately inconvenient. That is the whole of it. Bradley's shortcut is remembered because it was useful, but it deserves to be remembered because of the constraint he put on it -- he built a reset and then made it hard to reach, in the same sitting.

When we design and build connected hardware, that trade-off comes up in almost every review: which of these actions can the user never be allowed to trigger by accident, and what physically stops them? If you are building an IoT product and want that scrutiny applied to yours before it ships, get in touch.

Why Is It Called the Cloud? It Was a Diagram Symbol

fluidwire — Mon, 24 Aug 2026 21:15:14 +0000

There is a common assumption that "the cloud" is a marketing word invented sometime around 2010 to make renting servers sound weightless. It is older than that, and it is not a metaphor for weightlessness at all. It is a drawing convention — a shape engineers scribbled on whiteboards for decades before anyone thought to sell it.

The cloud started as a symbol for "not my problem"

Draw a network diagram by hand. You have boxes for the machines you control, lines for the cables you own, and then you reach the edge of your own responsibility — the telephone company's switching network, a carrier's backbone, the internet itself. You cannot draw what is in there. You do not know what is in there, and more importantly you do not need to: you hand data in one side and it comes out the other.

So engineers drew a cloud. A soft, deliberately vague blob, standing in for a system that is real, complicated, expensive and entirely somebody else's concern. The convention was well established in telecoms and networking diagrams long before commercial cloud computing existed — you can find it in ATM and frame-relay documentation through the 1990s, and the same idiom sits behind the phrase "out on the network cloud."

That is the whole origin. When utility computing became a commercial product in the mid-2000s — Amazon's EC2 opened to the public in 2006, and Google's Eric Schmidt used "cloud computing" on a conference stage the same year, which is usually credited with popularising the term — the industry did not invent a name. It reached for the symbol every engineer in the room already understood, because it described the product exactly: infrastructure you use without owning, inspecting or maintaining.

Why the abstraction is the actual product

This matters more than a naming trivia answer, because the cloud symbol is a promise about ignorance. It says: you may stop thinking about this part.

That promise is what you are buying. Nobody rents a virtual machine because they want a virtual machine; they rent one so they never have to source a rack, negotiate bandwidth or replace a failed drive at 2am. The value is the size of the blob — how much complexity fits inside the cloud shape and stays there.

It is also where the risk lives. Whatever you draw inside that cloud, you have chosen not to understand. That is fine right up until it is the thing that breaks.

Where the cloud boundary sits in an IoT system

Connected products make this concrete, because the line has to be drawn somewhere physical. On one side is a microcontroller with kilobytes of RAM, a battery budget and no fan. On the other is effectively unlimited compute that costs money per request and only exists when the network is up.

Deciding what goes where is one of the highest-leverage architecture calls in the whole build:

Push too much into the cloud and the device becomes a paperweight the moment connectivity drops. For a sensor in a Philippine warehouse with patchy Wi-Fi, or a field unit on cellular, that is not an edge case — it is Tuesday.
Push too little and you are shipping raw sample data at full rate, paying bandwidth and storage that scale linearly with fleet size, while burning battery on radio transmissions that carry almost no information.

The usual answer is neither extreme. The device filters, aggregates and makes time-critical decisions locally; it buffers to flash when the link is down and reconciles when it returns; the cloud gets summaries, exceptions and anything that needs history or cross-device context. Firmware handles what must be immediate and offline-tolerant. The backend handles what must be durable, queryable and shared.

Get that split right and the cloud genuinely is a blob you can stop thinking about. Get it wrong and you end up debugging across the boundary anyway — which is the one thing the cloud symbol was invented to spare you.

Silicon to cloud

The reason we describe our work as IoT and web services from silicon to cloud is that these are not two projects. The firmware decisions and the backend decisions constrain each other: your payload format sets your bandwidth bill, your buffering strategy sets your data-loss behaviour, your local decision logic sets how much downtime a customer actually notices.

If you are designing a connected product and trying to work out where that boundary belongs, tell us what you are building — it is usually a much shorter conversation than people expect, and it is far cheaper to have before the firmware is written than after.

The cloud is a real place full of real machines. It just got its name from a drawing that meant "do not look in here."

Why Wi-Fi Uses 2.4 GHz: The Microwave Oven Band

fluidwire — Sun, 23 Aug 2026 21:16:15 +0000

Every Wi-Fi router, every Bluetooth earbud, every Zigbee smart bulb and a huge share of the world's IoT sensors all crowd into the same narrow slice of radio spectrum: 2400 to 2483.5 MHz. It is the most congested unlicensed band on the planet.

It got that way because nobody wanted it. 2.4 GHz was the junk band — the frequencies regulators had set aside for machines that spray radio energy as a side effect of doing something else. Machines like your microwave oven.

The ISM bands were a place to put the noise

In the 1940s, international regulators faced a problem that had nothing to do with communication. Industrial heaters, medical diathermy equipment and, shortly after Percy Spencer's 1945 discovery at Raytheon, microwave ovens all emitted substantial RF energy. That energy was the point of the device, not a transmission, but it still leaked into the air and interfered with anyone trying to use those frequencies for radio.

The solution was zoning. The ITU designated a set of ISM bands — industrial, scientific and medical — as the places where this kind of RF-emitting equipment was allowed to operate. Anyone using an ISM band accepted that it would be noisy by design. 2.4 GHz was one of them, and microwave ovens settled at 2.45 GHz, right in the middle.

Worth killing a myth here, because it comes up constantly: 2.45 GHz is not the resonant frequency of water. Water has no meaningful resonance there. Microwave heating is broadband dielectric heating — polar water molecules being jostled by an alternating field — and it works across a wide range of frequencies. 2.45 GHz was chosen for practical reasons: it was an available ISM allocation, magnetrons for it were cheap to manufacture, and the penetration depth is right for cooking food through rather than searing the surface.

1985: the FCC opens the junk band

For decades that was the end of the story. Then in 1985, the FCC issued a ruling that turned the noisy leftovers into the most valuable spectrum in consumer electronics: it authorised unlicensed spread-spectrum communication in several ISM bands, including 2400–2483.5 MHz.

The reasoning was elegant. Spread-spectrum techniques — frequency hopping and direct-sequence — smear a signal across a wide band instead of concentrating it on one frequency. That makes the transmission robust against the kind of narrowband interference an ISM band is full of, and it makes the transmitter itself look like low-level background noise to everyone else. Devices could share the band without a licensing regime deciding who got what.

No licence meant no application, no fee, no spectrum auction, no waiting. Any manufacturer could ship a radio. And because ISM allocations were broadly harmonised internationally, a product designed for 2.4 GHz could be sold in most of the world without a different radio for every market.

That is why, when IEEE 802.11 arrived in 1997 and Bluetooth followed in 1998, both landed on 2.4 GHz. Zigbee and 802.15.4 did the same. Thread did the same. The band nobody wanted became the default.

The bargain: no protection from interference

Unlicensed spectrum comes with a condition that engineers deploying connected devices live with daily: you get no protection from interference. You may not cause harmful interference to licensed users, and you must accept any interference you receive. There is no regulator to complain to when the band gets crowded.

In a real deployment, "crowded" means: neighbouring Wi-Fi access points, every phone and laptop in the building, BLE beacons, wireless keyboards and mice, cordless phones, video senders, and yes — a microwave oven, whose leakage is small but sits directly on top of Wi-Fi channels 8 through 11.

For a shelf of consumer gear, that is an annoyance. For an IoT fleet, it is a design constraint with real consequences.

What this means when you deploy IoT

The ESP32 and similar Wi-Fi microcontrollers that anchor most connected-device projects are 2.4 GHz radios. They inherit every bit of this history, which shapes how a deployment should be engineered:

Channel planning is not optional. In 2.4 GHz Wi-Fi, only channels 1, 6 and 11 are genuinely non-overlapping. Surveying the site before installation, rather than after complaints start, is the cheapest reliability work available.
Budget for retries and gaps. Interference is intermittent by nature. Firmware should assume packets will be lost, buffer readings locally, and reconcile on reconnect. A sensor that drops data because the microwave ran for ninety seconds is a firmware problem, not a radio problem.
Watch the physical environment. In factories, hospitals and commercial kitchens the interference sources are industrial-scale, and they were there first — legally speaking, that is exactly what the band is for.
Consider whether 2.4 GHz is the right band at all. Sub-GHz options like LoRa trade bandwidth for range and penetration in a much quieter part of the spectrum. For low-rate telemetry across a campus or farm, that trade is often the right one.
Range is a promise you should measure, not read off a datasheet. Published figures assume clean air. Real sites have concrete, metal racks and neighbours.

None of this makes 2.4 GHz a bad choice. It is free, globally available, supported by cheap silicon, and it penetrates walls better than 5 GHz. It is simply a band with a specific character, and that character comes straight from the fact that it was zoned for ovens before it was zoned for networks.

The pattern is older than the technology

The 2.4 GHz story is a recurring one in engineering: a resource is written off as worthless, someone finds a technique that works despite the drawback rather than around it, and the worthless resource becomes essential. Spread spectrum did not clean up the junk band. It made the junk irrelevant.

If you are planning a connected-device deployment and want the wireless design pressure-tested before hardware is ordered — band selection, site survey, firmware behaviour under packet loss — get in touch with the Fluidwire team. Getting the radio decisions right early is considerably cheaper than sending a technician to every install site later.