Thank you for this project!

[JoshuaPeddle]

I'm using this to build a 3D RC airplane using 2 E01-2G4M27D modules. I wont have much time to work on it with finals coming up in a few weeks but I'm planning on spending the summer testing and writing code for these modules. I hope to be able to contribute!

[2bndy5]

Contributors are very welcome. So far, very few people has offered to help me ☹️ . I consider feedback, diagnosis, and testing platforms I don't own as contributions!

I haven't verified this but it looks like the E01-2G4M27D modules use a different IC for added PA/LNA passive functionality (compared to the typical un-shielded modules that people keep buying on Amazon & etc). I have made a special note about PA/LNA modules in the docs, but that info may not be also applicable to these E01-2G4M27D modules. It would be great to post the store links to these E01-2G4M27D modules and as much info we can find (especially Power/current requirements).

For passers-by: a store link I found for the E01-2G4M27D modules

[2bndy5]

I should really invest in a oscilloscope... Your ability to confirm peak current consumption makes me jealous.

[2bndy5]

but its not a + module.

Was this determined using this library (nrf.is_plus_variant attribute or nrf.print_details())?

I think I stumbled across an unintentional bug in the current release that may actually be yielding inaccurate results: The SPI command ACTIVATE (0x50) is getting or'd with 0x20 before getting sent over MOSI -- this is not proper. My dev branch has a special condition in _reg_write() to avoid or-ing 0x20 with the ACTIVATE command.

Recall from the datasheet that the SPI commands need to be or'd with 0x20 for SPI writing operations, but the ACTIVATE command is an artifact from non-plus variants that doesn't require or-ing with 0x20.

[flexphperia]

@JoshuaPeddle
Sorry, I'm digging up this thread, but you mentioned that you were dealing with the E01-2G4M27D and E01-ML01DP5 modules.
Have you been able to test them? How do they work? They have shields built in, does this solve the problem that occurred in typical PA LNA modules that had to be wrapped in foil?

[2bndy5]

I can vouch for E01-ML01DP5 now. I was gifted a bunch of teensy 4.0 that had E01-ML01DP5 attached (including a buck/boost board soldiered in).

It is still imperative that the power supply does not dip below the recommended minimum though, otherwise the nRF24L01 resets and the program will have to re-init the RF24 object (or just use the RF24 object in a with statement to rewrite all the registers).

[2bndy5]

Beware that E01-ML01DP5 don't support changing the PA level (as reported directly from ebyte). This doesn't stop the program from writing to that register, but it does mean that the value written is ignored by the E01-ML01DP5.

[2bndy5]

I'm using this to build a 3D RC airplane using 2 E01-2G4M27D modules

