DEV Community: fluidwire

The First Visible LED Glowed Red

fluidwire — Mon, 29 Jun 2026 21:14:36 +0000

Look at almost any piece of electronics on your desk and you will find a small light staring back at you. A router with a row of blinking status lights. A power brick with a steady green dot. A development board with a tiny red point that flickers every time it does something. We barely notice these lights anymore, but each one descends from a single laboratory breakthrough in 1962, when an engineer at General Electric coaxed a sliver of semiconductor into glowing visible red for the first time.

Who invented the first visible LED

The engineer was Nick Holonyak Jr., a consulting scientist at General Electric's lab in Syracuse, New York, and a former student of John Bardeen, one of the inventors of the transistor. On October 9, 1962, Holonyak demonstrated the first practical visible-spectrum light-emitting diode. It emitted red light, and it worked at room temperature, which made it genuinely useful rather than a laboratory curiosity.

What made his approach different was the material. Other researchers in the early 1960s were building diodes that emitted infrared light, which is invisible to the human eye. Holonyak gambled on a different alloy, gallium arsenide phosphide, and it paid off with the first light a person could actually see coming out of a semiconductor. He was so confident in the idea that he predicted LEDs would one day replace the incandescent bulb. At the time that sounded outlandish. Today it is simply how lighting works.

Why a tiny red light mattered so much

The incandescent bulb that Thomas Edison commercialized makes light by heating a filament until it glows. That is wildly inefficient, because most of the energy escapes as heat rather than light, and the filament eventually burns out. An LED works on a completely different principle. When current flows across a specially engineered semiconductor junction, electrons release their energy directly as photons. There is no filament to burn out, almost no wasted heat, and the device can switch on and off millions of times a second.

Those properties are exactly what connected hardware needs. An LED draws very little current, which matters enormously on a battery-powered sensor that has to run for months. It is physically tiny, so it fits on a crowded circuit board next to a microcontroller. And because it responds instantly to electrical signals, it doubles as a communication tool, not just a lamp.

From a lab bench to every connected device

The descendants of Holonyak's red diode are everywhere in modern embedded systems. The most obvious use is the humble status indicator. When you are bringing up a new board and the onboard LED finally blinks, that single point of light is often the first proof that your firmware is alive. Engineers jokingly call a basic LED-blink program the "hello world" of embedded development, and there is a reason it is the first thing everyone writes.

But LEDs do far more than reassure developers. Infrared LEDs, the cousins of Holonyak's visible version, drive the remote controls and proximity sensors in countless devices. Tiny LEDs paired with photodetectors form the optical sensors inside heart-rate monitors and pulse oximeters. High-brightness LEDs light up the machine-vision cameras on a factory line. And of course, the displays that make a device legible to a human, from a seven-segment readout to a full-color panel, are LED arrays at heart. Decades of materials science, much of it building directly on Holonyak's work, turned one red glow into an entire toolbox.

What it means for building connected products today

There is a lesson in this history for anyone shipping IoT hardware. The components that feel trivial are usually the ones carrying the most accumulated engineering. A status LED is one resistor and one diode on the schematic, yet it represents sixty years of refinement and a deliberate bet that visible semiconductor light was worth chasing. Good embedded design respects that. A well-placed indicator can tell a user at a glance whether a device has power, a network connection, or a fault, with no screen and no app required.

At Fluidwire we design connected devices from the silicon up, and we treat every detail of the hardware, down to which color a status light should be and what it should communicate, as part of the product rather than an afterthought. If you are developing an IoT product, a sensor, or an embedded prototype and want a team that sweats those details, get in touch. The next time a small red light blinks back at you from a circuit board, you will know it has been doing that job since 1962.

The First Website Is Still Online

fluidwire — Sun, 28 Jun 2026 21:15:09 +0000

Most of the web's foundational moments have vanished. The servers were unplugged, the code was lost, the pages 404'd into history. But the first website ever published is a striking exception: you can still read it today, more or less as it appeared when it went live on August 6, 1991. It is a plain, text-only page with a white background and blue hyperlinks, and it explains a brand-new idea called the World Wide Web.

One page that described itself

The author was Tim Berners-Lee, a British computer scientist working at CERN, the particle physics laboratory near Geneva. By the end of 1990 he had quietly assembled the three technologies that still define the web: HTML for writing pages, HTTP for moving them between machines, and the URL for addressing any document on any server. The first website, hosted at the address info.cern.ch, was the web explaining itself - what hypertext was, how to browse it, and how to make your own pages.

It ran on a NeXT computer, the sleek black workstation designed by Steve Jobs's company during his years away from Apple. That single machine was the entire World Wide Web for a while. A handwritten label was stuck to its case: "This machine is a server. DO NOT POWER IT DOWN!!" One unplugged cable would have taken the whole web offline.

Why a 1991 web page still matters to IoT

It is easy to file this under nostalgia, but the first website is more than a museum piece. It is the origin point of the request-and-response model that quietly powers almost everything connected today. When an ESP32 sensor node pushes a reading to a cloud dashboard, when a smart meter checks in with a server, or when you open an app to see whether your device is online, the same basic conversation is happening: a client asks a question over HTTP, a server answers, and a URL says where to look.

