Related lists

Description

We're building our own electronic badge. Goal is to provide some great hardware and a free tool chain for easy hacking.

Basic features include LEDs, RF, and an OLED screen plus anything else people want to add.

Details

WHO:: We are 3 dudes from California with backgrounds in HW and SW engineering. We enjoy building and hacking things for fun.

WHAT:: We built a hackable, open badge for use at DEFCON 24 in Las Vegas and any other conferences in the future. The badge also serves as a dev board for hardware developers of any experience level from novice to expert sorcerer.

WHY:: The purpose is to put some really awesome hardware around the necks of a bunch of hackers and see what they come up with. We hope to encourage others to make use of the badge and come back with their own flavor in years to come, AND to promote embedded development across the community.

HOW:: Pure internet science. We've developed algorithms which calculate the spin rate of cat quarks for generating our ssh keys at a rate of (P+9)/((# of blackberry users)^2), where P is the probability that a cat will leave a house when a door is opened for them.

WHERE:: Paris Hotel, Las Vegas

WHEN:: August 4th - August 7th, 2016

EXTRAS:: We are spending our free time and money outside of our busy work schedules to develop this from 3 separate locations across California. So we are definitely open and encourage feedback, suggestions, and features to be added onto the badge. If you complain that there are not enough blinky's happening then you are welcome to build your own. Feel free to Leave your comments below if you have questions, concerns, comments, philosophical statements, haiku's, or send us a tweet...that works too.

Twitter:: Check out AND!XOR, our official twitter account on twitter for daily and often hourly updates of the badge process.

Project Logs

We are blown away by the popularity of our unofficial badge. Our goal was to put a badge in people's hands that we liked and hope that others like it too. We've been putting a lot of our work out in the public to ensure enough people know about it before DEF CON that we can make our money back on production. We hit that goal and even a little above it with some donations from various folks. We are pouring the extra into next year's badge to help do things right and seed some of our development. At one point we had about 300 people lined up to buy 70 badges. Watching the elevators on the 9th floor open at once and seeing everyone poor in was humbling. We really wished we had more and were disappointed not everyone could get some.

Our favorite comment we received from owners of the badges was the fact that they had difficulty walking around the conference without being stopped. Sorry everyone! We were stopped a lot too but that usually led to some great conversations. We went home with tired feet and no voices but we wouldn't have it any other way.

Next year we won't be hand assembling, nor will our learning curve be as steep. Our team is already brainstorming what to do. Right now the ideas are grand, eventually we'll narrow it down and start our design but for now it's all about big ideas! We also plan to do a run of a lot more badges.

In the near term, you won't see anything from us on development. We'll probably startup another hackaday.io page for DC25. We'll be quietly brainstorming and doing proofs of concepts in between real-life responsibilities. DC25 will be bigger and better.

It's DEF CON week! We finished production of the badges over the weekend and have packed everything up. We'll be bringing spare parts and tools for the possibility that a few Benders break during the conference. Looking forward to seeing everyone there!

We've wasted so many hours fixing radios and LEDs on dozens of badges, turns out we were able to fix through software. We've posted some details on Twitter and complained/celebrated in IRC over the past week but wanted to write down exactly what happened.

Radio

Roughly 20% of all badges were having radio failures on startup. Through some built in debug features in code we could easily see the PLL was not locking on these badges during startup. Very strange behavior. In some cases this was due to a loose load capacitor for the radio's 32Mhz oscillator. Easy fix, but not enough on most of the failed radios. We then discovered that the radios on failed badges would start after a flash (about 30 seconds from cold startup). Turns out our badges were starting to quickly and not allowing the transceiver to startup in the radio. Moteino DualOptiboot has a similar fix and sets a delayed startup fuse. Updating our bootloader has since fixed a dozen badges. We tried adding a delay during setup() in the main badge code, sadly this is too late in the execution. The delay needs to occur very early in the bootloader.

LEDs

