Trying to keep the updates regular as we continue to push forward.

With the RF interrupt and interference issues behind us, we turned to developing the network spec for exchange of data between the badges. We have some basic ideas for five different packet classes supporting current and future features. We would rather not reveal them all so as not to over-promise anything.

After a weekend of coding on a single core device with no scheduler, we have a new appreciation for the mundane things like networking and multitasking in [fill in your favorite OS]. More on the fails here when we get time to document it properly.

We've implemented two packet types: Hello & Chat.

Hello

This is a simple 11 Byte packet containing the unique node ID and whatever name the user has called themselves in the badge. Periodically the badges will announce themselves to the world with one of these packets. Other badges that pick it up will add it to their list of peers. Understanding this is not the most secure way to do things, we may add some cryptographic overhead in the future.

Chat

A 42 Byte packet that extends the Hello packet and includes a 31 Byte message field. We don't expect users to be typing in long winded novels into the badge, so a short field should be sufficient. 31 Bytes was selected such that the messages don't wrap to three lines in the display.

Seems simple, but we basically had to build a rudimentary IP stack inside the badge complete with ports and a 1 Byte address field. This is on top of the STM32F1's inability to schedule tasks or do any parallelism. Hello and Chat packets appear to be received and processed in the "background" all while the badge is busy doing other tasks such as animation or user input.