Communications Protocol

General Requirements

• The communications protocol shall cover all communication handled through the XBee, including pairing, operation, unpairing, and exception handling between a Quackraft and a Mallard Module. 

  • The communications protocol shall permit any Mallard Module (controller) to effectively control any Quackraft (boat) with which it is paired.

• Interruptions in wireless communication are frequent and occur at irregular intervals, and the protocol should include some robustness against such interruptions.

• Communications between Quackrafts and Mallard Modules will take place over the airwaves using SPDL-supplied XBee radio modules in API mode.

• Each Mallard Module and Quackraft shall communicate with the XBee over an asynchronous communications channel using 9600 baud, 8N1 at 3.3V levels.

• Messaging between Mallard Modules and Quackrafts is limited to 5 Hz. That is to say that a single Mallard Module shall transmit one message every 0.2 s, with the paired Quackraft transmitting one message also during this period.

• Because of the inherent unpredictability in wireless latency, Mallard Modules and Quackrafts must be able to accept any message at any time, and may not have a fixed time window in which they are open to message reception.

• Human inputs, such as button presses and direction changes, may only take effect on the following transmitted message. Extra messages (and thus a greater than 5 Hz message rate) may not be generated as a result of a human action.

• Any other hardware or implementation requirements or recommended practices are left to the Communications Committee.

• The details of the communications protocol will be defined and specified by a Communications Committee, which will consist of a designated representative from each team. The specification must be in a written form and with sufficient detail that someone skilled in ME218 material could implement it.

• The class communications protocol must be defined to support the functional requirements listed earlier in this document. The Communications Committee is free to write a protocol of any complexity that fulfills the functional requirements. If a particularly clever messaging definition reduces overhead while maintaining the required functionality, this is perfectly acceptable. Or, if the Communications Committee implements a superset of the functionally required messaging, that would also pass.

• The communications protocol must define any addressing and packet formats if required.

• The communications protocol shall cover all communication handled through the XBee, including pairing, operation, unpairing, and exception handling between a Quackraft and a Mallard Module. Interruptions in wireless communication are frequent and occur at irregular intervals, and the protocol should include some robustness against such interruptions.