Berners-Lee made a deliberate choice that turned out to matter enormously. He kept the standards open and unlicensed. Anyone could implement a browser or a server without paying anyone or asking permission. That openness is exactly why the web outgrew CERN, and it is the same reason modern IoT leans so heavily on web protocols rather than closed, proprietary alternatives. REST APIs, MQTT bridges, and WebSocket streams are all descendants of that decision to keep the plumbing public.

The lesson: simple protocols outlast clever ones

The first web page had no images, no styling, no JavaScript, no database. It was almost embarrassingly minimal. And that minimalism is precisely why it scaled to billions of pages. A protocol simple enough to explain on a single page is a protocol that other people can build on without a manual.

That principle still guides good connected-device work. The most reliable IoT deployments are rarely the ones bristling with features. They are the ones built on small, well-understood, well-documented exchanges - a device that reports a clean reading, a server that responds predictably, an endpoint that does one thing. When something breaks at 2 a.m., simple systems are the ones you can actually fix.

From silicon to cloud, on open foundations

For teams here in the Philippines and beyond building thesis prototypes, products, or production fleets, the through-line from 1991 is encouraging. You do not need exotic infrastructure to put a device on the internet. The web that Berners-Lee sketched out on one NeXT machine is mature, free, and everywhere, and it is still the most dependable way to get a sensor talking to a screen.

At Fluidwire we build across that whole stack, from the firmware on the microcontroller to the web service that displays its data. If you have a connected-device idea and want it grounded on open, durable web foundations rather than a vendor's walled garden, tell us what you are building. The first website is still online thirty-five years later. The systems we build for you should be designed to last, too.

The First IoT Device Was a Vending Machine

fluidwire — Sat, 27 Jun 2026 21:15:22 +0000

Ask most people to picture the first Internet of Things device and they imagine something sleek: a smart speaker, a fitness band, a Wi-Fi thermostat. The real answer is far more ordinary and far more charming. The first internet-connected appliance was a Coca-Cola vending machine, wired up by graduate students at Carnegie Mellon University in 1982 so they could check whether it was stocked and cold without leaving their desks. Decades before anyone coined the phrase "Internet of Things," a group of programmers built exactly that: a physical object reporting its real-world status over a network.

A thirsty problem and a clever fix

The computer science department at Carnegie Mellon had a Coke machine on an upper floor, and a community of programmers spread across the building. The problem was simple and universally relatable. You would walk all the way to the machine only to find it empty, or worse, freshly restocked with warm bottles that had not had time to chill. Wasted trips, every day.

So the students did what engineers do. They added micro-switches to sense how many bottles were in each of the machine's six columns, and they tracked how long each bottle had been loaded so they could estimate whether it was cold yet. They wired that sensor data into a department computer connected to ARPANET, the research network that would eventually become the internet. Anyone on the network could now query the machine and get back the stock level of each column plus how long the newest bottles had been cooling.

Why this counts as the first IoT device

It is tempting to dismiss the Coke machine as a cute hack, but it contains every essential ingredient of a modern IoT system. There is a sensor reading the physical world, an embedded interface translating that into data, a network carrying the data somewhere useful, and a remote client acting on it. That is the entire architecture of a connected device, just built from 1980s parts. The same loop runs inside a smart water meter, an industrial vibration sensor, or a cold-chain logger today.

What makes the story matter is not the hardware, which was modest, but the pattern of thinking. The students did not set out to invent a product category. They simply refused to accept that checking a machine required physically walking to it, and they had the tools to close that gap with code. That instinct, the conviction that a device should be able to tell you what it knows from anywhere, is the seed of everything we now call IoT.

From ARPANET to the connected world

The vending machine predated the term "Internet of Things" by roughly seventeen years; Kevin Ashton would not coin that phrase until 1999. It also predated the World Wide Web, cheap microcontrollers, and the wireless protocols we now take for granted. What it proves is that the core idea of connected hardware was never really about the internet being fast or devices being small. It was about giving physical things a voice on the network. Everything since, from the ESP32 on a hobbyist's breadboard to a fleet of sensors in a factory, is a refinement of that 1982 insight.

Building connected hardware today

The barriers that made the Carnegie Mellon project a feat of improvisation have mostly fallen away. A modern microcontroller with built-in Wi-Fi costs a few dollars, sensors for almost any physical quantity are off-the-shelf, and cloud platforms make it straightforward to collect and act on the data. What has not changed is the discipline required to turn a clever idea into reliable hardware: choosing the right sensors, designing a board that survives the real world, writing firmware that does not crash at 3 a.m., and connecting it all securely.

That is the work we do at Fluidwire, here in Paranaque. Whether you are a student turning a thesis concept into a working prototype or a business adding connectivity to an existing product, the path runs from silicon to cloud, and we can help at every step. Take a look at the embedded and IoT services we offer, or tell us about your project and we will help you figure out the first move. The next "first connected device" story could be yours, minus the warm Coke.

The MOSFET: The Most Manufactured Device in History

fluidwire — Fri, 26 Jun 2026 21:14:14 +0000

