nRF24LE1及nRF24LU1+的GAZELL跳频协议_STM32F103C8T624L01资源-CSDN文库

4星 · 超过85%的资源需积分: 33 91 浏览量 2011-12-23 09:44:20 上传评论 5 收藏 631KB PDF 举报

资源推荐

资源详情

资源评论

RF protocol

[Firmware]

The Gazell protocol has a common code base and porting modules for the supported modules. This

common part of Gazell is written for an 8051 MCU. Apart from this, it is hardware independent.

Hardware dependency is ensured by HAL modules (Hardware Abstraction Layer (HAL)) and the

porting modules. HAL is used for the RF tranceiver, while the porting modules ensure that the special

needs of the protocol not reusable for other projects, are met.

The table below provides an overview of the RF protocol firmware modules available for the nRF24LE1 /

nRF24LU1+ radio MCUs.

Generated on Tue Mar 29 2011 13:46:12 for nRFGo SDK by 1.7.2

Gazell Link Layer (gzll)

[RF protocol]

Link layer for the nRF24L01+ radio.

Contents

Introduction

l Roles in a Gazell star network

Properties of Gazell

l Protocol states

l Protocol timing in Gazell

Pipes and addresses in Gazell

l Configuration

Application Programming Interface (API) for the Gazell Link Layer

Main Page Modules Index

RF Protocol modules Description

Supported

devices

Gazell Link Layer (gzll) Link layer for the nRF24L01+ radio.

nRF24LE1 QFN24

nRF24LE1 QFN32

nRF24LE1 QFN48

nRF24LU1+

Gazell Pairing Library (gzp)

This is a library for adding dynamic pairing

functionality to an application using the

Gazell Link Layer.

nRF24LE1 QFN24

nRF24LE1 QFN32

nRF24LE1 QFN48

nRF24LU1+

Main Page Modules Index

页码，1/64nRFGo SDK: RF protocol

2011-12-23file://C:\Documents and Settings\Administrator\Local Settings\Temp\...

Introduction

Gazell Link Layer is a library with functions for setting up and configuring the link layer of a wireless

desktop or other wireless applications. The Gazell Link Layer replaces the earlier Frequency Agility

Protocol from Nordic Semiconductor. In the rest of this text we will shorten "Gazell Link Layer" to

"Gazell".

Each Gazell node can be configured for communication with up to six other Gazell devices in a network.

Each node can transmit and receive data. Networks with more than seven (1+6) nodes can be set up

to work with Gazell, but no Gazell node in the network can know more than six other nodes.

For the sake of simplicity we will in the rest of the help file assume that we have a star network with

one Host node and one to six Device nodes. With this network it is very easy to write a wireless

application using Gazell, since no network layer will be needed on top of Gazell. Setting up addresses

and channel tables is also very simple for a star network.

Roles in a Gazell star network

In a simple Gazell star network we have two static roles: Host and Device. There will be one Host and

one to six Devices in the network. This is a typical wireless desktop configuration where no role

switching is ever required - there will be a "dongle" that is always a Host, plus a mouse, keyboard and

other input units that are always Devices.

A Host mainly receives data, but can still send data back to a transmitting Device by piggy-backing

data onto the acknowledgement packets returned to that Device.

A Device mainly transmits data, but can still receive data in the acknowledgements returned from the

Host.

It is always a Device that initiates a data transfer. This means that a Host has to wait for a packet from

a Device before it can send anything to the Device. Note that it is still possible to fulfill latency

requirements for Host to Device traffic (like a command from the PC to turn on the caps lock LED on a

keyboard). The application on the Device side will just have to send dummy poll packets at regular

intervals to the Host. The Host will then return any pending data in the following acknowledgement. In

a typical desktop application the Host to Device latency requirement is usually so relaxed that such a

poll will not consume significant power.

Properties of Gazell

Low Power

Gazell is a protocol designed to minimize power consumption. For applications like wireless desktops or

remote controls where the power capability on Host and Device are very different, Gazell will operate in

an asymmetric mode where the Devices draw much less power than the Host.

In this mode the Device is free to send data at its own discretion. A remote control will for instance

only send each time a button is pressed. All "protocol smalltalk" just to maintain a link is thus avoided.

This minimizes power on the Device side at the cost of more power on the Host, since the Host will

have to always listen.

In battery-to-battery operations, where power saving is equally important on both Host and Device

side, Gazell can be set up in a more symmetric mode where both Host and Device have a low duty

