We'll update this page weekly, until we launch our Kickstarter, and then updates will be cross posted here and there.
Until then, stay tuned to Hackaday for updates!
Hey, we're back!
We took a year off so we could sort some things out, get better gear, and try again to make a fantastic piece of hardware for Defcon 27.!
Who are we?
We're the team that built the Ides of Defcon, a hackable, wearable, game badge for DC25, that you could fight as a Roman Gladiator with, attacking your friends for points and glory. #badgelife !
We're at it again, building a new badge for DC27. Our badges are rechargable, filled with audio and video wizardry, and for use for you to learn microcontroller engineering and to generally hack on. It's the best thing that you can get your hands on when you've graduated from the world of just-make-it-blink and Arduino.
We're are we at?
We've been working on the badge design for about three months now. As of January 10th, we've got no DRC errors in our schematic, our schematic is finished (for now) and we're ready to take it out to Macrofab for a prototype board. I wanted to have this board done by Jan 1, but the 10th will do!
Our schematic passed DRC checks last night and today I've been bouncing back and forth between Mouser, Digikey, Alibaba, and the MacroFab House Parts List trying to check all of our footprints before we go into PCB Layout mode.
Our BOM currently contains about 133 parts per board-kit, and our BOM cost is much lower than last year thanks to the use of fewer through-hole parts (moar SMD!) and getting away from expensive parts like the WS2812B's.
Speaking of which, it's been pretty difficult to pick a board shape and design! (Dragons? Submarines? Triemes?)
When we did the badge for DC25 the obvious choice was Roman Something... but now that we're a couple years in and DEF CON is going to be spread across multiple hotels again, I don't know.
Because we've got BLE on the badge this year, and I wanted to do a Greek Naval battle game, I'm thinking of making the badge into a ship, but I haven't really decided yet. I think the plan for now is going to be do make it square so we can get our electrical tests done, and if those pass, we'll move on to fancier board designs.
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.
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.
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.