Ask someone to name the most manufactured object in human history and you will hear guesses like the nail, the brick, or maybe the smartphone. The real answer is something almost nobody can name out loud: the MOSFET. This tiny transistor, invented at Bell Labs in 1959, is the on/off switch inside every microprocessor, memory chip, and connected sensor. An estimated 13 sextillion of them have been built since 1960, making the MOSFET not just the foundation of modern electronics but the most-produced artifact our species has ever made.

What a MOSFET actually is

MOSFET stands for metal-oxide-semiconductor field-effect transistor. Strip away the jargon and it is an electrically controlled switch with no moving parts. A small voltage on one terminal, the gate, controls whether current can flow between the other two. Billions of these switches flipping on and off billions of times per second is, quite literally, what computation is. The genius of the design is that it scales: shrink the transistor and you can pack more of them onto a chip while using less power per switch, the trend that drove decades of Moore's law.

The breakthrough came from two engineers at Bell Labs, Mohamed Atalla and Dawon Kahng, who fabricated the first working MOSFET in 1959. Their key insight was using a thin layer of silicon dioxide, ordinary glass, to insulate the gate from the silicon underneath. That oxide layer turned out to be the unlock that made silicon the dominant material in electronics, edging out the germanium used in the very first transistors of the late 1940s.

Why it beat every earlier transistor

The point-contact transistor demonstrated in 1947 and the integrated circuit of 1958 were both monumental, but neither was easy to mass-produce by the standards we take for granted today. The MOSFET was different. It was simpler to fabricate at scale, drew far less power in its complementary (CMOS) configuration, and lent itself to the photolithographic processes that let manufacturers print millions, then billions, of identical switches onto a single wafer. By the 1970s it was the natural building block for the first microprocessors, and it has never been displaced.

That manufacturability is why the production numbers are so staggering. Thirteen sextillion is 13 followed by 21 zeros. If you tried to count them one per second, you would need trillions of times the age of the universe. Every logic gate in a microcontroller, every cell in a flash memory chip, every power-switching stage in a charger is built from MOSFETs.

Why it matters for IoT

Every connected device we build at Fluidwire rests on this 1959 invention. The microcontroller at the heart of a sensor node is a dense field of MOSFETs. The power management that lets a battery-powered device sleep for months and wake on a schedule depends on how little current a CMOS circuit leaks when idle. Even the radio that pushes a reading to the cloud is switching MOSFETs at high frequency to generate its signal. Understanding that the entire stack, from a thesis prototype on a breadboard in Manila to a fleet of devices reporting to a dashboard, ultimately reduces to one elegant switch makes for clearer engineering decisions at every layer above it.

That is the throughline of how we work: from the silicon physics up to the cloud services that make data useful. If you are building a connected product and want a partner who thinks across that whole range, take a look at our IoT and embedded services or get in touch to talk through your project.

The quiet workhorse

The MOSFET is a good reminder that the most important technologies are often the most invisible. It does not have a famous launch date, a charismatic founder story that everyone repeats, or a museum exhibit drawing crowds. It just sits inside everything, switching trillions of times a second, the most manufactured device in history doing the quiet work that all of modern computing and IoT is built on.

The First PLC Was Built in 1968

fluidwire — Thu, 25 Jun 2026 21:15:25 +0000

Walk onto almost any factory floor today and the machines are coordinated by a small, rugged industrial computer bolted inside a control cabinet. It is called a programmable logic controller, or PLC, and it is the quiet workhorse behind bottling lines, elevators, water treatment plants, and the connected sensors of modern industrial IoT. The first one was built in 1968, and the story of why it exists explains a design idea that still shapes how we build connected systems.

A wall of wires that nobody wanted to rewire

Before the PLC, factory automation ran on relay logic. A control system was a physical wall of electromechanical relays, timers, and counters, all wired together by hand. If a car maker wanted to change how a production line behaved, an electrician had to rip out and rewire that panel, a process that could take days and stop the line cold. General Motors, retooling its plants every model year, was tired of paying that cost over and over.

So GM put out a now-famous request: build a control system that could be reprogrammed instead of rewired, that could survive a harsh industrial environment, and that ordinary plant electricians could understand without learning to be computer programmers.

The Modicon 084

The answer came from engineer Richard "Dick" Morley and his colleagues at Bedford Associates in Massachusetts. Their machine was called the Modicon 084. The name is a compression of "MOdular DIgital CONtroller," and the 084 simply marked it as the eighty-fourth project the firm had taken on. GM took delivery of its first units in 1969 and was impressed enough to order a million dollars' worth.

The genius of the design was not raw computing power. It was the decision to move the control logic out of copper wiring and into software. A line could now be changed by editing a program rather than rebuilding a panel. Just as importantly, Morley's team kept the programming model familiar: instead of inventing an abstract new language, they used ladder logic, a diagram style that looked almost exactly like the relay wiring schematics electricians already read every day. The barrier to adoption nearly disappeared.

Why a 1968 machine still matters for IoT

That single trade-off, make the logic soft instead of hard, is the same principle behind every embedded device we build now. A microcontroller running firmware is doing conceptually what the Modicon 084 did: turning behavior that used to be fixed in hardware into something you can update, version, and improve in software.

