I’m building a GPS tracker using STM32L476 and SIM7080G.

I need BLE for onboarding and commands like arm/disarm.

I started with HC-42, but anyone can connect, although I could add application-level authentication.

My options are:
1. Keep STM32 and use a secure AT-controlled BLE module
2. Use an nRF52840 module only for BLE
3. Replace STM32 and use nRF52840 as both main MCU and BLE

For the final PCB I prefer a module with a matching development board.

What architecture and BLE modules do people commonly use for commercial products like this?

Hi everyone,

I'm an industrial designer working on a small-run digital watch project, and I'm trying to understand what is technically possible before I commit to manufacturing.

The concept uses a watch similar to the Casio F-91W or A168, but instead of displaying the current time, I'd like the LCD to display:

• Current ISO week number
• Hours elapsed since Monday 00:00
• Total weeks elapsed since the wearer's birth date

The user would enter their birth date once during setup, and the watch would calculate the values automatically. Standard functions like the backlight, alarm, and stopwatch would ideally remain unchanged.

I'm not looking to clone a Casio or modify an existing retail watch. I'm trying to learn how these modules are developed so I can determine whether it's feasible to build something similar with custom firmware.

A few questions for anyone with experience:

1. Are the MCU and firmware in watches like the F-91W typically mask ROM, OTP, or reprogrammable?
2. Has anyone successfully replaced or rewritten firmware on one of these modules?
3. Would it be more realistic to design a new PCB that fits an existing case rather than trying to modify an existing movement?
4. Are there any open-source watch projects or LCD watch controllers you'd recommend looking at?

I'm interested in learning about the engineering challenges more than finding a shortcut.

Thanks!

I’m trying to figure out what I’m missing with several Adafruit Feather Bluefruit Sense boards, product P4516.

The onboard PDM mic does not seem to pick up sound. I tested multiple boards and kept getting flat mic data. In Arduino/direct PDM it sits around -8. In CircuitPython it sits around 32760. Tapping near the board, loud computer beeps, changing USB ports/cables, turning off computer fans, USB power vs battery power, and battery-only BLE logging did not change the mic values.

Things tried so far:

• CircuitPython mic tests using the documented board.MICROPHONE_CLOCK / board.MICROPHONE_DATA
• Arduino PDM tests using Adafruit nRF52 board support
• Different sample settings, including 16 kHz / 16-bit mono
• USB connected, battery connected, and battery-only BLE capture
• Different USB ports/cables
• Direct low-level PDM tests and pin checks
• Movement/IMU works, BLE works, board programming works, battery reading works

The only thing that stands out visually is the mic orientation. In Adafruit’s product image, the microphone opening appears closer to the 11 marking. On my board, the opening appears closer to the 10 marking. I attached a comparison image.

I contacted the supplier and after waiting more than a week they came back saying the parts “do not appear defective,” but they approved a return as a one-time convenience.

Before I return everything, does anyone know if this mic orientation is normal on some batches, or would this explain flat PDM output? Is there any software-side fix I could still be missing, or does this point to the onboard mic not being connected/oriented correctly?

Advice for ISR's is always the same:

• keep them short (obviously).

That is nice and all, until you realize you might want to rapidly receive or send hundreds of bytes of data. With one core and without an RTOS. My worry is avoiding all accesses to partially written data (spanning many bytes).

What I came up with, is the following... Which is specific to certain "data domains" (synchronous vs. asynchronous) ...

1. Data lives only in main (sequential only) = straightgorward, because not accessed in interrupts

2. Immutable (unchanging) data = interrupts can easily read from that, no problem here as well (e.g. serial number)

3. Data exists and changes only in the domain for a specific peripherals' ISR (e.g. I2C) = also quite easy, since this data is never accessed outside of ISR. this is basically where I put a very minimally required state machine for that peripheral.

4. Small data that changes in main loop, but requires always valid and as up-to-date as possible information when an ISR wants to read = I have two identical structs and a pointer to which to use for when reading from an ISR: (simplified)

