标签：#IoT

This week, I covered the story of Casey Harrell—a man with ALS who is “the first power user” of a brain implant, according to the researchers who worked with him. Harrell is paralyzed and unable to speak coherently without the device. He has now spent almost three years using a brain-computer interface (BCI) that enables…

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 an

You scan one to pay at a sari-sari store, pull up a restaurant menu, or board a flight. The QR code has quietly become one of the most universal pieces of interface design on the planet. But it was never meant for any of that. The QR code was invented in 1994 to solve a very specific problem on a Japanese car factory floor, and the engineering decisions made under that constraint are exactly why it later conquered the world. A barcode problem on the assembly line In the early 1990s, Toyota's manufacturing arm had a data problem. Tracking thousands of distinct components through production meant scanning barcodes, and barcodes are stingy: a standard one-dimensional barcode holds roughly 20 characters. Workers were ending up with parts plastered in ten or more barcodes just to encode enough information, and each one had to be scanned separately. It was slow, and on an assembly line, slow is expensive. Masahiro Hara, an engineer at Denso Wave, a Toyota subsidiary, took on the challenge of designing something better. He wanted a code that could hold far more data, be read much faster, and tolerate the dirt, smudges, and odd angles of a real factory rather than a clean lab. Designing for speed and any angle The breakthrough was going two-dimensional. By encoding data in a grid of black and white squares rather than a single row of lines, Hara's team could pack in thousands of characters instead of a few dozen. The name they chose, QR for "Quick Response," was a direct promise about scanning speed. The most recognizable feature of a QR code, the three large squares in its corners, solves the hardest part of the problem: letting a scanner instantly find the code and work out its orientation no matter how the part is turned. Hara's team analyzed printed material to find a black-and-white sequence that almost never occurs naturally in text and images, and settled on a ratio of 1:1:3:1:1 for those corner markers. Because that pattern is so rare in everyday print, a scanner ca

Casey Harrell has had a set of electrodes embedded in his brain for almost three years. Harrell, who has amyotrophic lateral sclerosis (ALS) and is paralyzed, first used his brain-computer interface (BCI) to “speak” sentences with the help of a research team in 2023. Since then, Harrell has clocked thousands of hours of use. He…

Plug a sensor into a switch, wire up a building full of cameras, or rack a server, and you are using Ethernet. It is the most widely deployed wired networking standard on earth, the quiet backbone under offices, factories, and data centers. And it is named after a scientific idea that turned out to be completely wrong. The name was not an accident or a marketing afterthought. It was a deliberate engineering choice, and the reasoning behind it explains why Ethernet outlived nearly every rival and still underpins industrial IoT half a century later. A memo, a laser printer, and a dead theory The date Ethernet enthusiasts celebrate is May 22, 1973. On that day, a young engineer named Robert Metcalfe, working at Xerox's legendary Palo Alto Research Center (PARC), circulated a memo describing how to connect the Alto - one of the first personal computers - to a new device PARC had built: the laser printer. The problem was getting many machines to share one wire without their messages colliding into noise. Metcalfe needed a name for the shared medium that carried the signals. He reached back into nineteenth-century physics and borrowed the term luminiferous ether . For generations, physicists had assumed that light, being a wave, needed something to wave through - just as sound needs air. They called that invisible, all-pervading substance the ether, and they believed it filled the entire universe as a silent carrier of electromagnetic waves. The trouble is that the ether does not exist. The famous Michelson-Morley experiment of 1887 failed to detect it, and Einstein's special relativity in 1905 made it unnecessary altogether. By the time Metcalfe wrote his memo, the luminiferous ether had been a discredited idea for decades. He used it anyway, and on purpose. Why a debunked idea made for brilliant engineering Metcalfe later explained the choice plainly: "We called it Ethernet because the ether could be coax, twisted pair, radio, optical fibers, power line, whatever you wa

