How to maximize serial throughput for a wireless bridge?

Go To Last Post
2 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not sure if this is the correct section or not, but seems to fit. 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 along with my Xmega SPI, USART, and NRF24L01 driver code is here - https://github.com/forkineye/nRFbridge. Thanks to Dean Camera for the ring buffer code :) Any thoughts, ideas, or suggestions are welcome. Thank you!
-shelby

Last Edited: Fri. Oct 16, 2015 - 01:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyone see any pitfalls with the timer based approach for sensing the end of a stream? Going to give it a go this weekend and see how it works.