SE8R01 2.4Ghz wireless modules

I recently purchased what were advertised as nRF24l01+ modules.  The modules don't have any silk screen marking the pinout, so the first problem was figuring it out.  After a bit of searching I found the pinout for nRF SMD modules, which is the same as the modules with the 8-pin connector except Vcc and Gnd is swapped:

1. Vcc (1.8-3.6V)
2. Gnd
3. CE
4. CSN
5. SCK
6. MOSI
7. MISO
8. IRQ

The next problem was coming up with a way to hook them up to a breadboard.  The castellated pads use a half-pitch (1.27mm) spacing, so you can't solder on standard pin headers and plug the module into a breadboard.  My solution was to solder 24AWG wire from an ethernet cable to the castellations, and in turn plug those wires into a breadboard.

My initial testing of these modules indicated they did not use Nordic nRF24l01+ chips, or chips that are compatible such as the Beken BK2423 or the SiLabs Si24R1.  The most obvious indication that these are not nRF modules iss that the default pipe0 address (register 0A) is 46 20 88 41 70 instead of E7 E7 E7 E7 E7.  They also respond to the bank switch command (0x50, 0x53), which is not supported by the Nordic chip.  I sent a message to the vendor asking for a data sheet, and while I waited I tried to figure out what chip the modules use.

Besides Beken and SiLabs, Hoperf makes a compatible module called the RFM70.  The RFM70 modules have a pinout that starts with Gnd, and they have the same default pipe0 address as the nRF.  The only other chip I could find that is similar to the nRF24l01 was the NST LT8900 or LT8901.  The datasheets for the NST chips didn't match with the register values from my modules.

Surprisingly, less than 24 hours after messaging the seller, I received an attachment containing a datasheet for the Semitek SE8R01.  My initial thought that these would inter-operate with nRF modules simply by changing the pipe0 address was disrupted by the discovery that these modules use a slightly different packet format.  Section 7.3 of the datasheet shows a 2-byte guard after the address field, just like bluetooth EDR uses where it switches from GFSK to DPSK.

If these modules use DPSK after the guard byte, then there is no way they will communicate with genuine nRF modules.  Another less significant source of incompatibility is that these modules don't have a 250kbps mode; instead it has a 500kbps mode along with the 1 and 2-mbps modes.  The 250kbps mode on the nRF24l01+ modules is good for extended range, since it has 9 dBm better sensitivity than 1mbps (-94 vs -85 dBm).  The SE8R01 datasheet indicates -86 dBm sensitivity at both 1mbps and 500kbps, so there would seem to be little reason to use the 500kbps mode.

One benefit to these modules is that they have a received power report in register 09, something the nRF modules don't have.  Although the datasheet documents the bank switch command, and how the currently active bank is reported in the status register 0E, there is no documentation of the bank 1 registers.

I also tested the modules to see if they will support packet sizes over 32 bytes.  The chip seems to accept a payload length of up to 255 bytes, but the read Rx payload command only gives 32 bytes before looping back and repeating the first byte in the payload.

Power

The SE8R01 supports up to 4 dBm of output power, which should allow for better range than the nRF chip which tops out at 0 dBm.  To set the output power to 4 dBm, section 6.5 of the datasheet says to set PA_PWR[3:0] in the RF_SETUP register to 1111.  Power consumption for the Semitek chip at 0 dBm output power is 18.5mA - much worse than the 11.3mA consumed by the nRF chip at 0 dBm output.  The higher power consumption will make it much harder to power these modules with a CR2032 coin cell, since many cheap coin cells start dropping voltage when current output passes 10mA.

Conclusion

At a price of $6 for 10, the SE8R01 modules are 25% cheaper than nRF24l01+ modules selling for $8 for 10.  With nothing more than a couple minor tweaks, they can be controlled using existing nRF24l01 code libraries.  They do not inter-operate with nRF modules, and consume significantly more power, and likely have no better range than is available using the nRF 250kbps mode.  So while the lower price may make them attractive to a volume manufacturer, as a hacker I prefer to stick with the genuine nRF modules.