DEV Community: fluidwire

The Unix Epoch and the Year 2038 Problem

fluidwire — Mon, 20 Jul 2026 21:15:56 +0000

Ask a computer what time it is and, underneath the friendly clock on your screen, it is really counting one number: the seconds elapsed since midnight UTC on January 1, 1970. That instant is called the Unix epoch, and it is one of the quietest, most load-bearing decisions in all of computing. It is also the source of a ticking deadline that matters more to embedded and IoT engineers than almost anyone else: the Year 2038 problem.

What is the Unix epoch

Unix time is a way of representing a moment as a single integer: the count of seconds since 00:00:00 UTC on January 1, 1970. No time zones, no months, no leap-year arithmetic in the stored value -- just a running tally of seconds. Right now that number is somewhere north of 1.7 billion.

The design dates back to the early development of the Unix operating system at Bell Labs around 1970, and its appeal was simplicity. Storing time as one number makes it trivial to compare two moments (subtract them), to measure a duration, or to sort events. That elegance is exactly why Unix time spread far beyond Unix itself. It underpins Linux, macOS, most databases, network protocols, file systems, and the firmware inside a huge share of the world's microcontrollers and connected devices.

Why 1970

There is no cosmic significance to 1970. The Unix developers needed an arbitrary zero point that was recent enough to keep the numbers small, and the start of the decade in which they were working was a clean, convenient choice. Once real systems began storing dates relative to that epoch, changing it became impossible -- every timestamp in every file and database would have shifted. So 1970 stuck, and it will stay the zero point of computer time for the foreseeable future.

The Year 2038 problem

Here is where the tidy design meets hard arithmetic. For decades, that seconds counter was stored in a signed 32-bit integer, a data type called time_t on Unix-like systems. A signed 32-bit integer can only count up to 2,147,483,647. Unix time will reach that value at 03:14:07 UTC on January 19, 2038.

One second later, the counter overflows. Instead of ticking up, it wraps around to the most negative value it can hold, and the system suddenly believes the date is December 1901. Timers break, certificates appear invalid, scheduling logic misfires, and anything that compares timestamps can behave unpredictably. This is the Year 2038 problem, sometimes called Y2038 or, more dramatically, the "Epochalypse." It is the direct structural cousin of the Y2K bug, but rooted in binary math rather than two-digit years.

Why this matters for IoT and embedded systems

Desktop and server operating systems have largely moved on. Modern 64-bit builds of Linux and other systems store time_t as a 64-bit integer, which pushes the overflow roughly 292 billion years into the future -- comfortably not our problem.

The risk lives in embedded systems and IoT devices. A great many microcontrollers, industrial controllers, smart meters, and sensor nodes still run 32-bit firmware, often because the hardware is cheap, low-power, and more than capable for its job. The catch is lifespan. A building automation controller, a utility meter, or an industrial gateway is frequently designed to sit in the field, untouched, for fifteen to twenty years. A device deployed today can easily still be running in 2038. If its firmware, its filesystem timestamps, or its TLS certificate handling assume a 32-bit time_t, it can fail on a date that is already within its planned service life.

The fix is conceptually simple -- use 64-bit time representations, and test how the system behaves as the clock rolls past the 2038 boundary -- but retrofitting a fleet of deployed devices is expensive and sometimes impossible. That is why the smart move is to design for it now, at the firmware and data-model stage, rather than discovering the problem after thousands of units are already installed.

Building devices that outlast the deadline

The Unix epoch is a reminder that the assumptions baked into low-level firmware quietly outlive the engineers who made them. Time handling is exactly the kind of detail that is invisible when a product ships and catastrophic when it fails a decade later. If you are building connected hardware meant to run for many years, it is worth auditing how it stores and compares time early in the design.

That is the sort of long-horizon embedded and IoT work we focus on at Fluidwire. If you want a second set of eyes on your firmware's time handling, or help designing connected systems built to last, we would be glad to talk through your project -- from silicon to cloud.

The QR Code Was Invented in 1994 to Track Car Parts

fluidwire — Sun, 19 Jul 2026 21:14:36 +0000

Scan a menu, pay a bill, onboard a smart plug, and you are using a piece of technology that was never meant for any of those things. The QR code was invented in 1994, and its original job was tracking car parts on a factory floor. Understanding why it was built the way it was explains why it now shows up on nearly every connected device.

Who invented the QR code

The QR code was created in 1994 by a team led by engineer Masahiro Hara at Denso Wave, a subsidiary of the Toyota group in Japan. At the time, the automotive industry ran on standard one-dimensional barcodes, the striped labels still seen on grocery products. Those barcodes held very little data, usually around 20 characters, and a busy assembly line often needed a worker to scan ten different labels on a single box of components. It was slow, and it was error-prone.

Hara wanted a code that could store far more information and be read much faster. His answer was to go two-dimensional: instead of encoding data only in the width of vertical bars, a QR code (short for "Quick Response") stores data across a grid of black and white squares, packing in thousands of characters in a fraction of the footprint.

The board game that shaped it

