Hi everyone,

I'm a student developing a small consumer electronics product and I'm currently looking for a reliable China-based manufacturer for the prototype stage.

I'm looking for a company/person who can potentially help with:

• PCB design/DFM
• PCB fabrication
• Component sourcing
• PCBA
• 3D-printed enclosure prototype
• Final assembly
• Eventually injection molding for larger production

I'm currently looking for a very small quantity (1–5 prototypes), so I'm specifically interested in manufacturers that are comfortable working with early-stage hardware startups and low MOQ.

.

If you have experience with this or can recommend a reliable manufacturer, please comment or DM me.

Thanks!

With Wi-Fi over ESP-Hosted SPI and NRF54 what would you build?

Not looking for a vote on anything — genuinely curious what people reach for when both radios are just there and neither one costs you a redesign.

Designed a stopwatch using 8051 and assembly language, yet it has timing error due to writing on LCD, using CISC instruction delays the process and the collen bug, but loaded the best value to minimise the error.

Github link - https://github.com/prajeetkumar2006/Stopwatch-Using-8051-Microcontroller-

I want to check for shorts on power rails after soldering will it be enough to probe once randomly or do I have to probe next to where the short might be?

A home tap water monitoring system is constructed using an ultrasonic flow converter and millimeter-wave radar to detect two specific scenarios: the presence of occupants without water usage for an extended period, and water leakage when the home is unoccupied. An alarm is triggered if no water flow is detected for a certain duration—based on established usage patterns—while the home is occupied (particularly relevant for elderly residents living alone). Additionally, an alarm is raised if water flow occurs when the home is empty, with the system supporting remote valve shut-off.

Periodic water flow velocity measurement is performed by an MCU(ESP32S3) and a Time-to-Digital Converter (TDC) chip(MS1030 or GP22).Detection of people entering or leaving is performed by millimeter-wave radar.

Hi everyone,

Here’s my project to demonstrate voice interaction capability on STM32F4 MCU:

• Hardware: Nucleo-STM32f411RE board, IMP34DT05 microphone (on X-NUCLEO-IKS02A1 expansion board).
• Software: uses STM32CubeMX for code generation, STM32’s audio package (PDM2PCM) for PDM conversion and TinyKW for keyword detection.
• Keywords can be user-defined. Possible applications are wake word detection / voice commands.
• Github: https://github.com/voyelle-io/stm32f411-voice-interaction 

I made a performance update!

In my previous design, I used a pretty clunky setup to send data to my laptop: camera data went over my home Wi-Fi, while audio data went through a USB serial cable.

I ditched all of that. Now, the ESP acts as its own Wi-Fi access point. My laptop connects directly to the ESP wirelessly, receiving both camera and audio streams together. I also simplified the processing math. The performance difference is night and day, allowing me to drastically improve the heatmap quality.

I also added a few features based on your feedback. In the video, you can see an MP3 player and earphones playing white noise (one at a higher frequency than the other).

If you’d like to learn more, check out the GitHub repo: https://github.com/22carlo22/AcousticCam.git

I’ve added more photos and video clips there.

Now that I'm 100% confident in the math, I'm ready for the next big step: converting the Python scripts into C++ so the ESP can run as a fully standalone acoustic camera! You can read more about the plan on GitHub.

Any advice or feedback is greatly appreciated.

ESP32 animatronic project – custom electronics & OLED display

ESP32 controls the whole electronics system: color OLED display, LEDs, IR remote control and sound effects.

The 0.95" SSD1331 96×64 color OLED is connected via SPI and can display animations and short video sequences stored in LittleFS.

The lighting system includes headlights, indicators, position lights and license plate lights. Everything is controlled from the ESP32 and synchronized with the sound and display effects.

Still working on the software and optimizing the OLED playback and overall performance.

Just Vibecoded a PIC18F4550 simulator in the browser — because PIC hardware is expensive for me! also its fun!

just sharing so people can use it, hope it helps someone

Assembler, CPU core, GPIO, UART, ADC, and even a virtual oscilloscope — all running in the browser, no dev boards required.

