m8ta
You are not authenticated, login. |
|
{485} | ||
Problem: switching modes on the nordic radios. see also {486}
solution-
present performance: txed packets = 118513 rxed packets = 118218 (note: computer has seen 118512 packets ) (and 118414 status packets, ratio: 0.999165 ) (note: 'stage ratio 0.997511 )(this includes code validation) now, if i boost the SPI clock on the bridge up to 5 mhz (headstage clock still running at 8.25mhz) to eliminate race-case (?) & add in 16 data packets before the status packets, perfection: txed packets = 44151 rxed packets = 44151 (note: computer has seen 750583 packets ) (and 44152 status packets, ratio: 1.000023 ) (note: 'stage ratio 1.000000 )after adding separate counters for TXed status and TXed data packets: txed packets = 808640 rxed packets = 50538 txed status packets = 50540 (note: computer has seen 808639 packets, ratio : 0.999999 ) (and 50540 status packets, ratio: 1.000000 ) (note: 'stage ratio 0.999960 )yay!! almost no dropped packets!! This equates to :
| ||
{486} | ||
here is an email I wrote to nordic semiconductor technical support concerning switching reception/transmission modes. see also {487} & {485} Hello, I've been having problems with switching modes on the nRF24L01. I want to implement a asymmetric bidirectional link, where there is a periodic (every ~36ms) time when the primary transmitter sends a status packet, then listens for a 32-byte command packet from the primary receiver. The command packet is for conveying configuration information, etc. I am driving both radios with blackfin DSPs using the built-in SPI port @ 4mhz, and am very careful with the CSN signal. The shock-burst feature is not enabled. Unidirectional transfer works great - I get nearly 0% dropped packets when the primary transmitter & receiver never change modes, up to a rate of about 1.5mbps. Of course, I am careful not to let the radio stay in TX mode for more than 4 ms - every 3ms i give it a 'break' by de-asserting CE. But bidirectional does not work reliably. Here is my procedure, on the primary transmitter side, for sending a status packet then changing from TX to RX & back to TX, with the initial condition that CE is asserted:
The process on the primary receiver is basically the same, but inverted. Upon receiving a packet of the correct type, it switches to transmit mode, sends off a packet, waits for the TX_DS interrupt, and switches back to RX mode. Like I said, when the transmitter and receiver never switch modes, the packets always get through without any corruption. When they switch roles for one packet, only ~ 78% get through, making the status packet -> command packet reply about 62% reliable. This is when the radio is only sending status packets - hence mostly it is in what the datasheet calls 'standby-II mode'. When the radio is also transmitting data packets, the status packet -> command packet relay is about 79% reliable, suggesting that the first packet after a switch from RX to TX mode is somehow being lost. Indeed, when I look at the IRQ signals on an oscilloscope, it is apparent that a certain percentage of the time the TX_DS interrupt is not followed by a RX_DR interrupt. so - what am I doing wrong??!! I'm desperate to make this work, and have tried almost every permutation! thanks, Tim Hanson | ||
{484} | ||
experimential results with the Nordic nRF24l01 (recall, as per {477}, that all SPI signals have an in-line 100 ohm resistor on both the headstage and bridge)
finally, it is solved!how:
| ||
{477} | ||
I've been having problems transmitting packets in a pipelined fashion using the nordic nRF24L01 tranciever IC. Namely, I cannot send multiple packets at once by keeping the on-chip 3-packet fifo full (note packets are 32 bytes data, max; with header/CRC, they are close to 40 bytes). If this fifo is full, the radio should remain in transmit mode - see {470}, and also {484} Above, what happens when I let the fifo go dry / empty, and force the PLL to resync for each transmitted packet, as per the following sequence:
Note just about all packets are received properly and that the RX irq closely follows the TX irq. Above, what happens when i try to pipeline transmission, e.g.
One initial theory was that noise on the SPI bus was corrupting the packets. However:
|