DEV Community: fluidwire

Why Clocks Use a 32,768 Hz Crystal

fluidwire — Thu, 13 Aug 2026 21:17:59 +0000

Pry open almost any digital watch, alarm clock, or IoT sensor and you will find a tiny metal can, often shaped like a little cylinder, soldered next to the main chip. Stamped on it, if you can read the fine print, is an oddly specific number: 32,768 Hz. It is one of the most common components in all of electronics, and the number is not an accident. It is one of the most elegant design choices in the history of digital timekeeping.

The number is 2 to the 15th power

32,768 is exactly 2^15. That is the whole trick.

Digital circuits are built from flip-flops: simple one-bit memory elements. Chain flip-flops together and each one divides an incoming frequency by two. One flip-flop turns 32,768 pulses per second into 16,384. A second turns that into 8,192. Keep going, and after fifteen stages you have divided by 2^15 = 32,768, leaving you with exactly one pulse per second.

That one-pulse-per-second signal is the heartbeat every clock is built on. A cheap 15-stage binary counter, a component that costs almost nothing and draws almost no power, converts the crystal's buzz into a perfectly regular tick. No fractions, no rounding, no accumulating error from awkward division. Pick a frequency that is a clean power of two and the math falls out for free. That is why the industry standardized on 32,768 Hz rather than a round-sounding number like 30,000 or 50,000.

Why quartz, and why that frequency

Quartz is piezoelectric: squeeze it and it produces a small voltage, and conversely, apply a voltage and it physically deforms. Drive a precisely cut sliver of quartz with an oscillating voltage and it vibrates mechanically at a very stable resonant frequency, far more stable than anything you could build from resistors and capacitors alone. That stability is what makes a quartz watch keep time to within seconds a month.

The 32,768 Hz crystals used in clocks are usually cut in a tuning-fork shape and tuned to that frequency for a practical reason as well. It sits in a sweet spot: high enough to be stable and immune to slow drift, but low enough that the dividing circuitry sips almost no power. That last point matters enormously. A watch or a battery-powered sensor has to run for months or years on a coin cell, and a low-frequency clock is a big part of how it does so.

The idea goes back to 1927, when Warren Marrison and J. W. Horton built the first quartz clock at Bell Labs. By the time Seiko shipped the first quartz wristwatch, the Astron, in 1969, the approach was ready to take over consumer timekeeping. The 32,768 Hz standard has stayed with us ever since.

Where this shows up in embedded and IoT work

If you build connected devices, this crystal is quietly everywhere. A dedicated real-time clock (RTC) chip such as the DS3231 uses a 32,768 Hz reference to keep the date and time even when the main processor is asleep or unpowered. Microcontrollers like the ESP32 include a low-power oscillator input for exactly this crystal, so the chip can drop into deep sleep and still wake up on schedule.

That deep-sleep behavior is the foundation of battery-powered IoT. A field sensor might wake once a minute, take a reading, transmit it, and go back to sleep, drawing microamps in between. The thing counting down that minute is the 32,768 Hz clock. Get it right and a device runs for years on a single battery. Get it wrong, choosing a crystal with the wrong load capacitance, or laying out the traces carelessly so the oscillator does not start reliably, and you get devices that drift, miss their wake-ups, or fail intermittently in the field. Timekeeping bugs are some of the hardest to reproduce precisely because they only show up over long stretches of real-world running.

This is the kind of low-level detail that separates a prototype that works on the bench from a product that survives deployment. At Fluidwire we design IoT and embedded systems from silicon to cloud, and getting the fundamentals like clocking, power budgets, and reliable wake-up right is a big part of why our builds hold up in the field. If you are planning a connected product or a thesis prototype and want it engineered properly, get in touch.

The takeaway

The next time you see 32,768 stamped on a crystal, you will know it is not a random figure. It is 2^15, chosen so that fifteen simple halving stages land on exactly one tick per second, using a piezoelectric material that vibrates more steadily than almost anything else you could put on a board, all while barely touching the battery. It is a small, beautiful piece of engineering, and it has been keeping the world on time for the better part of a century.

The First Computer Bug Was a Real Moth

fluidwire — Thu, 13 Aug 2026 03:50:12 +0000

Every engineer who has ever chased a glitch through firmware has "debugged" something. The word is so ordinary now that almost nobody stops to ask where it came from. The answer is one of the best stories in computing history: on one particular day in 1947, the bug being removed from a computer was an actual insect.

A moth in Relay 70

On September 9, 1947, operators at Harvard University were running the Mark II Aiken Relay Calculator — a room-sized electromechanical machine built from thousands of relays, switches that physically clicked open and closed to represent ones and zeros. The Mark II started misbehaving, and the team went hunting for the cause. What they found was a moth that had become trapped inside one of the relays, physically obstructing the contacts and causing the fault.

The operators removed the moth, taped it into the machine's logbook, and wrote beside it: "First actual case of bug being found." That logbook page — moth still attached — survives today in the collection of the Smithsonian's National Museum of American History. It is one of the most famous artifacts in the history of computing.

Grace Hopper, the pioneering computer scientist who worked on the Harvard Mark series, loved to tell this story, and she is the reason most people know it. She was not necessarily present at the exact moment the moth was found, but she helped make the tale legendary, and her name is now inseparable from it.

Did the moth invent the word "bug"?