The first message ever sent across the network that became the internet was not "Hello, world." It was not a grand declaration. It was two letters, transmitted by accident, before the system fell over: LO . That two-letter packet is the ancestor of every connected device, every IoT sensor, and every web request running today. The story of how it happened is also a surprisingly useful lesson for anyone building embedded systems and connected hardware right now. What actually happened on October 29, 1969 On the evening of October 29, 1969, a programmer named Charley Kline sat at a terminal in Leonard Kleinrock's lab at UCLA. His job was simple on paper: log in to a remote computer at the Stanford Research Institute (SRI), roughly 350 miles away, over a brand-new experimental network called ARPANET. The plan was to type the command LOGIN . The remote machine at SRI was set up to auto-complete the rest once it saw the first few characters, so Kline only needed to start typing. He had a colleague on the phone at the Stanford end to confirm each letter arrived. He typed L . Stanford confirmed: "Got the L." He typed O . Stanford confirmed: "Got the O." He typed G - and the SRI system crashed. So the first message ever transmitted over ARPANET was "LO." As Kleinrock later liked to point out, it was an accidental but fitting first word: "LO" as in "lo and behold." About an hour later they fixed the bug and completed the full login, but the historic first packet had already gone out, two letters at a time. Why a crash is the perfect origin story It is tempting to read this as a cute footnote. It is more than that. The very first thing the internet ever did was fail partway through a transaction - and the system was built well enough that the humans on both ends knew exactly how far it had gotten before it died. That is the entire discipline of networked systems in miniature. Connections drop. Remote machines crash mid-request. Packets arrive out of order, or not at all. The n

MIT Technology Review Explains: Let our writers untangle the complex, messy world of science and technology to help you understand what’s coming next. You can read more from the series here. Your brain lives in the dark space of your skull. Yet it knows when the wind lifts the hairs on your skin, when your heart is…

Earlier this week, Life Biosciences, a biotech company focused on reversing age-related diseases, announced that it had dosed its first volunteer. A person with glaucoma has had an experimental treatment injected straight into their eyeball. The idea is to try to treat the disease—which can cause vision loss—by regenerating healthy nerves in the eye. But…

The new round values the physical AI startup that aims to automate heavy engineering and drug design at $41 billion.

Testosterone. Methenolone. Nandrolone. Human growth hormone and EPO. Meldonium, modafinil, and mixed amphetamine salts. Clomiphene, anastrozole, levothyroxine, and liothyronine. Patches and capsules, creams and pills. A whole galaxy of steroids, metabolic modulators, and synthetic hormones coursing through the blood of a few dozen swimmers, sprinters, and weightlifters. And millions of dollars up for grabs for athletes…

The FDA recently approved the cellular rejuvenation therapy ER-100 for human clinical trials. While vision is the first target, it could have applications for a variety of age-related disease.

The outspoken longevity scientist David Sinclair has been predicting that one day, you’ll go to the doctor and get a prescription that will make you 10 years younger. Now MIT Technology Review has learned that he has plans to launch human tests of an oral “reprogramming” drug as part of a $101 million competition organized…

Navigating the tech space today often feels like walking a tightrope between two extremes: massive corporate monopolies holding all the keys, and idealistic local projects trying to build everything from scratch. But this doesn't have to be an "Us vs. Corporations" battle. We don’t need to completely eliminate corporate tools; we need to leverage them. The real pragmatic goal is to use localized, decentralized data-driven systems to solve real-world physical problems on the ground, in real time. When people hear the word "decentralized," they often assume it means chaotic fragmentation, isolation, or losing control of data. It doesn't. Decentralization does not mean losing data; it means movement. In fact, the paradox of modern tech is that More Decentralized Data = Centralized Utility. 1. Moving Beyond "App Consumption" to Localized Edge Data For too long, the cultural conversation around tech has been stuck in the clouds. We talk about "the cloud" abstractly, and the average consumer's tech vocabulary is limited to a handful of corporate app names. True tech pragmatism brings data collection back down to earth, turning communities from passive consumers into active, node-operating contributors. Here is what that looks like in practice: Hyper-Local Climate Grids: Instead of teaching students about weather patterns using generic data from an airport weather station 50 miles away, a school can deploy its own low-cost local weather station. Students learn from their immediate microclimate, and that real-time local data is fed back into a wider community grid. Optimized Infrastructure: Instead of spending millions on speculative traffic studies, we can use existing, low-cost edge cameras to count traffic patterns locally. This decentralized edge data tells planners exactly what kind of infrastructure—like traffic lights (or "robots" as we call them here) or bypass lanes—a specific zone actually needs. It is planning based on true utility, not guesswork. The Energy Grid

