标签：#embedded

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 o

Why 40V Input and 500mA Output Matter in Noise-Sensitive Designs You’ve probably fought a power rail that looked clean on a multimeter but still trashed your 24‑bit ADC readings. The culprit is rarely the DC level—it’s the broadband noise, switching artifacts, and line‑frequency ripple that ride on top. In precision analog, RF, and sensor signal chains, even 50 µV of supply noise can bury a 1 mV sensor signal or degrade an RF PLL’s phase noise by 10 dB. The MAX20151R addresses this head‑on with a combination that’s hard to find in a single LDO: a 40 V input range, 500 mA output drive, and just 6.5 µV RMS output noise (10 Hz–100 kHz). That wide input headroom lets you power sensitive circuitry directly from a 12 V or 24 V industrial rail, an automotive battery, or a noisy intermediate bus without a pre‑regulator. You eliminate an entire buck converter stage, saving board space and avoiding the switching noise that would otherwise require heavy filtering. The 500 mA output current is equally important. Many ultra‑low‑noise LDOs top out at 200 mA or 300 mA, forcing you to split rails or add a discrete pass transistor. With 500 mA, the MAX20151R can comfortably supply a mixed‑signal chain—an MCU, a precision ADC, a low‑jitter clock, and a handful of op‑amps—from a single quiet rail. And because the device maintains its noise performance across the full load range, you don’t have to derate your noise budget as current increases. Field experience shows that transient events on 24 V vehicle buses can easily exceed 40 V during load dump. The MAX20151R’s 40 V absolute maximum input rating, combined with integrated reverse‑voltage protection down to –40 V, gives you a robust front end that survives those spikes without external clamping. This is a practical necessity for any design that must pass ISO 7637‑2 or similar automotive transients, and it’s a key reason engineers are migrating from lower‑voltage LDOs to the MAX20151R in harsh electrical environments. Key Takeaway: If

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 pr

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

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 acro

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 con

Dalla libreria embedded che ha invaso ogni dispositivo a un’implementazione moderna con concorrenza, async I/O e vector search: cosa cambia davvero per chi sviluppa app. Nel frontend e nel full‑stack capita spesso di parlare di database come servizi: Postgres gestito, cluster, repliche, connessioni, pooling, credenziali e una lunga lista di “cose che possono rompersi”. Ma esiste un’altra filosofia, più vicina all’idea di “dipendenza” che di “infrastruttura”: un motore SQL che vive dentro l’applicazione. Questa è la ragione per cui SQLite è ovunque. È una libreria, non un server. Legge e scrive su un singolo file su disco. Riduce drasticamente configurazione, porte, processi separati e complessità operativa. Ed è proprio questa semplicità a renderla una delle fondamenta silenziose dell’informatica moderna: la usi in browser, smartphone, desktop app, tool CLI, IoT… spesso senza nemmeno accorgertene. Ora immagina di riscrivere tutto da capo, in Rust, cercando di essere compatibile al 100% e allo stesso tempo più “moderna”. Sembra un’idea folle per definizione—finché non inizi a guardare ai limiti pratici che oggi emergono in molte applicazioni. Perché toccare SQLite, se funziona così bene? SQLite non è “il problema”. Anzi: è considerata estremamente robusta perché è conservativa, minimalista, e custodita con un rigore quasi maniacale. Il punto è un altro: il suo modello di sviluppo e manutenzione è atipico rispetto a quello che molti intendono per open source collaborativo . Il codice è disponibile e utilizzabile liberamente, ma l’evoluzione è guidata da pochissime persone e—di fatto—non segue la dinamica classica delle contribution esterne. Questa scelta ha un effetto collaterale positivo: riduce il rischio di regressioni introdotte da cambiamenti non coerenti con la visione del progetto. Ma ha anche un costo: se la tua azienda o il tuo prodotto hanno esigenze nuove (concorrenza più spinta, I/O non bloccante, funzionalità specifiche), “aspettare che arrivi upstream” n

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 o

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