The PLC also never went away. Modern PLCs have grown network interfaces, web servers, and the ability to stream telemetry to the cloud, making them a foundational layer of industrial IoT. When a factory wants predictive maintenance, energy dashboards, or remote monitoring, the data very often starts at a PLC and flows upward through gateways and protocols like MQTT into analytics platforms. The 1968 idea of programmable, electrician-friendly control sits underneath a great deal of today's smart manufacturing.

For engineering students in the Philippines and elsewhere prototyping automation or thesis projects, the lineage is useful to know. The microcontrollers and single-board computers you reach for, an ESP32 driving relays or a Raspberry Pi logging sensor data, are descendants of the same decision Morley made: separate the logic from the wiring so the system can evolve.

Building on the lineage

Good connected systems still respect the lesson of the Modicon 084. Keep the logic reprogrammable, make it understandable to the people who maintain it, and design it to survive the real world it runs in. Those priorities carry all the way from a single sensor node up to a full cloud platform.

If you are turning an industrial process or a hardware idea into a connected product, our team builds IoT and web systems from silicon to cloud, bridging embedded firmware and the dashboards that make its data useful. We are always happy to talk through a project, whether it is a factory integration or a first prototype. The tools have changed enormously since 1968, but the engineering judgment that made the first PLC a success is still exactly what separates a reliable connected system from a fragile one.

Who Coined the Term Internet of Things?

fluidwire — Wed, 24 Jun 2026 21:16:59 +0000

The Internet of Things is now a phrase you see on product boxes, in boardroom slide decks, and across thesis titles in engineering departments everywhere. But it has a surprisingly precise origin. The term was coined in 1999 by a British technologist named Kevin Ashton, and it was not born in a research lab or an academic paper. It started its life as the title of a corporate sales presentation.

A slide deck, not a laboratory

In the late 1990s Ashton was a brand manager at Procter & Gamble, the consumer goods giant behind products you would find on any supermarket shelf. He was wrestling with a mundane but expensive problem: store shelves kept running out of a particular shade of lipstick, even though the warehouse had plenty in stock. The supply chain simply had no reliable way to know, in real time, what was where.

Ashton's proposed fix was radio-frequency identification, or RFID: tiny tags that could be attached to products and read automatically by sensors, with no human scanning each item by hand. The vision was that physical objects could report their own location and status, feeding that data up into computer systems without anyone typing it in. To sell this idea to executives, he needed a title that would make supply-chain tagging sound as exciting as the technology dominating headlines at the time. So he linked his RFID proposal to the hottest topic of 1999 and called the presentation "Internet of Things."

By his own account, years later in RFID Journal, the choice was deliberate. Tying tags and sensors to the red-hot word "internet" was the surest way to get senior people in the room to pay attention. The pitch worked well enough that the phrase stuck, and Ashton went on to help found the Auto-ID Center at MIT, a research group that did much of the early standards work that made networked RFID practical.

Why the name was actually a good description

It would be easy to dismiss the term as a marketing flourish, but it captured something real. Ashton's point was that the internet of the 1990s was almost entirely built from information that humans had typed, photographed, or recorded by hand. Computers, he argued, were starved of data about the physical world because they depended on people to gather it, and people are slow, inattentive, and easily bored.

If everyday objects could sense and report on themselves, computers could understand the world directly. That is still the founding idea of IoT today, whether the device is a soil-moisture sensor on a farm, a water meter on a city pipeline, or a temperature logger inside a cold-chain truck. The technology has moved far beyond RFID to include microcontrollers, low-power wireless protocols, and cloud platforms, but the core ambition is unchanged: give physical things a digital voice.

From 1999 to the devices we build now

The leap from a single warehouse-tracking pitch to billions of connected devices took two decades of progress in embedded systems and wireless networking. Cheap, capable microcontrollers like the ESP32 put internet connectivity inside objects that cost a few dollars. Sensor prices collapsed. Cloud services made it trivial to collect and act on streams of device data. What was once a clever way to track lipstick became the backbone of smart agriculture, industrial monitoring, and connected consumer products.

For developers and students here in the Philippines, that history is more than trivia. It is a reminder that the most valuable IoT projects usually start with a concrete, unglamorous problem, such as a shelf that keeps running empty or a generator whose fuel level no one can check remotely. The technology is the means; the data about the physical world is the point. A capstone project that connects a real sensor to a real dashboard is following exactly the path Ashton sketched in 1999.

Building on a 25-year-old idea

At Fluidwire we work across that whole stack, from the silicon and firmware on the device to the web services that turn raw readings into something a person can use. Whether you are prototyping a thesis project, validating an industrial sensor, or planning a connected product, the questions are the same ones Ashton was really asking: what do you need the physical world to tell you, and how do you get that signal cleanly from device to cloud?

If you are building something that needs to sense, connect, and report, get in touch. The Internet of Things started as a way to let things speak for themselves, and that is still the most useful thing it does.

The First Integrated Circuit Was Built in 1958

fluidwire — Tue, 23 Jun 2026 21:16:16 +0000

