-
Notifications
You must be signed in to change notification settings - Fork 1
Description
Repo's
- (Original) - As tracked on https://github.com/kb1lqd/faradayio-firmware/tree/CreateUARTBridgeToRF
- (3-11-2018) - https://github.com/kb1lqd/faradayio-firmware/tree/3-10-18_improvetx
- This is the current repo being worked on
Possible issue brainstorm:
Looping inside of main function loop to get and send packets stop the radio PktRxHandler and TX handler routines from operation during transmission
Actions to reproduce:
- Sending more than 1 packet worth of data (253 bytes) before the initial packet has completed RF transmission
Throughput Bottleneck
During investigation of this bug it was found that overflows WILL occur if UART baudrate is faster than RF baudrate and in this repository implementation it is difficult to detect. This is because the TransmitData() uses a pointer to point at an array passed by reference. There is was no protection for that array to be overwritten prior to completing transmission.
UART
At 115200 baud 253 bytes takes 17.6ms to complete.
At 38.383484 kbaud the RF module takes 52.73ms to complete 253 bytes.
This will cause a bottleneck and overflow upstream UART buffers!
Solution
The current solution is to not implement flow control and simply set UART baudrate lower than RF baudrate to avoid bottlenecks. In this repo RF baudrate is 38kbps but can be increased significantly up to 500kbps.
UART Blocking RF TX Register Writes During Transmissions
It has been noted that when sending more than 253 bytes (one full payload packet) the RF transmitter starts up and transmits tones but doesn't start transmitting until all UART receiving is complete. This causes the radio to miss most of the data to be transmitted.
The image above shows the radio starting but not outputting data until all UART activity has stopped. It should be noted that the TX FIFO will underflow and cause failure if not kept full, this means that for the radio to stay enabled as seen above the strobe(STX) command has been initiated but no writes the RF TX FIFO have occurred!
Things to check
- Is Timer A being corrupted as it's CCRx's control both UARTBridge timeout and TX/RX rf control
Yep I stopped all references to start or stop the UARTtoRFBridge timer and thus avoid any chance of resetting the TX timer and I got sticcato packets! This is not a solution but an indication of the root cause being timer reset, we need both, now to just figure out why the CCRx's are interacting.
I fixed the UART affect RF bug by removing the TACLR's from the timer starts, I only perform that on timer init at boot. I also needed to keep all timer CCRx's synced whenever they start into a started timer and to do this when starting a timer I simply append to the current timer count:
void StartRadioRxTimer(void){
TA0CCR1 = TA0R + RX_TIMER_PERIOD; // x cycles * 1/32768 = y us
TA0CCTL1 |= CCIE;
}The bug I'm facing now is that I'm seeing RX only able to receive a single packet then it RX overflows. I can't receive any more packets until I TX with that unit. I believe this is something to do either with PLL calibration or radio register/interrupt settings.
I'm current at: 2be7b9c

