Project Logs

Collapse

• Where we at?

  John Adams • 03/28/2019 at 07:08 • 0 comments

  We spent the last few days getting the IS3736 to talk to us in a reasonable fashion (and fixing some fun I2C Bus issues). This is the 32x8 matrix LED driver chip, which saves us a whole hell of a lot of grief, and by grief, i mean the WS2812Bs. Never again. Neopixels suck.

  
  A few LED Animations are running on the chip now, and they look great. I've gotten the 3736's global current control (GCC) working for dimming, and that looks fantastic. 

  We also spent time bringing up the BMD340's flash, so saving configurations is now possible.
  

  On the audio front, the first of two orders of PCB speakers showed up. We're having a bit of a shootout here to see what sounds the best given the limited PCB space, and so far the AST-0108-MR-R seems to be winning. Unfortunately, it's through-hole. 

  SMD ones are coming tomorrow from Mouser.

  Once we sort out the speaker situation, I can put another prototype together with the right artwork, the proper speaker footprints, and move some things around the board to make it look nicer. We do have some minor crashing problems right now, but we're working through them.
  

  Egan just submitted a game spec too, so we're working on that. 
  

  More updates as we have them.

• Prototype is in!

  John Adams • 03/25/2019 at 02:34 • 0 comments

  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...

  Read more »

• That’s what prototypes are for !

  John Adams • 03/15/2019 at 03:49 • 0 comments

  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!

• Prototype is go!

  John Adams • 02/23/2019 at 09:48 • 0 comments

  Hope your weekend is going well!

  We've gotten word back that our prototype has passed the review phase and it's moved into production. Let's hope that our schematics are good and that all of the chips seat properly. 

  We'll know in a couple weeks if we've gotten it right. 

• Errors, and then some.

  John Adams • 02/20/2019 at 20:24 • 0 comments

  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.

  More updates as we have them. 

• And we're off!

  John Adams • 02/19/2019 at 02:47 • 0 comments

  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.

• DRC Passed!

  John Adams • 02/17/2019 at 09:21 • 0 comments

  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.

  Oh yeah! Photos... 
  

  Here's the routing so far. We're doing a 4-layer board here. 

  And here's the 3d view:

• Zero bugs, maybe.

  John Adams • 01/11/2019 at 00:29 • 0 comments

  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. 

  More updates this weekend, for sure.

• Back at it.

  John Adams • 12/09/2018 at 00:04 • 0 comments

  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...)

• Audio!

  John Adams • 10/07/2018 at 22:30 • 0 comments

  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. 

  He reports:

  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:

  https://www.facebook.com/insectoverlord/videos/10156800833524250/

View all 12 project logs