Ask almost any engineer what "Wi-Fi" stands for and you'll hear the same answer: "Wireless Fidelity." It is one of the most repeated facts in tech, it appears in textbooks and product manuals, and it is wrong. Wi-Fi does not stand for Wireless Fidelity. In fact, it does not stand for anything at all. A name invented by a branding agency In 1999, the industry group then known as the Wireless Ethernet Compatibility Alliance — today the Wi-Fi Alliance — had a problem. The wireless networking standard it was promoting carried the memorable name "IEEE 802.11b Direct Sequence." That string is precise, but no consumer was ever going to ask a store clerk for an 802.11b router. The technology needed a brand. So the alliance hired Interbrand, the same firm behind names like Prozac and the Compaq brand, to invent something catchy. Interbrand returned with a shortlist of about ten candidates, and the group chose "Wi-Fi." Phil Belanger, a founding member of the alliance, has been blunt about it for years: the name has no expanded meaning. It was picked because it was short, easy to say, and rhymed with "Hi-Fi," a term consumers already associated with high-quality audio gear. So where did "Wireless Fidelity" come from? The myth has a real origin. Some board members were uncomfortable shipping a brand name that "meant nothing," so the alliance briefly bolted on the tagline "The Standard for Wireless Fidelity." It was a backronym — two words reverse-engineered to fit the syllables "Wi" and "Fi" after the fact. The phrase was clumsy, it never described the technology accurately, and once the alliance brought on more marketing-savvy members it was quietly dropped. The tagline disappeared; the misconception it planted did not. Why this matters if you build connected things This is a fun piece of trivia, but it points at something real for anyone doing IoT and embedded development . The protocols we treat as immovable technical bedrock are often shaped as much by branding, licensing,

Learn how to build a real IoT weather station using the Arduino UNO R4 WiFi and BME280 sensor, sending live temperature, humidity, and pressure data to Arduino IoT Cloud — with full code, wiring diagrams, and dashboard. What We're Building In this project, you'll build a cloud-connected weather station that measures: Temperature (°C / °F) Humidity (%) Atmospheric Pressure (hPa) All three readings will be streamed live to the Arduino IoT Cloud , where you can monitor them from anywhere in the world via a browser or the free Arduino IoT Remote app on your phone. Components Required Component Qty Notes Arduino UNO R4 WiFi 1 Built-in ESP32-S3 WiFi module BME280 Sensor Module 1 Measures temp + humidity + pressure via I²C Breadboard 1 Full or half size Jumper Wires (M-M) 4 For I²C connections USB-A to USB-C Cable 1 For power & programming Why BME280 over DHT22? The BME280 gives you three measurements (including barometric pressure) over a single I²C bus using just 2 wires, making it more capable and cleaner to wire. The DHT22 only gives temperature and humidity. Wiring the BME280 to Arduino UNO R4 WiFi The BME280 uses the I²C protocol , so it only needs 4 wires: BME280 Pin → Arduino UNO R4 WiFi Pin ────────────────────────────────────── VCC → 3.3V GND → GND SDA → A4 (I²C Data) SCL → A5 (I²C Clock) Important: The BME280 runs on 3.3V , not 5V. Connecting it to the 5V pin can damage the sensor permanently. Here's the schematic overview: ┌────────────────────────────┐ │ Arduino UNO R4 WiFi │ │ │ │ 3.3V ──────────────► VCC │ │ GND ──────────────► GND │ ← BME280 │ A4 ──────────────► SDA │ │ A5 ──────────────► SCL │ └────────────────────────────┘ ☁️ Step 1 — Set Up Arduino IoT Cloud Before writing any code, you need to configure the Arduino IoT Cloud . It's free for up to 2 devices. 1.1 Create a Free Account Go to cloud.arduino.cc and sign up or log in. 1.2 Create a New "Thing" Click Things in the left sidebar Click + Create Thing Name it WeatherStation 1.3 Add Your Device Click

Somewhere along the way, computing became disposable. Devices became sealed. Systems became rented. Ownership became licensing. Repairability disappeared. Infrastructure moved away from the user and into distant cloud platforms. And I think we lost something important because of it. Lately, I’ve found myself becoming increasingly interested in hardware again. Not just software. Not just cloud systems. But actual computing devices. Servers. Home infrastructure. Repairable machines. Set-top systems. Local AI appliances. Sovereign computing. Because I believe the next era of computing will belong to people who own their infrastructure again. The Provider Box Realization One thing that kept sticking in my head was this: Almost every home in America already has a provider box. A Comcast box. An AT&T gateway. A router. A modem. A streaming box. People are already comfortable with the idea of a dedicated computing appliance sitting in their home quietly powering their digital life. That realization changed how I thought about computing infrastructure. What if those boxes worked for the user instead of the provider? What if they: hosted local AI, managed home storage, coordinated smart devices, powered media systems, handled automation, protected privacy, synchronized intelligently, and operated as sovereign infrastructure? That idea became part of the thinking behind KiwiHome. The Return Of Home Infrastructure For a long time, the industry moved toward centralization. Everything shifted toward: SaaS, subscriptions, streaming, cloud storage, cloud intelligence, and rented operational environments. Convenient? Absolutely. But also fragile. If: pricing changes, services disappear, companies shut down, APIs get revoked, or platforms change policies, entire workflows collapse overnight. I think people are starting to feel that tension. Especially creators. Especially businesses. Especially technical users. That’s why I believe we’re going to see a major resurgence in: home serv