Not quite, and this is the part most retellings get wrong. Engineers had been calling technical faults "bugs" for decades before 1947. Thomas Edison used the term in the 1870s to describe glitches in his inventions, writing about "bugs" as small faults and difficulties that show up as a design gets closer to working. So the Harvard team already knew the word — that is exactly why the logbook joke lands. Writing "first actual case of bug being found" is funny because everyone already used "bug" to mean a metaphorical defect, and here was a real one.

What the moth story did do is cement the vocabulary and give "debugging" its perfect origin myth. The joke was too good not to spread, and it carried the words "bug" and "debug" from electrical engineering slang into the permanent language of software.

Why a 1947 moth still matters for modern IoT

It is tempting to file this away as trivia, but the moth points at something that has never stopped being true: the hard part of building computers is not making them work once — it is finding out why they stop working. In 1947 the culprit was a physical insect in a relay. Today the culprit might be a race condition in an interrupt handler, a memory leak that only appears after nine days of uptime, or a sensor that returns garbage in cold weather.

Embedded and IoT systems make this harder, not easier. A connected device often lives somewhere you cannot easily reach — on a rooftop, inside a machine, in a field far from the nearest engineer. You cannot open the logbook and look for a moth. Instead, the debugging has to be designed in from the start: clear logging, remote observability, watchdogs, and firmware that can be updated over the air when a bug does surface. A device that cannot tell you why it failed is a device that will eventually strand someone.

This is why we treat debuggability as a first-class feature when we build connected hardware and firmware, not an afterthought bolted on when something breaks. Good instrumentation early is the difference between a five-minute fix and a truck roll to a remote site.

The takeaway

The first computer bug was a moth, but the lesson is bigger than the insect. Every generation of technology finds new ways to fail, and the engineers who win are the ones who plan for failure before it happens. Nearly eighty years after that logbook entry, "debugging" still describes the most important work in the room.

If you are building an IoT product and want it to be diagnosable in the field instead of a black box, we would love to talk. We build reliable connected systems from silicon to cloud at fluidwire.com.

What Is Null Island? The 0,0 Where GPS Errors Go

fluidwire — Wed, 12 Aug 2026 03:52:47 +0000

There is a place that shows up on maps, has its own weather buoy, and is "visited" by data from all over the world — yet it does not exist. It is called Null Island, and it sits at 0 degrees latitude, 0 degrees longitude, in the open water of the Gulf of Guinea, a few hundred kilometers off the coast of West Africa. There is no land there. What there is, instead, is a story every engineer who works with location data should know.

Where the equator meets the prime meridian

Null Island marks the exact point where the equator (0 degrees latitude) crosses the prime meridian (0 degrees longitude). It is a real coordinate — you can point a boat at it — but the "island" is a fiction. The name started as an inside joke among geographers and stuck, to the point that some mapping datasets, like Natural Earth, deliberately place a tiny one-square-meter phantom landmass there. Not because anything is on it, but because giving 0,0 a label makes a very common mistake easier to spot.

Why so much data ends up at 0,0

Here is the practical part. In most systems, latitude and longitude are just two numbers, and the default value of a number that has not been set is often zero. So when a GPS module fails to get a fix, or a geocoder cannot resolve an address, or a sensor reading arrives with an empty location field, the coordinates that get recorded are frequently 0, 0.

The result is that Null Island becomes a kind of digital lost-and-found. Every dropped GPS fix, every unparsed address, every uninitialized location variable quietly piles up on the same point in the Gulf of Guinea. Plot a day of raw tracker data on a map and, if something is broken upstream, you will see a suspicious knot of points sitting exactly where nothing should be.

Null Island as a debugging signal

For anyone building connected devices, this is genuinely useful. A cluster of readings at 0,0 is one of the fastest ways to catch a data-quality problem, because it almost never happens by accident in the real world. If your fleet-tracking dashboard, asset tags or environmental sensors report positions at Null Island, you are almost certainly looking at one of a few familiar culprits:

A GPS receiver that reported a position before it had a valid satellite fix.
A firmware bug that sends the default 0,0 when the location struct is empty.
A backend that stored a null or failed coordinate as zero instead of rejecting it.

None of these are exotic. They are the everyday failure modes of location-aware IoT and embedded systems, and Null Island is the tell that surfaces them.

Catching it before it reaches your dashboard

The fix is to treat 0,0 as suspicious by default and validate coordinates as close to the source as possible. On the device, that means waiting for a real fix (checking fix quality and satellite count) before transmitting, and sending an explicit "no location" flag rather than a fake zero when there is nothing to report. On the server, it means range-checking incoming coordinates and quarantining anything that lands on Null Island — or anywhere else the data has no business being.

This matters even more in deployments spread across the kind of terrain common in the Philippines: farmland, fishponds, remote facilities and buildings with thick concrete where GPS fixes drop in and out. A tracker that briefly loses the sky and defaults to 0,0 can drag averages, trigger false geofence alerts, or quietly corrupt a day of logs. Validating location at the edge is the difference between a map you can trust and one full of phantom trips to the middle of the Atlantic.

The short version

Null Island is the point at 0,0 where the equator meets the prime meridian — no land, just open ocean, and a magnet for every broken or missing coordinate in the digital world. For IoT builders it is less a curiosity than a free diagnostic: if your devices show up there, your location pipeline has a gap worth closing. If you are designing a GPS or asset-tracking system and want that pipeline built to catch bad data before it reaches your reports, that is exactly the kind of work we do — get in touch and we can talk through your use case.