Every FreeRTOS project I've worked on has the same problem. You have a sensor task that reads temperature. You have a UI task that needs to display it. So you create a QueueHandle_t, pass it to both tasks at init, call xQueueSend on one side and xQueueReceive on the other. Fine. Then you add a WiFi task that also needs temperature. You add another queue. Then a logging task. Another queue. Soon your app_init() is a mess of queue handles being passed around, and changing one task means touching everything it's connected to. On bare metal it's the same story in a different shape — a dozen global flags in main: if (flag_sensor) ... if (flag_button) ... if (flag_timer) ..., each one added as the project grows, none of them easy to trace back to where they're set. On embedded Linux it's pointers — modules holding direct references to each other, so a change in one ripples everywhere. I wanted one solution that works across all three without rewriting the dispatch logic every time. embedmq collapses it to 3 functions: embedmq_register(q, "sensor.temp", on_temp, NULL); // subscriber embedmq_post(q, "sensor.temp", &data, sizeof(data)); // producer, any thread/task No shared queue handles. No global flags. No direct pointers between modules. The library handles the ring buffer, the mutex, and the semaphore wakeup. Same API, three platforms: Linux: pthread + POSIX semaphore, zero external dependencies FreeRTOS: counting semaphore + xTaskCreate, static mode for zero heap after init Bare-metal: C11 atomic spinlock, drive dispatch with embedmq_poll() from your superloop FreeRTOS PAL is verified on the POSIX simulator in CI — not real hardware yet, I'll be honest about that. GitHub: https://github.com/w4ysonch/embedmq Happy to answer questions about the design or the FreeRTOS porting details.

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

Removing expf() from a fire detector: one header, 1.95x faster, zero accuracy loss A smoke detector is not a demo project. When it fires, someone either evacuates in time or doesn't. The firmware running on that microcontroller has one job, and it needs to do it without hesitation, without bloat, and without dependencies that can fail in unexpected ways. Last May 28th I published a bare-metal fire detection system built with Hasaki 刃先 — a neural network trainer that exports standalone C headers with no runtime, no Python, no TensorFlow. The model is a 12-8-4-1 MLP trained on 28,596 sensor readings. It fits in 3.8 kB of Flash and achieves 99.93% accuracy on held-out data, with a single missed fire event out of 3,599. But there was something in that header that bothered me. static inline float sigmoid ( float x ) { return 1 . 0 f / ( 1 . 0 f + expf ( - x )); } expf() . Right there in a life-safety application. On a microcontroller that may not have a hardware FPU. The problem with expf() on bare metal On processors with a hardware FPU — like the ESP32-C3 — expf() is fast. But the moment you deploy to an ATmega328P, an ATtiny85, or any Cortex-M0 target, that call becomes software floating-point. The CPU has to simulate the operation in firmware, cycle by cycle. It works. But it carries hidden cost: unpredictable latency, dependency on math.h , and a transcendental function sitting in the critical path of every single inference. For a smoke detector running at 1 Hz this might seem irrelevant. But inference latency compounds with sensor reads, normalization, and communication overhead. And more importantly — if you're deploying to a truly constrained target, expf() might be the difference between fitting in Flash or not. The fix: one header from kigu-quant kigu-quant(comming soon) is a new tool in the Rosito Bench ecosystem. It generates ready-to-include C headers for evaluating mathematical functions on microcontrollers — no FPU, no libm, no dependencies. One command: k

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,

The first time I encountered an EIA-96 resistor , I assumed the marking would tell me the resistance value directly. I was troubleshooting a PCB and found a resistor marked 24C . Naturally, I expected some relationship between "24" and the actual resistance. After measuring and checking the datasheet, I discovered the resistor was 17.4 kΩ . That raised an obvious question: Why doesn't the code match the resistance value? The Problem With Traditional SMD Codes Most electronics enthusiasts learn resistor markings through familiar examples: 103 = 10 kΩ 472 = 4.7 kΩ 681 = 680 Ω These markings are straightforward. The first digits are significant figures and the last digit is a multiplier. The system works well for common resistor values, especially 5% tolerance components. However, things become complicated when manufacturers need to identify large numbers of precision resistor values on extremely small packages. Enter the EIA-96 Series Precision resistors often use the E96 preferred value series. Instead of having only a handful of values per decade, the E96 series contains 96 standardized resistance values between powers of ten. Some examples include: 100 Ω 102 Ω 105 Ω 107 Ω 110 Ω 113 Ω Notice how closely spaced these values are. Trying to represent all of them with traditional three-digit markings would quickly become messy and inconsistent. A Different Approach Rather than printing the resistance value directly, EIA-96 uses an index system. Each number from 01 to 96 corresponds to one of the standard E96 values. For example: Code Base Value 01 100 24 174 68 499 96 976 A letter is then added to indicate the multiplier. So the resistor marking becomes: Number + Letter Instead of: Resistance Value Example: Decoding 24C Let's break down 24C. First, look up the base value: 24 → 174 Next, decode the multiplier letter: C → ×100 Now calculate: 174 × 100 = 17,400 Ω Final resistance: 17.4 kΩ At first glance, nothing about "24C" resembles 17.4 kΩ, but that's because the code i

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

