Dead Reckoning Plugin for OCPN

[Dutcho]

Hi,

Attached you find a first describing design of a DR and classical fixing plugin. Also I describe some additional features that are useful to the navigator. I havent started the design yet of the datastructure or decided on what to do first.

Looking forward to hearing some thoughts about other views on the matter or omissions that I should look at as well.

Regards, Martijn

(sorry one file would have been too easy)

plugin design 1.pdf Views: 135 Size: 329.7 KB ">DR-Manual-IRJDSUNE9932123321222xxeww-fixing-IRJDSUNE9932123321222xxeww-plugin-IRJDSUNE9932123321222xxeww-design-IRJDSUNE9932123321222xxeww-1.pdf

DR-Manual fixing plugin design 2.pdf

DR-Manual fixing plugin design 3.pdf

DR-Manual fixing plugin design 4.pdf

[Viking Sailor]

Martijn,

A very nice presentation. However, you maybe over thinking what is needed or desirable in a DR plug-in tool for a cruiser. You might want to consider that radar, depth, and AIS (sans GPS) data is not (at least currently) available to most cruisers. The navigation data that is available will most likely be manual depth, speed, and compass readings.

It seems to me that what would be most generally useful would be a DR tool that kicks-in when the GPS signal is lost. That uses the current position, SOG, and COG to simulate the GPS data input to OpenCPN. Allow easy inputting of parameters into the navigation data set. This should be implemented to accommodate running, cross, and depth fixes for coastal DR work.

Additionally, if following a route it should calculate the difference between the course for the current leg of the route against COG. This difference will used as a correction to subsequent route legs. Or, until it is manually changed in navigation data set.

Personally, I don't see much use in a "real-time" simulator.

[globalkeith]

Originally Posted by Viking Sailor

Martijn,

A very nice presentation. However, you maybe over thinking

My advice is similar, start small, get it working, publish it, then add features slowly.

[cagney]

It sounds interesting with a DR plugin. I'm looking forward to the first release.

It's a bit awkward, but fairly straight forward to execute DR on OpenCPN with present tools!



On a sailing yacht it's useless to enter a speed for DR. Speed varies all the time and is not accurately predictable, it just leads to more trouble than it's worth to even try. The exception is if you have a speed log with NMEA output.
Normally DR is done by plotting accumulated distance and average course during a period of time, which already is possible.

Thomas

[Viking Sailor]

Originally Posted by cagney

It sounds interesting with a DR plugin. I'm looking forward to the first release.

It's a bit awkward, but fairly straight forward to execute DR on OpenCPN with present tools!

Attachment 42143

On a sailing yacht it's useless to enter a speed for DR. Speed varies all the time and is not accurately predictable, it just leads to more trouble than it's worth to even try. The exception is if you have a speed log with NMEA output.
Normally DR is done by plotting accumulated distance and average course during a period of time, which already is possible.

Thomas

Hi Thomas,

Exceptions would be on long ocean passages or when motoring in more-or-less calm conditions. Then a manually entered average speed works.

Best regards,

[fgd3]

Rather than a DR plug-in wouldn't it be simpler to put a small program on the COM port that reads the GPS data and passes it along to OpenCPN as long as the GPS is functioning but supplies DR data if GPS input is lost?

When the GPS data is lost the program would simply use the last GPS fix, COG and SOG to start a DR plot and feed updates to OpenCPN. At any time the user could enter new COG and SOG and, if desired, a new position. That would avoid any changes to OpenCPN to make it look at Ownship's coordinates rather than the GPS fix, since OpenCPN wouldn't even know GPS had been replaced by DR.

Fabbian

[Viking Sailor]

Originally Posted by fgd3

Rather than a DR plug-in wouldn't it be simpler to put a small program on the COM port that reads the GPS data and passes it along to OpenCPN as long as the GPS is functioning but supplies DR data if GPS input is lost?

When the GPS data is lost the program would simply use the last GPS fix, COG and SOG to start a DR plot and feed updates to OpenCPN. At any time the user could enter new COG and SOG and, if desired, a new position. That would avoid any changes to OpenCPN to make it look at Ownship's coordinates rather than the GPS fix, since OpenCPN wouldn't even know GPS had been replaced by DR.

