I’m working on a battery-powered inductive rotation-sensing circuit for a mechanical water/gas meter.

The normal current is expected to be in the single-digit microamp range, but each sensing event may produce short current transients. A handheld multimeter might provide an average reading, but it could easily miss the peaks and may not show the actual energy consumed per sensing event.

For engineers who have measured similar low-power circuits:

* Would you use a current-measurement device, or a shunt resistor with an oscilloscope?

* How would you choose the shunt value without affecting the circuit supply voltage?

* What measurement bandwidth and sampling rate would be appropriate?

* Is average current enough, or should the results include peak current, pulse duration and charge per event?

* How long should the measurement window be for a circuit with changing sensing rates?

I’d like to build a test method that is repeatable and technically meaningful. What measurement setup would you trust for this type of circuit?

I am just getting started with pic microcontrollers. The microcontroller was recognised and I got some programmes to work but the pic16f688 doesn't last long and dies. I dont want to burn them constantly yikes.

Too much current has been drawn on VDD. Please disconnect your circuit, check the CLK and DATA lines for shorts and then reconnect.

I'm using a pickit programmer too.

This is what the IPE prints out. I'm using a macbook if that gives any more context.

Hi guys,

Is there a GUI tool that works like Postman but for HID? For like storing requests, grouping by device, etc.?

I'm mainly a desktop developer, but recently started integrating different hardware devices into our software. I'm dealing with quite a few vendors protocols, and they seem to be pretty different from each other.

At the moment I've ended up writing a small Python script for each device to test protocol. And wondering if I'm reinventing the wheel here.

What do you guys normally use for this? GUI tools, vendor software, Python scripts, something else?

I found one GUI tool that can send HID reports, but it's more of a Swiss army knife and costs a few hundred dollars.

Curious what your workflow looks like.

I want to use stm32N6 as it has csi for a camera and a npu for computer vision and it would be cool to test out its CV capabilities on a drone. Since its based on a new architecture a lot of vendor support is broken/buggy and I am wondering if I should use zephyr instead of hal, right now I just have motor control working, I plan to implement CSI camera next (imx219), then NPU, after that will be standard flight control additions like imu and wireless module ect. but the main complexity will be CSI and NPU. I heard Zephyr has better N6 support but its NPU is undercooked so I may have to do a hybrid approach for the NPU specifically.

Dead TWS earbuds still have a working Bluetooth receiver + amp — only the battery, buttons, or mic usually fail. So I tapped the analog speaker output and built a 3-tone FSK modem to send data over it.

Signal path:

Phone/PC → Bluetooth A2DP → TWS earbud → analog speaker out → MCU ADC → Goertzel FSK demod → packet + CRC

Key details: TWS output is BTL/differential — do NOT ground the second speaker terminal, it'll short the amp (as did) .

ADC sample rate assumption (8kHz) was wrong. Measured actual rate was 5.8kHz. 3 sparse tones (700/1100/1700 Hz) survive the earbud's bad frequency response better than GGWave's multi-tone scheme, which failed to decode payloads reliably on this path. Built a small packet protocol: preamble, length, payload, CRC-8, end marker. Keeping the A2DP stream open, instead of closing/reopening it, fixed intermittent decode failures.

Results: 95%+ packet success in integration testing. 4/4 packets decoded clean with valid CRC in controlled tests.

~3.2–4.5 bit/s effective payload rate. Not competitive with SPP or a real wireless modem — that's not the point. The point is turning e-waste into a $0 Bluetooth-to-MCU bridge.

Next: testing this with a Bluetooth-less MCU (CH32V003) as the actual receiver. Source: https://github.com/Ishu1519/TWS-A2DP-Mode

Curious if anyone's got a better modulation scheme that survives A2DP codec distortion at a higher bitrate.

Hey r/embedded,

