Firmware, dev stack, and programming instructions will be uploaded tonight. For those of you 
wondering about the issues we had this year, read on.

Our original feature set included: 

(1)	Four narratives, one for each Plague. Each badge would be assigned a starting narrative, 
and progress in that narrative would increase your infectivity for that Plague. Solving 
off-badge puzzles and entering keys would unlock branches in each narrative, similar to 
the way Asylum worked last year.


(2)	Plagues would be transmitted via BLE, one counter at a time, when you encountered a 
badge with more counters in a Plague than yours. The pentagram would light up to let 
you know other badges were in range, and you would push the button to complete the 
transmission.


(3)	5 counters in any Plague, plus the completion of that Plague's narrative, would kick off a 
spinning animation for that Plague's LEDs. Completing all 4 Plagues would start a 
breathing animation on the pentagram similar to the solved state of our previous two 
badges.


(4)	Our most ambitious feature was a pair of mobile apps that would act as a display for the 
badge, and all future HFS badges.


We ended up shipping a subset of these intended features. Why? Well, the first surprise 
constraint was space. The narrative for ImpBadge fit inside 20kB, and I never imagined we'd 
move beyond that by a full order of magnitude. The CC2640R2 contains 256kB of Flash 
memory, with half dedicated to TI-RTOS, leaving 128kB for our application. I got the narrative 
for PLAGUEBadge a couple of weeks before the con (well after the production boards had been 
ordered), clocking in at almost 120kB. No problem, I said, I'll just dust off some encoding 
algorithms. After writing a few encoding schemes in Python, I selected the most efficient and 
dicked around with the decoder in C for much longer than I'd like to admit before discovering 
the limitations of heap allocation in TI-RTOS. Lesson learned: embedded malloc is always a lie. 
Our inelegant solution was to include the first part of all 4 narratives on the badge and host the 
rest in AWS.


The second surprise constraint was my inability to get the CC2640R2 to act simultaneously as 
both a BLE central and peripheral device. For months I'd been keeping up with two versions of 
the project: one served a custom GATT profile that interacted nicely with our mobile apps, and 
the other looked at scan response data for Plague information. I completely underestimated 
the complexity of merging the two into a single firmware version before launch. This led to a 
complete rewrite of the project on the 20-hour drive to Las Vegas, with less than a day left for 
testing. We eliminated major features at this point because we no longer had time to integrate 
and debug (PWM, for instance, and timed button input). Our core features were Plague 
propagation and story delivery, and we felt that if we could nail those we could justify releasing 
the badge as planned.


The hasty rewrite resulted in the bugs you saw at the con. The narrative strings were memory-
adjacent, so the busted pointer that tracked story progress worked fine until the end of the last 
story (that is, it appeared to work fine in limited testing). Badges were able to gain more than 
one counter from the same badge because I wasn't clearing the entirety of the scan response 
buffer each time it was checked (despite temporarily blacklisting recently encountered badges). 
Badges were initially able to gain more than 5 counters in a Plague, which led to weird behavior 
when badges encountered each other. Identified bugs were fixed and new firmware delivered 
during the con, except for a particularly recalcitrant bug that replays the Plague update 
animation over and over again (but does not appear to interfere with transmission).


As for the apps: both versions are near complete, sans out-of-band authentication with a 
badge. The badge is supposed to display an authentication code across its LEDs when put into 
pairing mode.  The code would then be entered into the app to authenticate the session. The 
iOS version was submitted to App Store Beta Review the week before the con and approved for 
TestFlight distribution; we've yet to get that far with Android. Until the pre-con rewrite, the 
apps were working with the peripheral-only version of the firmware. With limited time after 
rewrite, I was forced to choose between apps or Plague. I chose Plague.


I am proud of this badge. I think it is a worthy development board for Laird's SABLEX-R2 
module. I think it is fucking gorgeous, and, having gone in with no prior knowledge of 
embedded operating systems or BLE, I'm proud we shipped it. I think @hfs_abraxis's stories 
deserve the repulsion and discomfort of as many hackers as we can get them in front of.
But I am also aware that the feature set is not as deep as last year, the animations not as rich, 
and the puzzles not as integrated. I'm also sorely disappointed that I left Las Vegas knowing 
there were still firmware bugs I wasn't able to resolve in time.


So, now I'm going to take the time I didn't have before to implement our original design, and 
release a golden image of the PLAGUEBadge firmware, with instructions for building the dev 
stack and flashing. I realize not everyone has access to the tools to do this themselves. Next 
year we will release new art and new theme on the same platform (with some hardware 
improvements + SPI flash module). Since we'll be able to forego some of the prototyping and 
dev costs, we'll be able to reduce the cost of next year's badge. We will also be selling badges 
online next summer instead of making you run around the con to find us. Anyone who brings 
me a PLAGUEBadge next year will receive new firmware, with a new game and puzzles specific 
to PLAGUEBadge for DC28.


--Belph, 2019-08-14