Fabbian

Hi Fabbian,

OpenCPN currently sets the OwnShip icon to gray when their is no GPS data and red when getting good GPS data. It would be a good idea to have the OwnShip icon be a different color when doing DR navigation. This would require that OpenCPN be informed when it is being provided with DR data. I suspect that the best way to implement this is via the plug-in API.

Best regards,

[Dutcho]

Hi Viking Sailor,

Maybe a lot of sailors dont have everything integrated on a NMEA bus but I think over time that is going to happen. Wouldnt it be a smart thing to build that option in it from the start?

The system could look at which NMEA strings are available and fill in the blanks. you could argue if you want a realtime input or that you use for example a 10s average.

And when course/speed are not available from an NMEA string you just manually enter them and when you update your position with a new cross fix for eaxmple you can draw your conclusions.

Regards,

Martijn

[Dutcho]

Hi Keith,

I'll defently start small. This is more of a description of what I am thinking about.

Regards, Martijn

[Zoef]

The reason for the plug-in is to continue navigation with DR in case no sufficient GPS signal is available. However, the latest satellite receivers can work with both GPS and the now available GLONASS signals, resulting in a substantial increase in reliability of the satellite positioning system.
Under which circumstances, and for how long, do you expect to fall back to DR?

[fgd3]

Originally Posted by Viking Sailor

Hi Fabbian,

OpenCPN currently sets the OwnShip icon to gray when their is no GPS data and red when getting good GPS data. It would be a good idea to have the OwnShip icon be a different color when doing DR navigation. This would require that OpenCPN be informed when it is being provided with DR data. I suspect that the best way to implement this is via the plug-in API.

Best regards,

It would certainly be desirable if OpenCPN were aware of the change from GPS to DR input, but that makes the solution more complicated and increases the risk that the change will break something else. Putting a little program between the GPS and OpenCPN offers a quick fix. That program would, of course, somehow have to notify the user that DR was in use instead of GPS. I guess it depends on how urgent is the need and how long the is development.

Fabbian

[rooiedirk]

Hoi Martijn,
I had also a plan to make a DR plugin. Maybe we can share workload and ideas.
Try nulzestweedrieachtdriezestweedrievier
grjes Dirk

[Dutcho]

Originally Posted by Zoef

The reason for the plug-in is to continue navigation with DR in case no sufficient GPS signal is available. However, the latest satellite receivers can work with both GPS and the now available GLONASS signals, resulting in a substantial increase in reliability of the satellite positioning system.
Under which circumstances, and for how long, do you expect to fall back to DR?

Hi Zoef,

With the arrival of multiple SATNAV systems overall reliability improves of course. However there are more links that can break up before you have your SATNAV position in your computer. Cables/receivers/antenna's can all malfunction.

So I am a firm believer of having redundant ways of establishing my position. The DR function to me personaly is nothing more then a way to plot my best guessed position in between the moments I make a fix with other means then SATNAV.

I think you should be able to run the DR indefenitly if needed but updated with terrestial/celestial based methods.

Regards, Martijn

[Dutcho]

Originally Posted by rooiedirk

Hoi Martijn,
I had also a plan to make a DR plugin. Maybe we can share workload and ideas.
Try nulzestweedrieachtdriezestweedrievier
grjes Dirk

Hi Dirk,

Sounds interesting. Will contact you.

regards, Martijn

[Zoef]

Originally Posted by Dutcho

Hi Zoef,

With the arrival of multiple SATNAV systems overall reliability improves of course. However there are more links that can break up before you have your SATNAV position in your computer. Cables/receivers/antenna's can all malfunction.

So I am a firm believer of having redundant ways of establishing my position. The DR function to me personaly is nothing more then a way to plot my best guessed position in between the moments I make a fix with other means then SATNAV.

I think you should be able to run the DR indefenitly if needed but updated with terrestial/celestial based methods.

Regards, Martijn

Hi Martijn,
I agree with most of the above. My concern about the DR plugin is that it assumes the proper functioning of the least reliable part of the sat positioning system: the pc with associated power supply and software. So if I have to use DR it will be on paper. And yes, I'm running 2 completely independent sat navigation systems simultaneously, one pc-based and the other one a Simrad plotter.
Klaas