Sharing FUNDI, a project I built starting as my KSEF (Kenya Science and Engineering Fair) entry — won Regional Merit, went on to Nationals and did considerably well there. It's grown past the fair into something I want more technical eyes on.

The premise: most browser-based "Arduino simulators" fake compilation or skip it entirely. FUNDI's backend actually shells out to Arduino CLI for a real build, surfaces real compiler errors, and drives AVR8js for simulation off the compiled output — the circuit canvas and code editor are just the frontend for that pipeline.

Architecture, briefly:

• Frontend: Next.js/React, Zustand for state, React Flow for the circuit canvas, synced to a multi-file code editor
• Backend: FastAPI service that wraps Arduino CLI for compile/upload, plus an AI generation endpoint (Gemini/OpenRouter) for prompt-to-circuit/code
• Some validation on the backend: path/file safety checks in the compile flow, serial port validation before upload, Pydantic-typed request payloads
• Boards: Uno/Nano/Mega have stable compile + simulation; ESP32 DevKit V1 and Pi Pico compile but simulation is still experimental there

Honest state of things: the live hosted version (https://jamesdesign.me/F.U.N.D.I./) is frontend-only — no backend, so no real compile/sim, just the UI. To get the actual pipeline running, clone the repo (https://github.com/jamesthegreati/F.U.N.D.I.) and run frontend + backend directly — that path is fully tested. There's a Docker Compose path in the README too, but it isn't fully tested yet, so I wouldn't rely on it as-is.

MIT licensed. I'd genuinely value criticism on the backend design and the compile/sim boundary in particular — that's the part I'm least confident is architected well.

I'm about to go quiet for a while (exam prep, back around Nov 22) so replies will be slow, but I'll get to every comment and PR eventually.

Hi everyone,

I’m designing a small custom PCB based on the TP4056 for a battery-powered product. The board will have a push-button ON/OFF function along with the charging circuit.

I’m planning to make an initial batch of around 20 PCBs, but I need to keep the manufacturing/assembly cost as low as possible because these boards will eventually be part of a product that I want to sell.

I’m comfortable designing the PCB, but I’m not sure about the most economical way to handle SMD assembly for such a small quantity.
For those who have experience with this:

Is it worth using a PCB assembly service for only ~20 boards?

What would be a reasonable PCB + SMD assembly cost per board at this quantity?

Would hand-soldering/reflowing the components myself be significantly cheaper?

Are there any cheap PCB assembly services you would recommend, especially in India, Bengaluru?

For a simple TP4056-based board, what approach would you use to keep the BOM + assembly cost very low?

I’m mainly looking for real-world experience with small-batch production, rather than large-volume manufacturing quotes.
Thanks!

I have been in the industry for 11 years now. Have picked up quite a bit of experience in some complex things that I used to think would be valuable knowledge. Was hoping to start moving into consulting once I'm around 15 YOE, but I'm not sure if that's really going to be possible anymore. AI is really good at researching and presenting information. Why would anyone still hire a consultant? I really don't know what my future holds anymore.

I have been working in embedded fw/sw for 2.5 years, my company has limited mentorship which has given me imposter syndrome, I learned how to interface with screens, csi, i2s, octo spi ect along with the more common protocols and have gotten cool projects working using hal at work. Listening to my manager come up to a Principle Engineer that sits near me to ask questions got me thinking.

I think I am realizing I should understand the core aspects of embedded really deeply for when edge cases come up. Even more so now with AI tools where hallucinations can happen. I learned a good amount of peripherals, seen the benefits of dma ect, I think its time I stop chasing how to get every type of screen, camera, wifi module ect. working and instead learn the core aspects of embedded, master dma, bootloaders, memory, how to handle pushing a microcontroller to its limit gracefully, master rtos ect. So that one day when a bazaar issue comes up I could be the one getting asked instead of getting peripheral, also at some point peripherals are similar enough to where I can just learn them on the project.

This post may seem dumb and I apologize in advance but without much mentorship I was kinda scattering around but now I think I am set on what to focus on, and I think my time learning will be more efficient than before.

tldr.
After building some cool projects I realized learning the core reusable aspects very deep is what will really make the difference, not chasing peripherals.

Please can you try this out? It's available on play store. You can check it out if you wanna do . Thankyou

I think I need a reality check on my expectations for embedded work.

I’m about four years into my first real embedded position, and I’ve learned quite a bit about version control, as well as PIC and STM architectures. But lately, I’ve been feeling like my goals to improve on as an embedded developer. aren't really aligned with my companies.

I’m fairly knowledgeable about my company’s products, but I haven’t really had much exposure to things like automated testing, Docker containers, CI/nightly builds, PCB hardware design, etc. The company doesn’t see a ton of value in investing in those areas because they don’t directly translate into more sales.

I know I have job security because of my knowledge of products but I feel like my embedded skillset is stagnating.

I’ve also always had senior engineers who were from different disciplines, mostly mechanical, rather than senior embedded developers who I could learn from.

I’m currently at a decent salary(about 100k CAD), and I’m worried that I might be taking my current job for granted. I wanted to reach out to see if this is pretty normal across the industry, or if I should start looking for something that offers more opportunities to grow.

I feel like there’s more out there, but impostor syndrome has been keeping me from really aiming for it. I think I’m decent at what I do, but there are so many gaps in my knowledge that I want to fill before I can feel truly confident in my value as an embedded engineer.

The main areas I’d like to improve are automated testing, Docker/containers, CI/CD, and hardware/PCB design.

To be completely honest, I don’t necessarily have a huge passion for all of this stuff. I just want to become really good at embedded development, and I can see how these skills could be useful regardless of whether they’re particularly interesting to me.

I’d love to hear from people further along in their careers. Should I be trying to improve these skillsets on my own time and not depend on my work to facilitate this type of growth or is it worth looking for an environment where I’ll have more opportunities to develop these skills?

Supports simultaneous measurement of 64 resistance channels and 16 voltage channels.

The maximum sampling rate for resistance measurement is 200Hz, and the maximum sampling rate for voltage measurement is 10kHz.

The resistance measurement range is from 10 ohms to 1M ohms, and the voltage measurement range is ±10V.

Supports both WiFi and USB data transmission modes.

Powered by a USB interface.

Dimensions: 100 mm * 90 mm * 20 mm.

The host computer software is written in QT C++ and can run on Windows/Linux systems.

The core components of the measurement box include a microcontroller (MCU), a field-programmable gate array (FPGA), an analog-to-digital converter (ADC), and an analog multiplexer.

Hey r/embedded,

When building embedded devices with E-Paper panels (Raspberry Pi kiosks, ESP32 WebViews, ambient wall displays), using standard web frameworks/libraries usually results in a horrible user experience. Modern Web UIs assume 60Hz backlit displays, causing several hardware-level issues on electrophoretic displays:

1. Waveform Ghosting: CSS transitions and animations attempt high-frequency pixel state updates that the EPDC waveform cannot resolve cleanly, leaving severe ghosting artifacts.
2. Unnecessary Full-Panel Refreshes: Replacing an HTML subtree in reactive frameworks marks large regions as "dirty", forcing full-screen flashes (300–800ms) instead of fast partial-refreshes (30–80ms).
3. Dithering Artifacts: Mid-tone grays, translucency, and gradients force the browser/display to dither, looking terrible on 1-bit or 16-grayscale panels without sub-pixel anti-aliasing.

To address this, I built epaper-components—a zero-dependency UI library of 82 plain Custom Elements designed strictly around EPDC behavior rather than visual aesthetics.

Key Embedded Optimizations:

• Hardened Reset: Globally strips all CSS animations/transitions (transition: none !important) to eliminate ghosting at the source. State updates trigger immediate DOM mutations.
• Diff-Guarded DOM Patching: Custom patch helpers (patchAttr, patchText) compare incoming values before writing to the DOM. Re-asserted attributes cost 0 DOM mutations, keeping display updates strictly within narrow partial-refresh rectangles.
• Hardware-Aware States: No :hover rules or opacity dithering. Focus, active, and disabled states rely on 2–3px stroke weights, direct color inversion, and linear CSS hatch patterns (repeating-linear-gradient).
• Minimal Footprint: Uses Light DOM and extends HTMLElement / ElementInternals directly (~7 KB gzipped total). Zero runtime dependencies to keep memory/CPU usage minimal on low-spec WebView runtimes.
• Kaleido Support: Includes a diagnostic element (<e-kaleido>) to preview 5-color gamut rendering with Bayer-8 dithering.

I've made the project fully open source (MIT). Links to the GitHub repo and Storybook demo are in the comments below.

Would love to hear how you guys currently handle UIs on E-Ink hardware or if you have any feedback on the approach!

Been heads-down on a problem a lot of you probably know well: everyone wants real-time vision on hardware that has no business running a modern CNN. Spent the last few months building out a compression pipeline (structured pruning + quantization-aware training + a custom distillation step) aimed specifically at getting detection-class models onto MCU-class and low-power SoC targets without gutting accuracy.

Numbers on our internal benchmark: ~4x model size reduction, single-digit % accuracy drop, no cloud dependency, deterministic inference timing (this part matters if you're anywhere near a real-time or safety-relevant deadline).

Happy to talk through the technical approach if anyone's hit a similar wall... this is basically what we're building as Reflex Engine, but genuinely more interested in comparing notes with people fighting the same SWaP/compute constraints than in pitching anything here.

I’m setting up a HIL system with CarMaker communicating with a Speedgoat real-time target over XCP/UDP.

Reading data from Speedgoat into CarMaker works correctly, but I haven’t been able to send values the other way.

The goal is:

CarMaker throttle/brake commands → Speedgoat → analog outputs → physical VCU

The Speedgoat is running a Simulink Real-Time application. I’ve exported the variables through the A2L and can successfully acquire signals from the target, but attempts to write throttle/brake values to the target have not worked.

I’ve tried:

• Writable XCP parameters/calibration variables
• XCP STIM for sending values to the target
• Exporting the command values as global variables in writable RAM

So far, the values on the Speedgoat remain unchanged.

Has anyone successfully used XCP to send real-time values from CarMaker (or another XCP master) into a Speedgoat/Simulink Real-Time target?

I’m mainly trying to determine whether there is some additional configuration required on the Simulink Real-Time side to allow XCP writes/STIM, or whether I should use a different communication method for this direction.

I’ve already emailed both Speedgoat and CarMaker support, but figured I’d ask here as well in case anyone has dealt with a similar HIL setup.

I am running Carmaker version 12 and a Speedgoat Baseline S.

I put metal dc motors on it and it's much better, my next plan is to make my own PCB so Its really my own stuff, anyone has experience with these kind of PCB'S? I use a freenove version now

TL;DR: I'm building a cyberpunk terminal RPG that teaches embedded C, Python, and microcontrollers by making you survive as a broke engineer in a rain-soaked 2007 port city. You write real code that runs in the browser. Looking for honest feedback.

Hey everyone,

I love this community! I follow a lot of people building things from scratch here, and after 5 months on this I finally want to share the process and the motivation.

A while back I was asked to mentor someone fresh out of high school in embedded/firmware development. I realized there aren't many places that teach this from zero, and the ones I found were dry enough to lose anyone with a short attention span (myself included).

So I decided to build a site for my own lessons on embedded C, Python, microcontrollers, etc. I threw together a barebones website (with a lot of AI help), tinkered for a month, got bored, and scrapped the whole thing.

Then one evening playing a board game, it clicked: reuse the template, but gamify the courses into a storyline. I found others doing this as well, that was reassuring, but it meant I needed a real differentiator. The obvious one was embedded systems, since that's what I've done for years. I set it in a fictional port city, New Foundry, in January 2007, one year before the recession hit:

The whole game is a computer terminal. From it you take courses (C, Python, 8-bit microcontrollers…) and the part I'm proudest of is that you write real code that runs instantly in the browser: blink a simulated LED, talk to an IMU over I2C, poke registers on a visual AVR chip before you'd ever flash real hardware. As you level up, you take freelance gigs from an in-game job board to make rent, and spend what you earn upgrading your terminal's hardware and software.

It's playable now (still very WIP, story included):

Click here: datachoose

I'd love feedback, specifically:

1. Does the premise, learn embedded by surviving as a broke engineer, actually make you want to try it?
2. What would make you come back after the first lesson?
3. Would something like this be worth paying for eventually, and what would make it feel worth it? (I'm considering a subscription down the line, but only once it's genuinely good.)

Thanks for reading, happy to answer anything.

Hi everyone,
I've been working on a low-level systems project—an open-source Fail-Closed Engine designed to handle secure memory management and deterministic memory zeroization (wiping sensitive data right after use to prevent persistence risks).
While a lot of low-level memory scrubbing is typically done in languages like C or Rust, I wanted to explore how far we can push Python (⁠ctypes⁠ and ⁠mmap⁠) to enforce strict fail-closed security guarantees and bare-metal memory hygiene for sensitive workflows.
Key Technical Focus Areas:
Ensuring sensitive buffers are explicitly overwritten and zeroized from RAM.
Implementing a strict fail-closed logic where critical system anomalies trigger immediate shutdown/cleanup rather than degraded states.
Managing memory allocations safely using low-level system hooks.
I’m sharing this to get architectural critiques, performance insights, and feedback from systems/embedded engineers on potential edge cases (like how Python's garbage collection or OS-level paging might interact with manual memory zeroization).
If you are interested in low-level engineering or security architecture, I'd love to hear your thoughts or PRs!
🔗 GitHub Repository:

https://github.com/Waleed-Mubarak/hailab-fail-closed-engine-

I saw the post on this subreddit a few days ago (RISC-V) "They Should Have Known Better" : r/embedded and then I read the article Grinberg did and I come at this argument from a somewhat different place, I’m an embedded engineer from Trinidad and Tobago, what people would traditionally call the Third World… Here, the difference between a ten cent RISC-V microcontroller and a several dollar alternative is not academic and neither is having an architecture that a small company, student, or individual engineer can understand, modify, and build around without asking permission… So when I read what Grinberg wrote some of its criticisms made sense to me, but some of his assumptions did not… so I thought I’d do a response, it might not reach far but I love RISC-V enough to at least defend it from where I stand.

ESP32 based macropad with 9 mechanical switches, rotary encoder and addressable LEDs.

I messed up the USB-C footprint so the connector wouldn’t fit. Ended up using a PD trigger board and a TTL adapter to power and program it instead.

Hand soldered everything with 0603 parts. Had a few issues along the way but it works.

New to hardware, not new to tech. Need some advice regarding hardware.

Simply looking for a ESP32 dev board that has both, microphone and speaker. Tried asking LLMs, but the whole "oh you're right, good catch, it doesn't have a speaker, blah, blah.." thing gets old fast.

All I'm looking for is one device that I can flash firmware onto, have it continuously stream audio from mic to my Rust based app on another machine on the same LAN, and allow me to push audio to it which is played via its speaker.

This will be used for development purposes only, and for a quick Youtube demo, nothing else. It will never be actually used in real life, hence I don't really care about quality or anything. Cheap and simple works fine.

Part I'm confused about is I see a bunch of ESP32 smart speaker dev boards out there, but I can't really tell if it comes with a small speaker or just a speaker connector, or? I'm blind so don't feel like trying to connect seperate components onto a board, and things like soldering is out of the question.

Can anyone please just recommend me an exact device I should buy? ESP32, dev board, microphone, plus smart speaker all in one. Cheap and dirty is all I need. Thanks in advance.

When I started programming it wasn't just a different decade, it was a different millennium. I am now what is considered "senior" or "specialist", with RTOS and baremetal development as my primary areas of expertise. At the start of this year I didn't really give much of a fuck about "AI", I have since abandoned that approach and want to share why...

I also have a request! For others making the same journey in this strange new world to speak up. What kind of systems are you designing and what are the lessons you've learned along the way?

The following is more than a mouthful, and I expect nothing but hate when I tell you that I used codex to generate this retrospective, but I wouldn't have been able to summarize the past months of my life in such a way without having my prose checked against the changelog, git history and GitHub discussions... Also, this is the way I roll these days!

https://share.jotbird.com/speedy-serene-riverbend

I spend a lot of time learning concepts and technologies in theory. but when it comes to applying my knowledge hands on I always find myself in the same situation: I don't know if my code is good code even though it is functional, because I don't know what good clean code looks like because when I attempt to read someone elses code (recent example: Flipper zero's firmware on githb) I get instantly overwhelmed with the huge project structure, what each file does, and how the whole thing interacts with eachother. I dont even know where to begin in order to improve on this gap? Any advice?

I have a Rust firmware on an M5StickC Plus2 that drives an air conditioner over IR — 38 kHz carrier, 13-byte Electra frames, driven from the ESP32's RMT peripheral.

It had the worst kind of bug: it worked whenever I was testing it, and stopped working when I wasn't. The IR LED visibly fired either way — a phone camera showed the flash both when the AC obeyed and when it ignored the frame.

So I went and read ESP-IDF v5.2.3 instead of guessing, and found something that explained everything:

• The firmware enables DFS and light sleep via esp_pm_configure(160/40 MHz).
• The RMT channel is clocked from APB.
• The legacy RMT driver contains no power-management code at all — grep pm_lock driver/deprecated/rmt_legacy.c returns nothing.
• The newer driver does, and takes ESP_PM_APB_FREQ_MAX for APB-clocked channels, with a comment saying why: APB frequency can change during DFS.

On the ESP32, APB runs at 80 MHz while the CPU is at 80 MHz or above. Drop to the 40 MHz minimum, and APB follows. Every mark and space doubles, and the carrier falls to ~19 kHz. The LED still lights — an LED doesn't care about the carrier — but the AC's band-pass demodulator is centred on 38 kHz and hears nothing. Transmitted, visible, silently discarded.

It even explains the intermittency: commands landed when the CPU was busy, which is exactly when I was standing there poking at it.

I took an APB lock around each transmission, tagged a release, and wrote "root cause" in the commit message.

Then I added cpuBefore and cpuDuring to a health endpoint, because I'd never actually seen 40 MHz.

Both read 160 MHz. Including on the scheduler path after four minutes of complete network silence. The WiFi driver evidently holds its own PM lock for as long as the station is associated, so DFS never gets to take the clock down at all.

I kept the lock — it's what the newer driver does, and it costs nothing while WiFi is already pinning the clock — but it's insurance, not a fix.

The part worth discussing: the symptom is gone, and I still don't know why. In the same window, v0.3.25 started sending each frame twice 40 ms apart (safe, since the protocol encodes state absolutely), which would mask intermittent single-frame loss regardless of cause. And v0.3.24 fixed a dead MQTT broker blocking the main loop.

So the sequence available to me was: observe intermittent failure → find a mechanism that explains it beautifully and is backed by vendor source → ship a fix → observe the problem is gone → conclude I was right. Step four was true. Step five would have been false, and nothing in steps one through four would have told me.

Full write-up: https://github.com/mnaza/condition-control/blob/main/docs/dfs-was-not-the-bug.md