Almost everything that makes the modern world hum, from the phone in your pocket to the sensor on a factory floor, traces back to a single quiet afternoon in a nearly empty laboratory in Dallas. In the summer of 1958, a newly hired engineer named Jack Kilby built the first working integrated circuit at Texas Instruments. It was a crude little thing, a sliver of germanium with a few components and some fine gold wires, but it carried an idea that would reshape electronics: that an entire circuit could be made from one piece of semiconductor material. Every microcontroller and connected device we build today is a descendant of that prototype.

The engineer who was left behind

Kilby had only just joined Texas Instruments and had not yet earned any vacation time. So when the company shut down for its traditional summer break in July 1958 and most of his colleagues left, he found himself nearly alone in the lab with time to think. The problem on his mind was one the whole industry called the "tyranny of numbers." Circuits were getting more capable, which meant more transistors, resistors, and capacitors, each one a separate part that had to be wired together by hand. Every added component meant more connections, more soldering, and more chances for something to fail. The complexity was becoming a wall.

Kilby's insight was disarmingly simple. If resistors and capacitors could be made from the same semiconductor material as transistors, then every part of a circuit could be fabricated together in a single block. No separate components, no forest of hand-soldered wires. He sketched the idea, and when his managers returned he had something to show them.

September 12, 1958

On September 12, 1958, Kilby demonstrated his prototype to Texas Instruments executives. The device was a phase-shift oscillator built on a bar of germanium, with its elements connected by delicate gold "flying wires." He connected it to an oscilloscope, flipped the switch, and a steady sine wave rolled across the screen. The circuit worked. It was the first time a complete electronic circuit had been built entirely from one piece of semiconductor.

It did not look like much. There were no clean rows of pins, no black plastic package, none of the visual language we now associate with a microchip. But the principle was proven, and that principle is the one every chip still follows.

Kilby and Noyce: two inventors, one idea

History rarely hands a single person all the credit, and the integrated circuit is no exception. A few months after Kilby's demonstration, Robert Noyce at Fairchild Semiconductor independently arrived at the same concept from a different direction. Noyce's version used silicon rather than germanium and relied on the planar process, a photolithographic technique that let circuits be printed onto a wafer in repeatable, manufacturable steps. Kilby proved the idea could exist; Noyce showed how to make it at scale.

The two approaches set off a long patent dispute that was eventually resolved in Noyce's favor on the manufacturing method, while both men are rightly credited as co-inventors of the integrated circuit. Kilby went on to receive the Nobel Prize in Physics in 2000 for his part in the invention. Noyce, who later co-founded Intel, had died in 1990 and so could not share the prize, but his contribution is inseparable from the story.

Why this still matters for IoT and embedded systems

It is tempting to file this away as pure history, but the integrated circuit is the reason the Internet of Things is even possible. The whole premise of IoT is putting intelligence into small, cheap, low-power devices and connecting them. That only works because decades of integration have shrunk what was once a roomful of discrete parts down to a fingernail-sized chip costing a few cents.

Every ESP32 or microcontroller we reach for when prototyping a connected product is the direct heir of Kilby's idea. The system-on-chip at the heart of a modern sensor node packs a processor, memory, radio, and analog interfaces onto one die, exactly the kind of consolidation Kilby was chasing when he proposed making every component from the same material. The "tyranny of numbers" he set out to defeat is the same force that, undefeated, would make a battery-powered wireless sensor impossible.

There is also a quieter lesson in how the breakthrough happened. It did not come from a massive program with unlimited resources. It came from one engineer with a clear problem, some uninterrupted time, and the freedom to chase an unconventional idea. That is often how the most useful engineering happens, in the gap between the obvious approaches, when someone questions a constraint everyone else had accepted.

From silicon to cloud

At Fluidwire we work across the entire stack that Kilby's invention made possible, from the silicon and circuit boards inside a device up to the web services that bring its data online. Understanding where the technology came from is part of building it well: the integrated circuit is not just a component we use, it is the foundation the whole field stands on.

If you are developing a connected product, prototyping a thesis project, or turning an embedded idea into hardware that ships, we would love to help. Get in touch and let's build something on top of seven decades of integration.

The First Text Message Said Merry Christmas

fluidwire — Mon, 22 Jun 2026 21:15:05 +0000

The first text message ever sent was not a love note, a meeting reminder, or a meme. It was a Christmas greeting. On December 3, 1992, a 22-year-old engineer named Neil Papworth sat at a desktop computer, typed two words, and sent the world's first SMS to a mobile phone: "Merry Christmas." More than thirty years later, that humble two-word message has grown into one of the most quietly important protocols in connected technology, and it still shows up in the IoT devices we build today.

The engineer who sent the first SMS

Neil Papworth was working for the Anglo-French firm Sema Group Telecoms, part of a team building a Short Message Service Centre (SMSC) for the British carrier Vodafone. The SMSC was the piece of infrastructure that would store and forward text messages across the cellular network. To prove it worked, Papworth sent a test message from a computer terminal to the Orbitel 901 handset of Richard Jarvis, a Vodafone director who was at a company Christmas party.

The message arrived. Jarvis read it. But he could not reply, because mobile phones at the time had no way to compose a text. There was no keypad-driven messaging app, no T9, no touchscreen. SMS started life as a one-way novelty riding on a spare slice of the network's signalling channel, and almost nobody involved thought it would matter very much.