If you find a lag in the response time, you might want to switch to using C++ (I recommend TMRh20's RF24 library). This library tends to average about 1-3 milliseconds per transmission (using auto_ack enabled) using CircuitPython MCU firmware. I've gotten better results on my dev branch using 2 different RPis and the python wrapped spidev (wrapped from C source) -- slightly more than 1 millisecond. FYI, with TMRh20's RF24 library, I have not seen transmissions faster than 530 microseconds (using auto-ack).

Unfortunately, there's nothing I can do to speed this library up on CircuitPython firmware. Well, maybe get rid of the extra_clocks=8 line in RF24.__init__(), but that may actually cause problems rather than speed things up (specifically not allowing time for the bouncing on the CSN pin).

Of course disabling auto_ack will provide faster transmissions, but could lead to a loss of data since the auto-retry feature is being neglected.

[mjooms]

Thank you so much for this project! I've been playing around with a raspberry pi and a rf24 module, trying to reverse engineer the remotes from our bed. So far I've been able to get channel, the preamble, address etc. and (partial?) payload from the noise using a crc of 0 and 2 byte address 0xAA/0x55. However when I fill in the address etc. as deduced from the noise, the lib doesn't return any data unfortunately. So I'm a bit stuck in how to find the other correct settings (like payload length, payload static/dynamic, crc, auto_ack settings). Do you know of a community where things like this can be discussed?

[mjooms]

Thanks, the chip used in the remotes is indeed nRF24L01 and I've been working based on this document that I found:
https://www.sparkfun.com/datasheets/Wireless/Nordic/nRF24L01P_Product_Specification_1_0.pdf

Basically I'm looking for someone that knows the Shockburst protocol in a bit more detail so that I can ask some questions; specifically regarding static/dynamic payload and crc

[2bndy5]

Everything I know about the ESB protocol is founded from reading the datasheet. There are some inaccuracies that only experience can teach, but they are mostly edge cases and have not ascended into the ESB support on newer nRF5x family of chips.

We host the v2 (& v1) of the datasheet in the nRF24/RF24 repo.

I've also conveyed most of the nuances from the datasheet into the RF24 API docs; see docs about RF24.crc and read up on dynamic payloads vs static payloads.

However, the datasheet explains the calculation of the CRC in detail (including the polynomial used as divisor and the initial dividend) in section 7.3.5. This would be handy if the remote is using auto-ack feature.

Important

The CRC checksum length is not included in the payload length number which would be embedded in the Packet Control Field (see datasheet sections 7.3 and 7.3.3 about the packet structure) if using dynamic payloads.

[mjooms]

Thanks for your suggestions. I'm just going to dump what I've done so far to the point where I'm stuck. I hope you like brainbreakers like this as much as I do, any tips are welcome!

Using the example/nrf24l01_scanner_test.py I determined the channel.

Then I configured the nrf module as follows:

nrf.auto_ack = False
nrf.dynamic_payloads = False
nrf.crc = 0
nrf.arc = 0
nrf.allow_ask_no_ack = False

nrf.address_length = 2 
nrf.open_rx_pipe(0, b"\0\x55")
nrf.open_rx_pipe(1, b"\0\x2A")
nrf.open_rx_pipe(2, b"\0\x2A")
nrf.open_rx_pipe(3, b"\0\x15")
nrf.open_rx_pipe(4, b"\0\x0A")
nrf.open_rx_pipe(5, b"\0\x05")

Using continuous nrf.read() I noticed a pattern when I press the remote, giving the following consistent byte arrays:

Full hex results of read():

000001554C8030F1D20409E20600000014000000000000000000000000000000
000001554C8030F1D20809E60600000014000000000000000000000000000000
000001554C8030F1D20C09E80600000014000000000000000000000000000000
000005553200C3C7480027B01800000050000000000000000000000000000000

Which corresponds with the following bits, matching the begin of an ESB packet according to the spec in the datasheet, giving the address of 53200C3C74:

01010101 53200C3C74 100000 01 0 0000010011110001000000110000000000000000000000000000101 
01010101 53200C3C74 100000 10 0 0000010011110011000000110000000000000000000000000000101 
01010101 53200C3C74 100000 11 0 0000010011110100000000110000000000000000000000000000101 
01010101 53200C3C74 100000 00 0 0000010011110110000000110000000000000000000000000000101 

Now according to the datasheet, the payload length follows after the address, which is set to 100000. I don't know if the payload is dynamic (then I assume according to the spec the six bits are still present but this part is simply ignored) or if it means a static payload length of 32 bytes. If it is a static 32 bytes, then the full payload (and a possible crc) are not present in the samples because I guess its too long.

After the pl you have two bits for the pid. They alternate which makes sense.

And then a 0 for the NO_ACK flag.
NO_ACK is high when auto ack is off, so I figured auto ack should be on.

Then the payload follows. It is consistent except for the second byte, which increases steadily when I hold the button. The last byte of the payload is consistent when I press different buttons on the remote.

So now, instead of parsing this noise, I want to configure the address in the module itself, so that I only receive the payloads using the chip itself.
I figured if I'm able to do that, I probably can send it that way too.

So I configured it like this:

nrf.dynamic_payloads = False
nrf.set_payload_length(32)
nrf.arc = 0
nrf.auto_ack = True
nrf.allow_ask_no_ack = False
nrf.address_length = 5
address = b"\x53\x20\x0c\x3c\x74"
nrf.open_rx_pipe(0, address)
nrf.crc = 1

And tried to read:

  nrf.listen = True
  while time.monotonic() < timeout:
        if nrf.available():
            print("AVAILABLE")
        #if nrf.any():
            # retreive the received packet's payload
        buffer = nrf.read()  # clears flags & empties RX FIFO
        if buffer:
          count += 1
          data = address_repr(buffer, False, " ")
          print("Received:", data)

But unfortunately the reading doesn't work, nothing happens. I've tried setting dynamic_payloads to True, and playing with the CRC length, static payload lengths, and disabling/enabling auto_ack, allow_ask_no_ack to no avail.

Uncertainties I have:

1. When I set auto ack to true, the CRC can not be 0, which makes sense. But what if the remote actually sends it that way anyhow (no crc and NO_ACK bit 0). Would that be a possiblity? And if so, a reason why I can't read anything because I can't configure it that way?
2. Since the ESB protocol specifies a min address length of 3, is nrf.address_length = 2 a special mode for reading a continuous data stream?
3. Could it be my module does not work for 100%? Ie.. I can pick up something using the continuous noise, but the actual parsing part of packets is broken or something?

Last but not least, I don't really care about reading... I want to send! Is there a way I can transmit a raw full packet, including preamble etc? Directly via spi maybe? I.e

5553200C3C7480027B01800000050000000000000000000000000000000

If you have any ideas/suggestions on what I could try further, I would greatly appreciate it!

[2bndy5]

1. The nRF24L01 is incapable of broadcasting a packet without a CRC checksum if auto-ack is enabled. Even if you use the RF24 class' private API to configure the CRC to use 0 bytes, the radio will still assert the CRC feature when assembling the packet and auto-ack is enabled. It is uncertain if it defaults to 1 or 2 bytes when CRC is configure to 0 bytes and auto-ack is used. I have written RF24.crc to return 1 when the register value is 0 but auto-ack is enabled.

2. Setting the address length to 2 bytes is a hack and does not conform to ESB specs. It is only exposed for reverse engineering purposes. It is only possible because the radio uses 2 binary bits to configure the address length (0bXX + 2 = address length).

   reading a continuous data stream?

   It is not possible for a payload in the radio's RX FIFO to be a direct continuation of the previously received payload. Each payload received must adhere to a packet structure (as defined by the radio's various configuration). This is a hardware limitation, not a software limitation.