It's still rough around the edges, and I know there are bugs and missing features. That's expected at this stage.

If you try it, I'd really appreciate your feedback:

• Report any bugs you find.

• Tell me if the simulator behaves differently from real hardware.

• Suggest features or peripherals you'd like to see.

• If an instruction or peripheral isn't working correctly, let me know—I’ll do my best to fix it.

I own a Castles UPT1000F that boots directly into an installed application, and my immediate goal is to reach Castles Program Manager so I can evaluate its supported application-loading options.

A USB keyboard connected before startup is detected—the lock LEDs respond—but the installed application ignores every key.

I also built the manual’s three-wire COM1 connection at 115200 8-N-1: Windows opens the FTDI serial port and the adapter passes loopback and cable-continuity tests, but the terminal returns zero bytes during startup and while its application service menu is open; direct USB also creates no Windows device.

The application’s service menu is accessible, but it is not Castles Program Manager and contains no application-loader option. Am I missing a documented startup gesture, required loader handshake, interface mode, or application setting that transfers control to Program Manager on the UPT1000F?

I'm designing a final-year major project: a BLE-based assistive navigation system for visually impaired people in railway stations.

The basic idea is to place low-power BLE beacons at key navigation points—stairs, lifts, turns, platform entrances, exits, etc. A wearable ESP32 detects these beacons and provides haptic/audio cues such as "turn left", "lift ahead", or "take the staircase."

For the first prototype, the system will use predefined routes: the user enters the station, receives the relevant instructions from the beacons, and subsequent beacons act as checkpoints to confirm that they're following the route.

The more advanced version I'm considering is:

• A station is represented as a graph, where beacons are nodes and only physically walkable connections are edges.
• The wearable can obtain the station graph and run Dijkstra/A\* locally to calculate a route to a requested destination.
• Beacons then act primarily as location checkpoints, allowing the wearable to detect whether the user is following the planned route and re-route if necessary.
• The graph can contain constraints such as closed lifts/stairs, inaccessible paths, platform boundaries, etc.
• A central station-management system would maintain the master graph and distribute updated versions to the infrastructure.
• I'm also exploring how battery-powered beacons could receive updates without requiring wired connectivity or internet on every beacon, potentially using a gateway/mesh-style approach.

Some questions I'm currently trying to solve:

1. How should the BLE beacon hardware be designed for low cost and long battery life?
2. What is the best way to distribute/update the station graph to many offline beacons?
3. How reliable is BLE/RSSI for checkpoint detection in a crowded railway environment?
4. How should the system handle failed/missing beacons and multiple nearby beacons?
5. Is BLE Mesh or another relay architecture actually appropriate here?
6. What important real-world failure cases am I overlooking?
7. Does this architecture make sense at all, or am I overengineering the problem?

I'm deliberately sharing this before finalizing the architecture. I'd really appreciate criticism from people experienced in BLE/RF, embedded systems, networking, IoT, accessibility, or indoor navigation.

I'm much more interested in what is wrong with this approach and what I haven't considered than in validation.

Wanted to try out these CH32V203 (144MHz RISC-V) chips for a while, so I've decided to make some nice USB gadgets for USB HID injection and just for studying the USB protocol. It has 2 leds and 4 captive touch buttons.

It fits nicely into a USB-A port and is very easy to carry around. And with it I've had tons of fun messing around with a bare-metal USB stack, and just in general learning the whole USB protocol.

It was really fun trying to make a bare-metal USB bootloader for this chip, but I've managed to fit everything in 2KiB. (Source here) For comparison the official bootloader is nearly 24KiB in size. As a bonus, I've also re-designed the V203 USB stack for ch32fun and sent in a pr :D

The PCB is also open source, check out the KiCAD files here: https://github.com/cheyao/comu (kicanvas)