cycle. In this case there is a trade-off between latency and power consumption. The longer latency one

can accept, the lower the power consumption will be. This tradeoff can be configured by Gazell.

To minimize power and latency in applications with high report rates, Gazell also has a semi-

synchronized mode. This mode needs an accurate system clock on both sides. This mode does not use

power-wasting synchronization messages to keep Host and Device in sync. Instead the Device uses the

ordinary acknowledgment packets to synchronize its transmission channel time slots with the Host

whenever an ACK is received.

页码，2/64nRFGo SDK: RF protocol

2011-12-23file://C:\Documents and Settings\Administrator\Local Settings\Temp\...

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\...

Gazell protocol states for a Host

Note that for a star network the Host should only be in the states IDLE and HOST. If a Host application

calls gzll_tx_data() the Host will enter the DEVICE state and switch roles and become a Device. Then

we do not have a star network any more - just a set of unconnected Devices.

Gazell supports two HOST-state modes:

l Mode 0: low latency mode

Mode 1: low power mode

In low latency mode the Host listens continuously. Each channel in the channel table is monitored in a

rotating fashion. This mode is used when the Host has ample power and when low latency for Device to

Host data is important.

In low power mode the Host radio is in POWER DOWN or STANDBY between listening periods. In each

listening period, the Host listens for a short time on one channel. Then the Host goes to sleep for a

while before listening on the next channel. This gives less power consumption on the Host side than for

low latency mode.

In asynchronous mode (see below) a Host in low power mode means more transmission attempts and

thereby longer latencies and more power consumption on the Device side. However, in semi-

synchronous mode the Device will be synchronized to the short listening periods of the Host, so we do

not waste transmit attempts and power at the Device side. (But we will still get increased latency.)

Low power mode is used for battery-powered Hosts and when a Host is in standby mode. It is normal

for a Host to switch between the low power mode and low latency mode. A Host like a USB-dongle for

a wireless mouse will for instance be in low latency mode when the mouse and PC are active, but will

switch to low power mode when the PC is inactive and the USB-dongle enters SUSPEND mode.

DEVICE state

In DEVICE state, the protocol sends data. Gazell enters DEVICE state with the function call

gzll_tx_data(). Gazell handles re-transmission of lost packets and channel changes to avoid

interference. This is transparent to the application.

页码，5/64nRFGo SDK: RF protocol

2011-12-23file://C:\Documents and Settings\Administrator\Local Settings\Temp\...

剩余63页未读，继续阅读

评论收藏

内容反馈

zzytyy1023

2012-11-16

很好的资料，谢谢，看得比较吃力
zoudejile

2012-10-30

有助了解而已，实际项目用处不大
老班-智勤

2019-06-03

不确定怎么样，研究研究看了，反正很贵
zhylun

2013-06-24

学习中，希望能有所帮助！
Daveee

2012-08-21

不是很清晰，学习一下

前往

页

xiaohua4758

粉丝: 13
资源: 16

nRF24LE1及nRF24LU1+的GAZELL跳频协议

跳频协议--nRF24LE1及nRF24LU1+的GAZELL跳频协议.rar

Gazell协议

NRF24LE1的跳频协议Gazell中文详细资料

nRF24LE1双向通讯

基于nRF2401软件跳频协议的设计与实现

基于跳频收发系统中的跳频频率合成器设计

nRF24LU1无线鼠标源代码.

NRF24LE1摄像头无线数据传输调试心得

nRF24LE1无线模块矩阵键盘实现源码

nRF24lu1+与nRF24le+ SDK-v1.3开发包

nRF24lu1+与nRF24le+ SDK-v2.3.0开发包

nRF24LE1 32脚 原理图及PCB

nRF24LE1，nRF24L0学习资料

基于AVR的NRF24L01跳频通信程序

nrf24l01跳频

nRF24LE1的通过无线更新固件例程

nRF24LU1无线鼠标代码

nRF24LE1实验例程

RF24L01 C51程序

RF24L01中文详细资料

nRF24LE1信号采集程序

nrf24le1无线温度测量

nRF24lu1+与nRF24le+ SDK-v2.2.0开发包

nRF24LU1_nRF24LE1_SDK

NRF24LU1 NRF24LE1各种封装引脚对应图表

NRF24LE1E 遥控发射接收完整项目程序（含发射和接收）

nRF24LU1无线鼠标源代码

nRF24lu1实现无线鼠标程序

最新资源

nRF24LE1 32脚原理图及PCB