by davethomaspilot » Sat Dec 03, 2011 10:42 pm
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