How to maximize serial throughput for a wireless bridge?

[sporadic]

I'm working on a project that's intended to be a RS485 wireless bridge, mainly for holiday lighting control. I'm utilizing a Xmega8E5, NRF24L01 module, and half-duplex RS485 transceiver. For the sake of this discussion, we're only operating the bridge one way. Either as rs485->nrf or nrf->rs485. This is typical of the system I'm designing this for as the endpoints only receive data and are physically unable to transmit (their TX lines daisy chain to another node).

The problem I'm trying to tackle is how to optimally packetize the serial data. RS485 data rates will typically be 115200, with the NRF modules configured for 250kbps (1Mbps and 2Mbps possible). Given the ~9 bytes of overhead and latency per packet, how do I choose an appropriate packet size? In a perfect world, everything would just be 32 bytes of data and I send it off one at a time to lessen the overhead. Single byte transmissions aren't feasible. What's the best way to handle this?

My first take on this is to use the dynamic payload feature of the NRF24L01 and attempt to sense pauses in the serial stream with a timer. We would build the packet and reset the timer until we hit a packet size of 32, then send off the packet. If the RX ISR doesn't receive a packet in X amount of time, the timer interrupt would fire and send the shortened packet. I'd have to work out some math based on the selected baudrate to calculate an acceptable X, but it shouldn't too hard.

The source code for the project (work in progress) along with my Xmega SPI, USART, and NRF24L01 driver code is here - https://github.com/forkineye/nRFbridge.  Any thoughts, ideas, or suggestions are welcome. Thank you!

[Jeroen3]

Create a fixed packet length x on a speed that is somewhat guaranteed to work some larger distance than only left of desk to right of desk (nrf24l01 are not equipped with an amplified antenna)
Than fill that x bytes with a structure.

Code: [Select]

struct{
uint8_t rs485_data_length
uint8_t rs485 data[]
}Then you can immediately send a package after a termination char, line break, or whatever you use in rs485.

Not really maximize, but simplified.

[sporadic]

Create a fixed packet length x on a speed that is somewhat guaranteed to work some larger distance than only left of desk to right of desk (nrf24l01 are not equipped with an amplified antenna)
Than fill that x bytes with a structure.

Code: [Select]

struct{
uint8_t rs485_data_length
uint8_t rs485 data[]
}Then you can immediately send a package after a termination char, line break, or whatever you use in rs485.

Not really maximize, but simplified.

The issue is there is no in-band signalling to trigger from. It's a binary serial stream with no flow control.  This needs to be agnostic to the serial data.  We're using these mostly outside and distance and signal strength isn't an issue.  When it is, modules with a power amp can be had for a few bucks more.

[scientist]

For reference:
http://www.rcgroups.com/forums/showthread.php?t=2037213
http://www.rcgroups.com/forums/showthread.php?t=2041451
http://www.rcgroups.com/forums/showthread.php?t=2038738
http://www.rcgroups.com/forums/showthread.php?t=2038091
http://www.rcgroups.com/forums/showthread.php?t=2043285

Guy's a bit of a twit but the info there is useful -- he's also using a half-duplex TTL radio.

[sporadic]

For reference:
http://www.rcgroups.com/forums/showthread.php?t=2037213
http://www.rcgroups.com/forums/showthread.php?t=2041451
http://www.rcgroups.com/forums/showthread.php?t=2038738
http://www.rcgroups.com/forums/showthread.php?t=2038091
http://www.rcgroups.com/forums/showthread.php?t=2043285

Guy's a bit of a twit but the info there is useful -- he's also using a half-duplex TTL radio.

Was some interesting stuff, thanks.  As for timing information, I took some scope readings utilizing a 32 byte payload, 5 byte address, and 2 byte CRC.  Auto Acks disabled.  According to the datasheet, the "Time On Air" is (8(1+addr_len+payload_len+crc_len)+9)/datarate.  Using the NRF24L01 interrupts, below is what I came up with. Nothing too exciting, but its data. For the CE signals, measurements started 15us into the CE pulse (radio requires 10us per datasheet).  For those unfamiliar with the NRF24L01 radio, CE triggers the radio to transmit when configured in TX mode, TX_DS is the Data Sent interrupt and RX_DR is the Data Received interrupt. 

250kbps data rate
ToA from datasheet calculation: 1316us
Time between CE (TX powerup) and TX_DS interrupt (on transmitter): 1408us
Time between CE (TX powerup) and RX_DR interrupt (on receiver): 1432us

1Mbps
ToA from datasheet calculation: 329us
Time between CE (TX powerup) and TX_DS interrupt (on transmitter): 440us
Time between CE (TX powerup) and RX_DR interrupt (on receiver): 444us

2Mbps
ToA from datasheet calculation: 164.5s
Time between CE (TX powerup) and TX_DS interrupt (on transmitter): 277us
Time between CE (TX powerup) and RX_DR interrupt (on receiver): 283us

[denizcan]

Why not keep it simple and set a timer to a fixed interval and send whatever data you collected with the packet length and packet marker at start?.. To resend the lost packages you might also need some extra bandwith.. As far as I remember handling variable length packages with NRF was a little difficult. But for your problem, fixed with packages are enough. It only wastes the power.. If that was also a problem it is better using CC1101 instead..

[sporadic]

Why not keep it simple and set a timer to a fixed interval and send whatever data you collected with the packet length and packet marker at start?.. To resend the lost packages you might also need some extra bandwith.. As far as I remember handling variable length packages with NRF was a little difficult. But for your problem, fixed with packages are enough. It only wastes the power.. If that was also a problem it is better using CC1101 instead..

I'm seriously considering a fixed length solution now.  I was pulling the little hair I have left out this weekend trying to get dynamic payloads to behave properly with ACKs disabled.  I had it working, but not without flushing the TX before each payload / TX cycle.  I posted about it in hopes to get some feedback from Nordic here - https://devzone.nordicsemi.com/index.php/discussions/nrf24l01-dynamic-payload-configuration-without-ack. 

[denizcan]

The communication is such an area that many solution fits in.. Because of that it is always hair puller.. Even you worked on RS422, there are many ways to do the same thing..

Years thought me something I can say most important: Don't force what others do. Just use, and spend your time on other stuff.. Problems waiting for solution are endless. If NRF is designed for fixed length, make it fixed length.. Or use other chip that has the capability. I can say that easyly, because at the time you read the pdf, that chip is about to be obsolete. Your time is precious, don't spend it for other's crap..