10Hz GPS receiver in CPN - smooth moving

[Baikal]

Will there be support for smooth moving as in chartplotters?

[nohal]

Originally Posted by Baikal

Will there be support for smooth moving as in chartplotters?

"Smooth moving" is what?

[petter5]

It's up to your GPS, not Opencpn.
Opencpn works great with 10HZ gps.

Originally Posted by Baikal

Will there be support for smooth moving as in chartplotters?

[seandepagnier]

This is a great idea, and can in fact, be computed using inertial sensors with a regular gps.

I could with a bit of effort implement a kalman filter for this exact purpose and integrate it into pypilot (already used as the imu backend in openplotter even if there is no autopilot). It would of course require gyro/accel/compass imu, as well as some sort of gps, but then the nmea stream for gps could be output at 10hz with any gps, and correct for gps lag at the same time.

I actually have a lot more to say about this, but will pause. Is anyone really interested? What other advantages are there besides a more steady course prediction line? It might plot a more accurate track over ground, but the differences are typically slight. It would also update the boat position a lot faster giving smooth panning in overzoom, but is this update rate of more than the usual 1hz really useful?

I think more useful might be when gps reception is poor, and sometimes I have seen the boat jump far away then back.. essentially gps errors could be easily detected and filtered.

[Baikal]

on the video what I meant
Smooth moving and rotating position

https://www.youtube.com/watch?v=W0i2lHOom00

https://www.youtube.com/watch?v=YSIWZ-H2JTA&t=

[petter5]

Mostly 10 Hz is important for fast boats/vessels when operating at high speed to avoid lagging in the chart. Using Digital-Yatch DualNav GPS is a easy way to upgrade old systems to 10Hz. http://www.dualnav.co.uk/

Originally Posted by boat_alexandra

This is a great idea, and can in fact, be computed using inertial sensors with a regular gps.

I could with a bit of effort implement a kalman filter for this exact purpose and integrate it into pypilot (already used as the imu backend in openplotter even if there is no autopilot). It would of course require gyro/accel/compass imu, as well as some sort of gps, but then the nmea stream for gps could be output at 10hz with any gps, and correct for gps lag at the same time.

I actually have a lot more to say about this, but will pause. Is anyone really interested? What other advantages are there besides a more steady course prediction line? It might plot a more accurate track over ground, but the differences are typically slight. It would also update the boat position a lot faster giving smooth panning in overzoom, but is this update rate of more than the usual 1hz really useful?

I think more useful might be when gps reception is poor, and sometimes I have seen the boat jump far away then back.. essentially gps errors could be easily detected and filtered.

[transmitterdan]

OpenCPN has a GPS smoothing feature. It works very well. There are two features in fact. One filters the COG and SOG. The other filters the chart “jumpiness”. They are both in options. One is in the chart tab and the COG/SOG filter is on the connections tab. That one has adjustable smoothing so you can set it however you like. Larger number means smoother.

[daga]

Do you mean the Tracking Precision setting on the 'Own Ship' tab rather than the Chart tab?

My understanding is that these just apply smoothing and actually decrease accuracy for rapid course changes.

Dave.

[nohal]

Originally Posted by daga

Do you mean the Tracking Precision setting on the 'Own Ship' tab rather than the Chart tab?

My understanding is that these just apply smoothing and actually decrease accuracy for rapid course changes.

Dave.

Sure not, this is a different and unrelated feature, serving exactly to what you describe - limiting the number of trackpoints recorded at a price of decreased accuracy of the track.
But yes, the information is incorrect and in fact the Setting mentioned is "Chart Rotation Averaging Time" on Display->Advanced tab. The other is correct - "Filter period (sec)" on the Connections tab.

Pavel

[nohal]

Just to add, even after watching those videos, I have no idea what Baikal asks us to implement.

[bdbcat]

Pavel, et al...

We have a basic 1 Hz. update of the screen in auto-follow mode.

I think Baikal would like to update the screen faster if there is hdg/cog info coming in faster than 1 Hz. Maybe especially interested in the rotation angle in course-up mode, so that the screen rotation does not appear to "jump" visually.

This we could do without much effort, I think, if there really is 10 Hz input. Somewhat more difficult if we want to fake it with 1 Hz data, and smooth the rotation by synthesizing and injecting intermediate hdg/cog values. I don't like the second idea much....

That's my take on it.

Dave

[seandepagnier]

using the compass rather than gps, I have data at 10hz.

It would be possible to do smooth rotation as well with averaging, this might look nice. So if the course up angle updates every 10 seconds, whenever it does, rather than change it immediately, do a smooth rotation of 10 or 15 frames to the new heading.

Could play around with these settings, I think it is somewhat already implemented in the rotationctrl plugin, but logic could be improved and better filters and more options added.

[Baikal]

Originally Posted by bdbcat

Pavel, et al...

We have a basic 1 Hz. update of the screen in auto-follow mode.

I think Baikal would like to update the screen faster if there is hdg/cog info coming in faster than 1 Hz. Maybe especially interested in the rotation angle in course-up mode, so that the screen rotation does not appear to "jump" visually.

This we could do without much effort, I think, if there really is 10 Hz input. Somewhat more difficult if we want to fake it with 1 Hz data, and smooth the rotation by synthesizing and injecting intermediate hdg/cog values. I don't like the second idea much....

That's my take on it.

Dave

Dave, that's right!
The angle of the course should work smoothly with a higher frame rate and in the presence of only COG, including for holders of receivers 1Hz. This is certainly harmful, but it could be a function that is customizable in advanced display options.
1-10hz GPS / Glonass / Galileo / JapanSat receivers on U-BLOX is full on aliexpress, there is also a marine version.

[Douwe Fokkema]

Originally Posted by transmitterdan

OpenCPN has a GPS smoothing feature. It works very well. There are two features in fact. One filters the COG and SOG. The other filters the chart “jumpiness”. They are both in options. One is in the chart tab and the COG/SOG filter is on the connections tab. That one has adjustable smoothing so you can set it however you like. Larger number means smoother.

A remark on the smoothing function. Generally it works nice when sailing. If you are moored however, and due to GPS inaccuracies there is a small SOG of say 1 kn turning around in circles, the average SOG will be 1 kn. This is because the averaging works on a scalar basis. The absolute value of the SOG is averaged, not taking the direction into account. It would be nicer to use a vector average, taking also the direction of COG into account. In that case the average in this example would be zero.

[Douwe Fokkema]

There is another case in which faster position updates would be very welcome. That is for the target tracking in the radar plugin (br24radar_pi), so called MARPA and ARPA. We determine the movements of targets by comparing target positions between successive sweeps of the radar beam. As these are small movements the exact position of the own ship on the moment that the beam passes the target is crucial. Currently I use the last GPS position. But as the sweeps pass every 2 sec and the position can be 1 second old, there is quite some variance in the positions. This variance is filtered out nicely by a Kalman filter, resulting in pretty accurate COG and SOG of the targets. But better positions would decrease the variance, and improve the target tracking such that we react faster on changes in target course and speed.
I do have an experimental version that uses a Kalman filter on the GPS and that gives instant interpolated positions (GetPosition()). But this needs a lot of testing, which I can't do in a simulated radar environment at home, this will follow when the ship is sailing again.
But the fundamental questing is if plugins should make intermediate positions, or if this should be done centrally in OCPN, so that everyone would use the same position source. A centrally interpolated 10 Hz position would be very nice.
And by the way, a Kalman filter on the GPS will give a nicely smoothed COG and SOG. The degree of smoothing could be adjusted by setting the parameters of the filter.