This first requires the HC-05 devices to be configured as a master-slave pair set to auto-connect to each other.
The HC-05 adapter communicates over RS232 protocol (~3.3-7V Vcc [internal ldo regulator to support wide range of supply voltages] and 3.3V IO). It has two modes; normal operation and AT mode. AT mode is used to configure the device.
To enter AT mode, the enable pin must be held high (usually by holding the button but can be driven by external logic) while the device is powered on. Once it is in AT Mode, it operates at 38400 baud, 1 stop bit, no parity. Each AT command is sent over serial to it and must be terminated with "\r\n". We must first configure the master and slave devices and pair them. The devices come configured by default in slave mode with pin "1234"
(write down address, we will need it later)
"AT+BIND=[enter address of slave here]\r\n"
Then connect the Vcc and GND pins of each device to the Vcc and GND pins of the badge, and the TX and RX pins of the device to pins C13 (RX) and C14 (TX) of the badge, respectively. Then enter the following 8 lines of basic into each badge's interpreter
10 x = uin 0
20 if x = 0 then goto 40
30 chr x
40 y = kin 0
50 if y = 0 then goto 10
60 chr y
70 uout y
80 goto 10
This basic code performs the following pseudo-code:
x = pollUartRX_NonBlocking()
if x != null:
y = pollKeyboard_NonBlocking()
if y != null:
Because the UART implementation in the firmware doesn't seem to have any fifo buffers on the RX or TX side in memory (which is odd because normally they do), and BASIC doesn't support multi-threading, this code side-steps the problem of how to simultaneously send and receive data by counting on the fact that human input is slow enough and the button/uart transaction valid long enough that simply alternating the tasks will catch both data streams without dropping packets.
This is really neat, I love the idea of being able to chat over the badges during the conference :)