The most famous detail of the QR code's origin is where Hara found his design inspiration. He was reportedly playing the board game Go on a lunch break, staring at the black and white stones arranged on the grid, when the idea of encoding information in a two-dimensional matrix of light and dark cells clicked into place.

The harder problem was speed. A scanner needs to find the code and figure out its orientation before it can read anything, and in a factory a label might be rotated any which way. Hara's team solved this with the three distinctive square markers in the corners of every QR code. Those "position detection patterns" use a ratio of black to white areas that almost never occurs by chance in printed material, so a scanner can instantly locate the code and work out its angle. That is why you can point a phone at a QR code sideways or upside down and it still reads in an instant.

Why QR codes became universal

Denso Wave patented the QR code but made a decision that changed its future: the company chose not to enforce the patent against people using the standard, effectively keeping it open and royalty-free. Anyone could generate and read QR codes without paying a license fee. That openness, combined with the rise of smartphones with built-in cameras, is exactly why the format spread from Japanese factories to the entire world.

There is also resilience built in. QR codes include error correction, so a code can still be read even when part of it is dirty, torn, or obscured, depending on the correction level chosen when it is generated. For industrial and outdoor use, where labels take a beating, that robustness matters as much as capacity.

What this means for IoT and embedded systems

The QR code's journey from parts tracking to global standard is a story every IoT team should appreciate, because the same design now does real work in connected devices. Manufacturers print QR codes on device housings to encode serial numbers and provisioning data. Setup flows for smart-home hardware ask you to scan a code to join a device to Wi-Fi or bind it to a cloud account. Asset-tracking systems across warehouses and factories still lean on them for exactly the reason they were invented: fast, cheap, reliable identification.

For engineers building connected products, QR codes are a quietly powerful tool. They cost nothing to generate, need no radio or power on the label side, and let a phone act as a universal reader for onboarding and diagnostics. A well-placed code on a board can carry a firmware version, a device ID, or a link to a provisioning page, turning a plain enclosure into something a technician or end user can act on immediately.

That is the kind of detail that separates a prototype from a product. If you are developing IoT or embedded hardware and want the web and provisioning side handled properly, from silicon to cloud, Fluidwire can help. The best engineering, like the QR code, solves one problem so cleanly that it ends up everywhere.

Tesla Built the First Wireless Remote Control

fluidwire — Sat, 18 Jul 2026 21:14:13 +0000

In 1898, years before radio broadcasting existed and decades before anyone used the word "electronics," Nikola Tesla stood in front of a crowd at Madison Square Garden and did something that looked like magic. In a large pool of water sat a small iron-hulled boat. With no wires connecting them, Tesla sent commands through the air and the boat obeyed, turning, stopping, and blinking its lights on demand. Spectators were so unprepared for the idea that some accused him of hiding a trained monkey inside the hull, or of controlling it with his mind. What Tesla had actually built was the first wireless remote control, and it is the direct ancestor of every connected device we make today.

A machine that took commands through the air

Tesla called his invention a "teleautomaton," from the Greek for "remote" and "self-acting." The boat carried a radio receiver, a set of relays, and a battery driving its motor and rudder. From a control box on the side of the pool, Tesla transmitted radio signals that the receiver decoded into physical actions. Press a control, and a coherer-based circuit closed a relay, which in turn stepped the boat's steering and switching mechanism to a new position.

The patent behind the demonstration, US Patent 613,809, "Method of and Apparatus for Controlling Mechanism of Moving Vessels or Vehicles," was granted in November 1898. Read today, it is startling how modern the thinking is. Tesla was not just wiggling a boat around a pool for show; he was describing a general system for sending control signals to a remote machine and having that machine act on them without a human physically present. That is the exact problem statement behind modern IoT, just with vacuum-era hardware.

Why nobody knew what to do with it

Tesla saw enormous potential. He imagined remotely piloted vessels, automated vehicles, and machines that could carry out instructions from miles away. He even pitched the concept to the US military as a radio-controlled torpedo. The reception was cool. The technology was so far ahead of its context that the people who might have funded it could not picture a use for it. Radio itself was barely understood, and the notion of trusting a machine to act on invisible signals struck many as a parlor trick rather than an engineering breakthrough.

That gap between invention and application is a recurring pattern in technology history. The same wireless-control principle would eventually reappear in garage-door openers, television remotes, drones, and industrial automation. But in 1898 the surrounding ecosystem of reliable radios, compact power, and cheap logic simply did not exist yet. The idea had to wait for the rest of the stack to catch up.

The direct line to modern IoT

Strip away the brass and the coherer, and Tesla's boat is doing exactly what a connected device does now. A sensor or a control surface generates an intent. That intent is encoded and sent wirelessly. A receiver on the far end decodes it and actuates something physical: a rudder, a relay, a valve, a motor. Every smart switch, every remotely managed industrial controller, and every fleet of connected robots is a descendant of that single loop of "send a signal, move the hardware."

