OpenIRT Draft 1, feel free to comment and add suggestions on the discussion group.

1. OpenIRT Draft 1
By Daniel Baek

2. Initial Considerations
• This protocol will most likely entail a single “wire” transmission.
• Our problem, then, become the noise associated with single-wire transmissions.
• We can add additional infrared output, however, this causes more noise then a
single-wire transmission would.
• If we are limited to a single-wire transmission, the protocol must also be
asynchronous.
• Since the only wire is occupied by the data transmission, we must assume that
the devices are set to poll at similar rates.
• We must also take into consideration propagation delays. (Some sort of packet
that includes a start, data, and end packet.)
• If we implement something like this, we will have to take into consideration some
sort of start sequence, end sequence, and bit stuffing algorithm.

3. Balance
• Balance between speed and reliability.
• Should we use some sort of repetition to ensure reliability? (Best-effort)
• Should we use some sort of acknowledgement to ensure reliability?
• How should we implement this?
• What rate is optimal?
• Will the average rate be acceptable for faster devices?
• Will slower devices be able to keep up with the protocol?

4. Proposal
• Using LOGICAL_LOW to correspond to 12.
• By waiting, we can verify that both devices are working correctly if they are able to
power the device before communication starts.
• 12-bit data streams.
• Start and end headers (2-bits each) must be the same.
• Data (8-bit) is in the center.
• First two data transmissions verify that the connection is valid.
• Moore- increment the start and end headers each time a packet has been transmitted.
However, reserve 112 as restricted value for:
• Transmission error:
• Errors are in the form of 0x0FC (error code) | 0x303 (error header).
• 0x3FF- Communication error. Expected Moore output does not match input.
• Data rate.
• 1.008 MHz- Standard frequency for UART (with a baud rate of 9600).