I'd like to introduce gsp32-httpd (screenshots in the link):

• https://genereese.github.io/gsp32-install/

Want to try it out?

1. Plug in your board to your computer
2. Install the firmware via the web flasher, above
3. Configure your WiFi and access the UI

I'm a 23-year veteran python developer and have worked with microcontrollers for several years now - exclusively with micropython on various ESP32 boards. I teach microcontroller classes at a local makerspace and have countless projects I've made over the years.

I've been working with AI to create this tool to make the process of deploying, accessing, and maintaining these projects as easy as possible.

^{DISCLAIMER: This is a beta software/firmware that changes daily. I've done my best to ensure that it's reliable and stable, but I'm just one guy with an AI. If you ever want to stop using it, just download your program files, reflash your board to standard micropython, and re-upload your code. It should still work without GSP32 with the exception of remote pairing to other boards.}

WHAT IS IT?

It's a micropython firmware with a custom web-based user interface for uploading and managing files your programs directly on your device. Whenever you want to change or update your code, there's no resetting, no re-uploading changed files, and no physically connecting to the board via USB cable (unless you want to).

Your main.py runs concurrently in the background as something akin to a virtual machine. You can change it and restart it in real-time and your changes take effect immediately without having to reboot the board.

When users are not actively accessing the web UI, the overhead is almost nothing aside from RAM usage.

Additionally, the web UI framework that runs this system can be used to make your own web-based user interface, populating your HTML with values directly from your python program that can be viewed or updated from that interface as you see fit. The default home page (above) is a fully commented, working version of this for your reference.

WHY DID I MAKE IT/HAVE IT MADE?

For several reasons.

ESP32 boards are usually overkill in terms of specs; so why are we still interacting with them like other older/inferior boards? I wanted to put those specs to good use and make my life easier in the process.

In addition to that, I found that bridging the gap from something like microblocks to micropython is very difficult for most of my students, so I wanted to create a system that would make setup, accessibility, and maintainability as easy, simple, and expandable as possible.

For me, personally, I wanted the fastest level of iteration possible, wireless access to my projects to configure and maintain them, easier file management, and an easy way to deploy and backup code.

WHAT DOES IT DO?

Well, reiterating a bit here, but it does a lot - and it does it surprisingly quickly. I had the AI focus heavily on optimization, caching, memory management, and GSP32's overhead. Basically, if you're not actively browsing the web UI, there's almost no overhead for your programs (aside from the memory usage).

It provides a framework for your own web pages that can be filled with live data from your micropython program. So, you can write your own HTML and use it to host web interfaces for your project for control, monitoring, etc.

It uses that same framework to run itself and includes password protection.

It includes a full-featured file management system that is drag and drop compatible with bulk uploads and downloads divided into two sections - one for your code, and one for your html.

It includes an onboard file editor with autocompletion and code inserting for many commonly used components as well as a pairing wizard that automatically exchanges encryption keys to make secured pairing with other GSP32 systems trivial.

Additionally, and this is one of my favorite features, it wraps your main.py with its code, so you can reload your project almost instantly without rebooting your board, which results in iteration rates that I don't know if any other system can beat.

It includes a mip package manager for quickly downloading micropython libraries.

It includes a backup and restore system for taking snapshots of your deployments.

It also includes a pin panel for real-time debugging of your physical pins based on the board you're flashing to.

Finally, it has a host of performance settings that can be toggled on or off.

WHAT BOARDS DOES IT WORK WITH?

It's compatible with most classic ESP32 (32S, 32C, etc.) and ESP32-S3 boards and there is a web flasher to take care of installing the firmware and configuring the WiFi.

Once configured, you may access the web UI.

^{Not supported: ESP32-S2 | C2 | C3 | C5 | C6 | H2 | P4}

WHAT'S NEXT?

I'm still adding new features almost daily. In general, I just want a highly polished, easy/fun to use micropython system that's not a pain in the ***.

If you try it out, please feel free to let me know your thoughts.

I am embedded systems engineer working for approx 2 years now. With advancements in AI, my company wants that i must be better in architecture and system design like they just tell me what to do and i must be able to do everything for board and component selection to coding and defining everything. I am good in coding when architecture is defined and boards is one which i have used.

Now problem is this i am stuck when i have to do it from scratch. I am unable to do it efficiently. I miss key details , lag to communicate and in end boss scolds me that i have to spoon feed you.
I want to get out of this. anyone with experience can you please tell me ways that i can improve my architecture so that i didnt lag behind.
Opionion from anyone with or without experience will be appreciated

Hey all, I’m a first-year CS student working on a small ESP32-S3 project and I’ve hit a wall trying to find the right display. Hoping someone here has run into something similar.

I need a 128x64 graphic LCD, and the look matters a lot. I want the old-school kind of screen, FSTN, positive (dark pixels on a light background), reflective or transflective, and no backlight. Basically the look of a 90s calculator, not a modern display.

The hard part is the size. It has to be under 2.8mm thick, with an active area around 60-65mm wide. The module itself can’t be wider than 74mm, and the enclosure has a curved inside, so I only get about 63-64mm of flat space. It also needs SPI or I2C over an FPC ribbon, not rigid pins. I’m fine with ST7567, UC1701 or similar controllers.

What I’ve already tried or ruled out:

The Sharp Memory LCDs (like the LS027B7DH01). I really liked them, but they’re TFT and 400x240, so no luck.

Standard 12864 modules. Parallel interface, rigid pins, and way too thick.

Anything backlit or white-on-blue.

I can order from DigiKey, Mouser, AliExpress or LCSC, and I’m in India so shipping matters. I’d also be open to a bare glass panel if I have to build the driver board myself.

I’ve been going through Newhaven, Winstar, Orient and Midas catalogs for days, so I’m probably missing something obvious. Does anyone know a part number that fits, or know a good way to filter for this on a supplier site? Datasheet links are very welcome.

Thanks a lot!

I’m building a tool to help small hardware teams screen firmware applicants. The role is an ECU for a small turbojet: FSM design, interrupts and timing, CAN/SPI/ADC, fault handling. I don’t want to guess what matters. What question reveals real hands-on experience in 15 minutes, and what’s the difference between a strong and a weak answer? Also, what do you think AI interviewers get wrong? Happy to share what I learn.

I want to start career in embedded systems, i have beed going through this course mastering microcontroller and embedded driver development by fastbit embedded brain academy on udemy.

I have almost completed this course now in parallel I want to learn RTOS. Buy without AI I feel the learning gets slow, this is a 28hr course which took 3 months of time still 10% is pending (I'm not always following the lectures as it is since my controller is different and more advanced than the instructors, I'm designing my drivers a little different).

I have started to get frustrated since these months I haven't worked on a single project, I'm being so desperate now to learn RTOS fast, do some projects and get a job.

Curious how you do this, because it's quite of a painful experience for me every time. Designing takes some time but it's at least kinda fun. Ordering from Chinese stores not really.

So the design side is done. Schematic, layout and firmware are ready faster or slower depending on complexity, but AI helps quite a bit. Then comes ordering the components which is painful by itself (at least for my wallet 😄). Digikey for the MCU and passives, LCSC because some of it is half the price, JLC for the boards, Amazon for whatever I need fast. Either way there is a lot of searching, clicking and a 100 tabs open.

Every vendor has its own minimums and shipping, so I end up moving parts between carts to dodge a $20 shipping fee on a $6 order. Then something is out of stock and I'm back in the BOM picking an alternate.

For people who build more than a board or two a year, what does your actual flow look like? Do you stick to one distributor and accept the price, or handle it somehow differently?

Hi all,

I'm an EE undergrad (hardware track). My diploma thesis is a 2-in/2-out USB studio audio interface on my own PCB. It's my first PCB, so before I spend real money on boards and parts I'd love some experienced eyes on the plan. Block diagram attached.

The idea
- 2 mic inputs (XLR), shared 48 V phantom (one switch), gain 0–60 dB in 10 dB steps (rotary switch + fixed RG resistors, cap in series with RG).
- Noise-reduction technique I'm evaluating: each input drives BOTH channels of a stereo ADC (dual-mono) and the MCU averages them. The host still sees 2 mono channels, with ~3 dB lower ADC noise. I'll measure the gain from averaging at every gain step, comparing same-chip vs two-chip channel pairs.

Current part choices
- Preamp: SSM2019 (the THAT1512 went EOL in Sept 2026).
- ADC driver: passive divider (6.2k/1k, ~17 dB) + RC into a PCM1808, so the ADC reaches full scale ~1.8 dB before the preamp clips (≈ +20 dBu max input at minimum gain).
- ADC: 2 × PCM1808. DAC: PCM5102A.
- Line outs: DRV134 on TRS jacks. Headphones: op-amp + BUF634A. Output mute relays with a brown-out detector.
- Digital: STM32F407G-DISC1 board stacked on headers above the analog board. TinyUSB, UAC2 asynchronous with explicit feedback endpoint, 48 kHz / 24-bit in 3-byte subslots (the 1.25 KB USB FIFO rules out 4-byte subslots and 96 kHz).
- Clock: 24.576 MHz oscillator → ADC/DAC system clock and the MCU's external I2S clock input.
- Between boards: SN74LVC244A buffer (Ioff, to avoid back-powering) + a power-good line; 5 V to the dev board through a Schottky.
- Power (version A): bench triple supply (±15 V, +5 V), local LDOs for the ADC's 5.0 V and the 3.3 V. Phantom from a boost converter + capacitance multiplier (soft start, ripple filtering, output disconnect).
- Phantom protection following Bortoni & Kirkwood, "The 48 Volt Phantom Menace Returns". The single-channel test board will start from ojg's open-source thatmicpre KiCad project.
- Metal enclosure, XLR pin 1 to chassis at the entry point.

Noise budget (unweighted, 20 Hz–20 kHz, 150 Ω source)
- Predicted EIN at 60 dB gain: −128.7 dBu (target ≤ −125 dBu; worst case with min-spec ADC ≈ −127.5 dBu).
- Because of the divider, the ADC dominates up to ~50 dB gain. That's where averaging should help (~3 dB); at 60 dB the source dominates (~0.3 dB).

Plan
1. Demo on the dev board with cheap PCM1808/PCM5102A modules (incl. a first averaging measurement).
2. Small 2-layer single-channel preamp board.
3. 4-layer analog board for the full 2×2 interface.

Questions
1. Any obvious mistakes or bad part choices?
2. Is a passive divider + RC into the PCM1808 reasonable, or would you drive it differently?
3. Phantom: boost + capacitance multiplier, or something simpler? Anything missing in the protection network?
4. Is stacking the dev board right above the analog board realistic for low noise at 60 dB gain? Any layout/grounding advice?
5. Measuring without an audio analyzer: the card's own ADC + a 0.1 % attenuator + a true-RMS meter + REW for noise/EIN, and loopback as an upper bound for THD+N. Sensible?
6. Anything you'd simplify for a first PCB?

Thanks!

Hello from the yes or no? post X-Y problem:

What im actually trying to do is write to eeprom whenever a switch is pressed and then recall that information from eeprom so that the Microchip MCU can recall what position the switch is in at power up.

I do not know how to write or read from eeprom without assembly. I already know how to do so in assembly so I was trying to not learn an additional step if I could translate from the WREG to a C variable.

Any suggestions much appreciated.

Story

After working on numerous hobbyist projects with microcontrollers and external hardware—such as sensors, relays, and motors—I noticed a recurring challenge: every new device required rebuilding the same core features from scratch. Tasks like serial communication, HTTP services, MQTT, logging, and, above all, a modern, full-featured web interface for configuration had to be re-implemented every time.

With powerful, Wi-Fi-enabled microcontrollers like the ESP32 family, which offer ample processing power and rich web-server libraries, I realized there was a better way.

This led to the concept of a micro-OS with a Hardware Abstraction Layer (HAL)—designed to integrate different boards seamlessly while providing a comprehensive suite of essential IoT services out of the box.

That is how LoopMxPro was born!

https://github.com/SmartiLabIt/LoopMaxPro

LoopMxPro allows you to skip the tedious boilerplate and focus entirely on developing your core device logic. By building on top of this micro-OS, your custom setup turns into a LoopMxPro Module with its own dedicated web interface. What's more, this interface can be easily replicated on a remote control server.

Today, I’m excited to share LoopMxPro + 6 Modules with the community. It is completely free and open-source for personal use!

Zappy 2Ch 3D viewer

Hi everyone,

I'm working on a project to replace physical coins on buses with a smart ID card.

Here are some specific questions I have:

• Hardware: What is a reliable, low-cost NFC or RFID reader module for a handheld device?
• Offline Mode: How should the scanner handle payments when the bus loses internet connection?
• Data Sync: What is the best way to sync local transaction logs to the cloud once the device is back online?

Short write-up in case it saves someone time with MediaTek's LK on MT8183.

The board was unlocked (kaeru), and it booted Amazon's 32-bit kernel fine, but nothing 64-bit ran. No console because the stock cmdline disables the UART. I found TX/RX on TP103/TP104 (1.8V, 921600) and the causes turned out to be:

- ramdisk size and address swapped in the boot header (header v1, load at 0x40080000)
- LK wanted Image.gz, not a raw Image
- no /chosen/bootargs in my DTB, so LK hits an ASSERT and resets about 45 seconds later
- my DTB declared atf/tee/sspm reserved memory that LK also carves out, which fails its overlap check
- bootopt has to say 64-bit (64S3,32N2,64N2)

After that, mainline 6.18 came up. Audio was its own fight. The I2C bus the amp and ADC sit on is shared with the SCP, and the hardware controller never completes a transfer from Linux, so it's bit-banged. The mainline AFE also wrote clock gates while the regmap was still cache-only. TAS5805M amp at 96 kHz and TLV320ADC5140 mics are working now.

This will be added to my TECHO5 project (Linux + Home Assistant on Echo Shows): https://github.com/HuskerMinion/techo5

Hey, does anyone know of a low-cost site for manufacturing a 4-layer PCBA that includes a Linux-based microprocessor?

I am new to all this so I am not sure what exactly I am even asking, and why I need to thisn, well.... For educational purposes

At my previous job, we used Squish to automate our UI test suites. I recently changed jobs and am researching alternatives.

The only thing that's shown up in my searches other than Squish is "Spix", but I want to make sure that I'm not missing something obvious when it comes to setting up automation from the ground up. Additionally, if there are any video tutorials on automating embedded systems to help refresh myself please feel free to recommend some.

I previously did automated testing with pytest and a legacy junit automation suite. As far as I know they aren't QT compatible, but if anyone has any expertise in this I'd appreciate any comments.

Want to design Nano-SIM male plug (4FF), a flexible ribbon, and a rigid breakout board housing the push-type SIM socket and analyzer header.Please Guide me !

Just curious as to what type of cross-section of users are here and if this would be a good place for me to share and ask questions.

Does anyone tend to run ESP32 boards and/or micropython primarily?

PIC16F1824-I/SL

I want to do something if the working register is 0x0A for example or 0xA0. I need to access it somehow and Im not sure how besides getting it into a C variable. Like this for example,

if(WREG == 0x0A){

bypassed = 0b00000000;

}

else if (WREG == 0xA0){

bypassed = 0b11111111;

}

I got Deere for embedded systems/firmware and RTX for a devops/simulation role. My goal is to work for vehicle firmware or flight software at a company such as Tesla, Rivian, SpaceX Anduril or firmware at Apple, Nvidia, AMD for my next internship. RTX has more aura and more of a weighted brand name, but Deere has more of the work I want to do in later companies.

My team is in a refresh process with our hardware supplier, we've been using a propriertary RTOS until now. This time our supplier suggests going for a yocto linux solution that they will support for us (for a additional cost)

Our real-time requirements are firm, i.e. a missed deadline in a 20ms window renders the system useless but it doesn't explode and kill anyone, thus a real time patched linux kernel will probably work (most of the time)

Regarding yocto and an expected lifetime support of 4 years, I have concerns with patching, CVE, updates etc. our current system has been running for 12 years now with minimal need for updates, less than 10 CVE's, and when we need to update software, we can do it easily.

Licensing for the propriertary RTOS is expensive, we're a small team (less than 5 devs), and our system is managing processes worth magnitudes of the licensing cost.

I'm concerned that we're saving pennies now and it ends up costing us dimes both in time and resources in the long run.

Anyone been in a similar situation and got some insight to share?

I’m trying to get the three front ultrasonic sensors working on my Lymow One Plus, using the original STM32 board’s power and interface circuitry as intended. I’d like to figure out the factory supply path before adding an external supply or changing any GPIO outputs.
I’ve attached full-board photos and close-ups. The coating makes the small component markings difficult to read. Does anyone recognize the three matching six-pin devices or the two three-pin parts beside them? More importantly, can anyone help work out where the front sensor supply comes from and what enables it?
Here’s what we have so far.
Hardware and measurements
Main MCU is an STM32F407V-series, 100-pin package. The second MCU is an AT32F403ARCT7.
Both chips’ flash has been backed up over SWD, with two matching reads of each. No firmware changes or GPIO writes have been made.
There are three front sensors: left, center and right. Each has red, black and yellow wiring. The modules are marked C26A03 / 0255E, but I haven’t found a matching module datasheet.
Their connections have been traced to the unpopulated 2×14 header footprint. My photo labels RR/RY, CR/CY and LR/LY mean right red/yellow, center red/yellow and left red/yellow; G marks confirmed grounds.
The three red-wire pads have continuity to each other. All measured 0 V with the mower running. The shared red net measured approximately 20 kΩ to confirmed ground with power disconnected.
A separate harness point labelled ULT_PWR measured 5 V, but there’s no measured continuity between that point and the front red-wire net. I’m not assuming they’re the same supply.
On earlier isolated bench tests, yellow idled around 2.6 V with 3.3 V supplied, and 4.2 V with about 4.9 V supplied. No convincing sensor reply was captured. That doesn’t establish the module’s rated voltage or prove the sensors are bad.
What the firmware shows
The STM32 contains a three-channel pulse interface whose timing is a very strong match for the Elmos E524-family IO protocol:
150 µs bits, with 100/50 µs or 50/100 µs phases.
A 250 µs command-mode interval.
Measurement windows of 8.25–46.25 ms, followed by additional captured edges consistent with a status reply.
Separate transmit and receive MCU pins: PA5 → PB1, PA1 → PB0, PA2 → PA7. The receive side uses TIM3 channels 4, 3 and 2.
Those are firmware pin pairs; their exact correspondence to the three physical yellow-wire connections still needs confirmation.
The Elmos E524.33 document specifies a 6–18 V operating supply, typically 12 V. That’s a useful lead, not a confirmed voltage rating for these exact modules. I haven’t applied 9 or 12 V based on that assumption. If you’re reading this you’re cool.
We also took read-only snapshots while the mower was running, roughly 19–46 seconds after boot:
TIM3 was configured for capture but stopped: CR1 = 0, DIER = 0, CCER = 0.
All three capture-event counters were zero.
The pulse driver’s state and descriptor records were all zero.
The three front-distance cache values stayed zero.
The rear ultrasonic readings changed normally during the same checks.
The firmware retains names ULT_F_1_task, ULT_F_5_task and ULT_F_10_task, but we haven’t found those tasks being created or a routine updating the front-distance cache at 0x2000130C. That strongly suggests dormant front acquisition in this build. It doesn’t prove nothing could enable it later in another operating state.
Possible supply controls
STM32 PD3 goes high during sensor initialization and was high in the live snapshots. It’s associated with the working rear-sensor code, but its physical supply net hasn’t been traced.
PE1 and PE8 are configured as outputs and have identified low-setting paths at startup/shutdown, without a discovered high-setting path. They’re candidates for an unused enable, not confirmed front-power controls. Other less certain candidates are PB8, PE4, PE5, PE6 and PE12. I haven’t toggled any of them.
Parts we’ve looked at
The eight-pin chip beside R250 is marked 8870 / TI…, matching a TI DRV8870 motor driver. The earlier idea that it was a sensor-supply regulator was a guess and should be discarded. Neither end of R250 showed continuity to the front red net in our checks.
Another eight-pin device appears to have a 4407-family marking, possibly an AO4407 P-channel MOSFET. That identification is tentative. The nearby two-pad footprint also showed no continuity to the front red net.
There are three matching six-pin circuits beside the sensor header, each surrounded by similar resistors/capacitors. They look like interface stages, but we haven’t identified the parts.
The two three-pin components beside those circuits are still unidentified. We also initially mistook a piece of grass for a jumper wire—there is no confirmed factory rework wire there.
I have a meter, logic analyzer, a Waveshare adapter that successfully accesses both chips over SWD, and the saved firmware/disassembly.
What I’m hoping someone can help identify is the original switched supply for the three front sensors: which component feeds the common red net, what voltage it should provide, and which MCU pin—if any—controls it. A schematic fragment, recognizable part marking, or a specific trace to check would be a huge help. I’d rather establish that circuit than keep guessing at nearby components or blindly switching GPIOs.

R-Right
L-Left
C-Center

I tried making it easy for myself.

I need a serial data logger which supports RS-232 and RS-422(maximum possible baud rate). I want to capture samples from sensors to the SD card. I will be mounting this on a DJI drone or a car, so it should be battery-powered.
What off-the-shelf options do I have?

Part of a series on the open-source J1939 emulator. This post covers how J1939 puts Parameter Groups on the bus and how ECUs join the network in the first place.

If you've stared at a raw J1939 CAN ID and wondered why the same byte means completely different things on different frames, this post is for you. We'll walk through the 29-bit identifier, the PDU1/PDU2 split that trips up almost everyone at first, and how an ECU claims its address on the network.

The 29-Bit J1939 Identifier

Every extended CAN frame on a J1939 bus uses this layout:

On the emulator, priority is 3 for EEC1 (engine speed/torque) and 6 for most other messages — this only affects bus arbitration, not meaning. Receivers ignore it entirely when interpreting the message content.

PDU1 vs PDU2 — The #1 Source of Confusion

This is where most people get tripped up, because the same field (PS) means two different things depending on the value of PF.

PDU1 (PF = 0–239): peer-to-peer / directed

• PS = Destination Address — literally who this message is for
• PGN = (DP << 16) | (PF << 8) — note that PS is not part of the PGN here
• Examples: Address Claimed (PF=0xEE, PS=0xFF for global), Request (PF=0xEA, PS=0x00 to address the engine directly), TP.CM/TP.DT sessions

PDU2 (PF = 240–255): broadcast / group

• PS = Group Extension — it's part of the PGN number itself, not a destination
• PGN = (DP << 16) | (PF << 8) | PS
• No single destination; any listener on the bus may consume it

On this emulator specifically:

The important thing to internalize: Group Extension is not a multicast group in the networking sense. It's simply the low byte of the PGN, baked into the CAN ID.

Scenario 1 — Cyclic Broadcast

On START, the emulator puts five J1939-71 parameter groups on the bus, plus address claim, VIN, and DM1 as configured. All five broadcast PGNs are PDU2 — PS is the PGN's low byte, not a destination address. Dash, ABS, telematics, and a logger all see the identical frames; each one simply filters by PGN for what it cares about.

This mirrors how a real engine works: on key-on, it publishes speed and temperature continuously, so the instrument cluster never has to poll for it.

EEC1 deep dive

PGN 61444, CAN ID 0x0CF00400. Example payload at 1250 RPM: F0 AF AD 10 27 F3 FF FF. Change the RPM slider in the GUI and watch bytes 3–4 update live — that's the actual RPM encoding in action, not a mocked value.

ET1 deep dive

PGN 65262, CAN ID 0x18FEEE00. Engine coolant temperature (SPN 110) feeds both the dash gauge and the DTC logic — the same signal that later triggers a fault (SPN 110 / FMI 3, voltage-high) is broadcast here. Broadcast every 1 second, no request required for normal driving — though a service tool can still request it directly for an immediate sample, which brings us to the next scenario.

Broadcast timing, no handshake involved:

Listeners filter by PGN/CAN ID — there's no CTS, no application-layer ACK. (Classical CAN's data-link-layer ACK still happens, from any healthy node on the bus, but that's a different layer entirely.)

Scenario 2 — Tester Requests a PGN

Sometimes a tool doesn't want to wait for the next broadcast cycle — it asks directly. This uses PGN 59904 (0xEA00), and it's a PDU1 message, which means PS finally does mean "destination."

Remember: SA = who sent it, PS on a PDU1 frame = who it's for.

A tool at SA 0xF9 asking the engine (SA 0x00) for ET1 looks like:

• Request frame: CAN ID 0x18EA00F9, 3 data bytes containing the little-endian PGN being requested
• Here, PS=0x00 means "destination = engine" — it is not the PGN low byte, because this is a PDU1 frame
• The engine typically replies as a normal PDU2 broadcast — on that reply frame, PS=0xEE is the Group Extension of PGN 65262

That contrast — same byte position, two different meanings depending on message type — is exactly why PDU1/PDU2 trips people up.

One honesty note: v1.0 of the emulator primarily broadcasts; it doesn't yet implement full request/response handling. It's still worth understanding this scenario, though, since it's exactly what a real scanner tool expects.

And there's a dependency worth calling out: if the engine hasn't claimed its address yet, a request just gets silence. Which brings us to address claim.

Scenario 3 — Address Claimed

PGN 60928 (0xEE00), governed by J1939-81, is how a node joins the network. On the emulator, SA 0x00 is claimed on start.

CAN ID: 0x18EEFF00. Worth noting: PF is 0xEE because that's simply the SAE-assigned PGN for Address Claimed (60928 = 0xEE00) — it's not a special "claim bit" hidden somewhere in the ID.

The NAME field

The 8 data bytes carry a 64-bit NAME, stored in the ECU's flash and copied into the Address Claimed payload every time it's sent. Peers decode this little-endian 64-bit value and update their internal address table: "SA 0x00 belongs to this NAME."

Conflict resolution: if two nodes claim the same SA, the one with the smaller 64-bit NAME wins. The loser either changes its SA (if it's configured as address-capable, AAC=1) or goes silent.

Timing

On start, the engine sends Address Claimed. Other nodes store the SA→NAME mapping and wait roughly a 250 ms class window for any contenders. A node may also explicitly request Address Claimed from others, prompting a re-announce. If a rival claims the same SA with a lower NAME, the current node loses that address. Once claiming succeeds, cyclic broadcast (EEC1, CCVS, etc.) begins.

Summary

• PDU2 broadcast: PS = PGN low byte; anyone may listen.
• PDU1 Request: PS = destination SA; SA = the requester.
• Address Claimed: the data payload is the NAME; the CAN ID carries PGN 60928 plus the node's preferred SA.
• Lower NAME wins a contested source address.

Watch It Live

Reading about PGN structure only gets you so far — seeing the actual frames change on a logger while you interact with the emulator makes it click. The full walkthrough, including a live address-claim capture, is in the YouTube series. Source and setup instructions: github.com/EmbeddedVerse/j1939-emulator.

Next in this series: how DTCs get packed into DM1 and split across multiple frames once you have more than one active fault.

Writing code comments is such an enjoyable activity.

AI can produce code quickly, but the difficult part seems to be keeping the connection between the requirement, the implementation and the test. Without that link, review becomes mostly reading code and hoping nothing important was missed. How are teams handling this in embedded projects, especially when the code is safety-related?