It’s been a couple of months since I’ve done anything on the projects, due to other commitments, holidays and the heat. But I’ve started to rectify that.
After remembering how far I’d for before, I decided to get the GPS working for Rover. I’d previously got Timer1 working on the Arduino, triggering every 20ms (50hz) and sending the bits of “Hello World” in 7N1 format. I spent some time with the TinyGPS and NewSoftSerial libraries from Mikal Hart, and got the parsing working nicely and building an output string in the UKHAS format. As, theoretically, the GPS might fail, and only transmits every one second, I put a 2.5 second timeout on the read; this ensures sufficient time to receive data, but prevents the system hanging. This was done through the simple process of checking the millis() on the Arduino – more on this later.
I’m using the NewSoftSerial library for a number of reasons; it makes development easier as I don’t need to remember to disconnect the GPS when uploading data (it clashes with the hardware serial), and gives flexibility to use other serial devices later. I will probably change this to use the hardware serial for the GPS later, for reliability.
Having the GPS parsing down, it was time to incorporate this into the main Rover code. Inside the timer which triggers every 20ms, I added a trigger every 30 seconds to read the GPS data and build the string to transmit. This was where the first of my problems arose. As I was running this code inside the timer interrupt, the code was just hanging on the loop. In hindsight this makes perfect sense, but it took a few hours of tweaking before it dawned on me that timers, delays and the NewSoftSerial library won’t work inside an interrupt. The main loop() on my Arduino was doing nothing, as I planned to do everything inside the timers. Instead, I changed the interrupt to set a flag, and the main loop() checks for this flag; when it sees it set, the program executes the code to read the GPS and build the string to transmit.
This lead to my second problem. No matter how I tweaked the settings in dl-fldigi, I couldn’t get a clean decode of the transmitted string. It transpired that the timers in the NewSoftSerial library were interfering with the data transmission timing. I resolved this by stopping and starting the library, using it only when necessary reading the data. This wouldn’t be an issue when using the hardware serial.
Finally, for some reason when sending a longer string of data, over 80 characters, the string broke up around character 70 but recovered before the end. Many thanks go to the guys on the UKHAS IRC channel for helping me with this, especially Daniel Richman who suggested using two stop bits (7N2) instead of one. This resolved the transmission issue. As part of this process, I also changed the way the timer runs. Instead of reading the GPS and sensors and building the strings every 30 seconds, I run this process as soon as the last stop bit of the last character of the message is transmitted, resulting in almost continuous transmission of data.