What Does LoRa Stand For? Long Range, Explained

fluidwire — Mon, 10 Aug 2026 21:14:39 +0000

Ask most engineers what LoRa stands for and you get a shrug. The answer is refreshingly literal: LoRa is short for "Long Range." It is a low-power wireless modulation that lets a battery-powered sensor send small packets of data across kilometers of open ground, and it has quietly become one of the backbones of modern long-range IoT.

Behind that plain name sits a clever piece of radio engineering borrowed from an unlikely source: radar.

Where LoRa came from

LoRa was developed by a small French startup called Cycleo, based in Grenoble. In 2012 the semiconductor company Semtech acquired Cycleo and turned the technology into a product line. Semtech still controls the physical-layer modulation itself, while an open networking standard called LoRaWAN — governed by the non-profit LoRa Alliance — defines how devices, gateways and servers talk to each other on top of it.

That split matters. "LoRa" is the radio trick; "LoRaWAN" is the protocol and network architecture built around it. People use the words interchangeably, but they are two different layers of the same stack.

The radar trick: chirp spread spectrum

The reason LoRa reaches so far on so little power is a technique called chirp spread spectrum (CSS). Instead of holding a steady frequency, a LoRa transmitter sends a "chirp" — a signal that sweeps smoothly up (or down) across a band of frequencies, exactly like the swept tones radar systems have used for decades.

Spreading the signal across a wide band this way gives it two useful properties. It is highly resistant to noise and interference, because a narrow burst of interference only clobbers a small slice of the chirp. And it holds up well against the Doppler shift and multipath reflections that scramble ordinary narrowband signals. The receiver can dig a LoRa chirp out from below the noise floor — which is why the range can stretch to roughly 15 kilometers in open rural terrain, and several kilometers even through the clutter of a town.

The trade-off is bandwidth. LoRa is deliberately slow, moving only a few hundred to a few thousand bits per second. You would never stream video over it. But for a soil-moisture probe or a water meter that needs to send a handful of bytes a few times an hour, that is exactly the right bargain: tiny data, enormous range, years of life on a single coin cell.

Why it matters for IoT — especially here

LoRa fills a gap that Wi-Fi and cellular leave wide open. Wi-Fi reaches tens of metres and drinks power. Cellular reaches everywhere but needs a paid SIM, a carrier and a hungrier radio. LoRa sits in between: a private, license-free (it runs in unlicensed ISM bands), long-range link you can own end to end for the cost of a gateway.

That profile is a strong fit for the Philippines, where deployments often span farmland, fishponds, remote facilities and buildings with thick concrete and patchy connectivity. A single rooftop LoRaWAN gateway can collect readings from hundreds of low-cost sensors spread across a barangay-sized area, with no recurring data fees and batteries that last for years rather than weeks. For agriculture monitoring, utility metering, cold-chain logging and campus asset tracking, it is frequently the most practical wireless choice on the table.

If you are weighing LoRa against Wi-Fi, BLE or cellular for a connected-device project, the right answer depends on range, data volume, power budget and cost — and it is worth getting that decision right before you commit to hardware. That is the kind of trade-off we help clients think through in our IoT and embedded services, and we are always happy to talk through a specific use case.

The short version

LoRa stands for Long Range, and it earns the name honestly: a radar-style chirp, spread across a wide band, that a coin-cell sensor can push for kilometers. It is not fast, and it is not meant to be. It is the connective tissue for the slow, sparse, far-flung data that a huge share of real-world IoT actually produces — from a single farm sensor to a city-wide network of meters.

What Does Wi-Fi Stand For? (Not Wireless Fidelity)

fluidwire — Mon, 10 Aug 2026 04:19:01 +0000

Ask most people what "Wi-Fi" stands for and you will hear the same confident answer: "Wireless Fidelity." It is one of the most widely repeated facts in tech, printed in textbooks and quoted in trivia nights. There is just one problem with it. It is not true. Wi-Fi does not stand for anything at all.

Where the name actually came from

In 1999, six companies formed an alliance to certify that wireless networking gear built on the new IEEE 802.11b standard would actually work together. The engineering name for that technology was accurate but hopeless as a consumer brand: "IEEE 802.11b Direct Sequence." Nobody was going to ask a store clerk for that.

So the alliance hired a branding firm, Interbrand, to come up with something memorable. Interbrand produced the name "Wi-Fi" as a short, catchy play on "hi-fi" (high fidelity), the term audio enthusiasts had used for decades to mean high-quality sound. The firm also designed the now-familiar yin-yang style logo. The whole point was to give a complicated engineering standard a friendly face.

Crucially, "Wi-Fi" was never an abbreviation. It does not expand into two words the way "laser" or "radar" does. It is a made-up brand name, chosen because it sounded good and rhymed with a concept people already trusted.

So where did "Wireless Fidelity" come from?

This is the part that fuels the myth. Shortly after the name launched, the alliance briefly used a marketing tagline: "The Standard for Wireless Fidelity." It was an attempt to give the invented word a reassuring meaning after the fact, a bit like inventing a backstory for a nickname. The slogan was short-lived and later dropped, but by then the damage was done. People assumed the tagline was the definition, and "Wi-Fi = Wireless Fidelity" spread as a false backronym that has never really gone away.

