IR protocol - all comm. is via infrared, modulated ~38.5khz, ~940nm - messages are 13 bits: 1 start/header bit 4 "from" address bits 4 "to" address bits 4 message bits - all bits have a 1ms +/- 10% between them - start bit: 3ms +/- 150us pulse; indicates start of tx, with 12 data bits to follow - databits: binary 1: 2ms +/- 150us pulse binary 0: 1ms +/- 150us pulse - bitmap: S = start bit T = "to" address bits (nibble) (intended recipient of message) F = "from" address (nibble) (who sent the message) M = message bits (nibble) bit: 12 11 10 9 8 7 6 5 4 3 2 1 0 S T T T T F F F F M M M M ms: 3 1|2 1|2 1|2 1|2 1|2 1|2 1|2 1|2 1|2 1|2 1|2 1|2 - maximum tx length would be 3+((13-1)*1ms)+(OneBits*2ms)+(ZeroBits*1ms) or 39ms to send [ start bit + $FFF ] or 27ms to send [ start bit + $000 ] - "to" address $0 is reserved for "broadcast to all" -- all platforms will use and parse messages sent from this address. - interactive language protocol bitmap for message bits. Note that these are structured so that "I am here" type messages are TXed much faster, using fewer one bits: +--------------- 0 = normal message; 1 = platform command | +----------- 0 = acknowledge; 1 = interrogatory | | +---+--- interr or ack message 0-3: | | | | Interrogatories: Acknowledgements: | | | | %00 = please ack %00 = ack; I am here bit: 3 2 1 0 %01 = how are you? %01 = Bad / No / Negative / Zero M M M M %10 = join me? %10 = OK / Ambivalent / Neutral / %11 = leave me alone? %11 = Great / Yes / Positive / One Example -- Robot address $3 just wants Beacon address $1 to "respond". Beacon $1 is a "home beacon" programmed to turn on and respond (acknowledge) *only* when it receives interrogatory $0 from address $3. Beacon $1 repeats this TX ack for 20 minutes. Meanwhile, Robot $3 keeps sending the interrogatory to the Beacon *until* it sees the Beacon's repeating message for the first time. At that point, Robot $3 can stop transmitting and focus on "reading" the beacon's data stream and connecting with the charger. Once hooked up to the charger, Robot $3 sends an "I'm hooked up to you" message, and the Beacon stops transmitting. In bits, it would like this this: Robot $3 has a low battery, so it sends an interrogatory to address $1 (it's "nest"). The 2 bit "message" is %00 -- "please acknowledge" -- the shortest message to send: to from message Robot $3 TX: %0001_0011_0100 Once the Beacon gets a message *for itself* (to address $01) AND the message is interrogatory %00, then it replies to that address with ack message %00: to from message Beacn $1 TX: %0011_0001_0000 There are very few bits in an "ack" -- this lets Robot $3 read the stream more quickly. *Every* platform is required to "ack" a "please ack", but only if the message is FOR THAT PLATFORM or if the sender uses $0 as the "to" address (a global "everyone please ack"). Since this is 'bot $3's nest, only 'bot $3 should be asking it *specifically* for an "ack". In any case, once the 'bot is hooked up to the beacon/nest, it says "shut down, please, I'm here", by sending a "platform" dependent message of %111 (8). to from message Robot $3 TX: %0001_0011_1111 (Or perhaps a non-platform-dependent "please leave me alone" or $11 would suffice, and the nest would never say "no".) The idea here is that interr/ack messages 0-3 are "required" interactions/responses by all the 'bots and platforms in the "fleet". The higher 8 "platform" commands are unique to each platform. One 'bot might accept commands from the master module to "stop", "home", "forward", "wait", while others may have none at all (a beacon, for example); beacons and nests would accept shutdown commands from their "masters", etc. But all platforms are required to respond to, and act upon, "language" messages -- if a platform asks to be left alone, other platforms that receive the message *must* reply (in this case, with a "no", "yes" or "maybe"). Platforms must respond to ack requests (so that other platforms may know "who is around").