So I've had the V0.3 boards for a week, and as is evidenced by the fact that it has been a week and there is no "Everything is horrible" post, I would say they're doing okay. But they are far from perfect. Lets run down the mistakes made on V0.3, from most critical to least:

Receiver Problems

The 5v to 12v boost cannot handle charging load

Just as it sounds, the IC I'm using to boost the USB 5v to 12v is well exceeding its capacity. While I'd seen the datasheet say "4A", this must be an extremely short peak capacity, as the boost converter was shutting down at 2.5A and getting extremely hot. What does this mean? Well, we can do two things, either upgrade this to a more spendy IC (most of which take up more space I don't have unless i re-layout the board... which i dont want to do right now... Option 2 is to just remove that boost alltogether and expect 12v at the USB plug. I have tons of 12v power supplies around, so that's what I'm going to do for now. I guess option 3 is to use a PD IC to allow PD chargers to negotiate the 12v at the plug, but those are both expensive and difficult (for me) to implement. So the 5v->12v boost circuit is gone as quickly as it came. A little cost savings!

I don't understand how capacitors work

Here are the analog inputs going into the receiver, one is for the battery voltage, the other to read the return from the 'board sense' line that uses the combined resistance of the cue modules to tell the receiver how many are plugged in.

This properly uses the capacitors to filter to ground. Oh! Also the voltage divider for the battery wasnt ideal, so I adjusted those values to give be a better voltage resolution into the ADC (Analog to Digital Converter).

I wasn't using great pins for the ADC.

For the board sense and battery voltage signals, I was feeding them into GPIO 40 and and some other one that didn't have an ADC attached, so they were useless for their use. Thankfully, I'd exposed a few pads to other GPIOs, so i could use that to verify function, which after fixing the capacitor mishap, were solved! So I adjusted there to move them to pins with an ADC.

The USB serials pads' ground wasnt connected to anything.

In my haste or state of sleep depravation, I had set the ground pad's network to "GN" instead of "GND", so the DRC check hadnt called out that it wasn't connected to anything. Simple fix - just via to the ground plane below!

The LEDs were all backwards.

This is more on JLCPCB... the schematic clearly had the correct anode/cathode markings, but it just seems like this part is reversed? It felt wrong, but I reversed them in the schematic and hope that's the end of that.

Receiver Wins

With the V0.3 receiver, I was able to flash the onboard ESP32 chip and run the perepheral checks on it. After the above issues were temporarily worked out on the boards, everything is looking pretty good! The SPI connection to the NRF24L01+ is solid, power is stable, and the receiver can connect to the host and pass stable telemetry.

Here we can see Receiver 2 and 3 in their housings with the charge state LEDs on (I'm using acrylic tube as 'fiber optics' to pass the SMD led light to the outside of the case). 3 is showing red, that it is actively charging and 2 is showing that it has completed the charge.

These are my 3 prototype modules based on the V0.3 boards. They use different NRF24l01 breakouts, which is why the antenna placement is different, and each has a USB breakout for flashing/logging as I continue to develop the firmware on the boards. When done, that cable will not be on the 'production' version. I'm really happy with how the modules fit together. Even without any bolts, the quality of fit on the ends is enough to keep them solid:

With some caveats (discussed in the next section), the power out and continuity signaling works great - super happy with how things are going with these. The range on the modules is still further than I can test in my neighborhood, which realistically speaking is more than enough for me at the moment.

Cue Module problems

The compact 8 channel cue module has mostly been performing pretty well - though it has two major-ish issues:

Crappy ground plane

The V0.2 receiver board (left) had what I would term a "severely compromised" ground plane. Probably more of a signal plane than a ground plane. Not that V0.3 is a lot better to that end, but as you can see, there is a much bigger path in most places on the ground plane back to the ground pin on the pin header. I hadn't seen this cause any issues with testing, but in general the v0.2 layout was super not ideal in terms of grounding. V0.3 is a little better, but still not great. Ideally, I'd just have a 4 layer board and dedicate a layer to 5v and GND, but I'm trying to save that money. The V0.3 board also re-oriented the shift registers to create less aggressive turns/loopy things.

Vias messing up manufacturing

Most of the V0.2 boards had odd transient issues with output and input register readings. Come to find out this was because some of the feet of the IC had not soldered properly during assembly. I'd figured this out mostly by observing that bad behaviors would change/go away, but only when I had my multimeter on the pins. What this is is that the multimeter pushing down on the pins completed the connection to the pad, which changed how they functioned.

The second to leftmost pin is a great example of this - See how I'd placed a via right in the pad. So when the reflow process started, the solder paste on the pad would fall down through that hole when it melted, not leaving enough on the pad to properly solder to the foot. It "looks" like it might be connected here, but most of the surrounding goo is flux. I solved this in the short term by manually going over all pins with the soldering iron and ensuring they are all connected, but in the v0.3 design, I made a point to move vias outside of the pad footprint to make sure there is a barrier with the silkscreen to prevent solder from adventuring down those via holes.

Misunderstanding with the 74HC165 shift register pins

In a brief chat with ChatGPT a bit ago, I'd asked about the two QH pins on that shift register. Wouldn't ya know it, it lied! It had spun some story about how Q'H (line above the Q) was specifically for input from another register, while QH was what you would pass to an MCU. Being dumb and relatively niave, I accepted that as fact and designed around it. The reality is much different in that Q'H returns the inverse of the pins (1 -> 0, 0 -> 1). So when chaining cues, every other one would have all 1's. Ultimately, I could correct this in the firmware by inverting the byte coming out if the index of the cue was i%2 == 1, but the v0.3 board addresses this and doesnt connect Q'H to anything. The lesson? Trust, but verify.

The new boards

The v0.4 (blue) receiver addresses all of the issues with the receiver noted above. It also relocates the battery input to pads on the side, intending the NTC thermistor be embedded in the battery pack (safety!), and that the battery be directly soldered to the board because finding a way to get the battery cables attached to the pins while keeping the form factor was difficult and kind of scary.

The V0.3 (purple) cues use the new layout, in addition to adding another bulk capacitor. This unfortunately requires me to redesign the cue's top cap, but that's okay as it's a pretty small part. Dont worry about that pin header clipping back - that's something I solder on, so I make sure it's the correct way :)

I put these orders in today, so that should be in this week! I'm doing a better job at keeping costs down by doing these orders at the same time... Each iteration of these costs me about 240 for 5 receiver boards, and 20 cue boards. About 150 of that is for the actual boards, then add 40 for shipping, 25 for tax and 25 for tarriffs and customs clearances and there ya go. Buying more allows a little bit lower price due to economy of 'scale' but for now this is okay. The cost is making me be a little more deliberate with iterations, and taking that extra day to really check designs.