Phil Belanger, a founding member of the alliance, has said plainly over the years that the term does not stand for anything and that "Wireless Fidelity" was never the official meaning. The organisation itself, now the Wi-Fi Alliance, treats "Wi-Fi" as a trademark, not an acronym.

Why this matters for IoT

This is more than a fun piece of trivia. Wi-Fi went on to become one of the most important connectivity technologies on the planet, and a big reason is that regular people found it approachable. A clear, non-technical name lowered the barrier to adoption in exactly the way its creators hoped. Good naming is quiet engineering work, and it shapes how widely a technology spreads.

For the Internet of Things, Wi-Fi is now a workhorse. Low-cost microcontrollers like the ESP32 ship with Wi-Fi radios built in, letting a sensor, a smart plug, or a thesis prototype join an existing network and talk to the cloud over familiar protocols like HTTP and MQTT. Because almost every home and office already has a Wi-Fi network, connecting a new device often means nothing more than entering a password. That convenience is why so many connected-device projects reach for Wi-Fi before considering alternatives like Zigbee, LoRa, or cellular.

It is worth knowing the trade-offs too. Wi-Fi is power-hungry compared to protocols designed for battery life, so a coin-cell sensor that needs to run for a year usually calls for something leaner. Choosing the right radio for a given IoT product is one of the first real engineering decisions in a build, and it depends on range, power budget, data rate, and how many devices need to share the network.

The takeaway

Wi-Fi does not stand for Wireless Fidelity. It does not stand for anything. It is a brand name invented in 1999 to make a mouthful of a standard feel simple and trustworthy, and it worked so well that most of us never questioned it. The next time someone confidently tells you the acronym, you will know the real story.

At Fluidwire we design and build connected hardware and the web services behind it, from silicon to cloud, and picking the right wireless technology is part of that work from day one. If you are planning an IoT product or a connected prototype here in the Philippines, see what we do or get in touch and we will help you choose the right foundation.

Why Is It Called a Byte?

fluidwire — Fri, 07 Aug 2026 21:15:16 +0000

You have typed the word thousands of times. Every file size, every memory chip, every firmware image is measured in bytes, kilobytes, and megabytes. Yet almost nobody stops to ask a simple question: why is it called a byte, and why is it spelled with that odd "y" in the middle? The answer takes us back to 1956, to an IBM engineering team building one of the most ambitious computers of its era, and to a naming decision that still shapes how we design connected devices today.

Who coined the word byte?

The word byte was coined in July 1956 by Werner Buchholz, a German-born engineer working at IBM on the design of the Stretch, formally the IBM 7030. Stretch was IBM's attempt to build a supercomputer many times faster than anything before it, and the team needed a term for a group of bits handled as a single unit, typically the bits used to encode one character.

Buchholz deliberately spelled it "byte" rather than "bite." The reason was purely practical: in a world of memos, code listings, and hand-transcribed notes, "bite" was one careless typo away from "bit," and the two words meant very different things. Changing the vowel to a "y" made the new term visually distinct and typo-resistant. It is one of the earliest examples of an engineering team naming something with human error in mind, a habit good hardware and firmware teams still practice.

A byte was not always 8 bits

Here is the part that surprises most people. When Buchholz coined the term, a byte did not have a fixed size. On the Stretch, a byte could be anywhere from 1 to 8 bits depending on how the machine was configured. The word simply meant "the group of bits we operate on together," and different machines of the era used 6-bit, 7-bit, and 9-bit groupings.

The 8-bit byte only became the near-universal standard with the launch of the IBM System/360 in 1964. The System/360 was wildly successful, and its 8-bit byte, capable of encoding 256 distinct values, became the de facto unit that the rest of the computing industry adopted. To be precise, engineers often use the word octet for a group of exactly 8 bits, precisely because the term byte was historically ambiguous. When you see octet in a networking specification, that is the ghost of this old ambiguity.

Why this matters for IoT and embedded systems

This is not just trivia for the embedded and IoT world, it is the foundation of how we reason about every device we build. When we specify that a microcontroller has 320 KB of RAM or that an over-the-air firmware image must fit in 4 MB of flash, we are counting in the exact unit Buchholz named seventy years ago. On the resource-constrained hardware that powers most connected products, every byte is a budget line.

An ESP32 sensor node, a smart meter, or an industrial controller lives or dies by how carefully its firmware manages bytes. Buffer sizes, packet payloads, and memory maps all trace back to the humble 8-bit byte. A single MQTT message, a Modbus register, a sensor reading serialized for the cloud, each is measured and transmitted in bytes. Understanding that history sharpens the instinct to treat memory as the scarce, precious resource it genuinely is on embedded targets. If you want a deeper look at how we approach that discipline, our IoT and embedded services page walks through the process.

From a 1956 supercomputer to your pocket

There is a pleasing symmetry to it. The byte was born on a room-sized machine that cost millions and pushed the limits of 1950s engineering, and today the same unit describes the few kilobytes of RAM inside a chip that costs a couple of dollars and fits on a fingertip. The scale inverted completely, but the vocabulary held.