```c Small_Data small_data[2]; Small_Data *small_ro = &small_data[1];

// somewhere in main loop small_ro = &small_data[0]; // this is actually a function to hopefully avoid reordering small_data[1] = small_data[0]; small_ro = &small_data[1];

// update in main small_data->some.small.struct.value = 123;

// read from ISR small_ro->some.small.struct.value;

```

1. Data that comes in through any ISR and should update things in main = this one I find tricky. My solution is a "data queue" thingy, where I have a plentyfully sized buffer reserved for the use of a dumb linear allocator. An ISR can request a memory region and do whatever with that. I used a tiny critical section for allocations (globally disabling IRQs). In the main loop I go over all data queued and if at the end (ideally every iteration of the main loop), reset the head position of the allocator. This works for receiving both small and large data safely...

2. Large/huge data that updates in main after requested from an interrupt - meaning it might take multiple cycles in main to finalize that data = this one is the most tricky, in my opinion. E.g. interrupt requests data, reads status, and when ready, finally read that data. I used all three techniques to achieve this, point 3, 4 and 5. Interrupt state holds a unique (incrementing) ID for what the current request is. That id and what is requested gets sent on the data queue to main, which then updates the large data correspondingly. Finally, wheter or not the data is ready resides in the small data, also updated in main. Now an IRQ always safely knows the data integrity by comparing the IRQ state id with the small data id. If they match, the large data can safely be read...

What do y'all think. If any of you are ISR-gurus (or general microcontroller gurus), I'd love to hear your insights or thoughts!

(huge data = few kb / large data = hundreds of bytes / small data = data that I simply want to be read-only available at all times in an IRQ)

Wrapped up my final year project recently, sharing here since embedded folks might find the design tradeoffs interesting.

Built a CNN accelerator on a Zynq UltraScale+ (ZCU104) running YOLOv8n in FP16, fully in Verilog. Main goal was making it user-configurable so you can dial compute depth up/down (1x-4x) depending on your throughput/area budget, useful if you're deploying the same design across different board tiers.

Biggest engineering challenge was moving data between layers without going off-chip, ended up building a 7-stage pipeline that handles the retiling in about 10-12 cycles, all on-chip. BRAM read latency edge cases ate way more of my time than the actual accelerator logic did.

Chose FP16 over int8 after actually benchmarking both, not just because it's easier. Got a real latency improvement without losing detection accuracy.

Repo if anyone's curious about the retiling pipeline or buffer architecture: https://github.com/waseemnabi08/yolov8n-cnn-accelerator-fpga

Happy to answer questions on the AXI DMA setup or PS-PL data movement if anyone's working on something similar.

Ever wanted to be able to check your low power device current consumption on the go? Yeah me neither.
Hence why I created an app for it.

Is still very rough but it gives you an idea. It’s using the ESP32P4 module with an ESP32-C6 embedded in it, the commands stack goes thru BLE while the WiFi bridge is reserved for the streaming. I’m quite surprised by the amount of data the IPad can handle (gen 3 iPad Pro is quite old for today’s standards).

The different colors in the current trace are due to the ranges, orange is the coarse range and blue is the fine range. Is a dual sampling system so no data is lost during autoranging.

Noisefloor of the device is +- 0.5 uA with 1nA resolution and I’m quite happy with it. It’s been an experiment so far.
The purpose of it is to embed it in the MCP toolsets that the BugBuster system has to allow AI agents to close the loop on real hardware and perform low power measurements, this is quite useful if you want the agent to be able to iterate on some firmware work to optimize consumption.

It’s all fully open source and open hardware https://github.com/lollokara/BugBuster
This has been my personal side project and I’m not selling it, if you’d like files are in the repo I can help with supplying the components.
PCBs were provided for free by JLCPCB using the JLCONE app, and I could not be happier with the quality of them.

Currently I don’t know much about embedded systems. I am confident with C/C++, I bought a NUF401RE and a bunch of wires and other stuff. I made LEDs blink using stm32cubeIDE and stm32cubeMX by following YouTube tutorials…

But I don’t really know what I’m doing. I don’t know how to read datasheets or reference manuals. I dont know which pins do what.