Why SMS was designed the way it was

The technical detail that makes this story relevant to anyone building connected hardware is how SMS was engineered. Text messages were squeezed into the control channel that phones already used to talk to cell towers, the same channel that handles things like call setup. That is why a single SMS is capped at 160 characters: it had to fit inside a small, fixed-size signalling packet.

This constraint turned out to be a feature. SMS is lightweight, store-and-forward, and works even when a data connection is weak or absent. The message waits in the SMSC until the device is reachable, then gets delivered. No persistent connection, no handshake-heavy protocol, no assumption of broadband. For a 1992 phone network, that was a clever workaround. For an IoT device sitting in a field, on a utility pole, or inside a shipping container, it is close to ideal.

From a Christmas greeting to cellular IoT

This is where a thirty-year-old text message meets modern embedded engineering. Plenty of IoT deployments cannot rely on Wi-Fi or stable mobile data. A water-level sensor on a river, a GPS tracker on a delivery truck, an agricultural monitor in a remote barangay: these devices often live where coverage is thin and power is scarce.

SMS remains a dependable fallback for exactly these situations. A microcontroller paired with a 2G or LTE-M cellular module can send a short status message or receive a command over SMS using simple AT commands, with far less complexity and power draw than maintaining a full data session. Many embedded designs use SMS as a low-bandwidth control and alerting layer: send a threshold alert, trigger a reboot, confirm a device is alive. The same store-and-forward resilience that let Papworth's greeting wait for Jarvis's phone now lets a sensor's reading wait for a network window.

For builders here in the Philippines, where connectivity varies sharply between a Metro Manila office and a provincial site, that resilience is not academic. Designing a device that degrades gracefully to SMS when data drops is often the difference between a prototype that demos well and a product that survives in the real world.

The lesson in a two-word message

The first SMS is a reminder that durable technology rarely arrives looking important. SMS was a side feature built on borrowed bandwidth, tested with a throwaway holiday message, and underestimated by nearly everyone who touched it. It endured because it was simple, frugal, and tolerant of bad conditions, the same qualities that make for good embedded design.

At Fluidwire we build IoT and web systems from silicon to cloud, including cellular-connected devices that have to keep working when the network does not cooperate. If you have a connected-hardware idea or a thesis prototype that needs to talk to the world reliably, get in touch and let's build it.

Why Email Uses the @ Symbol

fluidwire — Mon, 22 Jun 2026 04:24:38 +0000

Look at any email address and you will find the same small character sitting in the middle of it: the @ sign. It is so ordinary that almost nobody asks where it came from or why it is there. Yet that symbol was a deliberate engineering decision made by one person in 1971, and the convention has now survived more than fifty years of relentless change in computing. For anyone who builds connected systems, from a web app to an IoT sensor in Parañaque, the story is a small masterclass in durable design.

The engineer who sent the first networked email

In 1971, an engineer named Ray Tomlinson was working at Bolt, Beranek and Newman (BBN), one of the firms building ARPANET, the research network that would eventually grow into the internet. People could already leave messages for each other, but only on the same shared computer. Tomlinson was experimenting with a program that could move a message from one machine to a different machine across the network. When he succeeded, he had effectively sent the first email between two separate computers, which happened to be sitting side by side in his lab and connected through ARPANET.

That achievement created a brand-new problem. If a message was going to travel to another machine, the system needed a way to say not just who the recipient was, but which computer they were on. Tomlinson needed a single, unambiguous way to write "this user, at that host."

Why the @ symbol won

Tomlinson looked down at his Teletype Model 33 keyboard for a character he could borrow. His requirements were strict and practical. The symbol could not be something that already appeared in people's names or in the names of host computers, or the address would be impossible to parse. It also had to be a character the system would not confuse with a command.

The @ sign fit perfectly. It was already on the keyboard, it was rarely used for anything else in computing at the time, and, conveniently, it literally meant "at" in commercial and accounting usage. So user @ host read almost like plain English: this person, at this machine. The format stuck immediately and became the template every email system has used since. A choice made in a single afternoon now routes billions of messages every day.

What this teaches about building connected systems

The lasting lesson is not really about email. It is about the value of simple, unambiguous conventions in systems that have to interoperate. Tomlinson did not invent a complicated new addressing scheme; he picked an existing character that carried no conflicting meaning and gave it one clear job. That clarity is exactly why it scaled.

The same principle runs straight through modern IoT and embedded work. When you design how devices identify themselves on a network, how a firmware update names its target, or how a sensor publishes to an MQTT topic, you are making the same kind of decision Tomlinson made. A naming scheme that is clean, collision-free, and human-readable will quietly keep working as your fleet grows from one prototype to thousands of units. A clever but ambiguous one becomes a tax you pay forever. The best addressing decisions, like the @ sign, are the ones nobody ever has to revisit.

Build on durable foundations

At Fluidwire we build IoT and web systems from silicon to cloud, and that means caring about the unglamorous decisions, such as how devices are addressed, how data is structured, and how firmware talks to the cloud, as much as the features users see. Good plumbing is what lets a product last. If you are turning a connected-device idea or a thesis prototype into something real, take a look at our services or get in touch and we will help you build it on foundations that hold up.

