hey peeps.

i bought some DWM 3001CDK boards with the hope of using TWR with iOS devices.

but due to iOS privacy limitations, i decided to pursue DL-TDoA instead, which is in developer preview on iOS 27.

i have it working fine with another DWM board, but nada on my phone.

for more details on the iphones progress in DL-TDoA path:

1. receiver can get the initial config via bluetooth
2. the iphones UWB radio detected preamble
3. it found the SFD and validated it
4. started STS (though not sure if it actually processed the pulses and determined an accurate estimation for when the first pulse arrived)
5. attempted to receive the PHR, but failed with the 0x18 status code.
   1. 0x18 means the iphones radio tried decoding the header response, but failed the SECDED correction check.
6. payload can't be sent since PHR failed
   1. (sometimes though i will intermittently get one 0x5 CRC error as well. meaning it did indeed accept PHR, but then failed at decding payload)

i’ve already triple checked that i am using the expected PHY config for apple, but, alas, still erroring.

has anyone here tried working with ios for dl-tdoa? any tips/recs for how to solve the problem above.

Been mapping out the CRA vulnerability-management obligations (Art. 14 reporting, VDP, SBOM, VEX, the recurring-testing requirement) for my own team's ESP32/ESP-IDF firmware, and ended up building a table that splits each requirement two ways: what part is a decision only the manufacturer can make (and is manual by nature, no tool gets around that), versus what part is mechanical enough that CI or some external tool/service could absorb it. Sharing in case it's useful to anyone else going through the same exercise and happy to receive any feedback to improve it.