3. It might be possible that your radio is a clone. In which case, using auto-ack feature may not work. The easiest way to find out is to run the library's simple_test example on 2 modules. The Si24R1 clones are famous for misinterpreting the NO_ACK flag which causes the auto-ack feature to not work at all.

There is no way to manually create the entire packet using a nRF24L01. This could be done with the nRF5x chips, but not using CircuitPython nor Arduino.

My notes

It is better to configure pipe 1 for reading and leave pipe 0 for transmitting ACK packets. It is possible that you are not seeing the ACK packets in the noise because the address is wildly different. For auto-ack to work the TX address must be set to pipe 0.

I noticed that all addresses you use to sniff data start with binary 0. This means that you are filtering the noise detected to packets whose preamble is 01010101. An address that starts with binary 1 would detect packets whose preamble is 10101010.

Since the payload length in the Packet Control Field is set to 32, then we know dynamic payloads are enabled. A payload length of 33 means "don't care" or possibly static payloads. I forget how static payloads' Packet Control Field looked when TMRh20 used the nRF52840 to sniff ESB packets from the nRF24L01.

According to the ESB specs in the datasheet, dynamic payloads are required for auto-ack feature. From experience, I've learned that this is really only true when using the custom ACK payload feature. However, the nRF5x family indeed requires dynamic payloads enabled when any ACK packet is involved (with or without a custom ACK payload).

[2bndy5]

buffer = nrf.read()  # clears flags & empties RX FIFO

BTW, read() only empties the first slot in the RX FIFO. Use flush_rx() to discard all 3 slots in the RX FIFO. It would be quicker to use read(32) as that doesn't do any additional SPI transaction to get the payload length (bypassing an internal call to RF24.any()).

CircuitPython_nRF24L01/circuitpython_nrf24l01/rf24.py

Lines 293 to 309 in fc69216

	def any(self) -> int:
	"""This function reports the next available payload's length (in bytes)."""
	last_dyn_size = self._reg_read(0x60)
	if self._in[0] >> 1 & 7 < 6:
	if self._features & 4:
	return last_dyn_size
	return self._pl_len[(self._in[0] >> 1) & 7]
	return 0
	def read(self, length: Optional[int] = None) -> Optional[bytearray]:
	"""This function is used to retrieve data from the RX FIFO."""
	return_size = length if length is not None else self.any()
	if not return_size:
	return None
	result = self._reg_read_bytes(0x61, return_size)
	self.clear_status_flags(True, False, False)
	return result

[TMRh20]

I would try something like the following:

• Disable CRC
• Make sure you have your addressing correct
• Set the address length to 2
• Auto ack off
• Then play around with the addressing if getting nothing, at this point you should be able to pick something up if you get the addressing correct
• Then go through each static payload length setting, from 32 down to 1 and see if you receive anything. I would do this in a loop and continuously try to pick up a reading for like 5 or 10 seconds per setting. This is only if you enable CRC checking.

Also the NRF52x is much easier to work with IMHO if you want to get down and dirty and allows direct control of much of the radio options etc.

1. I dont think thats possible if its an NRF chip
2. Its just something the chip allows, so we have the option in the library
3. Not really, if CRC is disabled, AA is disabled you should have most of what you need, then you need to get the settings correct to actually receive data, I think you are correct in starting here.

Not really, the radios handle that stuff internally, you can control everything after preamble though through settings.