NRF24L01P Minimum Pulse Width for Transmit

[davethomaspilot]

Code: Select all

   rx_send_command(csn,0x20,0x7A);  // Power up, be an xmitter

The comment on that line is misleading. The write to the config register is to clear the PRIM_RX bit. The PWR_UP bit is never cleared.
So, the PWR_UP bit is already set at this point in the code, except maybe on the first transmit. (I'll add a line of code to set PWR_UP bit and delay -- once, at startup)

I'm probing CE on the transceiver card, so yes, a bad solder joint on the module to transceiver pcb could be the issue. I'll try probing right on the module pin.

I started looking closely at a "good" card. One that works reliably at 20 usec CE pulse width. Turns out that it does not work reliably at some longer CE pulse widths. Really long (1200 usec), it is solid, but not at some intermediate CE pulse widths.

I wasn't not sure I believed this wierdness, but it was 100% repeatable on that module. Frustrated, I just went to bed.

If I can't find a bad solder joint through inspection/probing. I'm now going to see if it's repeatable across all modules by "shmooing" CE pulse width in code, with data packet having the CE pulse width. That way I can tell what pulse widths are problematic for each module.

As far as using your firmware--I have been reviewing it carefully. I just removed stuff I didn't think was necessary (as we discussed in other posts). Could be something is needed I'm omitting, but it sure seems straight forward for a simple transmit loop.


Thanks,

Dave Thomas

[brennen]

I'm still a bit suspicious that CE time is truly the issue at hand here.

One experiment I can think of is to start a timer when you set the CE pin on one of the bad units. Measure the time until you get the TX_DS interrupt. Repeat the experiment with one of the good modules. Compare the time it's taking you to get the TX_DS interrupt. If the times are about the same, then CE is almost certainly not the issue.

[davethomaspilot]

I can try that next, but the data I have now convinces me it really is the CE pulse width.

I modified the code to vary the CE pulse width from 1 usec to over 1000 usec in 1 usec intervals as it looped and sent packets. The packet transmitted containted the CE pulse width. I verified the CE pulse width on an oscope and saw it varying as expected.

At the receiving end, I saved all packets received. I wrote a simple script that looped through them to identify which pulse widths had no corresponding packets.

I have five of on transciever card S and four of transceiver card L. (maybe more on that later)

Here's the data:

Module pulse width with no packets
s1 20-157
s2 23-72
s3 22-157
s4 18-160
s5 22-127

l1 none
l2 88-154
l3 none
l4 none


The second column indicates CE pulse widths for which packets were not received. (I'm simplifying a bit here, there are some pulse widths inside the range, at the boundaries that did get through.--I have the complete data set if needed).

So, all the s modules have a CE pulse range that causes problems. Only one of the L modules has a CE pulse range that causes problems. Very short CE pulse widths (1-20 usec) don't seem to cause a problem.

I changed to a fixed CE pulse width of 1000 usec, and all the modules sent 10,000 packets that were 100% received.

One thing I want to make sure I understand. By power down, you mean writing the PWR_UP bit of the CONFIG register to zero. If I don't do that, I should only need 10 usec min pulse width, right?

The S1 cards have only passive components, crystal, and the NRF24l01+ modules. The L1 also has a power amplifier and a different crystal/oscillator. I mention this only because this "smells" like a PLL lock issue that requires extra delay after power up. The spec shows different delay requires based on ESL of the crystal. Just speculating here.

I can just make the CE long in my application, but I too suspect something else might be going on that I really need to understand to get robust operation.

Here's an interesting paragraph in the spec:

The nRF24L01+ stays in TX mode until it finishes transmitting a packet. If CE = 0, nRF24L01+ returns to
standby-I mode. If CE = 1, the status of the TX FIFO determines the next action. If the TX FIFO is not
empty the nRF24L01+ remains in TX mode and transmits the next packet. If the TX FIFO is empty the
nRF24L01+ goes into standby-II mode. The nRF24L01+ transmitter PLL operates in open loop when in TX
mode. It is important never to keep the nRF24L01+ in TX mode for more than 4ms at a time. If the
Enhanced ShockBurst™ features are enabled, nRF24L01+ is never in TX mode longer than 4ms.

So, I think the TX FIFO should always be empty, even at the shortest CE pulse widths. Not sure how one would
stay in TX mode for more than 4 ms, since it apparently goes into standby-II mode automatically anyway.

Dave Thomas

[davethomaspilot]

Here's the code that varies the CE pulse width:

Code: Select all

//This sends out the data stored in the FobData
//FobData must be setup before calling this function
void transmit_data(uint8_t csn, uint8_t rf_channel)

{
   
   uint8_t ce = (csn == CSN_A)?CE_A:CE_B;
   
   
   cbi(CE_PORT,ce);
   //_delay_ms(1);   
   
   
   //rx_send_command(csn,0x25, rf_channel);     // Change to channel


   
   //
   ///*((uint32_t *)FobData) = delay_time++ ;
   rx_send_payload(csn,0xa0,8);     // Transfer data to xmit buffer
   //rx_send_command(csn,0x20,0x7A);  // Power up, be an xmitter
   //_delay_ms(1);   
   sbi(CE_PORT, ce);                  // pulse CE pin
   
   //_delay_us(1000);
   for (int i=0;i < *(uint16_t *)FobData ;i++)
      _delay_us(1);

   (*(uint16_t *)FobData)++;
   
   cbi(CE_PORT, ce);
   

}

[brennen]

One thing I want to make sure I understand. By power down, you mean writing the PWR_UP bit of the CONFIG register to zero. If I don't do that, I should only need 10 usec min pulse width, right?

Yes and yes.

The S1 cards have only passive components, crystal, and the NRF24l01+ modules. The L1 also has a power amplifier and a different crystal/oscillator. I mention this only because this "smells" like a PLL lock issue that requires extra delay after power up. The spec shows different delay requires based on ESL of the crystal. Just speculating here.

Did you by chance build anything into your L1 cards that allows you to bypass the power amp? If so, you may try that.

So, I think the TX FIFO should always be empty, even at the shortest CE pulse widths. Not sure how one would stay in TX mode for more than 4 ms, since it apparently goes into standby-II mode automatically anyway.

In your case, you are right that the TX FIFO should always be empty once your packet is sent (assuming you're only loading one packet). If you constantly load up the FIFO with packets such that there is always at least one packet in the FIFO while you are sending another packet, you can leave CE enabled and (theoretically) transmit packets forever.

[davethomaspilot]

Did you by chance build anything into your L1 cards that allows you to bypass the power amp? If so, you may try that.

The card isn't my design--I don't even have a schematic for it. It may just be a coincidence that only 1 of 4 of the cards with PA (L modules) show the CE sensitivity.

I have a few RF transceiver cards of a third design, but I'll need to do a little work to fit a 1x8 connector to a 2x4 connector. I'm inclined to do that next, unless you have a different/better suggestion.

I also have a new pcb coming in next week. This is a pcb that has an avr processor and sockets for the RF transceivers. This new version has more decap (100 uF low ESR tantalum caps and 2.2 uf ceramic) and polygon pours for ground planes that my existing pcb does not. So, if this is somehow noise related, I might see the CE sensistivity using one pcb and not the other.

My interest is still just to make I'm not missing something key in the firmware or hardware design.

Thanks,

Dave Thomas

[brennen]

I think it would still be a worthwhile test to try my suggestion about measuring the time from CE active until TX_DS. This would almost certainly isolate issues of CE rise time, at the very least.

[davethomaspilot]

One experiment I can think of is to start a timer when you set the CE pin on one of the bad units. Measure the time until you get the TX_DS interrupt. Repeat the experiment with one of the good modules. Compare the time it's taking you to get the TX_DS interrupt. If the times are about the same, then CE is almost certainly not the issue.

Ok, I'll try this. But I really don't understand why you would conclude "CE is almost certainly not the issue".

CE pulse width is the only thing varying and I have 100% repeatable results that show some pulse widths cause problems. Also, it seems all modules work reliably with pulse widths of 10 usec.

It could very well be that the NRF24L01 "thinks" it's transmitter a packet with a valid CRC, but for some reason the packet isn't received correctly by another receiver if the CE pulse width is within some ranges.

But it seems simple enough to get this data. Any reason to use a timer versus simply counting cycyles in a loop that is polling the TX_DS bit? When set, the loop would be exited, and the corresponding time would be sent in another packet. (The only way I can get output is via LEDs or transmitted data).

Thanks,

Dave Thomas

[davethomaspilot]

I'll predict all the modules will show TX_DS bit within 1 usec, since all of them work reliably with only 1 usec CE pulse width.

It's only longer times (between about 20 and 200 usec --e my previous post) that cause problems.

Given this, what will we learn from measuring the time for the TX_DS bit to go high?

Thanks,

Dave Thomas

[brennen]

Ok, I'll try this. But I really don't understand why you would conclude "CE is almost certainly not the issue".

I edited that opinion a bit in my last post, noting that CE rise time likely wouldn't be the issue.

It could very well be that the NRF24L01 "thinks" it's transmitter a packet with a valid CRC, but for some reason the packet isn't received correctly by another receiver if the CE pulse width is within some ranges.

This would be a good question to ask Nordic support. They are generally very responsive to questions.

But it seems simple enough to get this data. Any reason to use a timer versus simply counting cycyles in a loop that is polling the TX_DS bit? When set, the loop would be exited, and the corresponding time would be sent in another packet. (The only way I can get output is via LEDs or transmitted data).

A timer is generally more accurate. If you can use a logic analyzer you could use a GPIO. You want a measurement that you can easily and accurately convert into real world time, though, so you can compare it with the expected times given in the datasheet.