Differential GPS Continued

In order to test if this quasi-differential GPS system works, I need to get two GPS modules to talk to each other using radio. As discussed earlier, I have a couple of XBee Pros to use for the job. Ideally, the static GPS module will eventually talk to the existing Xbee on the mower. However, for now, I will use a different network address (panid) so these Xbees won't interfere with each other.

It is time to breakout the FTDI adaptor, fire up Coolterm and configure the radios. These are the details of this network. They will need reconfiguring when I integrate to the mower Xbee. Note the minor changes to the panid and addresses.

Remember the Xbee is a 3.3 volt device so use a 3.3v FDTI converter.

All done through Coolterm using the following recipie.

+++
ATID5556\r
ATMY1358\r
ATDH0\r
ATDL2469\r
ATWR\r

Getting GPS and Xbee to Play

The GPS device uses a serial interface. The XBees use a Serial Interface. The arduino Serial Monitor uses a Serial interface. I selected the Arduino Mega for Moana precisely so I could have several serial ports. However, I will be testing on UNOs which only have one serial port. I will therefore enlist the help of Software Serial to get more ports.

This will be a good learning experience, so my plans are to leave the UNO serial port free for programming and the Serial Monitor. I will need to create two Software Serial Ports, one for the GPS and one for the XBees. Let's hope that you can have multiple Software Serial ports without killing the UNO!

Tasks TODO

Notes:

XBee3 and XBee4 can communicate ok using the Xbee Pros. I have the a two way pass-through working.

GPS can be read easily with the Adafruit library. Getting Xbee and GPS running at the same time is proving difficult.

Progress so far: June 2019

Well, I got the remote UNO to read its own GPS, then receive a delta via the XBee and correct its readings. For now, the delta is sent vial CoolTerm via the Xbee channel. I must say that this was a pig to get working. SoftwareSerial only allows one serial port to listen at a time and you need to switch between then. You also need to keep slurping data all the time. However, I have a prototype running now. It is time to focus on the static GPS with the lessons learned and then I will come back and tidy up once I get true end-to-end working.

As both GPS will be reading all the time, I decided to cut down the chatter between the static and remote arduinos and use a push protocol from static to remote rather than have a request/response mechanism.

Going Mad with Averages

Previously, I had found the exact location of the static GPS by averaging over a couple of days. The result was accurate to 20cm. I thought I could do better than this and decided to use a cumulative average on the static GPS. This would mean you could get up and running quickly and the static GPS absolute position should become more accurate over time.

Well, I tried standard averages, cumulative averages, rolling averages and the results were pants. Firstly, you need to add the precisions to Serial.println(value, 6) in order to display the GOPS readings properly. Only when I pulled all the values off the screen and calculated the average myself did I see that the arduino was not doing its maths properly. On checking the documentation, I see floats are accurate to 7 DIGITS, not decimal DIGITS. This means the 2 digit degree lat value was only accurrate to 5 decimals and the 3 digit long value was only accurate to 4 decimals. A lesson learned!

So, using floats and representing GPS co-ords as [D]DD.dddddd was not going to fly. When you do the maths to find averages, precision drops off dramatically. I tried converting to longs so I could use integer arithmetic but longs are limited to 2 trillion so accumulation of results soon overflows.

A Different Approach

Fixed point arithmetic. By changing everything to long, I can represent the GPS readings as [D]DDdddddd. However a signed long in arduino has a max value of 2^31 (approx 2000 million). Since longitude is being represented as a 9 digit number this means we can only average 10 values before we start to hit the endstops. Using the average of 10 averages is also a limit. So we are pretty near the limits of the device here, unless I drop back to DDD MM SS.sss format.

I tried using fixed point arithmetic with longs and the results were not good. If a run 250 readings and average them on my laptop, it is much more accurate. I am wondering if having a cumulative average is going to work here.

I am wondering why the average I am calculating is so poor. I think this could be because the GPS is reading 10 readings that do not change much in a short period (10 seconds or so) and so they are skewing the average. One last thought. Maybe I could read the GPS value at much longer intervals and accumulate the average over a wider range of values.

June 2019