What has changed in the intervening century is not the concept but the economics and the layers on top of it. Tesla needed a hand-built receiver and a room-sized imagination. A modern engineer reaches for a two-dollar microcontroller, a Wi-Fi or Bluetooth radio, and a lightweight protocol like MQTT, and gets far more reliable remote control than Tesla could have dreamed of. The addressing, the security, and the cloud dashboards are new. The core act of steering a machine you are not touching is not.

Building on a 125-year-old idea

There is something useful in remembering how old the fundamental idea is. When a client asks whether a piece of equipment can be monitored and controlled from anywhere, the honest answer is that the concept was proven in a Manhattan exhibition hall in the nineteenth century. The interesting work today is not proving that remote control is possible; it is making it dependable, secure, and affordable at scale, from the silicon up to the cloud.

That is the work we do at Fluidwire. Whether you are prototyping a connected product, wiring up sensors for a thesis project here in the Philippines, or bringing an industrial system online, the challenge is the same one Tesla was solving on the water in 1898, just with better tools. If you have a device you want to make smart and remotely controllable, get in touch and we will help you close the loop from silicon to cloud.

Who Invented USB? The 1996 Story

fluidwire — Fri, 17 Jul 2026 21:15:51 +0000

If you have ever plugged a keyboard, a flash drive, or an ESP32 dev board into a computer without thinking twice, you have Ajay Bhatt to thank. In 1996 a team led by the Intel engineer published the first Universal Serial Bus specification, and it quietly ended one of the most frustrating chapters in personal computing. The strangest part of the story is that Bhatt never made a cent from it.

The mess USB was built to end

To appreciate USB, you have to remember the tangle it replaced. Before 1996, connecting a device to a PC meant matching it to the right port from a confusing lineup: a serial port for the mouse, a parallel port for the printer, a PS/2 connector for the keyboard, and a fistful of expansion cards and jumper settings for anything more exotic. Each interface had its own cable, its own speed, and its own quirks. Adding hardware often meant opening the case, flipping DIP switches, and rebooting, hoping the machine would recognize the new device.

Bhatt, then a systems architect at Intel, watched his own family struggle to connect a printer and decided the whole model was broken. His pitch was simple: one port, one connector, hot-swappable, that any device could use and any user could plug in without reading a manual. That idea became the Universal Serial Bus, developed by a consortium of seven companies including Intel, Microsoft, Compaq, and IBM, with the 1.0 specification released in January 1996.

Why the inventor earned no royalties

Here is the detail that surprises people. Intel held patents related to USB, but the company made a deliberate choice to keep the standard royalty-free and open to any manufacturer. That decision is exactly why USB spread so fast: no licensing tollbooth stood between a hardware maker and a working port. Billions of USB connectors have shipped since, and Bhatt, now widely credited as the face of the invention, has said he never earned money from it directly. As he put it, he did not do it for the money but to bring about change.

It is a useful lesson about open standards. A proprietary, licensed connector might have earned Intel a short-term fee on every port. Instead, by giving USB away, the industry got a universal foundation that outlived dozens of competing interfaces. Openness scaled further than ownership ever could have.

From desktop convenience to the backbone of embedded work

USB was designed for keyboards and printers, but its plug-and-play DNA turned out to be perfect for hardware development. Today the fastest way to flash firmware onto a microcontroller is over USB. Boards like the ESP32, the Raspberry Pi Pico, and countless Arduino variants expose a USB port that handles power, programming, and serial debugging all at once. A student in Manila can prototype a connected sensor on a single cable that costs almost nothing, precisely because USB is universal and free to implement.

That accessibility matters enormously for the growing hardware scene in the Philippines. When the barrier to entry is a laptop and a five-dollar dev board, more engineering students and small teams can build real IoT prototypes, from flood sensors to agricultural monitors, without importing expensive proprietary programmers. The humble USB port is a quiet enabler of that whole ecosystem.

The takeaway

The story of USB is really a story about reducing friction. Bhatt looked at a pile of incompatible cables and asked why connecting a device could not be as simple as plugging it in. The answer reshaped computing and, decades later, still shapes how connected devices get built and deployed.

At Fluidwire we work in that same spirit, turning messy hardware and software problems into clean, reliable connected systems from silicon to cloud. If you are building an IoT product or a web platform to run it, get in touch and let us help you make the complicated feel like plugging in a cable.

The First Barcode Scan Was a Pack of Gum

fluidwire — Thu, 16 Jul 2026 21:14:59 +0000

At 8:01 in the morning on June 26, 1974, a cashier at a Marsh Supermarket in Troy, Ohio slid a 10-pack of Wrigley's Juicy Fruit chewing gum across a new kind of scanner. A beep confirmed the price, and with that unremarkable purchase the barcode entered everyday life. That pack of gum, which cost 67 cents, was the first retail product ever scanned by a Universal Product Code. The pack and the receipt now sit in the Smithsonian Institution.

It is easy to overlook how radical that beep was. For the first time, a machine had read a physical object and turned it into data without anyone typing a single digit. That is the whole idea behind automatic identification, and it runs in a straight line from a gum wrapper in Ohio to the connected sensors and tracked assets at the heart of modern IoT.

From a bullseye in the sand to a striped label