That continuity is part of why understanding tech history is useful rather than merely charming. The constraints that shaped early computing, scarce memory, careful naming, and a relentless focus on efficiency, are exactly the constraints that shape good IoT engineering now. At Fluidwire we build connected hardware and the web services behind it, from silicon to cloud, and we care about every byte along the way. If you have a product idea that needs to run lean on real hardware, get in touch and let us help you count them well.

The First Hard Drive Held Just 5MB

fluidwire — Thu, 06 Aug 2026 21:15:06 +0000

The phone in your pocket holds more data than every hard drive on Earth did for the first few years the technology existed. That sounds like hyperbole until you meet the machine that started it all: the IBM 350 RAMAC, the world's first commercial hard disk drive. When it shipped in 1956 it stored roughly 5 megabytes, weighed about a ton, and took up the floor space of two refrigerators. It is the direct ancestor of the fingernail-sized flash chips that now sit inside every connected sensor we build.

What was the IBM RAMAC?

RAMAC stood for "Random Access Method of Accounting and Control," and the random-access part was the revolution. Before it, business data lived on punched cards and reels of magnetic tape, both of which forced you to read records in order. If the record you needed was near the end of the reel, you waited while the tape spun past everything in front of it. IBM's 350 disk storage unit, the component that made the RAMAC system famous, let a computer jump straight to any record on demand.

It did this with fifty spinning aluminum platters, each 24 inches across, stacked on a common shaft and coated with the same iron oxide used in paint primer. A pair of read/write heads rode on a mechanical arm that moved up and down the stack and in and out across each disk to reach any of the roughly five million characters stored on the surfaces. The whole cabinet spun those platters at 1,200 RPM inside a box about the size of two household refrigerators standing side by side, and the unit weighed on the order of a ton.

Five megabytes, and it cost a fortune

By modern standards the capacity is almost comic. Five megabytes will not hold a single high-resolution photo today. Businesses in 1956 did not buy the RAMAC outright; they leased it for around 3,200 US dollars a month, which is well over 30,000 dollars a month in today's money. Storage was so expensive that engineers agonized over every byte, a discipline that has never fully left the embedded world.

That constraint is the thread connecting the RAMAC to modern IoT. When you are writing firmware for a microcontroller with a few hundred kilobytes of flash, you are practicing the same frugality the RAMAC's users lived by, just with the decimal point moved. The difference is that today the scarcity is a design choice for cost and power, not a hard limit of what the planet can manufacture.

From a ton of iron to a chip you cannot feel

The arc from 1956 to now is one of the steepest in engineering history. The same 5 megabytes that once demanded a ton of precision machinery now occupies a corner of a flash die too small to see clearly without magnification. A microSD card the size of a fingernail routinely holds tens of thousands of times more than the RAMAC did, draws a fraction of a watt, and costs a few dollars. That collapse in size, price, and power consumption is exactly what makes the modern Internet of Things possible: you cannot bury a one-ton disk drive inside a soil-moisture sensor, but you can absolutely fit gigabytes of logging storage there now.

Persistent local storage is quietly one of the most useful things in a connected device. It lets a sensor keep recording when the network drops, buffer readings until a gateway is in range, and hold the firmware image needed for a safe over-the-air update. Every one of those behaviors traces back to the idea the RAMAC introduced: data you can reach directly, whenever you need it.

Why this history matters for builders in the Philippines

For teams and students here building connected products, the RAMAC story is a useful reminder that hardware limits shape good design. The most reliable IoT devices we help build are the ones that respect their storage and power budgets rather than assuming infinite resources. Whether you are prototyping a thesis project on an ESP32 or planning a fleet of industrial monitors, thinking carefully about what you store, where, and for how long will save you grief later.

If you are designing a connected product and want a partner who sweeps from silicon to cloud, take a look at the IoT and web engineering services we offer, or tell us about your project and what you are trying to build. We would be glad to help you turn a constraint into a clean design.

The next time you drag a folder of a few megabytes to the trash without a second thought, spare a moment for the ton of spinning iron that once held the same amount, hummed in an air-conditioned room, and cost more per month than a house. That machine is why the tiny sensor on your desk can remember anything at all.

Why Is It Called Firmware?

fluidwire — Wed, 05 Aug 2026 21:14:14 +0000

If you have ever flashed an ESP32 or updated a router, you have worked with firmware. The word is so ordinary now that few people stop to ask where it came from or what the "firm" is doing in the middle of it. The answer goes back to 1967, when a computer scientist named Ascher Opler coined the term to describe something that was neither fully hardware nor fully software. That in-between layer is still the beating heart of every connected device we build today.

Who coined the word firmware?

The term first appeared in print in a 1967 issue of the trade magazine Datamation, in a short piece by Ascher Opler. At the time, computer designers were wrestling with a new idea: instead of hard-wiring a processor's instructions directly into its circuits, you could store a set of very low-level instructions, called microcode, in a special control memory inside the CPU. That microcode told the hardware how to interpret the machine instructions it received.

Opler needed a word for this microcode, because it did not fit the two categories everyone already used. It was not "hardware" in the sense of soldered transistors and copper traces, and it was not "software" in the sense of programs a user could freely load and change. It sat in between: more permanent than an application, but not physically fixed like a logic gate. So he called it "firm" ware, and the name stuck.

How the meaning shifted

