andnxor / sao-reference-designs

AND!XOR Reference Designs for SAOs

AND!XOR SAO Reference Designs

This is where we will publically post our reference designs for SAOs. Some may just be schematics, some may include Kicad projects (depending on the SAO).

I2C Addresses

Type	IC	7-bit address
GPIO Expander	MCP23017	0x20
EEPROM	AT24C32	0x50
REDACTED	REDACTED	TBD

EEPROM

Simple I2C EEPROM SAO based on the AT24C32. All address pins are pulled to GND. Badges that detect the AT24C32 on the I2C bus should query for bytes at known addresses then perform actions.

AND!XOR has adopted the following format for data stored in the EEPROM, we hope that others from #badgelife do too.

0	1	2	3...n
DC Year	Maker ID	SAO Type ID	Data

• DC Year: Use 0x1B for DC27
• Maker ID: Unique identifier for SAO maker, AND!XOR uses 0x49 (Middle 8bits of our registered Bluetooth ID)
• SAO Type ID: Unique identifier assigned by the maker for the SAO
• Data: Arbitrary data parseable by anything recognizing DC, Maker, and SAO values

GPIO Expander

Returning from DC26 we will be using MCP23017-based SAO(s). When the MCP23017 is detected on the bus, the badge will play special patterns. d

sao-reference-designs's Issues

EPROM year is ambiguous

The Readme.md file states:

DC Year: Use 0x1B for DC27

...however Defcon is occurring more than once per year (for example Defcon 1.0 is in Beijing in the year 2019.)

The flawed EPROM identification design seems to assume that all Defcon occurrences outside of Las Vegas are invalid? Let's fix this, but how?

Implementation

I'm about to implement your AT24C32 based design for DC 1.0 (Beijing), so it would be great to help me avoid hundreds of loss or a flawed identification config.

EEPROM Data for GPIO Expander

I propose that bytes 3 and 4 of the data section be used to signal the direction of the GPIO expander pins, so that badges with LED flashing code will not set inputs as outputs, and potentially short the badge via a button. Something simple where each bit represents an IO pin, and 1 represents output, 0 represents input.

Additionally, byte 5 could be used to signal the "advanced functionality" of the GPIO pins (namely, their input/output/NC status, if they are set as UART, or if they are part of SPI.

I apologize if this is the wrong place to submit suggestions for SAO1.69BIS.