A wearable, hackable, blinky badge for Defcon27
featuring RGB leds, sound, BLE, games, and more!
It's been a couple of months, and I had to put the project on hold because I was overwhelmed with event production stuff. When I'm not working on electronics and computer things, I can be found at DNA Lounge making events go. This year has been pretty ridiculous, and only now do I have time to myself to get back to #badgelife.
We're going through the schematic and layout this weekend in an attempt to get a prototype out the door to Macrofab. It's a lot of work, because there are still a few things we're unsure of.
I'm hoping to get the UART sorted out today and then go back and fight with the autorouter for our board layout. I'm thinking that this year since 4-layer boards have come down, that we will do a 4-layer board.
There's many, many advantages to this in the "Reducing signal noise" and "making layout easier" departments. Four layer boards are way easier to route, and when you can insert power and ground planes into your design, you turn the board into one gigantic capacitor, and this reduces overall noise greatly.
I'm hoping that by Monday, we can get this thing out the door. We'll then start to work on our kickstarter (January) and the process of ordering parts. We've got 8 months until DC27. We can do this!
Sneak-peek at the schematic (at least, one page of it...)
Bill has been working through some of the low-level firmware issues while we march towards an initial schematic for prototyping the badge. Of special interest to me, is that we've got working communication between the MCPU and the Cirrus CS4344. This means, stereo audio is possible on our device which is a bit of a quality jump for us. Last year we were barely able to support 12-bit audio. This year, 24bit/96Khz is probably doable, but now we're going to have new and exciting video sync issues which may reduce our ability to pump hi quality audio down the bus.
I got the I2S interface to work. I had to deal with some... interesting quirks. The Cirrus Logic CS4344 chip takes a certain amount of time after the clock signals are applied before it can start playing audio. To deal with this, I turn the I2S controller on and enable streaming with the master clock and left/right clock enabled, but with the pin for the audio bit clock disabled. Then I wait for a certain number of sample cycles to elapse for the chip to get its brains together.
The playback here is monaural, but apparently doing stereo is as easy as just including stereo sample data and changing the setting of one register. Of course that makes the audio files twice as big.
But there's one stupid problem. Nordic designed their I2S controller such that you only have a limited number of clock frequencies you can choose from. This means you can only use a certain fixed number of audio sample rates. Right now I'm using 12500Hz. The problem is that the scheme I cooked up for the DC25 badge to keep audio and video synchronized during playback depends on the number of audio samples per video scanline being a whole number. With the DAC and timer mechanism I used for playing audio on that badge, I could select any audio sample rate I wanted, so I deliberately chose one that would yield the right results.
But here I'm stuck with the frequency values that Nordic saw fit to bake into the I2S controller, and none of them result in a sample rate that lines up nicely. I think that with 12500 samples/second, I end up with about 6.5 samples per scanline.
I think I can get around this by dropping a couple of samples periodically, but it's more hassle than I had expected.
A video of this working is here:
We're about ten days into our work now and I've spent most of them installing KiCad, figuring out our hardware needs, and getting my development environment up and running. Since we're now on cortex-m4 (last years KW01 was cortex-m0) we can still use the gcc-arm tool chain and Makefiles from our previous ChibiOs build. This means same OS as last year, and full support for things like uGFX. On my Mac, the operating system is up and running and we have full serial access to the board
Look at that boot!
On the hardware front, we have some decisions, and some issues.
Bill reports that:
wpaul [1:47 AM] "The nRF52840 supports up to 32MHz SPI clock!!!" Yeah, right: but only for one bus! (SPIM3) Oh, and by the way, that one bus? It's totally broken in the early engineering versions of the silicon. So that preview board you bought? Yeah, it won't work with that. Seriously, what the hell.
The nRF52832 had three SPIM blocks. The nRF52840 has 4. Only the 4th supports a clock speed faster than 8MHz.
The instances can be configfured for SPIM or I2C, and they're tied to the same interrupt pin, but nothing about that necessarily restricts the speed of the SPIM logic. So now, not only can I not achieve the simultaneous display and SD card speed that I wanted, I have to order another DK board because the preview board I have is basically worthless to me.
So, what this means is that 1) We need to immediately order new development boards. 2) Our current boards are useless. 3) We can't do any SW development until this happens.
In other areas we've made some decisions. Audio will be over I2S. Most likely using the CS4344. If everything works out, we're going to get DMA audio, stereo, and 24bit/96Khz output which makes the audio nerd in me very, very happy. I will do everything I can this year to reduce noise -- last year we had to stop PCB changes and go to production before I could fix noise issues on the board.
LED-wise, We're not going to use the WS2182's. Instead, we're going to do something similar to what Queercon did on their badges, and that's to use the IS31FL736 chip to control our LEDs. This means that we're going to have to have a dual power supply (5v and 3.3v), and getting that 5v is going to require some sort of buck converter to get from our LiPo's 3.7V to 5.5V.
The LED wiring is going to be a bit of a nightmare, and reminds me more of keyboard row/column wiring than anything else. we're also going from less bling (12 LEDs) to way more bling (32 LEDs). To support this we will most likely be using slightly large LiPos and a stronger charging circuit this year. I am also very interested in adding the MAX17043 to the board to have a full "fuel gauge" circuit to read battery life. We didn't have one last year and it was annoying.
I've also decided that we're going to remove a lot of the debugging LEDs from the board. There may be spots on the board for them, but I'm probably going to mark them DNP to reduce costs. We'll see what the cost differences are.
So many wires...
That's it for now, see you next week.
Hey! Welcome back friends! It's been awhile! Let's get going again.
We're just getting started this week and we were able to get ChibiOs running on our nrf52840 development board. Now, this is step 1 of about 10,000, but getting to blinky is half the battle and we're there.
Last year we wanted to use the NRF58240. I'm glad we decided not to do a badge last year because the chips were not available in the quantity we needed them by DC26. Aborting was probably the right thing to do.
However, we're very excited about using this chip now. It's available. It's QFN, it's going to be much easier to work with than the KW01 we used for DC25. It's even available in a module and it is quite powerful for the low low price of about $4.90 in quantity.
Dual SPI busses mean we can pump out more frames per second, and built-in I2S mean that supporting clean stereo sound is going to be an achievable goal if we get our analog circuity right. Additionally, having 256KB of RAM (up from last year's 128KB will mean more apps, and more things we can do.
Over the next couple of weeks we will order screens and LED controllers to experiment with, and start to work through the hard problems like "what's it going to really look like?" and "what sort of games will it support?"
We're sticking with ChibiOs because 1) we know it and 2) we liked working with it last time.
We'll keep you posted, and don't worry, we're not going to reveal everything that's coming before DC27.