Opler's original firmware lived deep inside the processor as microcode. Over the following decades, the meaning drifted outward. As read-only memory (ROM), then EPROM, then flash memory became cheap and common, engineers started using "firmware" for any low-level program stored in a device's non-volatile memory: the code that runs the moment you switch the device on, before any operating system or user application gets involved.

Today, when we say firmware, we usually mean exactly that. It is the program burned into the flash of a microcontroller, the boot code in a hard drive's controller, the software running a smart thermostat, or the sketch you upload to an Arduino. The "firm" quality is still there: it does not change on a whim like an app, but you can update it in the field when you need to, unlike a fixed circuit. That combination of permanence and updatability is precisely what makes modern connected products possible.

Why firmware matters for IoT

For an Internet of Things device, firmware is not a supporting detail. It is the product. A temperature sensor, a smart plug, an agricultural monitor, or an industrial controller is really just a small circuit board plus the firmware that decides how it behaves. That firmware handles reading sensors, managing power, talking to the network over protocols like MQTT or HTTP, and deciding what to do when the WiFi drops or the battery runs low.

Three things make firmware the make-or-break layer for connected devices. First, reliability: an IoT node might sit in a field or a wall for years, so its firmware has to recover cleanly from crashes, power loss, and flaky connections without a human nearby. Second, security: because these devices are exposed to the network, their firmware is the front line against attackers, which is why secure boot and signed updates matter so much. Third, updatability: good firmware supports over-the-air (OTA) updates, so a product can be patched and improved long after it ships. Get the firmware right and a cheap microcontroller becomes a dependable product; get it wrong and even the best hardware becomes an expensive brick.

From a 1967 word to today's devices

It is a small piece of history, but a telling one. Ascher Opler reached for a new word because the technology had outgrown the neat division between hardware and software, and that middle ground has only grown more important since. Every connected product now lives or dies on the quality of the code sitting just above its silicon.

At Fluidwire we design and write that firmware for embedded and IoT projects here in the Philippines, from thesis prototypes to production-ready connected devices. If you have an idea that needs to become working, reliable hardware, get in touch and let us build the layer between your silicon and your cloud.

Why Is It Called Baud Rate?

fluidwire — Tue, 04 Aug 2026 21:15:10 +0000

If you have ever wired up a microcontroller, you have typed something like Serial.begin(9600) without thinking twice about that number or its unit. That "9600" is a baud rate, and the word "baud" is not an acronym or a technical abbreviation. It is a surname. The unit is named after Jean-Maurice-Emile Baudot, a French telegraph engineer who, in 1870, invented one of the first practical digital character codes. More than a century and a half later, his name still appears in the setup line of nearly every embedded project on Earth.

Who was Emile Baudot?

Baudot was born in 1845 and worked for the French Telegraph Administration. In his era, sending text over a wire meant Morse code tapped out by hand, one operator per line, slow and prone to error. Baudot wanted something faster and more mechanical. Around 1870 he designed a system built on a 5-bit code: each letter, number, and punctuation mark was represented by a fixed pattern of five on-or-off signals. Five bits give 32 possible combinations, enough to cover the alphabet plus control functions when you use a couple of "shift" codes to switch between letters and figures.

His hardware was just as clever as his code. Operators used a five-key keyboard, pressing combinations with both hands to spell out characters. Baudot then multiplexed several operators onto a single telegraph line by giving each a rotating time slot, so one expensive wire could carry multiple messages at once. The French Telegraph Administration adopted his system in 1877, and versions of it spread across Europe and beyond. His 5-bit encoding, later refined into the International Telegraph Alphabet No. 2, was a direct ancestor of the ASCII that your firmware uses today.

From a name to a unit

Baudot's contribution was so foundational that engineers later named the unit of signaling speed after him. One baud equals one symbol, or signaling event, per second. In the simplest case, where each symbol carries a single bit, one baud equals one bit per second. That is why on a basic UART link running at 9600 baud, you are moving roughly 9600 bits per second.

It is worth being precise here, because baud and bits per second are often used interchangeably and they are not always the same thing. Baud measures how many symbols cross the wire each second. Bits per second measures how much actual data those symbols carry. When a modulation scheme packs multiple bits into each symbol, the bit rate climbs above the baud rate. For the plain, one-bit-per-symbol serial links common in embedded work, though, the two numbers line up, which is why we casually say "9600 baud" and "9600 bps" as if they mean the same thing.

Why this still matters in embedded and IoT

Open any datasheet for an ESP32, an Arduino, a Raspberry Pi Pico, or almost any sensor module, and you will find baud rates everywhere. UART links between a microcontroller and a GPS module, a fingerprint reader, or a debug console are all specified in baud. Common values like 9600, 57600, and 115200 are not random; they descend from a long line of standardized telegraph and modem speeds that trace back through Baudot's work.

Understanding the vocabulary is more than trivia. When two devices fail to talk, a baud-rate mismatch is one of the most common culprits: set one side to 9600 and the other to 115200 and you get nothing but garbage on the line. Knowing that baud is a symbol rate, not automatically a bit rate, helps you reason about timing budgets when you push a link fast or squeeze data through a noisy channel.

There is something fitting about a 19th-century telegraph engineer's name living on inside 21st-century connected devices. The physical layer has changed beyond recognition, from clattering electromechanical printers to silicon running at gigahertz, but the core idea of encoding characters as fixed patterns of bits and clocking them across a wire at an agreed rate is exactly what Baudot pioneered. Every connected sensor we build still rests on that foundation.

