I can think of several different uses of heading which would each warrant a different algorithm, or at least different adjustments to the algorithm.
Without looking at the code, I would assume that Emlid would have set up the heading algorithm to work better for a UAV flying a mapping mission than a human walker.
I think it would be in your best interest to take control and write the code that works for your application.
If you take as many samples as you can before spitting out a heading, then you can apply a lot of smoothing. If you use statistics instead of simple averaging, then you can weigh each sample as to add emphasis to good samples and disregard bad ones. If you abstain from outputting a heading until a certain minimum of distance has been traveled in a certain minimum time, then you will get rid of a lot of the noise.
Yes, we may have to as the readings we currently get are not reliable enough. As mentioned these are intended to be installed on relatively slow moving vehicles that are constantly changing their course over short periods of time. Accuracy is critical.
I wasn’t sure if there was some special configuration or setup that will help, I’ve checked the documents and could not find anything.
Also curious if anyone else is using the NMEA sentences to extract heading data?
Because of the historical nature of the position data, there is also inherent lag in the NMEA heading information because it is reporting the heading you were on and not the heading you are on. This is where an IMU sensor might help you out a lot. Either the one built-in Reach RS (experimental) or an external one.
The other (more expensive) way to improve heading accuracy is to install two Reach units on each vehicle. This setup would also give a current heading value instead of previous heading value. The more distance between the units, the more accurate the heading (on an exponentially decreasing scale).
We have some of the issues described above fixed in the latest dev update. However, it’s important to remember that Reach, even in RTK mode, can only give reliable heading data if it is moving, and moving rather fast. The newest update has the heading field empty, unless you are moving at least 0.5 m/s.
Just as @bide mentioned, IMU should be your main source of information for the heading.
Do you know the typical lag in heading? I’ve been working on a project that needs heading, and understand the lag problem. How much lag is there, is heading simply calculated from the two previous points (so nominally behind by the output frequency of the GPS) or is there a more complex calculation?
If accuracy is critical, you need a dedicated GNSS / inertial device with two antennas input. So the device can catch exactly simultaneous location of antennas and issue a clean heading. Such as this one:
But this is not the same budget !