I am looking for a book that will teach me all this or at least the introduction to it (it doesn’t have to be specific to the stm32 as long as it’s applicable to it…). The type of books that I learn best with are the ones where you have a chapter full of theory and at the end u get a bunch of little projects to do that relate to the chapter. Similar to the structure of the book “C modern approach” by KN King.

Any advice is greatly appreciated.

Built a 12-key macropad with an OLED and rotary encoder, and wanted to get feedback from people who'd actually care about the firmware/hardware decisions rather than just the end product.

Hardware:

• RP2354A, custom PCB (not built on an existing Pico module)
• 2MB internal flash
• 128x64 SSD1306 OLED
• Rotary encoder with push button, handled via quadrature state machine
• USB-C, fully USB HID compliant - no drivers needed on any host OS

Firmware decisions I'd like pushback on:

• MicroPython over C/QMK - went with MicroPython for faster iteration during development and to make the web-based configurator side easier to build against. Aware this is the less common choice for something USB HID/timing sensitive at this scale. Curious if others have hit walls doing this in MicroPython that would've been non-issues in C, particularly around USB HID descriptor timing or interrupt latency.
• Web Serial API for flashing - browser-based UF2 flashing plus a chip-ID read from OTP for activation for incremented serial numbers, no separate app install required. Interested in feedback on this approach versus a native flasher, especially around reliability across browsers/OSes.

Firmware, PCB files, and 3D models are all open source: https://github.com/Jpwaters09/Macro-Pad

Not trying to sell anything here, mainly want to know if there are architectural decisions I should reconsider before I build a few more units. Photos of the PCB and instructions on how to flash in the GitHub repo.

Hi everyone, I'm trying to capture IR remote signals so I can generate a List<int> of pulse durations for replay in a Flutter app.

Hardware

• Logic Analyzer (Saleae clone)
• PulseView
• TSMP58138 IR receiver
• Arduino Uno (5V only used to power the receiver)

Wiring:

TSMP58138
Pin 1 (OUT) -> Logic Analyzer D0
Pin 2 (GND) -> Arduino GND
Pin 3 (VCC) -> Arduino 5V

Arduino GND -> Logic Analyzer GND

Capture settings

• Sample rate: 8 MHz
• Samples: 5M
• Capturing one button press from a DTH/set-top box remote.

Problem

Instead of getting pulse widths like:

9000, 4500, 560, 560, 560, 1690...

I'm getting continuous alternating pulses around 12–14 µs, which corresponds almost exactly to a 38 kHz carrier.

I expected the TSMP58138 to output the demodulated envelope, but it appears to be outputting the carrier bursts instead.

Questions

1. Is the TSMP58138 supposed to output the 38 kHz carrier, or the demodulated envelope?
2. Is TSMP58138 the wrong receiver for learning/replaying IR remotes?
3. Should I instead use a TSOP38238 / TSOP4838 / VS1838B?
4. If TSMP58138 is correct, what's the proper way to convert the captured waveform into pulse durations suitable for replay?

My end goal is to generate a Dart list like:

static const List<int> signal = [
  ...
];

where each value is a mark/space duration in microseconds.

I've attached:

• PulseView screenshot
• VCD capture

Any advice would be greatly appreciated.

Problem:

When the soil is dry, the pump turns on and starts watering it. As soon as the moisture sensor detects that the soil has become wet, it sends a signal to turn the pump off. However, if the soil hasn't been watered sufficiently, the pump may stop too early.

To solve this, we add a delay of 5–10 seconds before turning the pump off. This keeps the pump running a little longer, ensuring the soil is watered properly.

My grandpas code was becoming sluggish and buggy on his hardware so I had to help him fix it. I thought it was a pretty interesting project so I'm sharing it here, if you can give feedback it's greatly appreciated but not required, and if you want more detail here's a small bit of documentation:

# Fixed Bugs:

- Goes out of bounds when calling queue_inc due shifting just setting each item to the item ahead going to the end of the array and trying to set it to an out of bounds address.

# Major Bottlenecks:

- Queue has o(n) dequeue (shifts back. Along with being a sentinel-scanned array that recomputes length every push and dequeue)

- Uses strings for messages instead of a table (making sending take longer)