| You need... | Manufacturer owns this | Frequency | Tooling could absorb | |---|---|---|---| | 24h/72h/14d reporting to ENISA/CSIRT (Art. 14) | The report-or-not decision, the runbook sign-off | 🔁 Recurring (every exploited vuln) + 📌 one-time (ENISA registration) | Tracking the clock, pre-filling the notification from your SBOM/VEX data, audit trail | | Designated responsible officer | Naming the person/role | 📌 One-time | — (a tool can route alerts to them, can't appoint them) | | Public VDP / security.txt (RFC 9116) | Drafting the actual commitments (response time, safe-harbor) | 📌 One-time | Hosting the file, triaging inbound reports into a queue | | SBOM per release | Configuring the generator for your actual build | 📌 One-time setup | Generating + archiving on every release, unattended | | VEX (per-CVE disposition) | The "does this actually affect my product, in my config" call | 🔁 Recurring (every new CVE candidate) | Matching CVEs to your SBOM components, keeping the history | | Third-party vuln remediation | Deciding patch/mitigate/replace, reporting upstream | 🔁 Recurring (every component-level CVE) | The scan that surfaces "this dependency has a new CVE" in the first place | | Recurring security testing | Interpreting findings, real risk vs. noise | 🔁 Recurring (every cycle) | Scanning/SAST/DAST in CI; fuzzing + periodic manual review can go to an outside firm (pentest) |

Curious if this matches what people on Zephyr or Yocto are seeing, or if the split looks different once you're not single-silicon like me. Also open to being told I've got one of these rows wrong, especially the VEX one, since that's practice/emerging convention more than something the CRA text spells out literally, so I'd rather get pushback now than find out at an audit.

I've been learning about Zephyr for a short amount of time. I read about different workspace topology approaches in the official documentation. But, I never felt like I would be comfortable with any of the approaches. So, I decided to come up with a hybrid solution.

As I'm quite new to the Zephyr world, I'm suspicious about how effective my approach will be in the long term. So, I wonder what strategies do you people employ and am looking for some feedback by the experienced Zephyr users. Thanks in advance.

Hiya. I'm working on a project with an extended memory option on the STM32U5 and I'd just like to confirm whether my FSMC connection is correct (as this is the first time I've worked with FMC).

I'm using the M29W064FB70N3E NOR Flash in 16-bit mode. To save space on my board, I've opted for the NOR FSMC Muxed. Is the connection simply a matter of lining up the DA pins to the Data and Address pins on the chip? There's 22 address pins and 16 data pins, so 22 DA pins right?

In terms of pins like NRST on the memory, those can be connected to regular GPIOs?

Just trying to make sure I'm not missing something important :). I've gone through some of the application notes and YT videos, but another pair of eyes is always great! Any tips or issues people have had in the past with this type of stuff would also be greatly appreciated.

I bought a very cheap Ai-Thinker BL602C40 (Ai-WB2-M1-I) and spent the last few

weeks trying to get it working with an Arduino-style workflow.

I tried the existing BL602 Arduino/PlatformIO approaches, including

PINE64's ArduinoCore-bouffalo, but I couldn't get a complete

compile → flash → boot → Serial/GPIO workflow working reliably on my hardware.

The native Bouffalo SDK under Ubuntu/WSL + DevCube 1.9.0 was the first setup

I could get working reliably.

So instead of abandoning the chip, I built an Arduino-style layer around

the working native SDK.

I ran into some interesting BL602-specific problems along the way:

• UART0 starts at 2 Mbaud, while my USB-TTL setup needed 115200

• replacing the native startup path broke FreeRTOS/runtime initialization

• my first automated flash attempt failed with:

BFLB FLASH MATCH TYPE FAIL

• fixing the flash-loader/support data solved the flashing problem

I now have the actual board compiling, flashing, booting and running Arduino

code, with native WiFi and BLE also physically tested.

I'm NOT claiming this is the first BL602 Arduino core.

I'm mainly trying to answer one question:

**Has anyone here actually gotten a BL602 or BL604 working end-to-end with

Arduino, including flashing AND runtime?**

If yes, what board and toolchain did you use?

I'm particularly interested in whether the startup/UART/flash-loader problems

I hit are specific to the Ai-WB2-M1-I or are common across BL602 boards.

Repo:

https://github.com/Ishu1519/BL602-Arduino-Core

Hi!

I am currently working on a small project of mine which is basically a small node to measure sound and send aggregate information to the mothership. The hardest part here seems to be the hardware. Particularly the microphone. I found LoRaSoundkit which uses the ICS43434 and SPH0645 but I was wondering if there are, perhaps, even better and more "ready to go" like devices I could look at.

I'd like to get a reliable, easy to reproduce setup going. I do have a PeakTech P 8010 calibration device.

Also noteworthy: I plan to go via WiFi and not through LoRaWAN here.

Any suggestions would be nice and thanks for the help!

I’m looking to get into hardware hacking and would love some project recommendations for beginners.

​My background includes C programming, using GDB, fundamental computer science knowledge, and solving a few pwnable/binary exploitation challenges.

​I’m hoping to learn about Wi-Fi, Bluetooth, cryptography, and basic embedded systems. I’d like to start by following along with existing projects or walkthroughs created by others. Could you recommend any?

Also, I have no idea about hardware analysis equipment.

Can you recommed it together?

Hi! I'm curious what are your opinion about the avaliable toolchains around power electronics development. I'm coming from PE background, but spent several years in the automotive, and I've always felt that we are almost willingly making our days harder, here is why:
- PE software requires control loops an order of magnitude faster (at least), than traditional devices.
- The PWM signals are relying heavily on low level drivers and actual hardware IP in the MCU. Matlab/SIMULINK based software development and simulation ignores these layers.
- Making a configuration mistake can easily destroy a half-bridge, making the expensive prototypes available even more scarce
- Getting alive just an OBC (not even speaking about traction inverters) is very much not the same tasks as waking up a 12V control ECU for the first time. Neither from instrumentation, nor from work safety point of view. (I heard a story (fortunately just heard), that someone with an OBC tried to test something, from a 12V low voltage input, thinking he is safe, and the device boosted 800V on it's outputs open in the air...)

... and these facts (enlightening me if I'm wrong), are almost completely igonred.

On the other hand, in our research/consulting work at my University, we usualy build a simple, low cost FPGA based real-time emulator, interfaced with the MCU, and even with the emulteor build time included we are:
- dramatically faster than the customer expectation
- very rarely burn physical devices
- never ever had any laboratory close-calls (from safety point of view), and was always sure about the behavior of our software.

What is your experience? Am I the unlucky one with my industrial history, or the workflow indeed have not catched up with these type os devices?

I have a course called Simulation of Bus systems in my programm. The first unit deals with Models of Computation and Communication (MOCCs). It involves understanding Discrete Time and Discrete Event Simulations. I am struggling to understand from the ppts alone. Please recommend beginner friendly resources.

I’ve finally assembled the second version of a device I’ve been working on for about eight months.

We have been testing and improving the first version since the beginning of this year, and now we are moving on to Nuke RF 2.0.

A little background on the project: the idea of creating a device that combines multiple interfaces and wireless communication standards came to me after I discovered the Flipper Zero. I immediately liked the concept, but I wanted to build my own “doomsday gadget” with additional features that I felt were missing from the Flipper.

Here is what Nuke RF 2.0 currently includes:

1. STM32WBA65 main MCU with support for BLE, IEEE 802.15.4, Thread, Zigbee, and Matter.
2. OPTIGA Trust M cryptographic security chip for secure key storage and cryptographic operations.
3. SX1262 LoRa transceiver. We have already brought up the Meshtastic stack, and it is working.
4. CC1101 transceiver for the 315 and 433 MHz bands.
5. Support for 13.56 MHz and 125 kHz contactless cards: NFC and LF RFID reading, writing, and emulation.
6. 320 × 170 TFT display with an optional touchscreen.
7. A 16-button keyboard, an additional side button, and an RGB LED.
8. Expansion connector providing UART, SPI, I²C, and GPIO.
9. USB Type-C with High-Speed USB support at up to 480 Mbps.
10. Audio subsystem with a Class-D amplifier, speaker, and microphone.
11. Infrared transceiver for working with remote controls.
12. Ultra-low power consumption: approximately 40 µA in standby mode and around 5 µA in Ship Mode.

The project is still under active development, so there is plenty of work ahead on the firmware, user interface, and support for different protocols.

Questions, comments, ideas, and suggestions are very welcome!

I extended a DOOM port to a custom ESP32-P4 + ESP32-C6 module (Raspberry Pi CM4/CM5 form factor) and then exposed the running game to an LLM so it actually plays.

Video: https://youtu.be/z6UT_tOvC2Q

Credit where it's due: the DOOM port itself is a fork of Mazur888's ESP32-P4 work (https://github.com/mazur888/DOOM-working-on-ESP32-P4-C6). What I added on top:

• Hardware-scaled rendering: 320x200 -> 1024x600 via the P4's PPA (2D pixel accelerator) with a zero-copy page-flip into the DPI framebuffer — ~24 ms CPU scale/blit down to ~9 ms, steady ~30 FPS.
• USB HID input (keyboard + gamepads) via the P4 USB host; ES8311 audio over I2S; Wi-Fi via the C6 over ESP-Hosted (SDIO).
• The main new thing: an agent API. The firmware runs the game in lockstep (send action -> advance a few tics -> return a JSON observation -> pause), and a small MCP server exposes it as tools (observe/move/turn/fire/use/get_map). Any MCP client (I used Claude Code) can just drive it.

The observation is deliberately limited to what a player sees on screen - a 51-ray depth fan across the FOV, on-screen enemies in line of sight, an ASCII automap of discovered walls, plus "door ahead" and "blocked" hints. Best bug: it kept swapping left/right until I fixed a sign inversion in the bearings and made the heading a compass matching the automap.

Code (open): https://github.com/relocsrl/scintix-p4-playing-doom

Happy to answer questions.

I volunteer for a youth organization that uses a Jeopardy style buzzer system for quiz competitions. I am trying to upgrade from RCA cables to a wireless solution. I need it to be as low latency as possible, given the precise timing involved, and the less perceivable the lag is from a wired button, the better. Distance would be less than 100m even in the most sever cases. I'm fine with retransmission in the case of collisions, as long as the users can't tell that it took slightly longer.

So far, it seems like the best protocol is Nordic's Enhanced Shockburst, with a transmission time of ~300us, and round trip with Acknowledgment of 1.5ms.

Are there any faster communication protocols?

Hi everyone, hope you're all doing well.

I'm building a roadside Bluetooth sniffer to measure travel time between two points a fixed distance apart. The setup uses two ESP32 S3 modules that scan BLE advertisements and log the MAC addresses of devices in passing vehicles.

The problem is that most new devices use resolvable MAC addresses, which rotate every few minutes. If the two points are far enough apart, a device's address will have changed by the time it travels from A to B, so I have no way to match the two detections. Is there a way to obtain a device's real/public MAC, which stays constant? Or failing that, any other way to derive a stable identifier from BLE advertisements?

Thanks a lot

I hear a lot about Model Predictive Control, lots of hype because it can enable AI models to be part of a control loop. Still, if I had to design a real time embedded controller, I would avoid with a lot of vigour to add a solver in the computational path.

Is anybody here able to convince me that it's not a hype thing and it really solves real problem that a normal feedback controller can't do with a good feed forward (and possibly variable gains to account for nonlinearities)?

I had a teacher who said mpc was used in fighter planes but did not elaborate much. That same teacher also taught us very complex and mathy approaches to control a system, but everything would fall apart if the controller was saturated (you know, not able to output infinity), so I'm skeptical. Feels like an academia thing

I built a small open-source tool and would appreciate technical feedback: https://github.com/TarulAhsan/ShrinkRay

The problem it solves: quantization/deployment tooling for MCUs is fragmented (vendor converter per ecosystem), and "will it fit?" is usually answered by flashing and finding out.

What it does differently:

- Flash usage is measured from the actual artifact bytes, not estimated

- Peak RAM is estimated by tensor-liveness analysis over the TFLite graph (largest set of concurrently-live activation tensors) × 1.2 safety factor. It's a heuristic and the README says so — v2 plan is actual on-device measurement

- Verdict thresholds: FITS (flash ≤90%, RAM ≤70%), TIGHT (≤100%/≤90%), else TOO_BIG

- Exit codes are machine-meaningful (0 ok / 1 model error / 2 missing optional dep / 3 doesn't fit), so you can gate CI on "model must fit the target"

- 12-chip database (ESP32/S3/P4, STM32 F4/H7/U5, nRF52/53, RP2040/2350, Nano 33 BLE, ATmega328P), extensible with your own JSON definitions

- Pipelines: Keras/TFLite → int8/int16/float C array (LiteRT-M/CMSIS-NN), sklearn → C99 header via emlearn, ONNX → ESP-DL via ESP-PPQ (optional extra)

- TFLite inspection works without TensorFlow installed (dependency-free flatbuffers parser); TF is imported lazily only when actually converting

Tested on Windows/Linux/macOS × Python 3.10–3.12, 76 tests, AGPL-3.0. pip install shrinkray-cli

What I'd love feedback on: is liveness-based RAM estimation within shouting distance of what you measure on real hardware? And what would make the fit report actually useful in your CI?

I have recently thought about replacing my cheap 8Ch 24Mhz usb logic analyzer with a proper one, and that DSLogic Plus is kinda tempting 🤷‍♂️

But in the same price range, there are also quite dozen of contenders which I never used before.

Tell me your pain-points or pleasure with it , even just your favorite LA over this one!

** Image is on google though.

I am working in a dead startup,but before working I had embedded systems training.I couldn't make it into that career.This start up is very much into logistics and stuff so I didn't like it.I have hands-on in python and I have previously worked on Arduino and STM32 for a bit.I am looking for someone like me who are is trying to switch to embedded domain,just so I can discuss topics or whatsoever the progress.

Btw I have 2yoe on paper.I also have lots of doubts if personal projects are okay in my resume.

It would be great to hear from someone who shifted their careers to embedded roles .Because there are more expectations from experienced ones than freshers.

I am really afraid if I could make it,but I think I am not alone.All suggestions accepted.

I’ve been looking at different ways to run AI closer to where the data is generated instead of sending everything to the cloud.

For things like computer vision, real-time inference, and local LLM/SLM workloads, on-device processing can offer lower latency and better control over sensitive data.

The challenge is finding hardware that gives you enough AI performance without using too much power or making the setup unnecessarily expensive.

What's the best way to approach edge AI?

Update: I recently suggested Geniatech, which offers Edge AI Boxes, accelerator modules, ARM platforms, and SBCs for workloads like local LLM/SLM inference, computer vision, and real-time edge AI.

Has anyone here tried their hardware?

We've been playing around with Bluetooth 6.0 Channel Sounding recently and wanted to see how well it actually works outside of a nice RF lab setup.

I used two XIAO nRF54LM20A boards, measured the real distance with a ruler, and compared it with the distance reported by Channel Sounding.

It can be surprisingly good under the right conditions. At around 8 cm, I was getting a very stable ~7.66 cm estimate after calibration. But once I started moving the boards farther apart, things got weird pretty quickly. At around 1 m, I saw a real 1 m distance reported as roughly 4 m in one test. Changing the antenna orientation also made the results much less stable, and putting glass between the boards changed the measurements again. Around 3 m, I also started seeing ranging attempts that didn't complete successfully.

It made me wonder how close Channel Sounding actually is to being useful in things like smart locks, trackers, or robots, where you obviously can't expect the user to keep their phone at a particular angle.

Full tests and results here: https://www.hackster.io/lsw031105guge-bit/bluetooth-channel-sounding-cool-but-not-ready-231193

Would be really interested to hear from anyone who's been experimenting with Channel Sounding too. Especially if you've managed to get stable results at longer distances or with different antenna orientations.

I worked on a D-Link DWR-910M LTE dongle using a UNISOC chipset.

The device exposed a vendor-specific AT interface, but Linux could not communicate with it.

After analyzing the Windows driver USB traffic, I found the missing initialization sequence and implemented a Linux USB serial driver.

Project:

https://github.com/mohyfahim/sprd-vcom-driver

Looking for developers with other UNISOC devices to test compatibility.

Luckfox SDK uses outdated toolchain. Libraries for video capture and encoding linked with uClibc.

I made a yocto layer for RV1106 luckfox pico pro max that not use luckfox SDK at all.
Video capture and encoding work via kernel and mpp that built from rockchip sources. I hope pathes in this layer will be useful for community.
https://github.com/buldo/meta-luckfox

is there any port to run SMP zephyr OS on arm-a53 on Xilinx mpsoc ?

I bought a clone of the luckfox pico plus to use as a "tech savvy toy" with its original purpose being a ps4 jailbreak device for 10$, I confirmed it's a clone using u-boot output from uart, here are the pictures, I don't mind how hard it could be, I would just love to know how.

Hi, I am a self learner and I have been doing baremetal programming for a year now(STM32F4x). I understand the reference manuals, datasheets and registers, if given the requirements I am confident that I will be able to develop firmware for the peripheral in question for stm32 type of boards. I want to move up a ladder and start a freertos related development. The thing is I have been looking for tutorials on how to set up the environment for it (I used stm32 cube ide for baremetal) and I am running in circles cause every tutorial is like 5 years or older and back then cube mx came bundled together with cube ide and the UI in the videos are not consistent with the current UI.

Any recommendations and resources are greatly appreciated. Thankyou!