How do I ‘cost-optimize’ nRF24L01P ?

I recently got a nice batch of nrf24l01 modules dirt cheap (~55 cent per module). If anybody wondered if you could cost-optimize these modules even more… Well, turns out you can. They won’t be quite working, but who cares? A detailed analysis of what those folks actually ‘optimized out’ is just under the cut.


So, these modules have the die on the pcb in a nice epoxy blob. Something out there tells me it’s most likely one of those fake ASICs under the epoxy with more power consumption and less sensivity.
After the initial shock seeing these ‘optimizations’ wore off, I opened up the reference schematics and tried to figure out what the heck they’ve optimized out. See the schematic below. I’ve crossed out the thing’s we’re missing.


Looks cool? Well, to start with we’re missing the IREF resistor. Either it’s now integrated under the blob, or it shouldn’t work at all without the proper reference current.

Next, we can see that ANT1 pin is now… floating. Right? Right! Since ANT1 and ANT2 is a differential amp output we’re most likely missing some 30-40% of transmit power out there, since only half of the amp is doing anything.

Missing one of the caps on the power rails and the 1M resitor near the crystal are the only safe things here to do as I see it. Or it at least looks like that.

Do they work at all?

Surprisingly – something in the middle. The first thing I’ve done – popped one of these modules into a board armed with my rf24boot. Nothing worked. I made a debug build of the loader and looked into the log.
Turned out the module WAS receiving packets. But there was random gibberish in them instead of actual data. Alas, it didn’t properly ack packets received. After adding a bunch of debug messages here and there and starting to hate humankind I put one of these modules into my usb2nrf dongle and… It worked (not speaking of crappy signal quality, as I expected seeing the above hackery).
So epoxy blob version works only with epoxy blob version. Period. Why? Remains a mystery. I still have a quest to get refund from the seller.

If I find any more details about the guts of these modules – I’ll make a followup post. Details are below.

Meanwhile, if there’s someone in Moscow with access to proper hardware willing to help do some 2.4Ghz RF analysis, plz drop me an email.

EDIT: Looks like the answer why was at the very bottom of the comments of the Hack-A-Day comment feed discussing those fake ASICs. And the very comment was made made by someone from Nordic. Turns out that those clowns who made that ripoff ASIC brought a typo from the original specs to silicon, so the NO_ACK bit in the packet control field is inverted in the fake chips. Testing a little bit more – no matter whether the dynamic payloads are enabled or not, fakes will not be able to properly ack packets received from genuine devices, as well as those from nrf24lu1, nrf24le1. The reverse (surprise!) works!

If you thought that this is good news (we have a good way to distinguish fake and non-fakes) you are quite mistaken. Googling the internets I found at least 2 ‘compatible’ chips: SI24R01 and SE8R01. And forum threads indicate some differences in default pipe addresses after reset, so there may be even more of them. Maybe even those modules I have and consider ‘good’ are just better clones.

What can be done?

So far the only working way to communicate from fake to genuine and vice versa – have the auto-ack feature disabled on both modules. I couldn’t find any other way to invert NO_ACK field without disabling the auto-retransmit machinery on the TX side.

Print Friendly

2 thoughts on “How do I ‘cost-optimize’ nRF24L01P ?”

  1. I’ve been caught by this problem.

    I’ve had a thought though. Since the NO_ACK bit in the packet control field is inverted, why not transmit using the W_TX_PAYLOAD_NO_ACK command? Problem is that it puts the PTX directly into standby mode, so then directly retransmit the same packet using W_TX_PAYLOAD to put the PTX into receive mode, ready to receive the ACK packet from the PRX.

    Is that a mad idea? I haven’t had a chance to test it yet.

    1. Nah. this won’t quite work:
      1. This ruins the auto-retry functionality.
      2. AFAIK there’s a continuity field that is used to drop duplicate packets, that will spoil the fun.

      But, still worth giving a try.

Leave a Reply