EM406 dynamics: final resolution

Comment by Chris Anderson on April 22, 2009 at 12:46pm

Thanks for the excellent detective work, Bill.

(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?

Comment by William Premerlani on April 22, 2009 at 8:19pm

Chris,

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

Comment by Chris Anderson on April 22, 2009 at 8:29pm

Bill,

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.

Comment by bcr on April 22, 2009 at 8:58pm

> GPS units with reporting rates that are faster than 1 Hz. As far as I can tell, all they do is interpolate.

Have you tried a u-blox LEA-5H? Allegedly it is actually solving at 4Hz

Comment by William Premerlani on April 23, 2009 at 2:30am

@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.

Comment by William Premerlani on April 23, 2009 at 2:49am

@bcr,

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.

Comment by Daniel Dyer on April 27, 2009 at 5:33am

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.

Comment by Jonathan Lussier on November 19, 2009 at 2:54pm

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)

Should be even more accurate :)

Comment