I have the issue of the latency in the dynamic response of the EM406 GPS in binary mode finally resolved: you have to run at 57,600 baud in binary mode. Apparently there is a large communications buffer in the EM406 that gets flushed by the carriage return/line feeds in NMEA mode, but which does not get flushed in binary mode, unless you run at 57,600 baud. There must have been a memo on this, but I missed it.I will revise the MatrixNav code and release it as soon as I can give it a test flight. The drop in latency from 12 seconds to a few seconds should vastly improve the performance in windy conditions.Thank you all for your help, especially Chris Anderson, Jack Crossfire, and automatik.I should have listened to you, Jack. Next time I will.By the way, the EM-406A performs very well with respect to sensitivity and fast response. Now that I have resolved the binary interface issue, it performs as well as any of the other GPS radios that I tested. I plan to continue using it in future designs. There really is no point to using GPS units with reporting rates that are faster than 1 Hz. As far as I can tell, all they do is interpolate.Bill Premerlani
I just read on the U-Blox website that there is a new U-Blox 6 coming out, I emailed them for info but no answers yet... anyways the part number should be LEA-6H. (programmable with kickstart)
Yep - I can confirm the U-Blox LEA-5H actually solves at up to 4Hz. The solution rate can be set independently to the reporting rate, and dead reckoning (interpolation) can be disabled if required.
I'm using it on a board which I've developed for a UAV helicopter project I'm working on, and have been very impressed by its performance so far. The latency (in both velocity and position) appears to be very low. It should also be mentioned that it calculates velocity not from successive position measurements, but from the doppler shift of the various satellite signals.
I'll probably post some latency figures for this module in a new thread once I've worked out a good way to accurately measure it.
Thanks for the info on the u-blox LEA-5H, this is useful information for everyone.
In my firmware, the main source of course heading information is the gyros, through the direction-cosine-matrix (DCM) algorithm. It is 10 times faster (40Hz) than the u-blox, and very accurate. If you have not seen this video, you might want to take a look at it to get feel for the perfomance of DCM.
DCM uses GPS information to null the gyro drift, and to determine location. For those purposes, it does not need a high reporting rate. It will work with a reporting rate as low as 0.1 Hz. 1 Hz is more than adequate for DCM, and 4 Hz would not provide any benefit.
If you are not using gyros, then the higher the reporting rate, the better.
@Chris,
I do not think that you should give up the binary interface if there is a noise problem, there are too many useful features in the binary interface that you will eventually want to use. You could simply reduce the baud rate down from 57,600 a little bit. I am not sure how far down you should go, I just took a guess that 19,200 would work. It may be that 9,600 would work too. Either of those rates should be fine.
That's very helpful--I had no idea that higher serial rates could cause a noise problem (although now that you explain why, it makes perfect sense). That may explain this report of RF noise near our GPS connector. Perhaps using ArduPilot in NMEA mode at 4800 will solve that prob.
Up until now, all of my firmware for all of my boards communicated with the GPS at 4800 baud. It was a deliberate decision.
I selected baud rate based on the structure of my software. There is no activity in the main program for any of my UAV DevBoard firmware. For efficiency sake, everything is done on an as-needed basis during interrupt service routines. There is no operating system. Nowhere in my code are there any loops waiting on a hardware status bit to change. Within that framework, there are several advantages to using the lowest possible baud rate that will keep up with the message stream from the GPS:
1. If gives you the greatest noise immunity. The lower the baud rate, the more time there is for any ringing on the signal lines to decay. I have never had any trouble with corrupted data.
2. It spreads the work load of servicing the communications, so that other tasks can also be evenly spread. This improves the response to time critical events.
3. It allows the communications interrupt priority to be set rather low, in favor of more critical tasks like doing manual control.
4. It makes efficient use of the hardware resources. In the case of the dsPIC30F4011, there is a 4 byte deep hardware buffer for the serial port, so you can be off doing other calculations while the hardware is receiving data.
Up until now, there was no good reason for me to have a higher baud rate than 4800, which was more than adequate to keep up with the GPS. Of course, now I have good reason to go higher, to get the EM-406A to behave properly.
By the way, the EM-406A works just fine at 19,200 baud.
(For of those who may be confused by this chain, we weren't seeing the same problems Bill was, in either NMEA or binary mode. That's because ArduPilot already uses 57,600bps in binary).
What speed were you using before in your code? And why had you chosen that instead of the max of 57,600?
Comments
Should be even more accurate :)
I'm using it on a board which I've developed for a UAV helicopter project I'm working on, and have been very impressed by its performance so far. The latency (in both velocity and position) appears to be very low. It should also be mentioned that it calculates velocity not from successive position measurements, but from the doppler shift of the various satellite signals.
I'll probably post some latency figures for this module in a new thread once I've worked out a good way to accurately measure it.
Thanks for the info on the u-blox LEA-5H, this is useful information for everyone.
In my firmware, the main source of course heading information is the gyros, through the direction-cosine-matrix (DCM) algorithm. It is 10 times faster (40Hz) than the u-blox, and very accurate. If you have not seen this video, you might want to take a look at it to get feel for the perfomance of DCM.
DCM uses GPS information to null the gyro drift, and to determine location. For those purposes, it does not need a high reporting rate. It will work with a reporting rate as low as 0.1 Hz. 1 Hz is more than adequate for DCM, and 4 Hz would not provide any benefit.
If you are not using gyros, then the higher the reporting rate, the better.
I do not think that you should give up the binary interface if there is a noise problem, there are too many useful features in the binary interface that you will eventually want to use. You could simply reduce the baud rate down from 57,600 a little bit. I am not sure how far down you should go, I just took a guess that 19,200 would work. It may be that 9,600 would work too. Either of those rates should be fine.
Have you tried a u-blox LEA-5H? Allegedly it is actually solving at 4Hz
That's very helpful--I had no idea that higher serial rates could cause a noise problem (although now that you explain why, it makes perfect sense). That may explain this report of RF noise near our GPS connector. Perhaps using ArduPilot in NMEA mode at 4800 will solve that prob.
Up until now, all of my firmware for all of my boards communicated with the GPS at 4800 baud. It was a deliberate decision.
I selected baud rate based on the structure of my software. There is no activity in the main program for any of my UAV DevBoard firmware. For efficiency sake, everything is done on an as-needed basis during interrupt service routines. There is no operating system. Nowhere in my code are there any loops waiting on a hardware status bit to change. Within that framework, there are several advantages to using the lowest possible baud rate that will keep up with the message stream from the GPS:
1. If gives you the greatest noise immunity. The lower the baud rate, the more time there is for any ringing on the signal lines to decay. I have never had any trouble with corrupted data.
2. It spreads the work load of servicing the communications, so that other tasks can also be evenly spread. This improves the response to time critical events.
3. It allows the communications interrupt priority to be set rather low, in favor of more critical tasks like doing manual control.
4. It makes efficient use of the hardware resources. In the case of the dsPIC30F4011, there is a 4 byte deep hardware buffer for the serial port, so you can be off doing other calculations while the hardware is receiving data.
Up until now, there was no good reason for me to have a higher baud rate than 4800, which was more than adequate to keep up with the GPS. Of course, now I have good reason to go higher, to get the EM-406A to behave properly.
By the way, the EM-406A works just fine at 19,200 baud.
Best regards,
Bill Premerlani
(For of those who may be confused by this chain, we weren't seeing the same problems Bill was, in either NMEA or binary mode. That's because ArduPilot already uses 57,600bps in binary).
What speed were you using before in your code? And why had you chosen that instead of the max of 57,600?