The barcode did not begin as the familiar pattern of vertical black lines. Its origins trace back to a 1952 patent filed by Norman Joseph Woodland and Bernard Silver, two graduate students who wanted to help a grocery chain automate checkout. Woodland's insight came, by his own account, while sitting on a Florida beach: he drew Morse code dots and dashes in the sand, then dragged his fingers downward to stretch them into thin and thick lines. His first working design was actually a circular bullseye, so it could be read from any angle.

The bullseye was elegant but hard to print cleanly, and the technology to read it cheaply did not exist yet. It took two more decades, the invention of the laser and the low-cost integrated circuit, before the idea became practical. When a committee finally standardized the Universal Product Code in 1973, they chose the now-iconic rectangular stripe pattern designed by IBM engineer George Laurer. The gum was scanned less than a year later.

Why a barcode is really an IoT ancestor

Strip away the retail context and a barcode is a beautifully simple protocol: a way to encode a small amount of structured data onto a physical object so that a machine can read it reliably, at speed, without human error. That is exactly the problem every connected device solves at a larger scale.

The barcode was the first mass-deployed member of the auto-ID family. Its direct descendants are everywhere in embedded and connected systems. The QR code added two dimensions and far more data. RFID removed the need for line of sight, letting a reader energize a passive tag from a distance. Today those same principles power smart shelves that report their own stock, warehouse robots that navigate by scanning fiducial markers, and asset trackers that log every step of a supply chain to the cloud. In each case the goal is unchanged from 1974: let the physical world describe itself to the network.

What this means for building connected products

The lesson of the gum pack is that the hard part of IoT is rarely the cloud dashboard. It is the reliable, cheap, physical act of turning a real object or a real measurement into trustworthy data at the edge. A barcode had to survive smudged printing, bad lighting, and a bored cashier moving fast. A modern sensor node has to survive noisy power, intermittent connectivity, and years in the field on a coin cell. The discipline is the same.

At Fluidwire we build that edge layer, from the silicon up to the cloud: the PCBs, firmware, and connectivity that let a product identify itself, sense its environment, and report back reliably. If you are turning a physical product or a thesis prototype into a connected system, our IoT and embedded services cover the full path, and you can get in touch to talk through what you are building.

The next time you hear a checkout beep, remember it started with a pack of gum, a beach, and a very old idea that machines should be able to read the world for us.

The First Computer Mouse Was Made of Wood

fluidwire — Thu, 16 Jul 2026 07:09:19 +0000

The device sitting next to your keyboard started life as a block of wood. In 1964, at the Stanford Research Institute in California, Douglas Engelbart and his lead engineer Bill English built the first computer mouse: a hand-carved wooden shell riding on two small metal wheels, with a single button on top and a cord trailing out the back. It looked nothing like the sleek pointing devices we use today, but every one of them is a direct descendant of that rough little prototype.

A wooden box on two wheels

Engelbart had been thinking for years about how to make computers easier for people to actually use. In the early 1960s a computer was something you fed punched cards or teletype commands; the idea that you might point at a screen and move things around was close to science fiction. Engelbart wanted a way to select text and objects on a display quickly and naturally, and after testing several ideas his lab landed on a small handheld box.

The first working unit was carved from wood. Underneath sat two metal wheels mounted at right angles to each other -- one tracked horizontal movement, the other vertical -- and as you slid the box across a desk, those wheels translated the motion into cursor movement on the screen. It was crude, but it worked, and in side-by-side tests it beat every other pointing method the team tried.

Why we call it a "mouse"

The name was never official. Because the connecting cord came out of the back of the device, the whole thing looked a bit like a mouse with a tail, and the nickname stuck around the lab. Engelbart later said no one could remember who first said it, but by the time the device reached the public it was simply "the mouse," and no formal name ever replaced it.

The world got its first look in December 1968, when Engelbart gave a live demonstration in San Francisco that has since become known as "The Mother of All Demos." In one sitting he showed the mouse, on-screen windows, hypertext links, and real-time collaborative editing -- a preview of computing decades ahead of its time.

The inventor who earned nothing from it

Here is the part that stings for any engineer. The patent for the mouse -- US Patent 3,541,541, filed in 1967 and granted in 1970 -- described an "X-Y position indicator for a display system." But the patent was owned by SRI, Engelbart's employer, not by Engelbart himself. It expired in the 1980s, right around the time the mouse was becoming a standard part of every personal computer thanks to systems like the Apple Macintosh. Engelbart never received a cent in royalties for one of the most widely used input devices ever created.

Why a 1964 prototype still matters for IoT

It is easy to file the wooden mouse under "fun history," but there is a real lesson in it for anyone building connected hardware today. The mouse was a triumph of the human-machine interface -- the layer where a person's intent gets translated into something a machine can act on. Engelbart did not just invent a gadget; he proved that the right interface can make a complex system feel simple.

