Hello! It's been a couple of months since we've posted here, but here's some fun technical tidbits for you to think about. Our generic postings have moved to out Kickstarter Updates, but I'll try to keep the more technical ones here.

I've written and rewritten the networking code about five times for the fight game.

The last attempt, which I am still on now has taken about three weeks of off and on, but very serious critical thinking. What have we learned?

Well, first off, you should be very grateful that you get to use TCP/IP on the Internet every day. It is a remarkably well designed protocol and has served us well for many years. When you are attempting to recreate the same protocol on a tiny 48Mhz system with barely any stack space or RAM (16KB, OMFG.) you learn to appreciate what you have in your average TCP/IP stack.

Currently the protocol on the badge could be described much like TCP/IP, minus, well, the good stuff in TCP/IP. We don't have the RAM for sliding window ACKs and generally our protocol is closer to Stop and Wait ARQ. As you may know from your college networking textbooks (I had to go back and read mine), SaW ARQ is very inefficient but can be written with a very small memory footprint.

Our protocol is "Stop and Wait ARQ, with Time Outs (TO), and a small (four packet deep) Circular TXQueue."

Writing that was hard, but writing a version that played nice with our graphics was harder.

Things I would have done differently;

1) Move packet handling to a different thread. I did it in the game thread, this was stupid.

2) Written my animations in a way that didn't impact networking.

Okay, this right here is the #1 reason our badge had problems. Because to do animations I would paint a frame and then do a chThreadSleep() -- Nothing in your device should go to sleep if the same thread is processing the damn network. DO NOT put your thread to sleep, you will drop packets and life will suck.

3) Written in the txqueue ring buffer in from day one. Only being able to have one packet in the queue was killing us, but needing the queue at all was an indication that Stop and Wait really wasn't Stop and Wait. We needed the txqueue, because sometimes we have to tell one badge more than one thing in a row (i.e. "I have moved, and after you get that understood this game round is over.")

In any event, we now have some very nice radio networking code that works well on ARM machines. The fight sequences are fast and tight, and for the most part the badge doesn't deadlock anymore waiting for moves. We're still torture-testing the badge though and will probably have a few more sets of changes before DEF CON.

*Crosses fingers* I think I got it this time.