Differences Between GPS Heading Data and Online Compass Readings

Kernel
1

I am using a device with FreeRTOS that receives GPS information, and I have noticed that the direction values do not always match when I compare them with an online compass tool. The online compass uses the device’s GPS location to provide direction information and works as a real-time direction tool for checking orientation based on current location data.

The issue I am seeing is that the heading from my device can sometimes be slightly different from what the online compass shows, even when the device is staying in the same place. The difference is not constant, and I am trying to figure out if this could be related to how FreeRTOS handles task timing or data updates.

My GPS readings are handled in a periodic task, while other tasks are also running for communication and sensor processing. When I look at traces, I wonder if the timing of when data is collected, processed, or displayed could affect the final direction value. For example, if the GPS task updates at one moment and another task reads the data a little later, could this create a mismatch in the reported heading?

I have checked the GPS signal and the values seem reasonable, but I am not sure how much delay is normal in a FreeRTOS system when working with location-based data. I am also curious if trace tools can help identify whether the problem is caused by task scheduling, interrupts, delays, or synchronization between different tasks.

Has anyone experienced similar differences between GPS heading data and compass readings on a FreeRTOS device? Are there specific trace events or timing details I should look at to understand whether the data is being updated at the expected intervals?

2

A “True GPS” doesn’t give orientation, as that data isn’t in the GPS system signal. Many GPS devices have in them a magnetic compass and can relay that orientation data in addition to the GPS information.

While GPS data (at least for consumer level devices) updates one a second, the magnetic compass can update much faster (and will have some noise in it) so two separate reads can easily get different values.

Normally, GPS updates aren’t done on a “periodic task” that asks the GPS for data, as that by its nature WILL have lag. Instead if you want the most recent information, you configure the GPS to stream out a data packet as it gets new positions, and you have a task waiting on the stream for the packet, and update your cached values when you get the new message (and hopefully also notices a lack of messages and marks the data as stale).

If you have two tasks reading from the GPS module, why do you expect to get the same answer each time? Especially for orientation which can update at a fairly fast rate. The two tasks have different “now’s”, so “current orientation” can easily be different.

FreeRTOS itself won’t introduce any delays here, only the delay YOU put into your code, or the delays inherent in your location device.