That same problem sits at the heart of modern IoT. A smart sensor, a controller, or a connected appliance is only as good as the way people interact with it, whether that is a physical button, a capacitive touch pad, a companion app, or a voice command. The sensors and encoders that read a user's movement in that 1964 mouse are conceptually the ancestors of the accelerometers, rotary encoders, and touch controllers we wire into embedded boards every day.

There is also a design philosophy worth borrowing. Engelbart's team built a quick, ugly, functional prototype out of whatever was on hand, tested it against alternatives, and let the results decide. That rapid, evidence-driven approach to hardware is exactly how good connected products still get built -- prototype early, measure honestly, and refine.

The takeaway

The first computer mouse was a wooden box that its inventor never profited from, demonstrated at a conference most people have forgotten, and named after a rodent as a joke. It went on to shape how billions of people touch computers. Foundational interface decisions tend to outlive the recognition of the people who make them.

At Fluidwire we build IoT and web systems from silicon to cloud, and we spend a lot of time on exactly the problem Engelbart tackled: making the connection between people and hardware feel effortless. If you have a device idea that needs both solid electronics and a clean interface, get in touch.

Why ARM Chips Power Nearly Every IoT Device

fluidwire — Tue, 14 Jul 2026 21:15:48 +0000

Look inside almost any modern connected device -- a smartphone, a smartwatch, a Wi-Fi thermostat, a battery-powered sensor node -- and you will find a processor core designed by ARM. It is one of the most successful engineering ideas in computing history. And here is the strange part: ARM has never manufactured a single one of those chips. It does not own a factory. It sells blueprints.

A three-person project in Cambridge

The story starts at Acorn Computers in Cambridge, England, in the early 1980s. Acorn had built the BBC Micro, a hugely popular educational computer in the UK, and it needed a faster processor for its next machine. The commercial chips available at the time were disappointing, so a tiny team decided to design their own.

The acronym everyone knows today originally stood for Acorn RISC Machine. Sophie Wilson designed the instruction set and wrote the simulator; Steve Furber led the physical chip design. RISC -- Reduced Instruction Set Computing -- was the key bet. Instead of piling on complex instructions, they kept the instruction set small and simple, which made the chip easier to build, cheaper, and remarkably power-efficient.

The first silicon, the ARM1, was fabricated by VLSI Technology and delivered to Acorn on 26 April 1985. When the team powered it on, it simply worked -- first try. For anyone who has designed hardware, that is almost unheard of; new processors normally need several rounds of revisions to shake out design errors. A famous piece of Acorn lore is that the early ARM chips drew so little current they could keep running on leakage alone after the power was disconnected.

From a British computer to the whole world

Acorn the computer company faded, but the processor design did not. In 1990 the ARM team was spun out into a separate joint venture, and the acronym was quietly re-expanded to Advanced RISC Machines. The new company made a decision that defined its future: it would not build chips. It would license the designs and let other companies manufacture them.

That licensing model is why ARM ended up everywhere. A chipmaker can take an ARM core, wrap it in its own custom peripherals, radios, and memory, and ship a product without designing a CPU from scratch. Hundreds of companies did exactly that, and the low-power heritage from those Cambridge origins made ARM the natural choice as computing went mobile and then went embedded.

Why it matters for IoT and embedded design

For IoT specifically, that power efficiency is not a nice-to-have -- it is the whole game. A connected sensor deployed in the field might need to run for years on a coin cell or a small battery. The ARM Cortex-M family, the microcontroller-class cores, is built precisely for that: enough compute to run firmware and a network stack, sipping current the rest of the time in low-power sleep modes.

When you pick a microcontroller for a project -- an ESP32, an STM32, a Nordic nRF, a Raspberry Pi Pico -- you are almost certainly picking an ARM core underneath the vendor's branding. The architecture decision made at the silicon layer ripples all the way up through your firmware, your toolchain, and your battery budget. Understanding what ARM is, and why it was designed the way it was, helps you reason about those trade-offs instead of treating the chip as a black box.

The takeaway

ARM proves that owning the factory is not the only path to dominating an industry. A small team in Cambridge optimized for simplicity and low power, then chose to share the design rather than hoard it. Four decades later, that decision put their descendants inside a majority of the world's connected devices.

At Fluidwire we build IoT and embedded systems from silicon to cloud, and nearly every board we prototype has an ARM core at its heart. If you are turning a hardware idea into a working device, get in touch -- we can help you choose the right microcontroller and build the firmware around it.

Moore's Law Is a Prediction, Not a Law of Physics

fluidwire — Mon, 13 Jul 2026 21:15:21 +0000

You have heard the phrase a thousand times: "Moore's Law says computing power doubles every couple of years." It gets quoted like gravity, a fixed rule of the universe that chips simply have to obey. But Moore's Law is not a law of physics at all. It started life as an educated guess in a magazine article, and the fact that it held for half a century says more about human ambition than about silicon.

A four-page article, not a natural law

In April 1965, an engineer named Gordon Moore wrote a short piece for Electronics magazine titled "Cramming more components onto integrated circuits." At the time Moore was head of research at Fairchild Semiconductor; three years later he would co-found Intel with Robert Noyce. Looking at just a handful of data points, he noticed that the number of transistors manufacturers could economically fit on a single chip had been roughly doubling every year, and he predicted that pace would continue for at least another decade.

