Note that synchronization occurs at the discretion of the Device - the Host does not even know whether
the Device is synchronized or not. This means that some Devices can operate in asynchronous mode at
the same time as other Devices are in synchronous mode.
Gazell does not lose any data when the Host and Device eventually drift out of sync - it merely leads to
more retransmissions until the Device is able to sync up again. As soon as a retransmitted packet is
acknowledged, the Device will use the arrival time of the acknowledgement to adjust its
synchronization. So this is an imprecise sync mechanism where power and latency are saved whenever
the protocol is in sync, but the protocol is still working fine when we happen to be out of sync. We call
it "semi-synchronized mode".
Robust against interference
Gazell can be configured with frequency agility or frequency hopping to avoid interferers. "Frequency
agility" means that the protocol stays on the same frequency channel as long as there is little
interference on that channel. When a channel is quiet it makes little sense to switch to another
channel. The new channel is more likely to have interference than the current channel, so
unconditionally switching channels for each packet would increase the average number of
transmissions and thus the average power consumption and latency.
"Frequency hopping" means that that the protocol changes channel for each packet transmitted. This is
required by some radio regulations to spread the radio power across the spectrum when power
amplifiers are used to increase the range of the radio.
Gazell itself will cause little interference for other 2.4 GHz radios since the protocol does not need to
send packets to maintain a link. Gazell is only active when there is data to send. This also gives little
interference between Devices talking to the same Host. (These Devices have no knowledge of each
other and operate independently of each other.)
The size of the channel table is a trade-off between latency and robustness. Having a large channel
table gives us the option of trying many channels from the 2.4 GHz band to find a quiet channel. But
this means that the Host and Device need more time to find each other and consequently more
transmissions per packet, increasing power consumption and latency.
Gazell has configurable channel tables. Experience has shown us that having three to five channels
spread out in the 2.4 GHz band is a good compromise, giving very low latency and maintaining good
immunity to interference.
Low latency and high report rate
The perceived responsiveness and accuracy of a Device like a wireless mouse depends on the sample
rate and resolution of the optical sensor, but equally on the report rate and latency of the radio
protocol.
Gazell is a simple protocol with little protocol overhead and, combined with 2 Mbits/s data rate of
Nordic Semiconductor radios, we get high report rates.
Gazell achieves low latency by two means: asymmetric duty cycles and semi-synchronization.
Asymmetric duty cycles means that the Host can be configured to always listen while the Device only
has to send whenever there is data. Therefore the Device does not have to wait for the next listening-
slot on the Host before starting a transmission attempt.
The semi-synchronized mode described earlier also helps to achieve low latency, since when we are in
sync the Device will hit the correct channel and channel time-slot at the Host every time.
Simplicity
Using the Gazell protocol is easy. Since the Devices in a Gazell star network do not know about each
other and there is no co-ordination between them, setting up the Devices becomes very simple.
There are no special connection setup packets - all packets are data packets - and Gazell has no need
for packet headers of its own. We do not need send link packets at regular intervals to maintain a link.
页码，3/64nRFGo SDK: RF protocol
2011-12-23file://C:\Documents and Settings\Administrator\Local Settings\Temp\...
- 1
- 2
- 3
- 4
- 5
- 6
前往页