-------------------------------------------------------------------------------
nRF24L01/nRF24L01+
-------------------------------------------------------------------------------

This directory contains a capture of the communication between two nRF24L01+
transceivers, one connected to a Raspberry Pi and the other connected to an
AVR microcontroller, and some generated files to test paths in the protocol
decoder that aren't covered in the capture.


nrf24l01-communication.sr
-------------------------

Logic analyzer setup
--------------------

The logic analyzer used was a Lcsoft Mini Board (at 12MHz):

  Probe           Description
  ---------------------------
  PB0 (TRG)       used to trigger the logic analyzer
  PB1 (rpi_CSN)   chip select signal of the receiving chip, active low
  PB2 (rpi_CLK)   clock signal of the receiving chip
  PB3 (rpi_MOSI)  MOSI signal of the receiving chip
  PB4 (rpi_MISO)  MISO signal of the receiving chip
  PB5 (rpi_IRQ)   interrupt signal for the receiving chip, active low
  PD0 (uc_CSN)    chip select signal of the sending chip, active low
  PD1 (uc_CLK)    clock signal of the sending chip
  PD2 (uc_MOSI)   MOSI signal of the sending chip
  PD3 (uc_MISO)   MISO signal of the sending chip

  Note that the nRF24L01(+) chips have two chip select pins, "CE" used to
  control the standby mode, and "CSN" used for SPI communication. This capture
  only contains the "CSN" signals of the two chips.

Data
----

The sigrok command line used was:

  sigrok-cli --driver fx2lafw --config samplerate=12M \
    -p '0=TRG,1=rpi_CSN,2=rpi_CLK,3=rpi_MOSI,4=rpi_MISO,5=rpi_IRQ,8=uc_CSN,9=uc_CLK,10=uc_MOSI,11=uc_MISO' \
    -t TRG=0 --time 140 -o nrf24l01-communication.sr

The capture starts with the Raspberry Pi initializing its chip as a receiver,
followed by the microcontroller initializing the second chip as a transmitter
at about 8.8ms - 9ms. 30ms after the start of the capture, the microcontroller
starts sending the strings "message #0" to "message #9" in intervals of about
10ms. After sending a message, it uses polling to detect when the message is
sent and the acknowledge from the receiver is received. The Raspberry Pi handles
the first six messages after the receiving chip asserts the interrupt signal.
Because it doesn't handle the other four messages and the receive FIFO in the
receiver runs full after three messages, the last message isn't acknowledged.
The sender detects that and reads the lost packet counter from the sender chip,
which consequently has a value of one.


nrf24l01-communication-[rx|tx].sr
---------------------------------

These files were generated from the file 'nrf24l01-communication.sr' using
the commands

  sigrok-cli -i nrf24l01-communication.sr -O csv | \
  awk -F , '{if (NR > 3) {print $2","$3","$4","$5}}' | \
  sigrok-cli -i /dev/fd/0 -I csv:samplerate=12M -o nrf24l01-communication-rx.sr

and

  sigrok-cli -i nrf24l01-communication.sr -O csv | \
  awk -F , '{if (NR > 3) {print $7","$8","$9","$10}}' | \
  sigrok-cli -i /dev/fd/0 -I csv:samplerate=12M -o nrf24l01-communication-tx.sr

respectively, because apparently the pdtest/runtc tools don't support capture
files with extra channels. The files are then used to check if the protocol
decoder correctly decodes the message payload.


nrf24l01-test-...
-----------------

These files were generated by the 'gen-testfiles.py' script and contain test
cases for the decoder that aren't yet covered by the other captures.

  ...-activate.sr:          Tests decoding of the 'ACTIVATE' instruction. This
                            instruction is only valid for the nRF24L01 chips
                            (without the plus) and is therefore not in the
                            communication dump.

  ...-excess-bytes.sr:      Used to check if the protocol decoder correctly
                            recognizes and reports superfluous bytes after the
                            commands.

  ...-misc.sr:              Contains checks for the instructions 'REUSE_TX_PL',
                            'R_RX_PL_WID', and 'W_ACK_PAYLOAD', that aren't
                            covered by the other dumps.

  ...-missing-bytes.sr:     Used to check if the protocol decoder correctly
                            recognizes and reports missing bytes after the
                            commands.

  ...-no-command.sr:        Used to check if the protocol decoder correctly
                            handles empty commands.

  ...-unknown-command.sr:   Used to check if the protocol decoder correctly
                            recognizes commands that do not exist.

  ...-unknown-register.sr:  Contains a 'R_REGISTER' (read register) instruction
                            of a non-existing register.