That was the whole claim. No equations of physics, no fundamental constant. Just an observation about a manufacturing trend and a bet that it would keep going. In 1975 Moore revised the estimate to a doubling roughly every two years, which is the version most people remember today.

Why a guess became a roadmap

Here is the part that makes Moore's Law fascinating. Because everyone in the industry believed the prediction, they organized their plans around it. Chipmakers set research budgets, equipment suppliers scheduled their next machines, and software companies designed for hardware that did not exist yet, all on the assumption that transistor counts would keep doubling on schedule.

The prediction became a self-fulfilling prophecy. Moore's Law worked not because nature demanded it, but because a whole industry treated it as a deadline and spent enormous effort meeting it. That is a very different thing from a physical law, and it is why engineers now openly debate whether the "law" is slowing down as transistors approach the size of individual atoms.

From room-sized computers to coin-sized IoT nodes

The reason any of this matters for connected devices comes down to two words: small and cheap. Every doubling meant more transistors in the same space, which in turn meant either more capability at the same price or the same capability at a lower price. Decades of that compounding is exactly why you can now buy a full 32-bit microcontroller, complete with Wi-Fi, for the price of a cup of coffee.

That trend is the quiet engine behind the entire Internet of Things. Putting a programmable brain and a radio into a light switch, a soil-moisture probe, or a wearable only makes sense when the silicon is nearly free. Moore's curve is what dragged the cost of "adding intelligence to an object" down to almost nothing.

What this means when you design hardware

Understanding Moore's Law as a prediction rather than a guarantee changes how you plan a product. You cannot simply assume next year's chip will be twice as good and design yourself out of a corner. The economically sensible choices, how much memory you actually need, how little power you can draw, how cheap the bill of materials can be at volume, are the same trade-offs engineers have wrestled with since 1965. The free lunch of automatic doubling is no longer something you can lean on.

Building on cheap silicon in the Philippines

For students, startups, and small manufacturers here in the Philippines, the upside of sixty years of Moore's Law is enormous. The hard part of building connected hardware is no longer affording the chip. It is the engineering around it: firmware that does not crash, a PCB that survives manufacturing, and a cloud backend that stays online.

That is the work we do at Fluidwire, from silicon to cloud. If you are turning a connected-product idea into something real and want a team that handles both the embedded side and the web services behind it, take a look at our services or get in touch. Moore's Law was only ever a bet on human effort, and it paid off spectacularly. The rest of the work is still up to the engineers.

The First Microcontroller Was the TI TMS1000 (1974)

fluidwire — Sun, 12 Jul 2026 21:15:51 +0000

Ask most people to name the chip that started modern electronics and they will say the microprocessor. But there is a quieter hero inside almost everything you own that beeps, blinks, or connects to the internet: the microcontroller. And the first one you could actually buy shipped in 1974 as the Texas Instruments TMS1000.

Microprocessor vs. microcontroller

The distinction matters. A microprocessor, like Intel's famous 4004, is just the processing core. To build anything useful with it you still have to wire up separate memory chips, input/output controllers, and support logic on a circuit board. A microcontroller collapses all of that onto a single piece of silicon: the CPU, the ROM that holds your program, the RAM that holds your data, and the I/O pins that talk to the outside world, all in one package.

That is exactly what the TMS1000 did. Designed by Texas Instruments engineers Gary Boone and Michael Cochran, it was a 4-bit device using a Harvard architecture, meaning it kept program memory and data memory in separate spaces so it could fetch an instruction and read data at the same time. One chip in, one chip out, and you had a complete tiny computer dedicated to a single job.

Cheap enough to put in everything

The genius of the TMS1000 was not raw power, it was economics. In 1974 you could buy the chips in volume for around two dollars each. By 1979, Texas Instruments was selling roughly 26 million of them every year. That price point changed what engineers could build. Suddenly it made sense to drop a small, programmable brain into products that never would have justified a full computer.

You have almost certainly held one. The TMS1000 family ran the Speak & Spell, the Big Trak programmable toy vehicle, and the electronic memory game Simon, along with countless calculators, microwave ovens, and appliances. Each one was doing the same fundamental thing an IoT node does today: read some inputs, run a fixed program, drive some outputs.

Why this still matters for IoT

Every connected sensor, smart plug, and wearable you build today is a direct descendant of that 1974 idea. The modern equivalents, an ESP32 or an STM32 or an Arduino's ATmega, are vastly more capable, but the architecture is the same story: put the processor, memory, and I/O on one low-cost chip so that adding intelligence to a physical object is nearly free. That is the entire premise of the Internet of Things.

Understanding this lineage is not just trivia. When you are choosing a microcontroller for a product, you are making the same trade-offs Boone and Cochran faced: how much memory do you actually need, how many I/O pins, how little power can you get away with, and how cheap can the bill of materials be at scale? Getting those answers right is the difference between a prototype and a product that ships.

Building on that heritage in the Philippines

