原地址https://devzone.nordicsemi.com/b/blog/posts/intro-to-shockburstenhanced-shockburst
Wireless PC accessories (the ones that shipped with a dongle in the box) overwhelmingly adopted 2.4GHz radios because these radios offered an attractive trade-off between power consumption, throughput, and range. Nordic Semiconductor's devices were very successful during that time and, as a result, many devices still use the legacy ShockBurst (SB) packet format that Nordic introduced sometime around 2004. This isn't too surprising because SB is just as useful today as it was then; low-level access to the radio offers performance and flexibility that protocols such as Bluetooth Low Energy (BLE) cannot match. Not only is SB compatible with the same radio as BLE, contemporary Nordic devices allow the firmware to use BLE and SB concurrently.
Here is an overview of the radio:
- GFSK modulation
- 2.4GHz ISM band
- 250kbps, 1Mbps, or 2Mbps baud rates
- Up to 20dBm transmit power (typically not more than 4dBm)
Comprehensive SB documentation can be found in the data sheets of legacy Nordic devices.
The Packet
The SB packet format looks like this:
Although this format uses the radio very efficiently, it doesn't provide any extra features. For example, both sides of the link need to be configured to use the same payload length before transmitting anything because the payload length is not specified anywhere in the packet.
Enhance!
Changes were soon made to the original SB packet format in order to allow the hardware to do some additional processing. The new format is referred to as Enhanced ShockBurst (ESB):
In addition to making the CRC field mandatory, a Packet Control Field (PCF) was introduced:
The new payload length field, packet ID, and an acknowledge bit mean that payload lengths can be dynamic, packets can be acknowledged by the receiver, and unacknowledged packets can be automatically retried. If an acknowledgement is required then it can contain a payload in order facilitate bidirectional communication. Note that acknowledgement payloads must be preloaded; it is not possible for a transmitter to send a command and receive a direct response to that command in the acknowledgement. Instead, the response would have to be preloaded so it could be sent as the acknowledgement for the next command that is received. Preloaded acknowledgement payloads are required in order to guarantee that acknowledgement timing is deterministic.
Timing
The amount of on-air time that is required to send a particular packet is primarily determined by the packet's length and the baud rate that is being used. Additionally, radios have a ramp-up time that is required whenever the radio switches mode (e.g. from disabled mode to RX mode). The nominal ramp-up time for SB is 130us. This means that when an ESB transmitter requires an acknowledgment it must wait 130us after the packet is sent; during this time it switches to RX mode and the receiving device switches to TX mode. Presumably, both devices would then spend another 130us switching back to their original modes after the acknowledgement is sent.
Going Forward
Prior to the nRF51 series the ESB acknowledgement process was performed in hardware without CPU intervention. However, the increased flexibility that was required for BLE also forced the hardware to give up this optimization. The micro-esb library has been created by the Nordic support team as an example of emulating SB and ESB on the nRF51. [Update: Formal, source-level ESB support was added to the nRF5x SDK. See the nrf_esb module for more details.]
On the other hand, the improved radios on the nRF51 and nRF52 devices allow payload lengths to be expanded. On the nRF51, the maximum SB payload length is 254 bytes and the maximum ESB payload length is 252 bytes (2 bytes are lost to the PCF). The nRF52 is capable of 255-byte payloads in both SB and ESB modes. Throughput is greatly improved when larger payloads are used; As an example, 1.28mbps throughput is possible on the nRF51 when using five address bytes, two bytes of CRC, 2mbps baud rate, 252-byte payloads, and empty acknowledgement payloads.
Furthermore, the radio that is used by the nRF52 series requires only 40us to switch between RX and TX modes. This means that two nRF52 devices can transmit a packet, transmit the acknowledgement, and then switch back to their original modes 180us faster than previous devices could.
Lastly, the nRF52 no longer supports the 250kbps baud rate. Unfortunately, this means that the nRF52 will not be able to communicate with some existing devices.
Conclusion
The SB and ESB protocols allow low-level access to the radio and should be considered any time maximum throughput or flexibility is required between two Nordic devices. Although SB packets themselves are simple, it's possible to build arbitrarily-sophisticated protocols on top of them. And, via the Multiprotocol Timeslot API, many devices are now leveraging the strengths of SB networks at the same time that they use BLE to communicate with smart devices.