NRF24L01P Minimum Pulse Width for Transmit

[brennen]

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.

If so, then there's a problem. Going from standby to active TX mode should take at least 130 uS, due to the PLL lock delay. Then it has to send the packet, which takes a fairly short (but non-negligible) time.

[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.

If so, then there's a problem. Going from standby to active TX mode should take at least 130 uS, due to the PLL lock delay. Then it has to send the packet, which takes a fairly short (but non-negligible) time.

"Going from standby to active TX mode should take at least 130 uS, due to the PLL lock delay"


Now I'm really confused. I thought as long as I never cleared the PWR_UP bit, I didn't have the delay. Are you saying bring CE low is power down mode? Or did you mean to say going from power down to activte TX mode should take at least 130 usec?

I never clear the PWR_UP bit.

The code just loops on a transmit, reloads the TX FIFO each time through the loop, and pulses the CE input. Are you saying transitioning from CE low to CE high is going from standy to active TX mode and that this has to be 130 usec min?

Sorry, I'm confused, but hopeful this confusion is my problem!

Thanks,

Dave Thomsa

[davethomaspilot]

Ok, I think it all makes sense now.

I must have misunderstood your reply to one of my previous posts.

The delay required to assure PLL lock applies coming out of any of the standby modes. And, just bringing CE low puts you in a standby mode, right? You don't come out of standby mode until CE is high. Therefore, you must keep CE high for at least 130 usec + 10 usec? Do I have it right?

So, you cannot count on reliable operation with CE pulse widths less than 140 usec, even if you never clear the PWR_DOWN bit?

Thanks,

Dave Thomas

[davethomaspilot]

I missed your comment about talking to Nordic support and that they were generally supportive.

I appreciate the time you've take to respond to these posts. Your replies been helpful.

Maybe this thread is not of general interest, so I should just work with Nordic support people?

No worries, if that's your preference.

Thanks for your help,

Dave Thomas

[brennen]

Maybe this thread is not of general interest, so I should just work with Nordic support people?

No, no. I'm happy to help. There are just some things that are either over my head or would require access to the RTL of the chip that I just don't have, and I couldn't answer that particular question.

The delay required to assure PLL lock applies coming out of any of the standby modes. And, just bringing CE low puts you in a standby mode, right? You don't come out of standby mode until CE is high. Therefore, you must keep CE high for at least 130 usec + 10 usec? Do I have it right?

If you look at Figure 15 on p. 42 of v1.6 of the nRF24L01P datasheet, the timing might make more sense to you. When you're in a standby mode in TX, you start the PLL lock sequence when CE is asserted. I'm sure there's some finite delay there between the actual assertion of CE and when the PLL starts to lock, but it isn't shown in that figure. The datasheet also shows that you must keep CE high for at least 10 uS. You only have to keep CE high for 10 uS according to the datasheet, and that's what I do in my library code, as well.

[davethomaspilot]

Ok, figure 16 does help.

You only need 10 usec CE pulse width, but the packet won't get transmitted until the PLL settles--as much as another 130 usec.

So, you do always have the PLL settle time for each transmission, but you're not supposed to have to hold CE high during the entire settle + TOA time.

So, I'm back to thinking the CE pulse width is not supposed matter, as long as it's greater than 10 usec (and PWR_UP bit is never cleared). And I also understand about the finding out when TX_DS bit goes to one might be helpful. The TX_DS bit should not be one only after PLL lock and TOA.

So, I think I'm on the same page as you know, as far as understanding the spec. But it sure doesn't seem like the modules I have conform to the spec.

I'll get the data and post. The easiest way will be for me to just poll the TX_DS bit after setting CE and toggle the LED output when it goes to one. I can then look at the time between those edges on my o-scope.

Thanks again,

Dave Thomas

[davethomaspilot]

I added a line to unmask the TX_DS interrupt, so the IRQ pin would go low after TX settle time + Toa.

The IRQ falling edge was more than the 130 usec spec, but I haven't calculated my Toa with eight byte payload and 1 Mbs. It could very well be consistent with that Toa + 130 usec.

So, in my case, the CE pulse width was providing the Tx settling time, since the code was in a spin loop until resetting the CE signal to zero. I didn't transmit another packet until 10 msec later, so I had essentially infinite time after CE transitioned low before the next transmission. But, I was checking the status register immediately after CE went low to check for the TX_DS bit being high. I think this is what messes up the transmit. When I commented out the line the reads the status register, the CE pulse width no longer matter.

Or, using a fixed 10 usec CE pulse width, I found that if I didn't read the status register immediately after CE went low he signal was transmitted reliably.

I don't really see that in the spec, but it seems like you can't transition CSN low until after the transmit settle time + Toa.

This would definitely explain the issue I was having with the other (transmit trigger) hardware. I was using TX_REUSE_PLD to get minimum latency for packet send. After pulsing the CE pin, I was reloading the packet "just in case" it didn't stay intact in the TX Fifo. That write of the payload started right after CE went low, and was probably right on the margin of having sufficient Tx settle time.

So, I think it's likely my issues had nothing to do with WiFi interference and will be resolved by simply inserting a delay after a 10 usec (or slightly longer) CE pulse. (Or by just eliminating reload of the TX FIFO).

I'm going to test all the modules again, fixed 11 usec CE pulse, 130 usec + Toa (+ a little more) with lots of packets to make sure a very high percentage of the packets are successfully transmitted.

Thanks for your help!

Dave Thomas