For students and startups here in the Philippines, this history is encouraging. The barrier to building real connected hardware has never been lower. A capable 32-bit microcontroller now costs less than that original TMS1000 did in inflation-adjusted terms, and the tooling is free. Whether you are prototyping a thesis project or taking a smart-device idea to market, the hard part is no longer the silicon, it is the engineering around it: reliable firmware, a clean PCB, and a cloud backend that actually stays up.

That is the work we do at Fluidwire, from silicon to cloud. If you are turning an idea into a connected product and want a team that understands both the embedded firmware and the web services behind it, take a look at our services or get in touch. The chip that made all of this possible turned fifty this decade, and it is still teaching the same lesson: put a small, cheap brain in everything, and the everyday world becomes programmable.

Why Is It Called the Raspberry Pi?

fluidwire — Sat, 11 Jul 2026 21:20:05 +0000

If you have ever wired a sensor to a Raspberry Pi or run your first Python script on one, you have used a device whose name hides two small jokes and one very deliberate design decision. Why is it called the Raspberry Pi? The short answer: "Raspberry" is a nod to a decades-old tradition of naming computers after fruit, and "Pi" is short for Python, the programming language the board was originally built to run. Both halves say something about where the machine came from, and why it went on to become a staple of IoT and embedded development.

The fruit tradition behind "Raspberry"

The "Raspberry" is not random. In the early decades of personal computing, a surprising number of companies named themselves after fruit. Apple is the obvious one, but there was also Acorn Computers (the British firm whose ARM architecture now sits inside nearly every phone and microcontroller on Earth), Apricot Computers, and Tangerine. When Eben Upton and his collaborators at the University of Cambridge set out to build a cheap computer to teach kids to code, choosing a fruit name placed the project squarely in that lineage. Upton has also cheerfully admitted the name is a bit of a pun, a wink at "blowing a raspberry" and at raspberry pie the dessert.

Why "Pi" stands for Python

The "Pi" is the part that reveals the machine's original purpose. As Upton has explained in interviews, the plan was to produce a computer that could really only run one thing well: Python. So the "Pi" in the name is a compressed reference to Python. It doubles neatly as a nerdy nod to the mathematical constant, but Python was the driving idea.

That original intent matters because it explains the board's whole philosophy. The Raspberry Pi was never meant to be a powerhouse. It was meant to be cheap enough that a student could own one, simple enough that a beginner could learn on it, and open enough that it ran a full Linux operating system with Python ready to go. During development the design grew more capable than Upton first intended, but the education-first spirit stuck.

From classroom tool to IoT workhorse

Launched in early 2012, the Raspberry Pi found an audience far beyond the classroom. Its combination of low cost, general-purpose input/output (GPIO) pins, and a real Linux environment made it ideal for exactly the kind of work Fluidwire does every day: reading sensors, driving displays, talking to cloud services, and gluing hardware to software. Tens of millions of boards later, the Pi sits at the center of countless IoT and embedded projects, from home automation and environmental monitoring to industrial dashboards and machine-vision rigs.

For students and first-time builders in particular, the Pi lowered the barrier to real connected hardware. A thesis prototype that once needed an expensive development kit could now run on a board that cost about the same as a textbook. Pair it with a microcontroller like an ESP32 for the low-level sensor work and a Pi for the heavier processing, and you have a stack capable of shipping a genuine product.

The name as a design statement

It is easy to treat the name as a throwaway bit of branding, but "Raspberry Pi" actually encodes the project's values. The fruit half connects it to a computing heritage built on curiosity and accessibility. The Python half signals that this was, first and foremost, a tool for learning to program. Those two ideas, approachability and education, are exactly why the board went on to become one of the most influential platforms in modern IoT.

At Fluidwire we build IoT and web systems from silicon to cloud, and boards like the Raspberry Pi are often where a connected product begins. If you are turning an idea or a thesis project into real hardware, get in touch and let us help you take it from prototype to production.

The First Digital Camera Was Built in 1975

fluidwire — Fri, 10 Jul 2026 21:16:23 +0000

Every camera-equipped connected device you build today, from a smart doorbell to an ESP32-CAM streaming frames over Wi-Fi to a factory machine-vision rig, is a descendant of one clunky, toaster-sized prototype: the first digital camera, built at Eastman Kodak in December 1975. It weighed about 8 pounds, took 23 seconds to capture a single 0.01-megapixel black-and-white image, and recorded that image to a cassette tape. It looked like a science-fair project, but it proved a radical idea that underpins the entire IoT sensing industry: an image could be captured, digitized, and stored as data with no film at all.

An engineer, a side project, and a CCD

The camera was built by a 24-year-old Kodak engineer named Steven Sasson. His manager had handed him a loose assignment: could the newly invented charge-coupled device (CCD) image sensor be used to build a camera with no moving film? The CCD, developed at Bell Labs in 1969, converts light falling on an array of tiny capacitors into electrical charge, pixel by pixel. Sasson took a Fairchild 100-by-100-pixel CCD, bolted it to a lens from a Super 8 movie camera, added a digitizer, and wired the output to a portable cassette recorder.