At Fluidwire we design IoT and embedded systems from silicon to cloud, and getting the fundamentals like serial timing right is where reliable products begin. If you are planning a connected device or debugging one that will not behave, get in touch or read more about what we do.

The First Solar Cell Was Built in 1954

fluidwire — Mon, 03 Aug 2026 21:19:45 +0000

On April 25, 1954, three scientists at Bell Telephone Laboratories in Murray Hill, New Jersey, showed reporters something that sounded like science fiction: a strip of silicon that turned ordinary sunlight into enough electricity to run a small radio transmitter and spin a toy Ferris wheel. Daryl Chapin, Calvin Fuller, and Gerald Pearson had built the first practical solar cell, and although few people that day understood what they were looking at, they were watching the birth of the technology that now keeps sensors alive on rooftops, farms, pipelines, and mountaintops all over the world.

Why "practical" is the important word

People had known that light could produce electricity since the 1800s. Charles Fritts coated selenium with a thin layer of gold in 1883 and made a working solar cell, but it converted less than 1% of the light that hit it into usable power. That is far too little to run anything real. For seventy years the photovoltaic effect stayed a laboratory curiosity, interesting but useless.

The Bell Labs breakthrough was efficiency. Their silicon cell converted roughly 6% of incoming sunlight into electricity, a jump that finally crossed the line from novelty to tool. The team stumbled onto it partly by accident while studying how silicon behaved when doped with impurities, the same materials science that had produced the transistor at the same lab a few years earlier. Solar power and modern electronics grew from the same silicon roots.

From satellites to your backyard

The first real customer was not a home or a factory but outer space. Batteries could not keep a satellite running for years, but the Sun never sets in orbit. The Vanguard 1 satellite, launched in 1958, carried a handful of silicon solar cells, and they kept its radio beeping long after its chemical battery died. That success made photovoltaics the default power source for spacecraft and proved that solar could be reliable where nothing else could reach.

Prices fell slowly for decades, then dramatically in the 2000s and 2010s as manufacturing scaled. What was once a technology reserved for space missions is now cheap enough to glue onto a garden light. That collapse in cost is exactly what makes solar interesting for connected devices.

Why this matters for IoT

The hardest problem in the Internet of Things is rarely the code. It is power. A sensor bolted to a bridge, buried in a field, or mounted on a shipping container has no wall socket, and sending someone to swap a battery every few months destroys the economics of a large deployment. This is where the 1954 breakthrough pays off. A small photovoltaic panel, paired with a rechargeable cell or a supercapacitor, can let a low-power device run for years with no human intervention. Engineers call this energy harvesting, and it is one of the design decisions that separates a prototype from a product that can actually ship at scale.

Modern microcontrollers such as the ESP32 have made this practical from the other direction too. Deep-sleep modes draw only microamps, so a device can nap for most of the day, wake to take a reading, transmit it, and sleep again. A modest solar cell only has to gather more energy than that tiny duty cycle spends. Match a good power budget to a good panel and the battery becomes a buffer rather than a lifeline.

Getting that balance right is genuinely hard. You have to estimate worst-case sunlight for the install location, size the storage for cloudy stretches, and shave every unnecessary milliamp out of the firmware. It is the kind of end-to-end thinking, from the silicon in the sensor to the cloud that receives its data, that we care about at Fluidwire.

The through-line

The story of the solar cell is a reminder that the components inside a connected device usually have long histories. The panel trickle-charging a remote sensor traces back to a 1954 press demo. The chip reading that sensor traces back to the transistor and the integrated circuit. None of it was designed for the Internet of Things, because the Internet of Things did not exist yet. Good embedded engineering is often the craft of combining decades-old inventions in a new and useful way.

If you are building a connected product that has to survive in the field without a power cord, we would love to help you get the power budget right. Tell us what you are working on.

The MOSFET: The Most Manufactured Object Ever

fluidwire — Sun, 02 Aug 2026 21:14:39 +0000

Ask someone to name the most manufactured object in human history and you will hear guesses like nails, screws, bricks, or bottle caps. The real answer is invisible to the naked eye: the MOSFET, the tiny transistor that switches and amplifies the electrical signals inside virtually every chip you own. By one widely cited estimate, around 13 sextillion (that is 13,000,000,000,000,000,000,000) MOSFETs were manufactured between 1960 and 2018 — making it, by a vast margin, the most-produced device our species has ever built.

What a MOSFET actually does

MOSFET stands for metal-oxide-semiconductor field-effect transistor. Strip away the jargon and it is essentially a voltage-controlled switch with no moving parts. A small voltage on its "gate" terminal controls whether current can flow between its other two terminals. Pack billions of these microscopic switches onto a sliver of silicon, wire them into logic gates, and you have the digital brain of a microcontroller, a processor, or a memory chip. Every "1" and "0" your devices shuffle around is, at the bottom, a MOSFET turning on or off.

Because the MOSFET switches with almost no standing current — it mostly draws power only when it changes state — it is extraordinarily energy efficient. That single property is what makes battery-powered, always-on electronics practical, from your phone to the sensor nodes that quietly report data in an IoT network.

Invented at Bell Labs in 1959