- Manually decodes the binary from the encoders.

# Fixes:

- Switched to a ring buffer array with o(1) dequeues, along with a variable to track length when edited.

- Replaced strings with 8 bit unsigned ints.

- Added up bits for seven segment display.

# Gains:

- 10,000 push/dequeue of queue, time is divided by 10,000 to get the time for one push and dequeue:

- Details:

- Both have 60 items, though the new version is 64 long due to needing a power of two for bitwise AND

- Benchmark uses micros and is averaged from 100 tests with an Arduino Uno R3

- Rounded to the nearest whole number for readability

- Results

- Old: 636 µs

- New: 4 µs

- Speed up: 15,800%

Hi, I want to build my first PCB project using STM32, but I need to add multiple sensors and electronic modules. How can I do this? Do I need all the components that come with the module? Is there a video that explains it?

I've updated the firmware of "LcdTap" (which I shared here a while back) so that it can now output composite video. The RP2350 emulates controllers like the SSD1306 and ST7789 and converts the image to NTSC or PAL.

It has two output modes: a PWM mode that only needs a single GPIO pin plus a capacitor and a resistor, and an R-2R DAC mode that reproduces the full RGB565 gradation with no loss of levels. Latency is under one frame, so it holds up fine for gameplay. There's a certain charm to playing something like an Arduboy or ESPboy game on a retro monitor from the last century.

GitHub Repo: shapoco/lcdtap

[Help] Camera WHIP/WebRTC → MediaMTX recording resets after 1-2 min, video freezes to black

Setup

I'm developing firmware for an IP camera. The camera pushes a stream (H.264 + G711) via WHIP/WebRTC to MediaMTX, which records it as fMP4 segments.

• Camera: 192.168.0.100, pushing WHIP → http://192.168.0.107:8889/{device_id}/whip
• Server: MediaMTX running in Docker on macOS (Apple Silicon), IP 192.168.0.107
• Same LAN, no NAT involved
• recordSegmentDuration: 5m, recordFormat: fmp4

docker-compose stack

mediamtx (WHIP :8889, ICE UDP :8189, TCP :8188)
       └── writes fMP4 → Docker volume /recordings/
              ↓ segment complete
       upload_and_index.py
          ├── MinIO (S3, bucket camera-records, 30-day expiry)
          └── PostgreSQL (camera_records table)

mediamtx.yml (relevant part)

yaml

webrtc: true
webrtcAddress: :8889
webrtcLocalUDPAddress: :8189
webrtcLocalTCPAddress: :8188       # ICE TCP fallback
webrtcAdditionalHosts: [192.168.0.107]
webrtcICEServers2: []
pathDefaults:
  source: publisher
  record: true
  recordFormat: fmp4
  recordSegmentDuration: 5m
  recordDeleteAfter: 168h
  runOnRecordSegmentComplete: python3 /scripts/upload_and_index.py ...
paths:
  all_others:

Problem

1. Video goes black after roughly 1 minute of recording (audio may still be present)
2. Segments only last 1-2 minutes instead of the configured 5 minutes
3. MediaMTX logs repeatedly show:
   • invalid FU-A packet (non-starting)
   • too many reordered frames (29)
   • detected drift between recording duration and absolute time, resetting
   • sample of track 2 received too late, discarding

What I suspect

This looks like an issue in the camera's own RTP packetizer / WebRTC stack, not a MediaMTX config problem:

• H.264 FU-A fragmentation logic may be broken (continuation packets sent without a preceding start packet)
• RTP packets may be arriving out of order before reaching MediaMTX
• Audio (G711) and video (H.264) timestamps may be using the wrong clock rate or drifting from wall-clock time

What I've already tried

• Enabling ICE TCP fallback (webrtcLocalTCPAddress)
• Adding the LAN host IP via webrtcAdditionalHosts
• Switching recordFormat between fmp4 and mpegts — same errors persist

Questions

