Oh man, it's here, and we've got about 95% functionality. Bask in its programmed glory... 

The only mistake I really made was in the fuel gauge circuit, which I got completely wrong. The footprint on the chip was no good, and they couldn't place that. Without the chip in place, our power circuit didn't function. Some how I was also shorting the battery to ground through a 0.1 ohm resistor, so that was really fucking smart. oops.

Removing R403 solved battery power, and the board came up. All systems, as we know it, are functional and we have some minor changes to make the badge production ready. 

We've also ordered a bunch of speakers to test with from digikey and mouser to see if we can find better speakers. The best speaker wins, and that's what we'll go with for final design.

Everything we've tested so far sucks, and sucks badly. I'm unhappy with the 200mW amplifier but we have hit the limit on our battery budget and parts to go to a bigger amp. I am hoping that larger speakers will help a lot. Anything is better than the weak-ass 100mW amp we had in 2017. 

Bill writes:

I spent most of yesterday at John's place doing more testing and fixing with the badge prototype.

The good:

• John ported in some reference code for the LED controller chip and got it hooked up to the ChibiOS I2C API, and was able to get the LEDs to turn on. This means that a) the I2C bus controller and driver are working correctly, b) the LED controller chip is hooked up to the I2C bus right and c) all the LEDs are functional. This is a big relief since John basically put the LED circuit together based on the datasheets and we crossed our fingers. Let there now be bling.

• I finally got the BLE code to work correctly with the nRF Connect app on the iPhone. The nRF52840 supports BLE 5.1 which means that it can handle larger packet sizes and has a higher speed PHY (2Mbps vs 1Mbps). But in order to interoperate with older devices, it defaults to smaller transfer sizes and speeds. A peer can request that you switch to higher transfer sizes and speeds, which the iPhone does, and you need to respond. Sometimes the correct response is: "no, piss off." But you have to say something, and that means correctly handling all the necessary events. Now it finally does.

• I also fixed a problem with some of the buttons. It seemed to me that one of the three buttons at the front edge of the bomb wasn't triggering, and I was right. It turns out that although I documented the button pins correctly and they were hooked up right in the schematic, I made an off-by-one error in the code: instead of enabling pins 9, 10 and 11 on GPIO port 1, I enabled pins 10, 11 and 12 instead. That was easy to correct though, so now all 7 buttons work. (And yes, we put on 7 buttons so that we could more easily implement a Konami code.)

The not so good:

I think we definitely need to move the screen over to the left a few millimeters so that it's not so close to the front button pad. But this is a huge headache: it means moving the 40-pin connector and all 4 screw holes for securing the screen, and doing that means having to relocate a bunch of other stuff too and re-routing it all.

Also, now I have to write a BLE GATTC client module. I already have a GATTS module which provides attributes with characteristics which can be read and written, but so far I've only tested that from my phone using the nRF Connect app. I want the badge to be able to do it too. Using this I can more easily send notifications from one badge to another. It looks like a bit of a pain in the neck to implement, but that seems to be par for the course for Bluetooth.

On the whole I'm pleased though, because now that we know the bling works, it means that the prototype had zero assembly glitches from Macrofab, which hopefully means we'll get a much better yield this year.

The next step is for John to rig up some quick code to make the LEDs do something neat and film a demo video so that starts may be kicked.