Sometimes the radio fails to have its parameters set over UART on the first time broadcaster is run. This sometimes happens intermittently when broadcaster is run subsequently.

There should be some kind of retry to communicate with the radio to set parameters. It would also be good to understand the root cause of this issue, and why it happens intermittently. Is it because of timings?

Currently /dev/ser3 is hardcoded as the device handle for the LoRa radio. This may change depending on where the program is run (not necessarily on our Pi with the custom boot image).

It should be provided as a positional command line argument.

The RN2483 datasheet requires a mac pause command before a radio tx <data>, as discovered by Scott. Ideally we should include a new function for transmitting which does the following necessary steps:

1. mac pause
2. tcdrain() (to ensure module has received previous command)
3. radio tx <data>
4. tcdrain()
5. Ensure success response was returned by reading radio output

The function should take the radio file descriptor and a string of data to transmit as input, and should return true or false based on whether or not the transmission was successful.

Currently, broadcaster can receive input so quickly that the UART connection to the LoRa module cannot keep up. If the transmission fails, the LoRa radio reports it through stderr and continues.

In our telemetry system, the only acceptable packet loss should be due to loss over the air, not failure to be transmitted in the first place.

The program should retry failed transmissions until it is successful. There should be an upper limit to how many times broadcaster retries transmission. This may require experimentation to see what limit provides an acceptable throughput without piling up the input stream. Note that tests are currently being run with a dummy version of fetcher, which operates much faster than it will in reality (reading actual sensors takes time).