User's Manual

On-Ramp Wireless, Inc. 27 014-0033-00 Rev. H
6 Messaging Protocol
The details of Host/Node messaging are typically not necessary for integrators to implement;
however, low-level understanding of the SPI protocol used may be critical in resolving Host
interface issues. For mid-level details of the messages that may be sent over this interface, refer
to Node Host Message Specification (014-0020-00).
6.1 Arbitration
Arbitration is the process a Host uses to signal to the Node that it supports the On-Ramp
Wireless bi-directional messaging protocol. The arbitration sequence is designed to reduce the
probability that an arbitrary non-Host transfer sequence can mirror a valid arbitration sequence.
Arbitration consists of both Host and Node transmitting an arbitration request/reply pair. After a
defined turn-around delay, both transmit a validation request/reply. The turn-around delay
avoids race conditions between Host and Node and provides enough time to allow ISR execution
to complete before the next SPI transfer.
If the Node does not reply to the Host request, the Host needs to wait for a turn-around delay
and retry the arbitration request.
The Host must perform the arbitration sequence before any other SPI Bus communication can
take place between the Host and the Node.
The Host must initiate this arbitration sequence on boot up. Additionally, the Host must perform
the arbitration sequence when the Node sends to the Host an arbitration message. This can
occur due to the Node going into Deep Sleep and then waking up. Since the Node requires the
arbitration sequence after waking from Deep Sleep and since the Host is not aware of when the
Node goes to Deep Sleep, the Host must be able to detect that the Node is requesting
arbitration and the Host must then reset its Host interface state machine and perform
arbitration. For more information on the Host interface SPI bus state machine, refer to section
6.3: Host Interface SPI Bus State Machine.
6.2 Message Protocol
Host-to-Node transfers use master message command pairs and Node-to-Host transfers use
slave message command pairs. Both transfers use identical command sequences with only the
encoding of the commands differing. The command sequence for a message transfer consists of
a request/acknowledgement pair followed by a defined turn-around delay and then a message
composed of a header pair and a payload.
Variable length payloads are supported by encoding the payload size in the second half of the
message request. The second half of the message reply contains the available receive buffer
size. If the message payload size exceeds the receive buffer size, then a new request must be
made after a turn-around delay with a payload size that does not exceed the receive buffer size.