The next time you type an @ into an address bar, remember it is a fifty-year-old engineering shortcut that simply refused to break.

The First Transistor Was Built in 1947

fluidwire — Sat, 20 Jun 2026 21:14:06 +0000

Almost every piece of electronics you will touch today, from the phone in your pocket to the microcontroller blinking on a workbench in Parañaque, traces back to a single afternoon at Bell Telephone Laboratories. On December 23, 1947, a small, ungainly contraption of germanium, gold foil, and a bent paperclip-like spring did something no practical device had done before: it took a weak electrical signal and made it stronger, using nothing but a sliver of solid material. That device was the first transistor, and it quietly began the age of modern electronics that the Internet of Things now lives in.

What actually happened at Bell Labs

The breakthrough belonged to physicists John Bardeen and Walter Brattain, working in a group led by William Shockley. Their creation is called a point-contact transistor, because it relied on two fine metal contacts pressed onto a block of germanium, a semiconductor. By applying a small voltage to one contact, they could control a much larger current flowing through the other. That ability to use a tiny signal to govern a bigger one, called amplification, is the heart of nearly all electronics.

It mattered because the alternative was the vacuum tube. Tubes worked, but they were bulky, fragile glass bottles that ran hot, burned out, and drank power. A room-sized computer of the 1940s might hold thousands of them. The transistor did the same job in a fraction of the space, with far less power and heat, and no filament to fail. Bardeen, Brattain, and Shockley shared the 1956 Nobel Prize in Physics for the work, and within a decade the transistor had started replacing the tube almost everywhere.

From one transistor to billions

The 1947 device was hand-built and finicky. The real revolution came when engineers learned to make transistors small, cheap, and many at a time. Once thousands and then millions of them could be etched onto a single sliver of silicon, the integrated circuit was born, and after that the microprocessor. Every step in that lineage is just transistors getting smaller and more numerous. A modern chip can pack tens of billions of them into a space smaller than a fingernail.

This is why the transistor is not a museum curiosity but the literal building block of the work we do. When you program an ESP32 or an Arduino, you are commanding a city of transistors arranged into logic gates, memory cells, and radios. The pull-up resistor, the I2C bus, the firmware loop, all of it sits on top of that 1947 invention. Understanding that the whole stack is made of switches helps you reason about the physical reality of a board, not just the code running on it.

Why it still matters for IoT and embedded work

The Internet of Things is, at its core, a story about putting cheap, low-power intelligence everywhere. None of that is possible without the transistor's defining trait: it shrinks and sips power. A sensor node that runs for years on a coin cell, a microcontroller small enough to hide inside a light switch, a radio that fits on a board the size of a thumbnail, every one of these is a direct descendant of what Bardeen and Brattain demonstrated. The vacuum tube could never have given us a connected world; the transistor made it inevitable.

For students and makers in the Philippines building thesis prototypes and connected products, there is a practical lesson in this history too. The most important advances in electronics came from understanding the device at the bottom of the stack, then building cleanly on top of it. Good IoT hardware is not magic; it is layers of well-understood switches, power, and signals.

At Fluidwire we turn embedded and IoT concepts into working hardware, from silicon to cloud. If you have a connected-device idea or a thesis prototype that needs to become a real board, get in touch and let's build it.

The First Computer Bug Was a Real Moth

fluidwire — Fri, 19 Jun 2026 21:14:33 +0000

Every developer who has ever muttered "there is a bug in this" is repeating a word with a surprisingly literal origin. On September 9, 1947, the operators of the Harvard Mark II, an early electromechanical computer, traced a malfunction to its source and found something they did not expect: a moth wedged inside Relay #70. They removed the insect, taped it into the operations logbook, and wrote a now-famous line beside it: "First actual case of bug being found." That page, moth and all, survives today in the collection of the Smithsonian's National Museum of American History.

It is one of the best-loved stories in computing, and like most good stories it is a little more complicated than the popular version. Worth getting right, because the discipline it gave us is the same one behind every connected device we build.

What actually happened in 1947

The Mark II was a room-sized machine built from relays, switches, and thousands of moving parts. When a moth flew into one of those relays, it physically interfered with the contacts and caused a fault. The technicians who found it had a sense of humor: calling it the "first actual case of bug being found" was a joke precisely because engineers had already been using "bug" for years to describe mysterious faults in machinery. Thomas Edison used the term in his notebooks back in the 1870s.

So the 1947 moth did not invent the word "bug." What it did was give the term a perfect, photographable origin story, and it cemented the companion word that really matters: debugging. The act of removing that moth was, quite literally, de-bugging the computer.

The Grace Hopper connection

The story is almost always told with Grace Hopper at its center, and that deserves a small correction. Hopper, a pioneering computer scientist who later helped develop COBOL, was part of the Mark II team in 1947, but the evidence suggests she did not personally find the moth or write the logbook entry. What she did do was tell the story, brilliantly and often, for the next four decades. Her retelling is the reason the moth became famous and the reason "debugging" entered everyday engineering vocabulary. It is a useful reminder that the people who explain ideas clearly often shape a field as much as the people who discover them.

Why a 78-year-old moth still matters