The result captured just 0.01 megapixels, a grid of 10,000 pixels. To view a photo, Sasson's team built a custom playback rig that read the tape and painted the image onto a television screen. That first image, a Kodak lab technician, took 23 seconds to write to tape and several more to display. Crude, yes, but it was the first fully electronic, filmless photograph.

Why Kodak shelved the future

Here is the twist that every embedded engineer should remember. Kodak owned the patent on the first digital camera, but the company made its money selling film, chemicals, and photo paper. Executives saw a filmless camera as a threat to that business, so the project was quietly set aside. Kodak did file the patent in 1978 and collected licensing revenue for decades, but it never led the digital transition it had invented. By the time digital photography went mainstream in the 2000s, the market had moved past Kodak, and the company filed for bankruptcy protection in 2012.

The lesson is not really about cameras. It is about what happens when a working prototype threatens an existing revenue line. The technology that felt inconvenient in 1975 became the foundation of an entire industry.

From cassette tape to the edge

The CCD in Sasson's camera is the direct ancestor of the CMOS image sensors inside almost every modern connected device. The core idea, turning photons into structured digital data at the edge, is exactly what a modern IoT camera does, just with millions of pixels instead of 10,000 and a cloud pipeline instead of a cassette recorder.

That heritage matters when you design connected products. A smart doorbell, an agricultural crop-monitoring node, or a jeepney fleet dash cam here in Metro Manila all wrestle with the same constraints Sasson faced: how much data can the sensor produce, how do you store or transmit it on a tight power and bandwidth budget, and how much processing happens on the device versus in the cloud. Every one of those trade-offs is a straight line from a 1975 prototype recording to tape.

Building connected devices in the Philippines

At Fluidwire we help students and businesses turn ideas like these into working hardware, from thesis prototypes to production IoT systems. If you are building anything with a camera or image sensor on board, from an ESP32-CAM proof of concept to a full machine-vision deployment, our IoT and embedded services cover the path from silicon to cloud. Have a project in mind? Get in touch and tell us what you are trying to sense.

The first digital camera weighed 8 pounds and took 23 seconds to save one grainy frame. Fifty years later, that same core idea fits on a chip smaller than your fingernail, and it is probably watching your front door right now.

The First Microprocessor Was the Intel 4004

fluidwire — Fri, 10 Jul 2026 03:50:37 +0000

Every connected device you build today, from an ESP32 blinking on a breadboard to an industrial gateway pushing sensor data to the cloud, is a descendant of one small chip released in 1971: the Intel 4004. It was the first commercially available microprocessor, and it proved a radical idea, that the entire logic of a computer's central processor could live on a single piece of silicon. That idea is the foundation of the whole embedded and IoT industry.

A calculator contract that changed computing

The 4004 was not born from a grand plan to reinvent computing. In 1969 a Japanese calculator company, Busicom, asked Intel to design a set of chips for a line of desktop calculators. The original request called for around a dozen custom chips. Intel engineer Ted Hoff proposed a different approach: instead of hard-wiring the logic for one calculator, design a single general-purpose processor that could be programmed to do the job, and reuse it across many products.

Federico Faggin led the design work that turned the concept into working silicon, with Stanley Mazor and Busicom's Masatoshi Shima contributing to the architecture. The result, shipped in November 1971, packed about 2,300 transistors onto a 4-bit chip running at 740 kHz. By the standards of a modern microcontroller it is almost comically small, yet it did something no chip had done before: it separated the hardware from the task. Change the program, change what the machine does.

Why a 4-bit chip from 1971 still matters

The lesson of the 4004 is not nostalgia, it is architecture. Before it, building an electronic product meant designing custom logic for that specific product. After it, you could buy a standard processor and define behavior in firmware. That shift is exactly how embedded development works today. When we prototype a connected device, the microcontroller is a commodity, and the value lives in the code and the system design around it.

The 4004 also set a pattern that scarcity drives elegance. Its designers had a tiny transistor budget and had to be ruthless about what mattered, the same discipline that makes good embedded firmware today, where memory and power are still limited. A well-built IoT sensor node running on a coin cell is solving the same class of problem the 4004 team faced, just fifty years later and several billion transistors richer.

From one chip to billions of connected things

The line from the 4004 to modern IoT is direct. The microprocessor idea scaled from 4 bits to 8, 16, and 32, spawned the microcontroller (a processor with memory and peripherals on one chip), and eventually gave us the low-cost, low-power parts that make connected devices economically viable. An ESP32, the workhorse of countless IoT and thesis prototypes, is fundamentally the 4004's idea taken to its logical extreme: a whole programmable system on a single inexpensive chip.

For engineering teams and students here in the Philippines building their first connected products, that history is a useful reminder. You are not fighting the hardware, you are standing on fifty years of it. The hard, valuable work is the design: choosing the right architecture, writing reliable firmware, and connecting the device to services that make its data useful.

That is the work we do at Fluidwire, from silicon to cloud. If you are turning an idea into a connected product and want a team that understands both the embedded side and the web services behind it, get in touch.