We're the team behind the DC25 Ides of Defcon badge. We're making a Badge for Defcon 27. Join us on our journey!
If you want an idea of what we're capable of and what we did for DC25, have a look herehttps://hackaday.io/project/14756-the-ides-of-defcon-an-unofficial-electronic-badgeWe'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 six months now. The schematic, PCB layout, and BOM are complete, although untested.
The prototype is being manufactured at Macrofab in Houston, TX over the next couple weeks and we're moving on to game design / software and marketing to get our Kickstarter up and running.
Well, I guess we screwed up a bit on part U403. It’s our battery monitor and it’s a single chip solution to monitor battery power. I thought it was going be one footprint but it was another. Never trust SnapEDA!
I’m going to have to switch the footprint to a TDFN-10, 2.5x2.0 mm footprint. This sucks, but we can still use the prototype if we deadbug that chip and test, so we will do that.
I’m floating around Austin,TX right now at #sxsw but we will have a prototype to show you , along with our kickstarter video in a week or two ! If you’re here? Say hi!
I spent most of yesterday doing financial projections for the badge and writing out the copy for our Kickstarter page.
From that copy will come a two-minute script which I will orchestrate in Pro Tools, and then I'll shoot lots of product shots and B-Roll to fill in the timeline.
It's coming along but I'm still working through ideas for the video. Maybe a 1940's newsreel or something campy would be fun given the "bomb" theme. Let's hope it doesn't bomb...
Unfortunately, during all of this I heard back from Macrofab that C506 and R605 were wrong. Apparently we'd placed C506 on the wrong side of the board and the cap wouldn't fit. Because we're doing stereo audio this year we've got a set of large electrolytic caps to sort out all of the audio signals. They take up a lot of board space.
As far as R605 goes, there was some confusing descriptions in the parts order. We're shooting for 0603 parts across the board this year to save space and money. On the 2017 board, we used mostly 1205 parts to make it easier to hand-solder. Now that we own a stereo microscope, I don't really care about size as much. But, R605 had a 0201 pad (doh) instead of an 0603 pad, and that ruined everything.
Side note -- Did you know that a) it's next to impossible to get SMD electrolytics that are smaller than 35V (sure, there are some 16V caps out there but not much smaller) and that b) Most of the SMD aluminum electrolytics derate when they reach 60-70% of their voltage? It's no wonder that you can only get them at 16V. You've got to buy things that are 3x the supply voltage to make them work at all and maintain proper ESR.
You're also not allowed to replace your gerber files at Macrofab if the order has been started. This morning, I cancelled the prototype order and replaced it with new files.
All I can say here is that I would much rather be catching these issues now instead of a month from now when the PCB comes back.
Maybe I should be reading my own post-mortem from DC25 and reminding myself what not to do.
After quite a bit of back and forth with our parts list, including a redesign of the fuel-gauge circuit, I'm happy to announce that our badge prototype for DEFCON 27 was sent to the factory today for prototyping! This is a huge milestone for Bill Paul and I.
This means that our schematic, PCB design, part selection / supply verification, and bill-of-materials are all done.
We're about a month later in the process than I'd like to be, but the prototype that went to the factory is the same board (if it works) that we'll use for DEFCON. That alone should cut out 30 days of work. At least one less spin.
We'll be working with Egan again to make a multiplayer game, and we're looking for sponsorships.
We will be making 500 badges this time, and selling them through Kickstarter. We need to raise about $35k-40k to make this happen, and I think we'll be able to do that as we did a couple of years ago.
The remainder of this week will consist of getting the Kickstarter video together and game design.
I've managed to hand-route the entire board (the autorouter was an evil, evil monster) and get it to pass DRC (design rules check). The first important step in getting our prototype done.
I also spent the last six hours working on the bill-of-materials. This has required me to go back quite a few times and change parts on the circuit board. It's a lot of work.
Most of my changes are things like, "Hey, Macrofab's house parts list has the resistor I want, but it's only available in 0603, so now let's go back and change the board to fix that, because we specified 0805 before."
The takeaway here is: "If you are designing a PCB, get all of your footprints 100% dead-on before you start running traces." Going back and changing things after you've passed DRC sucks and creates a shitload more work to deal with.
Looking at the schedule here I feel like we're about a month late. I had a prototype, in hand (in 2017) around the end of January. The big difference between 2017 and 2019 is that now we know what we're doing, and the operating system is built already. Bill's got that seriously under control and the OS is already up and running on the BMD340.
Having the prior work to fall back on gives us time to work on all sorts of crazy nonsense like the new LED driver code, and
I'm going to throw in some photos at the end of this so you can a) see how crazy the PCB routing is and b) get excited about what we're doing.
Tomorrow afternoon I'm going to start in on the Kickstarter video. That's going to be a lot easier too because I've gotten way, way better at video editing and have better gear than I had in 2017.
I have to say that it's extremely gratifying to get to this point. I almost gave up last week because the routing was so hard.
In March I'm heading to SXSW Interactive/Music/Film in Austin, TX. I hope some of you show up, and I really hope I get to meet up with the Macrofab guys again. It was great to talk to them. If you'll be there, ping me. Let's have a Shiner and listen to some music.
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.