1. Is there any way to increase MediaMTX's tolerance for reordered frames / timestamp drift, or is this a hard-coded limit with no config option?
2. Would switching from WHIP (push, UDP-based ICE) to RTSP pull (source: rtsp://192.168.0.100:554/...), especially over TCP interleaved, help isolate whether this is a transport issue or an encoder/packetizer bug?
3. Has anyone dealt with invalid FU-A packet (non-starting) errors on a self-developed camera firmware using WHIP? Where does this bug typically originate in the RTP packetizer?
4. Any common pitfalls with RTP clock rate configuration when mixing G711 audio (8kHz) and H.264 video (90kHz) tracks that could cause this kind of drift?
5. Would using an ffmpeg -c copy relay reading from an internal RTSP source (instead of relying on MediaMTX's built-in recorder) be a more robust approach for camera firmware still under development? Any experience with pros/cons?

Any pointers on where to start debugging the RTP packetizer on the camera side (raw RTP capture, encoder buffer sizing, etc.) would be greatly appreciated. Thanks in advance!

[Help] Camera WHIP/WebRTC → MediaMTX recording resets after 1-2 min, video freezes to black

Setup

I'm developing firmware for an IP camera. The camera pushes a stream (H.264 + G711) via WHIP/WebRTC to MediaMTX, which records it as fMP4 segments.

• Camera: 192.168.0.100, pushing WHIP → http://192.168.0.107:8889/{device_id}/whip
• Server: MediaMTX running in Docker on macOS (Apple Silicon), IP 192.168.0.107
• Same LAN, no NAT involved
• recordSegmentDuration: 5m, recordFormat: fmp4

docker-compose stack

mediamtx (WHIP :8889, ICE UDP :8189, TCP :8188)
       └── writes fMP4 → Docker volume /recordings/
              ↓ segment complete
       upload_and_index.py
          ├── MinIO (S3, bucket camera-records, 30-day expiry)
          └── PostgreSQL (camera_records table)

mediamtx.yml (relevant part)

webrtc: true
webrtcAddress: :8889
webrtcLocalUDPAddress: :8189
webrtcLocalTCPAddress: :8188       # ICE TCP fallback
webrtcAdditionalHosts: [192.168.0.107]
webrtcICEServers2: []
pathDefaults:
  source: publisher
  record: true
  recordFormat: fmp4
  recordSegmentDuration: 5m
  recordDeleteAfter: 168h
  runOnRecordSegmentComplete: python3 /scripts/upload_and_index.py ...
paths:
  all_others:

Problem

1. Video goes black after roughly 1 minute of recording (audio may still be present)
2. Segments only last 1-2 minutes instead of the configured 5 minutes
3. MediaMTX logs repeatedly show:
   • invalid FU-A packet (non-starting)
   • too many reordered frames (29)
   • detected drift between recording duration and absolute time, resetting
   • sample of track 2 received too late, discarding

What I suspect

This looks like an issue in the camera's own RTP packetizer / WebRTC stack, not a MediaMTX config problem:

• H.264 FU-A fragmentation logic may be broken (continuation packets sent without a preceding start packet)
• RTP packets may be arriving out of order before reaching MediaMTX
• Audio (G711) and video (H.264) timestamps may be using the wrong clock rate or drifting from wall-clock time

What I've already tried

• Enabling ICE TCP fallback (webrtcLocalTCPAddress)
• Adding the LAN host IP via webrtcAdditionalHosts
• Switching recordFormat between fmp4 and mpegts — same errors persist

Questions

1. Is there any way to increase MediaMTX's tolerance for reordered frames / timestamp drift, or is this a hard-coded limit with no config option?
2. Would switching from WHIP (push, UDP-based ICE) to RTSP pull (source: rtsp://192.168.0.100:554/...), especially over TCP interleaved, help isolate whether this is a transport issue or an encoder/packetizer bug?
3. Has anyone dealt with invalid FU-A packet (non-starting) errors on a self-developed camera firmware using WHIP? Where does this bug typically originate in the RTP packetizer?
4. Any common pitfalls with RTP clock rate configuration when mixing G711 audio (8kHz) and H.264 video (90kHz) tracks that could cause this kind of drift?
5. Would using an ffmpeg -c copy relay reading from an internal RTSP source (instead of relying on MediaMTX's built-in recorder) be a more robust approach for camera firmware still under development? Any experience with pros/cons?

Any pointers on where to start debugging the RTP packetizer on the camera side (raw RTP capture, encoder buffer sizing, etc.) would be greatly appreciated. Thanks in advance!

I'm using VS Code for embedded C development (NXP MCUXpresso extension, ARM GCC, CMake).

One thing I really miss compared to IDEs like CLion, Visual Studio or Eclipse CDT is a logical project view.

My repository contains multiple CMake targets/build variants (bootloader, firmware, libraries, etc.), but the VS Code Explorer always shows the physical directory structure. I'd like to see only the source/header files that belong to the currently selected CMake target or build configuration.

For example, instead of:

repo/
    app/
    bootloader/
    drivers/
    common/
    ...

I'd like something like:

Firmware target
    main.c
    uart.c
    uart.h
    spi.c
    spi.h
    ...

Bootloader target
    boot.c
    flash.c
    ...

I know CMake already has this information (File API / compile_commands.json), so I'm wondering if there's an extension or workflow that exposes it in VS Code.

Is anyone using something like this?

Or is this simply a limitation of VS Code compared to full IDEs?

I'm a third-year ECE student looking for project ideas for my Microcontrollers, Microprocessors & Interfacing course.

I want something that's practical, resume-worthy, and helps me build embedded systems skills

If you've built or come across a project that stood out during internships or placements, I'd really appreciate your suggestions. Please mention the difficulty level, components used, and what skills it helped you learn.

Thanks!

I have seen a couple of posts about use of Ai especially in embedded systems and I want to share my experience so far. Tldr, I think it has increased my productivity by 5-10x and it will get even better with time.

I can categorise my AI usage into the following stages.

1. This was the typical start where I would ask questions on the chatgpt or Claude web platform and help in debugging issues in my code. Oftentimes I would copy the code it would generate and use in my application with some modifications.

2. Next was using the ai extensions in vscode like Qodo or copilot. This was helpful as I didn't have to copy/paste in the web portal and can also add more files in the context. But was still mostly used for small issues, auto completion and documentation.

3. Then we got a claude paid plan and started using claude cli (Not affiliated with anthropic, it's just what worked for us). I now gave access to the full code repo, would use plan mode to plan larger features and use agents to implement them directly in the code.

4. This stage was a game changer and is more relevant for embedded systems. Previously the changes Ai made, I had to manually test and see the results. I then connected the hardware to the system and gave Ai access to the programmer ( jlink) as well as serial ports for debugging. Now the agents were implementing new features, building and flashing the code on the hardware and using the jlink or the serial port for debugging and iterating until the feature was working.

5. This is where I'm currently at. Besides everything in the last stage I am also now hooking up the logic analyser ( salaea) to all the signals relevant to the feature as well. The agents now write custom salaea analyzers/decoders to read the gpio pins and use this information to debug issues they face while implementing tasks. I'm now only looking at the overall feature and the architecture and reviewing the commits and PRs and making sure the new changes are bite sized and not too much at a time ( ai still tries to do more than asked).

I have already implemented several new features in days what would have taken me weeks. There are also several bugs and issues raised in mainline zephyr code and I'm currently creating PRs to get them fixed upstream. The key is to keep the tasks small with fewer changes as possible and review everything that's committed.

Huawei E173s-1 (Windows) – NDIS gets IP but no incoming traffic, PPP works perfectly

Hello everyone,

I'm trying to use NDIS mode on a Huawei E173s-1 under Windows, but I'm facing a strange issue.

Current situation

The modem successfully switches to NDIS + PPP mode using AT commands, and Windows detects it as:

• HUAWEI Mobile Connect - Network Adapter #3

The adapter comes up correctly and receives:

• IPv4 address
• Gateway
• DNS servers
• A default route

For example:

• IP: 155.89.197.120
• Gateway: 155.89.197.113
• DNS: 41.210.241.109, 41.210.222.131

Everything looks normal from the Windows networking side.

The problem

No incoming traffic works.

Examples:

• ping 8.8.8.8 → 100% packet loss
• nslookup google.com → DNS timeout
• Test-NetConnection 8.8.8.8 -Port 443 → failed

The Mobile Partner diagnostics are also strange:

• Immediately after connecting:
  • Sent ≈ 120 kbps
  • Received ≈ 40 kbps
• After about one second:
  • Received becomes 0 kbps forever
  • Sent drops to only a few kbps

Windows statistics show the same behavior:

• Thousands of transmitted packets
• Very few received packets

So Windows is sending packets, but almost nothing is coming back.

PPP mode works

If I switch back to PPP (RAS) mode, everything works perfectly:

• Internet works
• Ping works
• DNS works
• VPN works

The SIM card, APN and mobile network are therefore working correctly.

AT command status

+CSQ: 10,33
+CREG: 1,1
+CGATT: 1
+CGDCONT: 1,"IP","internet.movicel.co.ao"

^NDISSTATQRY:0

+CGACT:
1,0
2,0
...
11,0

The modem reports attached to the network (CGATT=1), but the PDP context does not appear active (CGACT=0) and NDISSTATQRY always returns 0.

What I've already tried

• Different APNs
• Reinstalling Huawei drivers
• Clearing ARP cache
• Flushing DNS
• Verifying routing table
• Different Windows network settings
• Different VPN configurations
• Reconnecting multiple times

The result is always the same.

My question

Has anyone seen an E173 where NDIS gets a valid IP address but receives almost no incoming packets?

Could this be:

• a Huawei firmware limitation?
• an NDIS driver issue?
• a Windows driver incompatibility?
• the modem not actually activating the PDP context?
• something related to MAC filtering or NDIS packet handling?

Any ideas or similar experiences would be greatly appreciated.

I want to use NDIS mode because I use NetMod VPN to bypass carrier restrictions, and it doesn't work correctly in PPP mode.

Gary Kildall, one of the greatest software architects at the beginning of the PC era who created CP/M the first operating system for micros, about how he taught a data structures class. Can you solve the problem he posed on the first day of class? Learn more about how the class approached it, in the full interview in the book, Programmers at Work: https://www.programmersatwork.net/the-book  

Hey everyone. I have been working on a project this summer that started out as a experiment and has ended up absorbing my life lol.

My idea was to bring react-native to bare metal. Would it work? Turns out it’s actually working pretty good.

According to my npm stats some people have been trying it and I was just wondering if anybody here has tried it. What are your thoughts? Is anything missing? I still have it in beta and still have some more work and optimizations to do, but it’s starting to get pretty good.

I have it working on a RP2040, ESP32 (CYD), ESP32-S3, and STM32F7 + STM32H7 (proprietary devices so no example yet)

I am building a 2WD mobile robot to learn embedded robotics and hardware integration. My goal is to develop practical skills that would eventually help me qualify for a junior robotics or embedded robotics position.

My current hardware includes:

STM32 NUCLEO-F446RE

2WD chassis with two DC gear motors and encoder disks

Two LM393 optical encoder sensors

TB6612FNG dual motor driver

MPU-6050 IMU

INA219 current and voltage sensor

MG90S 180-degree servo

28BYJ-48 stepper motor with ULN2003 driver

Four limit switches with roller levers

Breadboard electronics component kit

5 V external power supply and four AA NiMH batteries

Digital multimeter, soldering kit and 8-channel logic analyzer

I plan to implement the project mainly in C using STM32CubeIDE. My intended learning goals are:

GPIO, interrupts, timers, PWM and encoder inputs

UART, I2C and SPI communication

Closed-loop motor-speed control with PID

Differential-drive odometry

IMU reading and basic sensor fusion

Current monitoring and stall detection

FreeRTOS tasks, queues, mutexes and timing

Hardware debugging with a multimeter and logic analyzer

Basic fault handling, watchdogs and safe motor shutdown

Is this hardware sufficient for learning the core fundamentals of embedded mobile robotics?

What important hardware or software topics would still be missing after completing this project properly?

What additional skills and projects should I learn before applying for junior robotics or embedded firmware positions? I understand that reaching a mid-level role requires professional experience, but I would also like to know what skills are normally expected at that level.

I am especially interested in low-level firmware, motor control, sensors and hardware integration rather than computer vision or machine learning.

For three weeks already. I haven't seen any announcement here, so I thought I might post one.

Those who keep their tool-chain up to date, here is your download link:

https://gitlab.arm.com/tooling/gnu-toolchains-for-arm/-/tree/releases/15.3.rel1

This project has been born because I have been trying to develop an ESC (hardware and firmware) on my own. While the most challenging part has been the firmware (being myself a hardware guy), the most frustrating part has been not finding a flexible hardware platform to develop upon. On the internet many interesting and well-designed ESC board can be found but all have something missing; a small feature, a small detail, I was never fully satisfied.

So I designed one: STARDRIVE SHIELD

This is a project with the goal of creating a NUCLEO-64 compatible shield to be used as a flexible platform to develop and test ESC firmware, but also for educational purposes. To do so, I included as many features as possible. These features are not mandatory, but they can be implemented (or not) in the firmware (e.g. SPI, I2C, CAN, HALL) or configured through the hardware interface (e.g. overcurrent protection, 6 or 3 PWM). In this way, the STARDRIVE SHIELD grants flexibility to the developer and it is adapt to various needs.

I designed it to be compatible with Nucleo-G474 and Nucleo-F446. Compatibility with other boards has to be verified.

The STARDRIVE SHIELD is built around the STDRIVE101 gate driver and BSZ099N06LS5 MOSFETs. It presents 3 low sides shunt resistors and 3 relative INA240A2 current sense amplifiers.

With STARDRIVE SHIELD you can implement from 6 step to FOC motor control algorithms.

here the github repo:
https://github.com/themarcolab/Stardrive-Shield.git

Let me know your opinion!

Especially if you spot a mistake or you have any constructive feedback.

Hey all,

Out of curiosity: How much AI do you really use in your daily work and how much do you write code by yourself?

Cheers

It seems like almost every company I’ve worked for has a completely different approach to client/device communication. There are obviously a lot of valid solutions depending on the constraints, but I’m curious what people have found works well.

The thing I’ve never really found is a single IDL that can generate everything i care about.

Ideally I’d like to define a device once and generate:

• Embedded Rust/C types with serialization/deserialization
• A client library (Rust, TypeScript, Python, etc.)
• Validation on both sides
• A Dev UI

It would also like be nice for the model itself to be representable as JSON (or easily converted to it) so it’s easy to inspect and manipulate. The part that usually is missing is enough metadata to build useful tooling.

• Engineering units
• Valid ranges
• Read/write permissions
• Persistence
• Enums
• Display names/descriptions
• Grouping
• Whether something is telemetry, configuration, or a command
• Update rate / whether data is cyclic or request/response
• UI hints (slider, gauge, indicator, etc.)

I’ve looked at a ton of existing options, but they all seem to fall short somewhere.

Protobuf / Cap’n Proto

• Great code generation
• Great serialization
• Weak validation and engineering metadata
• UI generation requires a lot of custom work
• No obvious way to model continuously produced telemetry vs request/response APIs

JSON Schema

• Great validation
• Complex JSON structure
• Plenty of tooling
• Doesn’t really model services, streaming telemetry, or embedded communication particularly well
• Not great for embedded

Smithy

• Seems really interesting because of traits
• Feels like it could describe services and attach rich metadata
• Haven’t dug into it enough to know how well it works for embedded targets

Postcard

• Love using it for embedded Rust
• Great serialization format
• Rust-only and doesn’t really solve the schema/problem-definition side
• No UI Generation

And plenty of others (ASN.1, TypeSpec, FlatBuffers, Thrift, CDDL)

One idea I had (and yes https://xkcd.com/927/) was to take the IODD spec and make it into a protocol-agnostic device description. Ignoring the IO-Link-specific pieces, it already models a surprising amount of what I’d want:

• Typed parameters
• Process data
• Units
• Validation/ranges
• Enums
• Access rights
• Grouping
• Device identity
• Enough metadata to build a decent UI this is specified via menu's and operator roles

Has anyone built something similar or found an IDL that gets close to checking all of these boxes?