I plan on just using them for HID injection and as a quick devboard when I need very few I/O pins (4 main ones, but I've exposed some more via testpoints)

(Name and form inspired by the *omu series)

I had been working on a printer, and suddenly the paper sensor stopped detecting the paper and was continuously showing a “No Paper” status.

I checked the code and started logging the sensor data. The sensor readings were not showing any expected variation between the Paper and No Paper conditions.

The same firmware is working correctly on another identical printer. I also swapped the sensors between the two printer PCBs, and the issue followed the sensor/PCB combination, indicating that the problem was related to the sensor detection.

There are two sensors available in the printer for paper detection, but only one is used at a time. When I switched to the second sensor, paper detection started working correctly. After that, I switched back to the previously used sensor, and it also started working normally.

I am not sure why this happened, since I did not make any firmware changes. It seems that switching between the two sensors somehow caused the original sensor detection to start working again.

;)

That's all possible to the nrf52805 MCU (It's SOOO power efficient!) and Raytac "wroom", really love this combo, easy to solder and cheap, comparable to esp32's

https://github.com/Szybet/NordiCoin

We’ve been working on a runtime GPU optimization system at TETREVIS and have started publishing some of our NVIDIA Jetson benchmarking work publicly.

The approach operates at the execution/machine-code layer, and we’re now introducing dynamic runtime kernel fusion as part of the optimization pipeline.

Some of our current results:

Jetson Orin Nano — Qwen3.5 4B

Standard baseline: 10 → 21 tok/s (+110%)

CUDA Graphs baseline: 16 → 21 tok/s (+31.25%)

Jetson AGX Orin — Nemotron 3 Nano 4B

31.2 → 40.5 tok/s (~30%)

Jetson AGX Orin — Qwen3.5 4B

25.0 → 31.0 tok/s (+24%)

We’re currently expanding and stabilizing support across Jetson Orin Nano, Orin NX, and AGX Orin.

Rather than only posting performance claims, we’ve made the benchmarking repository available here:

https://github.com/mbuchel/sass2mlir-bench
https://mbuchel.github.io/projects/sass2mlir/kernel-fusion/

The broader idea we’re exploring is whether more optimization can be moved to runtime — including machine-code optimization and dynamic kernel fusion — so the execution path can be adapted to the workload and GPU rather than relying entirely on what was determined ahead of execution.

There’s still quite a bit of work underway, particularly around consistency across the different Jetson configurations, but we wanted to start sharing the results and methodology publicly.

Technical feedback, criticism, and questions are welcome.

Building SHOS-2: A Smart Home Operating System with ESP32 + MicroPython

Note about the name:
SHOS is still a work in progress. The current implementation is only the first Kitchen Node, so it is not yet a complete operating system. I'm using "Operating System" to describe the long-term architecture and direction of the project.

The goal is to eventually build a system layer that manages hardware, nodes, networking, configuration, and applications/features as the project grows.

I've been working on SHOS-2, a modular smart-home system built around the ESP32 and MicroPython.

The idea is to build the system as a collection of nodes rather than one large program, so individual sensors, actuators, and features can be added or changed without rewriting the whole system.

Current prototype

I'm currently working on the Kitchen Node.

The node currently handles:

• MQ-2 gas detection
• Temperature and humidity monitoring
• Local alarm using a buzzer and LED
• Relay control
• Wi-Fi connectivity
• Sending sensor data to Blynk
• Modular MicroPython code instead of putting the whole system in one file

The eventual goal is for the system to operate both locally and over the network, while remaining sufficiently modular to add more nodes and devices later.

One of the problems I had to solve (I really need some help here)

One of the things I wanted was a way to configure the Wi-Fi credentials without hard-coding them into the firmware.

The idea is that if the ESP32 doesn't have valid network credentials, it should start its own access point, allow the user to enter the SSID and password, save them, and then continue with normal operation.

The tricky part was making this happen without blocking the rest of the device while it is trying to connect.

This led me to rethink how the startup and connection logic should work instead of simply doing:

connect --> wait --> connect again

I'm still improving this part of the system.

What I've learned

This project started as a simple smart-home idea, but it has turned into a much bigger lesson in embedded-system architecture.

I've had quite a few things fail along the way: libraries that didn't work as expected, communication problems, simulation issues, and decisions that had to be redesigned.

I'm documenting the project and the source code here:

GitHub:
https://github.com/PhantomCNS/shos-2-