Voltage lies. Put a battery under load and its terminal voltage sags. Let it rest and the voltage springs back. A naive fuel gauge watching only voltage will happily tell you a worn-out cell is "fine" right up until it falls off a cliff. The number you actually care about — is this battery still good, or is it time to replace it? — isn't in the instantaneous voltage at all. It's in the capacity : how much charge the cell can still deliver between full and empty. That quantity fades as a cell ages. Tracking it is called State of Health (SoH) , and it's the difference between "the device says 80%" and "the device has 80% of the runtime it had when it was new." I wanted my open-source battery SDK ( ibattery-sdk , Apache-2.0) to learn SoH on the device itself — no cloud model, no floating-point, on MCUs with kilobytes of RAM. This post is the story of getting that working end to end: from a coulomb integral in firmware to a faded value showing up live on a Grafana dashboard. The idea: learn capacity from one full→empty trip You don't need a PhD-grade model to estimate usable capacity. You need two anchors and an ammeter. Full anchor — when the cell is at its full-voltage plateau, declare "this is full" and set the coulomb counter to the rated capacity. Discharge — integrate current over time (coulomb counting). Every milliamp-hour that leaves the cell ticks the counter down. Empty anchor — when the cell hits its empty-voltage threshold, look at how much charge actually flowed. A healthy cell delivers close to its rated capacity before going empty. An aged cell hits empty early — it simply has less to give. From the charge measured between those two anchors, you get the cell's real usable capacity, and SoH = measured / rated . The SDK runs it through an integer EMA (so one noisy excursion doesn't whip the estimate around) and a plausibility guard (reject anything outside 30–120% of rated — that's almost certainly a glitch, not a real measurement). The whole thing is inte

The chatbot is tricking me!!! 💬📜⌛ When you text a chatbot, it doesn’t actually remember who you are or what you said two minutes ago. The exact millisecond it finishes typing a response, its brain completely wipes clean. To pull off the illusion of a continuous, flowing conversation, the web application secretly copy-pastes the entire past chat history, bundles it up, and blasts that whole massive block of text back into the processor every single time you hit send. Your "chat session" is an illusion maintained entirely by an ever-growing stateless prompt wrapper. You aren't interacting with a growing, adapting mind; you are repeatedly gas-lighting a brand-new entity into believing it has been talking to you for an hour. Wait, I am the one training it ??? 🚦🚸🚲 AI models are inherently blind to context; a computer doesn't instinctively know that a specific cluster of raw pixel values represents a real-world object. It requires billions of examples to be manually labeled by a human mind before the math can understand it. Every time you click on squares containing "traffic lights," "crosswalks," or "bicycles" to unlock a website, you are acting as an unpaid data annotator. You are manually labeling complex, messy real-world data points that feed directly into the computer vision systems of autonomous vehicles. The grand paradox of modern cyber security is that we force humans to act like mechanical data annotators to prove they are not computers, all so that computers can learn how to perfectly impersonate humans. The supercomputer is stupider than a toddler... 🍓👶🏻🖥️ We assume AI read letters and words the same way human eyes scan a page. It doesn't—it is entirely alphabet-blind. Before text hits the AI's brain, a parser chops strings of text into numerical blocks called "tokens." For example, the word "strawberry" isn't seen by the model as ten distinct letters; it is compressed into numerical IDs representing chunked pieces like "straw" and "berry". Because it never s

There is a moment every embedded Linux developer hits eventually. You have spent days building something that works beautifully — a sensor pipeline, a streaming server, an MQTT client — and then you reboot the device and everything is silent. Nothing started. You SSH in, manually run your script, and it all comes back to life. The hardware is fine. Your code is fine. You just have no way of automatically running it. That is the gap systemd fills. It is the init system on virtually every modern Linux distribution, and on embedded Linux systems like the Raspberry Pi it is what decides what runs at boot, what gets restarted if it crashes, and where all the logs go. Once you understand how to write a service file, your applications stop being fragile scripts you need to babysit and start being first-class system services that survive reboots, network drops, and unexpected crashes. This tutorial builds up from the simplest possible service file to a production-ready configuration, explaining every line along the way. By the end you will have a service running your own Python application, logging to the system journal, and automatically restarting itself after failures. See Complete Tutorial in Github: Systemd Services Tutorial What systemd Actually Does Before writing any configuration, it helps to understand what problem systemd is solving, because the design of service files makes much more sense once you see the underlying model. When your Raspberry Pi boots, the Linux kernel starts and immediately hands control to process ID 1 — the very first user-space process. On modern systems, that process is systemd . Everything that happens next — mounting filesystems, bringing up the network, starting your application — is orchestrated by systemd. It reads configuration files called unit files that describe what should be started, when, in what order, and what to do if something goes wrong. A service file is just one type of unit file (there are also unit files for timers, so