Hardware has changed beyond recognition since 1947. A modern ESP32 microcontroller fits on a fingertip and outperforms that entire room of relays by orders of magnitude. What has not changed at all is the core activity of finding the one small thing breaking the whole system.

In modern IoT and embedded development, debugging is the work. A sensor returns garbage values and you have to decide whether the fault is in the wiring, the I2C address, the firmware, or the sensor itself. A device connects to Wi-Fi perfectly on the bench and then drops offline once a day in the field. A board behaves flawlessly until it gets warm. None of these announce themselves with a convenient moth taped to a relay. The engineer's job is to reproduce the fault, isolate it, and prove the fix, exactly as those Harvard technicians did with a pair of tweezers and a logbook.

That methodical mindset is the unglamorous skill that separates a prototype that works in a demo from a product that survives in the real world. It is the difference between a thesis project that runs once for the panel and a connected device a business can actually deploy.

Debugging is the real craft

At Fluidwire, debugging is a large part of what we do every day, whether we are bringing up a new PCB, chasing an intermittent fault in connected-device firmware, or helping a student in Parañaque get a stubborn sensor to behave before a thesis deadline. The tools are better than they were in 1947, but the patience and the systematic thinking are identical.

If you are building an IoT or embedded project and you are stuck on a fault you cannot pin down, that is a normal and necessary stage of engineering, not a sign you are doing it wrong. Every working device on earth was buggy first. If you would like a hand finding your moth, get in touch with our team and tell us what is misbehaving.

The next time your code throws an error, remember that you are part of a tradition going back to a single insect in a Harvard relay. Find the bug, log the fix, and ship it. Learn more about how we build connected hardware from silicon to cloud at fluidwire.com.

The First Microprocessor Was Built for a Calculator

fluidwire — Thu, 18 Jun 2026 21:15:08 +0000

Every connected device on your desk, from a smart plug to a fitness band to a hobbyist ESP32 board, runs on a descendant of one tiny chip that was never meant to change the world. In 1971, Intel released the 4004, the first commercially available microprocessor. It was not built for computers, robots, or the internet. It was built to run a desk calculator. The story of how a calculator chip became the foundation of modern IoT is one of the most instructive in all of electronics.

A calculator contract that got out of hand

The 4004 began as a job for hire. A Japanese calculator company called Busicom approached Intel in 1969 wanting a set of custom chips for a new line of printing calculators. The original plan called for around a dozen separate, purpose-built integrated circuits, each wired to do one fixed task. It was the standard approach of the era: if you wanted a device to do something, you designed silicon that did exactly that and nothing else.

Intel engineer Ted Hoff looked at the sprawling design and proposed something radical. Instead of a pile of single-purpose chips, why not build one general-purpose processor that could be told what to do through software? A program stored in memory could make the same chip behave like a calculator today and something else entirely tomorrow. Stanley Mazor helped shape the architecture, and a newly arrived engineer named Federico Faggin turned the concept into a working device, inventing the silicon-gate design techniques that made it physically possible. Masatoshi Shima, Busicom's representative, worked alongside them on the logic.

2,300 transistors that started everything

When the 4004 was announced on November 15, 1971, it packed about 2,300 transistors onto a single sliver of silicon. By modern standards that is almost nothing; a current smartphone chip holds tens of billions. But the leap was not about raw count. It was about the idea. For the first time, a complete central processing unit existed on one chip that anyone could buy and program for their own purposes.

That was the breakthrough that mattered. A general-purpose, programmable processor meant the cost and effort of designing custom silicon no longer had to be repeated for every new product. You could buy the brain off the shelf and define its behavior in software. That single shift is the reason embedded computing exists at all.

Why this matters for IoT today

Trace the lineage forward and the path runs straight to the devices Fluidwire builds. The microcontroller at the heart of a modern IoT sensor, whether it is an ESP32 reading temperature in a warehouse or a low-power chip counting steps on a wrist, is a direct descendant of the 4004's core idea: a programmable processor cheap and small enough to embed inside an ordinary product.

The economics that the 4004 unlocked are exactly what make connected devices viable. Because a capable processor now costs a few dollars or less, it makes sense to put intelligence into a light switch, a water meter, or a soil-moisture probe. The same logic that let Busicom replace a dozen fixed chips with one programmable one is what lets a startup ship a smart product without designing custom silicon from scratch. You write firmware instead.

The lesson for builders in the Philippines

For engineers and students here in the Philippines, the 4004 carries a useful message. The chip that launched a trillion-dollar industry was not the product of a grand plan; it came from solving a specific, unglamorous problem (a calculator) in a more general way than the brief required. That instinct, to build a flexible foundation rather than a one-off, is the heart of good embedded and IoT design.

It is also a reminder that hardware and software are partners. The 4004 was useless without a program, and its real power was that the same silicon could do countless jobs depending on the code it ran. Every thesis prototype and connected-product build we help teams ship works the same way: capable, affordable hardware made specific through firmware.

If you are designing a connected device and want a partner who understands both the silicon and the cloud it talks to, see how Fluidwire approaches IoT and embedded development or get in touch with our team. The chip that started it all was built for a calculator. What you build with its descendants is entirely up to you.