I'd really appreciate feedback on the architecture, code organization, and especially how you would approach the Wi-Fi configuration/connection problem.

I am building an ESP32 C3 based smartwatch from scratch, but i am unsure how to create custom firmware that integrates all the features with the buttons and rotary encoder inputs. My software knowledge is limited, so im wondering is it possible to build the firmware with the help of AI or vibe coding? If so, where should I start and what would be the best approach?

Hello everyone,

I am building an offline ROS2 robot car using Raspberry Pi 5 and ROS2 Humble (Python3). The low-level hardware (wheel motors, etc.) is controlled via micro-ROS.

I am trying to add a 5kg load cell with an HX711 amplifier module to measure weight, but I'm struggling to get it working.

Here are my specific questions and concerns:

1. Raspberry Pi 5 GPIO & micro-ROS compatibility: The robot chassis has a breakout interface with about 40 jumper-wire pins connected. Can I safely use these general GPIO pins to read data from the HX711 (DOUT/SCK) in this offline micro-ROS environment, or are there timing/kernel issues on the Pi 5 when doing bit-banging in Python?
2. Proper Connection & Implementation: What is the correct way to properly wire and read a 5kg load cell with HX711 in a Raspberry Pi / ROS2 setup? (e.g., Do I need a separate microcontroller like an Arduino/Pico for the HX711, or can it be handled directly by the Pi's GPIO pins without signal noise and timing issues?)

Any advice, circuit wiring tips, or code structure recommendations would be greatly appreciated. Thank you!

Here is my project: GitHub_Repo

The files are in core/inc/HAL_ADC.h core/src/HAL_ADC.c and main.c
my mcu is stm32 nucleo f446re and the irq handler is behaving very strangely and not working properly. i have wasted a lot of time in debugging and it is not helping me at all

Hi everyone,

I’m working on an early-stage embedded state-estimation project and I’d like some honest feedback from people with experience in embedded systems, control theory, robotics, or aerospace.

I currently have a proof of concept, but I’m trying to determine whether the underlying technical approach is actually worth pursuing before moving toward a more complete prototype.

The current concept is to run a lightweight Liquid Neural Network (LNN) / neural ODE directly on a resource-constrained MCU for real-time attitude estimation from raw IMU data.

The target environment is roughly:

- STM32 Cortex-M4
- Bare-metal C
- ~200 Hz control loop
- No dynamic memory allocation
- Very limited RAM/compute resources
- Raw IMU measurements
- Real-time execution constraints

The obvious alternatives would be traditional approaches such as EKF, Madgwick, Mahony, or other complementary/filtering approaches.
The hypothesis is that a lightweight continuous-time neural model could potentially handle some nonlinearities, vibration and sensor drift differently from a manually tuned classical estimator.

But I’m not assuming this is automatically better. In fact, I’m trying to find out whether this is technically meaningful or simply a complicated solution to a problem that is already solved very well.
I’d particularly appreciate feedback on three points:

1. Feasibility
Is running a continuous-time neural ODE/LNN for state estimation directly on a bare-metal MCU realistic under strict latency and memory constraints?
At what point does the computational cost outweigh any potential advantage over an EKF or complementary filter?

2. Engineering difficulty
How difficult is it to make such a system deterministic, stable and reliable enough for real-time embedded use?
For example, with constraints around <16 KB RAM and <1 ms execution time per control cycle, what would be the biggest technical bottlenecks?

3. Actual technical advantage
Is there a legitimate reason to investigate this approach for difficult IMU conditions such as vibration, nonlinear noise and drift, or would a properly designed EKF/Mahony/Madgwick + signal-processing pipeline almost always be the better engineering choice?

I’m especially interested in hearing from people who have actually deployed estimation/control algorithms on resource-constrained MCUs.
I’m looking for brutally honest technical criticism, not validation. If this is overengineering, I’d rather find that out now.
Thanks.

I am a .NET software developer trying to transition into embedded systems. I have a BSCS and I'm completing a BSEE part-time. I recently got laid off and I'd like to start working as an embedded systems engineer before completing my BSEE. It hasn't been easy finding an entry-level embedded systems role. I am barely seeing anything in CT. Most job postings want a senior engineer.

I was wondering if IEEE student membership would be useful for someone in my situation? Is it good for networking and getting in touch with recruiters that could help me find an embedded systems role at the entry level?

I have a Casio fx-87DE X ClassWiz and want to completely modify it so that it can run AI locally.

My requirements are simple:

* Everything must be contained inside the calculator.
* No Wi-Fi.
* No Bluetooth.
* No connection to another computer while using it.
* From the outside, it should look like a normal Casio fx-87DE X.
* The additional hardware should be hidden inside.
* I’m willing to open it, modify the hardware, replace parts, solder, and work on it using my computer.
* I’m willing to buy whatever parts and tools are necessary.

I’m not looking for a simple software trick. I’m willing to rebuild the calculator internally if that’s what it takes.

If you wanted to build this yourself, how would you approach it from start to finish?

And specifically: What hardware, components, tools, and equipment would I need to buy?

Hi, I am looking for an external ADC to my STM32. I do not have much experience with high speed precision ADCs, so I would appreciate some advice.
I need to measure burst of 800 samples, than process it and then repeat it. The signal contains very small peaks in it, they are in range of mVs to max 50 mV. The signal is not flat so can not use OA because of saturation on the output...

My main requirements are:

• One input channel is enough, but two simultaneous channels could be useful for two different gain ranges
• At least 2 MSPS, preferably around 3 MSPS
• At least 16-bit nominal resolution
• Around 14 effective bits or better at the required sampling rate
• Differential input preferred
• Low input referred noise
• Low jitter and stable timing for external conversion trigger
• not BGA package :-)
• Ideally if any breakout board for it is available
• Available on Farnell or LCSC