40% of assembled badges were having LED failures. We're using WS2812B LEDs (at least that's what we ordered) that require specific timing. In code we bitbang to send the colors and meet the timing requirements. No issues during prototyping or the first 20 badges. Until we ran out of LEDs and switched to our large batch from China. We should have known better when the reels came labeled as WS2815B. Most of the badges with these WS2815B failed. Usually the left eye (LED #1) would work but 2-8 would flash or show full white randomly. Our fix was to desolder the left eye and replace with a new LED. Most of the time this fixed it as the LED would get a better connection to the pad.

Ultimately the fix was in software. Our timing of the 1s and 0s to the LEDs was just outside spec. The higher quality LEDs easily dealt with it but not the WS2815Bs. We've messed with the High/Low timings in code before but nothing helped. Eventually we tried lowering the latch time to 45usec, suddenly all the broken badges worked! 17 badges off the rework pile and into the complete pile.

Production was in full swing over the weekend. We started Friday evening and continued into the afternoon on Sunday. Once the solder-smoke had cleared, 15 bling badges were completed, all main badges had been reflowed and assembled. Of the main badges 36 have been fully tested and set aside for final badge code flashing and kitting.

During the evenings I will be reworking badges that failed testing and running each through full functional tests.

We made a couple minor tweaks to the firmware so that will need to be flashed on all badges during kitting.

If you've been following us on Twitter (@ANDnXOR) production of the final badges has begun. The goal is to produce:

100 White Badges

20 Black Badges

50 White LED-only "Bling" Badges

This upcoming weekend the three of us will converge on San Diego and spend the weekend furiously soldering, flashing, and testing badges. To help ease the workload we have started production a little early. To date, we have reflowed 60 white badges with 22 of those fully assembled and flashed. This has helped us work out the physical space and process required to pull this off.

If you follow us at all on Twitter, you've probably heard us complaining and celebrating success with the RFM69 radio we're using on the badge. Through many frustrating hours of tedious debugging of the radio's registers and a lot of trial and error we believe we've narrowed down an issue related to production of the radios themselves.

Issue: Occasionally we would notice the badges unable to receive data. It turns out the radios were getting stuck in a frequency synthesizer mode waiting for PLL to lock. RFM69 has an automatic sequencer (that we're using) that does the job of walking the radio through standby, receive, synthesizer, etc modes as our application switches it. Frequency synthesizer is an intermediate mode between standby and receive. According to the data sheet the radio should spend about 60 usec in this mode before jumping to receive. In our case it was getting stuck.

Hours and hours of debugging lead us to be able to recreate the issue (cycle the badge several times by removing the battery) and detect the issue (opmode = synthesizer and irqflags ready = 0). Every register we tried to manipulate to get it into a receive mode failed. Even re-initializing the radio failed. As a workaround the badge now detects the issue on startup and prompts the user to cycle the badge by removing the battery. Not ideal, but it works.

Eventual Solution: Over the past few months my four year old has become interested in what I've been working on. He likes to watch the animations and flashing lights. This past weekend I let him play with it only to have him drop it on the floor. Upon picking it up and restarting, the radio failed every time it was restarted. I inspected the radio and found this:

Notice the capacitor is dislodged from one of its pads.

After fixing the capacitor the PLL lock failure went away. I wasn't able to repeat anymore either. Not even once after many battery removals. This leads me to believe the dislodged capacitor is a load capacitor for the 32mhz crystal (also pictured). Without it, the radio doesn't have a good reference clock and can't lock.

We've started producing a few of the badges now for DEFCON. Part of the production process includes a functional tests of each component. The third badge produced came up with the PLL Lock error when first booted. Upon inspection, its capacitor was also dislodged. It turns out the next four radios inspected also have this issue to various degrees. Most are good enough. There is clearly a manufacturing QA issue here.

Fortunate for us, this is a simple fix. The capacitor is extremely small but doesn't take much work with a soldering iron to straighten it out.

Over the weekend we took two prototype badges (rev 2 and rev 3) to Layer One in Los Angeles. This was our first time at the conference and enjoyed the small size compared to DEFCON. Throughout the conference and Saturday Night activities we sported both the Layer One badge and our Bender badges. This was as much of a test of how well they performed as much as an early peek to folks at the conference.

The badges were great conversation starters, people were very impressed with the OLED screens and animations. We also identified a fair number of bugs we haven't seen before, the biggest being random freezes.

Revisions 1 and 2 of the badge had noise issues related to the layout of the board. This would make the badge seem to be deaf. What we also found was that revision 3 also would occasionally drop packets although with much higher gain due the hardware being fixed. In addition we determined that the badges could not pass data if within 10 feet of each other. After hours of debugging and monitoring registers in the radio we found a race condition during initialization and misuse of a sensitivity setting that was reducing the dynamic range by about 8dB.

While frustrating, this is very good news. The software fixes we employed for the dynamic range and race condition issues have improved the reliability of the radios immensely. Even on revision 2 which has the hardware issue and has about a 35dB loss it is able to send and receive data with no issue (at reduced range).

At one point we were leaning towards dropping the radios and social features from the badges altogether. Even with revision 3 we couldn't send / receive data reliably. Fortunately that won't be happening.

The month of April was spent developing the final design of the badge. We just completed the third revision and are confident in the design. We are ordering an initial round of 20 PCBs to perform a final validation before placing an order for the remainder. The 20 PCBs will serve as the special badges for friends and will be in a different color.

The focus now shifts completely to software and production. Software has reached 4000 SLOC and using about 75k of the badge. All hardware components are fully integrated and in use. The badge now includes a 2MB SPI flash chip, of which we are using about 200kB for animations, graphics, and settings. USB is fully functional and we routinely flash the badges over USB. Although, debugging over USB is difficult so we keep our USB to Serial adapters close by.

As far as bling goes, the badge has 14 different animations utilizing the display and LEDs with a few more planned.

As recently as last week we added a basic shell that runs over serial or USB for control of the badge and additional user interactions. There is something oddly satisfying seeing a terminal prompt come from an embedded device.

Since the last update, we've added a light sensor (to save power by dimming the LEDs) and a tilt sensor that flips the screen. This will make the badge useable when worn around the neck.

Next major features to add to the badge will be to build upon the social features and games (several planned).

On the production front, we have about 1/3 of our material in hand. Capacitors, resistors, flash chips, displays, tilt sensors, and crystals. With last of our capacitors and buttons in route.

Finally, we've produced three revision 2 badges that will be headed to Layer One in Los Angeles at the end of the month. Looking forward to showing them off.

Build/Deploy Instructions

Connect badge to USB while holding the "Down" button -or- Hold the "Down" button, press and release the reset button, then release the "Down" button. A red LED light on Bender's mouth will flash.

Click "upload" in IDE

Profit

64-bit Linux Notes

If you receive this error on Linux, ".../Arduino/hardware/Arduino_STM32-master/tools/linux/stm32flash/stm32flash: No such file or directory" while trying to upload it is likely due to missing 32-bit libraries.

To fix on Ubuntu, i386 support needs to be installed for several libraries:

Parts: There is a list here, but there is missing a 100 ohm resistor, the board shows 18pf caps for the clock (list shows 22pf), and one other detail: Where do all the parts go? What I did to figure this out was to use the schematic, pictures, and this: https://hackaday.io/project/9064/gallery#770ed9cfb15937bacc7f50ca59da9091Alightment of the LED, the green end goes towards the top of the board. I also came up with this to help: http://imgur.com/5Q0Ih8P (fixed thanks to @yaakov_g)

Check for bridges when you solder in the cpu, then check again, oh yeah CHECK FOR BRIDGES! All angles, magnifing glasses, flashlights, whatever it takes. My first cpu died when the magic smoke left it because of a bridge.

Where to get the parts? I used Mouser and Digikey for the majority of the parts. The radio and usb connector came from Amazon, the display, antenna, and reset button came off of ebay. The tactile switches came from my junk box.

Assembly:I divided the board in to three areas: the mouth, eyes, and head. I put the surface mount components on the mouth and head first. The cpu was next, followed by the rest of the eye section. The tilt switch and radio were next, then the display and tactile switches. The usb connector was last, for me since I couldn't find an exact match for what was used on the original, I removed the tabs that were on mine and used a pin to tie one side of the connector to the board for stabilty. Last part was the battery holder.

I also put a set of header pins to make selecting the programming mode easier, for everyday use, temporarily jumpering the pads should be good.

So you checked 348 times to ensure there are no bridges, put the batteries in, if there is no smoke, you most likely did good :)

Programming:I used one of these: CP2102 Module STC Download Cable USB 2.0 to TTL 6PIN Serial Converter For STC (https://www.amazon.com/gp/product/B009T2ZR6W)It just so happens it will plug right into the programming header on the board, I held it in place when I did the flashing of the bootloader. Janky? Yes, but it worked just perfect. I used a ubuntu vm to program the board, it was easier to just use the linux tools that were provided that way.

Bootloader: ANDnXOR_Badge-Bootloader.bin found in the Provision directoryUsing the CP2102 and having the top two pins of the boot pins jumpered or shorted will get you in to the mode so you can flash the bootloader.You can find stm32flash in the tools directory for you os (ie Arduino_STM32/tools/linux64/stm32flash/ for 64bit linux)../stm32flash -w ANDnXOR_Badge-Bootloader.bin /dev/ttyUSB0

Badge code: ANDnXOR_Badge-Human.bin found in the Provision directoryI moved my jumper to the middle and lower pin on the boot pins when I did this part. The dfu-util program can be found at in the tools directory for your OS in the dfu-util directory. If you are using virtualbox, you will need to "connect" the badge usb device to the vm. If you can't see the device (check device manager on windows or if on a linux box, check dmesg), check your board, check the resistors near the usb connector (that was my issue, the 1.5k wasn't).While connected to USB:dfu-util -D ANDnXOR_Badge-Human.bin -d 1eaf:0003 --intf 0 --alt 2

NAND load: ANDnXOR_Badge-Flash.bin found in the Provision directoryThis is also done while connected to USB. It was very slow for me, you should see a percentage progress counter when it is working. It took a couple of tries for me to get it to run, but it finally did../flashdata.sh /dev/ttyACM0 ANDnXOR_Badge-Flash.bin

I have to say it is an awesome badge, I had it with me at DerbyCon this weekend and had at least 8 or 9 people ask me about it, how to get it, and/or how to make it. Great job guys, can't wait to see next year's badge. One thing, please add a power switch :P

First off, this project is super cool! From the pictures I've seen here and on twitter, I'm very excited to see bender in action! I'm also excited to see what extra functionality others add to it.

A couple friends and I developed a badge a few years ago for defcon 19, so I understand some of the stress involved getting this ready for the con, but it also reminded me of all the fun involved with making something for DEFCON, so I'm working on a last-minute hardware add-on for your bender badge in the shape of a cigar. I finally got a proof of concept for my idea breadboarded and working with a maple mini clone, so I'm going to attempt to send a design out for fab in the next day or two...or just etch a few boards myself. My question is, what's the distance between the right button of the 4-way setup and the single button on the right (pic to show what i mean http://imgur.com/gfXzafl). I want to make sure my board will fit in between.

I'll probably have a few more questions as I continue to develop the software to go along with this. Are you planning on uploading the firmware to github before the con?

Thanks in advance, and good luck with the software updates and remaining soldering!

If one wanted to run in parallel to port a library over to the badge - what dev board would be best for me to grab? FastLED already runs on a couple of stm based boards - it'd probably be a fast port to get it spun up with this chip.

We're using STM32Duino (http://www.stm32duino.com/) to make the barrier of entry very low for users. Honestly, we weren't very impressed with FastLED, the compiled size was very large. Ended up fixing an older Maple port of the Adafruit library for STM32Duino - link to our github is on this page.

Good dev boards are the Maple Mini clones on Ebay. They are very cheap. The major difference from the badge is that we are using the native STM32 port numbers (PA3, PB9, etc) rather than the Arduino-like numbers (1,2,5,etc) that are on the silkscreen on the clones so you'll need to do some mapping.

Finally, the components we're using on the badge will ride on SPI2. Most Arduino libraries simply refer to "SPI" which in our case means SPI1, this will minimize porting efforts.