1. Receiving diversity: Multiple receivers, single transmitter
Instead of doing antenna diversity based on the signal strength, the data consistency is analyzed after receiving. This is receiver diversity. The receivers can be positioned with some distance to each other in order to compensate multipath or with various orientations of the antennas to compensate for misalignment of antenna orientation between transmitter and receiver. Or one can do both at the same time.
The nRF24 protocol is packet-based. A transmitted packet will be received by every receiver at almost the same time, if it is received at all of course. Auto acknowledgment and auto retransmit must be turned off. If lost packets are unacceptable, which is not the case for radio control and telemetry, must be managed at higher levels of your own communication protocol.
Case 1a. Checking for a packet with valid CRC
The nRF24 packets can contain a 2 bit packet identification (PID) field (sort of packet counter) as well as a 1 or 2 byte CRC field. By looking at PID and CRC from all the receiver modules, one can hope for at least one successful reception for every transmitted packet.
Case 1b. Comparing bytes
In the case 1a, if the CRC check fails for a transmitted packet in every receiver, no packet is presented at all, because packet with failed CRC are dismissed inside the nRF IC. Thus, discarding CRC-failed packet should be deactivated. This seems to be more comfortable with the nRF52.
Once discarding CRC-failed packets is deactivated, several receivers might present a packet with the CRC field of every packet being wrong. One can compare the bytes of those packets to each other in terms of which bytes are the same across all received packets and which ones differ. For those bytes that differ (could be all of them), a majority decision is made in the hope to construct a packet with valid CRC.
Example: For one single transmitted packet, the set of receivers provides 3 packets with the following bytes:
1. A B C D E F
2. A B G H E J
3. K L C H M J
The reconstructed packet would be:
A B C H E J
Case 1c. Comparing bits
Same as 1b., but instead of bytes, the bits are compared. For the algorithm, please have a look into the executable specification file.
Case 1d. Distributed bit comparison (large scale, 60+ receivers)
Like 1c, but the data processing is distributed on several hierarchical levels. Lets investigate an example with 60 receiver, 32bytes/packet and a 1Mbps baud rate:
There shall be a hierarchy of 3 levels A,B,C
A. Total amount of data, if 60 modules are receiving: 60*1Mbps=60Mbps
B. Total amount of data, if 15 modules are receiving: 15*1Mbps=15Mbps
C. Total amount of data, if 3 modules are receiving: 3*1Mbps=3Mbps
Analysis of level C:
One MCU shall handle 3 receivers as follows:
Add up the data in terms of bit comparison. However, stop before deciding whether a bit of the resulting packet is 0 or 1. Instead, the sums of zeros for each bit and the number of packets is transmitted to a higher level in the hierarchy of MCUs.
Each sum of zeros can have a value between 0 and 3 (including). This can be encoded in 2bit. Thus, we can encode 4 bits in one byte.
Maximum incoming data/packet: 3modules*32byte*8bit=768bit=96Byte
Analysis of level B:
5 of those 3x-levelC-groups are combined.
Maximum number of zeros: 15 -> encoded in 4 bit -> 2bits per byte
Incoming data: 5*65Byte=325Byte
Analysis of level A:
4 of those 15x-levelB-groups are combined. Thus, the top MCU has to process 4*129Bytes=516Bytes per packet. However, if the top MCU were to process the data from 60 modules directly, that would be 60*32=1.920bytes per packet. The ratio of those two values is 1920/516=3.7. As a consequence, the top MCU does not require a SPI capability of 60Mbps, but only of 60/3.7=16Mbps!
Read more »
What processing needs to be done in the top MCU (see executable specification...