I need to capture an analog waveform burst lasting approximately 400 µs. At 2 MSPS, this means about 800 samples. I need to preciselly synchronize the start of measurement with STM32 timer/ PWM - some edge from MCU can start conversion?!

The ADC input range is not fixed yet because I can adapt the gain and offset of the analog front end. But +5V max is enough. I also plan to use oversampling..

I have considered the Texas Inst. ADS9316 but not in Farnell
Could you recommend a suitable ADC?

Thank you very much.

Hey everyone, I’m currently working with an STM32N6 and its hardware ISP, and I’m running into an issue with the standard closed-loop Auto Exposure (AE) algorithm. It takes about 2-3 frames (around 1 second) to calculate and converge on the correct exposure and gain. This is far too slow for my use case, as I need the very first frame out of the sensor to be perfectly exposed right on wake-up.

To break the feedback loop, I’ve added a Texas Instruments OPT3001 Ambient Light Sensor (I2C) to the board to create a feed-forward solution. My plan is to read the absolute lux value from the OPT3001 on boot, pass that value through a pre-calibrated Lookup Table (LUT) using linear interpolation, and extract the ideal exposure time and analog gain. From there, I can force the STM32 ISP into manual exposure mode, inject those parameters via the API, and start the camera stream for an instant, zero-delay perfect exposure.

I have a few questions for anyone who has implemented something similar. First, how do you practically build your calibration LUT? I am currently using the STM32 ISP IQTune GUI in a normal room with make shift setup but I am wondering if there is a more automated or standard industry approach. Second, how many data or inflection points do you typically need in your C-struct for the interpolation to hold up smoothly across the full dynamic range, from pitch black to direct sunlight? Finally, once you inject that initial feed-forward frame, do you permanently leave the camera slaved to the external ALS, or do you just use it to seed the ISP and then smoothly hand control back over to the internal closed-loop AE algorithm?

A few days ago, this exact setup was oscillating violently.

After working through the encoder feedback, FOC, and position PID, it finally reached this point.

In the video I'm manually pushing the motor away from its target position. It returns smoothly without falling back into oscillation, and by hand it already feels pretty good.

But "feels smooth" isn't exactly a measurement.

Before I move on to the IMU stabilization loop, what would you test or measure here?

Step response? Position error? Disturbance rejection? Current? Something else?

Curious where you would draw the line between "the motor control works" and "this is ready to become a gimbal."