Ask a roomful of engineers where the name "Arduino" comes from and you will get confident answers about acronyms, Italian for "bold friend," or some clever electronics pun. Almost all of them are wrong. The most influential open-source microcontroller board in history — the one that introduced millions of students, artists, and tinkerers to embedded development — is named after a bar. The pub in Ivrea The story begins in Ivrea, a small town in northern Italy straddling the Dora Baltea river. In the early 2000s it was home to the Interaction Design Institute Ivrea, where a team led by Massimo Banzi was looking for a cheap, approachable way to teach design students how to make things that sense and respond to the world. The tools available at the time were either too expensive or too intimidating for people who were not electrical engineers. So, in 2005, the team built their own board and released the design as open hardware. They needed a name. Banzi and his collaborators were regulars at a local pub called Bar di Re Arduino — "the Bar of King Arduino." When it came time to christen the project, the bar's name stuck. There was no acronym, no marketing committee, no focus group. The board was named after the place where the people who made it spent their evenings talking through ideas. The medieval king behind the bar The bar itself carries a much older name. Arduin of Ivrea — Arduino in Italian — was a real historical figure, an Italian nobleman who became King of Italy in 1002 and held the crown until 1014. He is one of Ivrea's famous "underdog kings," remembered locally long after his short reign ended. So the chain runs a thousand years deep: a development board used in connected sensors and robots today is named after a pub, which was named after an early-medieval king who ruled around the year 1000. It is the kind of detail that sounds like trivia, but it points at something real about how durable technology actually comes together. Why the origin story matters

Applications for Startup Battlefield 200 officially close on June 8, 11:59 p.m. PT. Don't wait any longer. Secure your shot at competing on the Disrupt Stage at TechCrunch Disrupt 2026 this October at San Francisco's Moscone West.

There are more IoT protocols out there than most teams will ever need. That sounds overwhelming until you realize most connected products only use two or three; one for local communication, one for cloud connectivity, and sometimes one for device management. The problem is not the number of options. The problem is that the protocol you pick at the design stage gets baked into your firmware, your cloud pipeline, and your data model. Change it later and you are rewriting half of your stack. Here is a practical breakdown of the protocols that matter for most developers building connected products today. The Three Layers You Are Choosing Across IoT protocols sit in three distinct layers, and you typically pick one from each: Application Layer → MQTT, CoAP, HTTP, AMQP (how data reaches your cloud) Network Layer → LoRaWAN, NB-IoT, LTE-M, Wi-Fi, BLE (how data travels physically) Industrial Layer → Modbus, OPC UA, Profinet (machine-to-machine on the factory floor) A soil moisture sensor on a farm might use LoRaWAN at the network layer to push data 10 kilometers to a gateway and MQTT at the application layer to deliver that data to a cloud dashboard. Two protocols, two layers, one product. The Big Three for Cloud Connectivity MQTT - The Default for a Reason Publish-subscribe model. Lightweight. Three QoS levels for delivery guarantees. Run over TCP with TLS encryption. Roughly 70% of cloud-connected IoT deployments use MQTT today. A basic publish looks like this: import paho.mqtt.client as mqtt client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2) client.tls_set() client.connect("broker.example.com", 8883) client.publish("sensors/temperature", '{"value": 23.5, "unit": "C"}') Use when: You need real-time telemetry, bidirectional device control, or guaranteed message delivery across unreliable networks. HTTP - Not for Telemetry, But Still Essential Too heavy for continuous sensor data. But it is the standard for OTA firmware updates, cloud API integrations, and management das

This week I’ve been at SXSW London. There’s been music, film, and a lot—and I mean a lot—of talk about AI. I also had the opportunity to sit down with Gloria Mark, a psychologist at the University of California, Irvine, who has spent the last 30 years studying how people interact with digital technologies. Early…