The MOSFET was invented by Mohamed M. Atalla and Dawon Kahng at Bell Labs in 1959. Their breakthrough built on Atalla's earlier work on surface passivation — the discovery that a thin, thermally grown layer of silicon dioxide could stabilise and protect the silicon surface. That oxide layer turned out to be the perfect insulator for the transistor's gate, and it is the reason silicon (rather than germanium) became the foundation of the entire semiconductor industry.

At first the MOSFET was overshadowed by the older bipolar junction transistor. But as manufacturers learned to shrink it, its low power draw and superb scalability won out. The complementary pairing of two MOSFET types — CMOS — became the dominant way to build digital logic, and it still is today.

Why the MOSFET matters for IoT

Modern connected devices live and die by their power budget. A soil-moisture sensor buried in a field, a wearable, or a smart meter may need to run for months or years on a coin cell. That is only possible because the CMOS logic inside their microcontrollers — built from millions of MOSFETs — sips power when idle. When engineers talk about putting an ESP32 into deep sleep to stretch battery life, they are ultimately exploiting the physics of the MOSFET.

The relentless shrinking of the MOSFET is also why capable microcontrollers now cost less than a cup of coffee. Cheaper, smaller, lower-power transistors are the quiet reason it is now economically sensible to add intelligence and connectivity to almost any product. Understanding that building block helps teams make better decisions about which platform to target, how to budget power, and where the real cost of a design lives.

From silicon to cloud

The MOSFET is a good reminder that every connected product rests on a deep stack — from the transistor physics on the die, up through firmware and radio protocols, to the cloud services that store and act on the data. Getting that whole stack right is exactly the work we do at Fluidwire. If you are building a connected device and want a partner who understands it from the silicon up, tell us what you are working on or take a look at our services.

The next time you pick up a phone or glance at a smart sensor, remember that it runs on billions of copies of a 1959 invention — the most manufactured object the world has ever made.

How Hedy Lamarr Helped Invent Modern Wireless

fluidwire — Sat, 01 Aug 2026 21:15:07 +0000

One of the biggest movie stars of the 1940s also holds a patent that helps explain how nearly every wireless device on Earth avoids interference. Her name was Hedy Lamarr, and in 1942 she co-invented a technique called frequency hopping spread spectrum -- an idea that quietly became a foundation of Bluetooth, Wi-Fi, GPS and the modern Internet of Things.

The actress who tinkered

Hedy Lamarr was marketed by Hollywood as a glamorous leading lady, but off-set she was a self-taught inventor who kept a drafting table in her home. During World War II she wanted to help the Allied war effort, and she focused on a specific problem: radio-guided torpedoes were easy to defeat because an enemy could find the single frequency the control signal used and jam it, sending the torpedo off course.

Working with the avant-garde composer George Antheil, Lamarr designed a system where the transmitter and receiver would rapidly and simultaneously switch across many different radio frequencies in a shared, secret pattern. If the signal never stayed on one frequency long enough to be found, it could not be reliably jammed. Antheil, who had once synchronized sixteen player pianos for a concert piece, contributed the mechanism: a punched paper roll, like the ones in a player piano, that stepped both ends of the link through the same sequence of 88 frequencies -- the same number as the keys on a piano.

A patent ahead of its time

The pair received US Patent 2,292,387, "Secret Communication System," on August 11, 1942, filed under Lamarr's married name at the time. The US Navy, however, shelved the idea. The mechanical implementation was considered impractical for wartime hardware, and the patent expired before it was ever used in the conflict it was designed for.

The concept was simply waiting for electronics to catch up. Once transistors and later integrated circuits replaced paper rolls and relays, switching frequencies thousands of times per second became trivial. By the 1950s and 60s the military was building spread-spectrum radios on exactly this principle, and by the time the patent's ideas entered the commercial world, they had become part of the invisible plumbing of wireless communication.

Why frequency hopping still matters for IoT

If you have ever wondered how dozens of Bluetooth devices share a crowded room without drowning each other out, the answer is frequency hopping. Classic Bluetooth hops across 79 channels up to 1,600 times per second, and Bluetooth Low Energy -- the version that powers most battery-operated IoT sensors -- uses an adaptive hopping scheme to dodge interference from Wi-Fi and microwaves. The broader family of spread-spectrum techniques also underpins Wi-Fi, GPS and cellular networks.

For anyone building connected hardware, this history is a useful reminder that reliability in the real world is mostly about coexistence. A temperature sensor on a factory floor, a smart meter in an apartment block, or a fleet of asset trackers all have to work in noisy, shared radio space. The protocols that make that possible trace a direct line back to a wartime patent from 1942.

Building on these foundations today

At Fluidwire we work with these wireless building blocks every day -- choosing between Bluetooth Low Energy, Wi-Fi, Zigbee and LoRa depending on range, power budget and how much interference a deployment has to survive. For teams and students here in the Philippines prototyping thesis projects or products on ESP32 and similar boards, understanding why a protocol hops frequencies is often the difference between a demo that works on the bench and one that survives a real building full of competing signals.

If you are planning a connected product and want help choosing the right wireless stack, take a look at our services or get in touch -- we build IoT and embedded systems from silicon to cloud.

Hedy Lamarr was inducted into the National Inventors Hall of Fame in 2014, decades after her film career ended and long after most people had forgotten she was ever an engineer. The next time your earbuds pair without a hitch in a crowded coffee shop, there is a small piece of a 1940s movie star's idea making it happen.