Visit our Popular Forums

skipperearly · 18-05-2018, 11:23

Quote:

Originally Posted by nohal

This is by design for cases where SOG data from the instruments is not available or wrong and the user does not want to use it. As far as I can tell this also works as expected.
If the OP has a problem, we simply need more input to asses if it is a real problem and worth a fix or a change or not.

well if the VDR is just a NMEA testing tool then this is ok but to be a Voyage Data Recorder it is miss leading to calculate the SOG based on replay speed. Missing SOG data should rather get calculated based on GPS times.

What is meant with "... the user does not want to use ..." in that context and how could SOG data in a NMEA sentence be "wrong" but replay speed calculated SOG's be right ?

Ideally a future version of VDR should enable a user configurable option to filter specific NMEA sentences recording/playback and how to handle missing NMEA supplied SOG's (and maybe other speed related data)

nohal · 18-05-2018, 11:34

Quote:

Originally Posted by skipperearly

well if the VDR is just a NMEA testing tool then this is ok but to be a Voyage Data Recorder it is miss leading to calculate the SOG based on replay speed. Missing SOG data should rather get calculated based on GPS times.

What is meant with "... the user does not want to use ..." in that context and how could SOG data in a NMEA sentence be "wrong" but replay speed calculated SOG's be right ?

Ideally a future version of VDR should enable a user configurable option to filter specific NMEA sentences recording/playback and how to handle missing NMEA supplied SOG's (and maybe other speed related data)

Again. VDR does not calculate anything. Speeds are shown as recorded, by default, regardless of how you use VDR.

If you think there is a problem, please post your recorded data and tell us where exactly you think that problem is.

**Paul Elliott** · 18-05-2018, 12:31

Quote:

Originally Posted by nohal

Remember that when you play the VDR data, you simulate data flow from the actual sensors - while playing at 10x the original speed at which it was recorded, your position changes 10x faster and your resulting SOG is obviously something like 10x higher than it actually was.

Quote:

Originally Posted by nohal

Again. VDR does not calculate anything. Speeds are shown as recorded, by default, regardless of how you use VDR.

Nohal, this is what you said that has got us apparently confused. So if VDR doesn't do the recalculation, what does? Or is there nothing in the OCPN family that does this recalculation of SOG, and your upper comment was just hypothetical?

When I do a high-speed playback with VDR, I'm just seeing the original SOG (as I would expect), but I'm using the original SOG data.

nohal · 18-05-2018, 12:43

Quote:

Originally Posted by Paul Elliott

Nohal, this is what you said that has got us apparently confused. So if VDR doesn't do the recalculation, what does? Or is there nothing in the OCPN family that does this recalculation of SOG, and your upper comment was just hypothetical?

When I do a high-speed playback with VDR, I'm just seeing the original SOG (as I would expect), but I'm using the original SOG data.

My comment is by no means hypothetical, go to Toolbox, and check the "Calculate SOG and COG from position changes" checkbox on the Ships->Own ship tab and play your data with VDR again.
And again. If the OP thinks there is a problem, I would like to see the input data and description of what exactly he considers to be that problem.

**Paul Elliott** · 18-05-2018, 15:04

Quote:

Originally Posted by nohal

My comment is by no means hypothetical, go to Toolbox, and check the "Calculate SOG and COG from position changes" checkbox on the Ships->Own ship tab and play your data with VDR again.
And again. If the OP thinks there is a problem, I would like to see the input data and description of what exactly he considers to be that problem.

Yes, I see that now. I've never enabled the "Calculate SOG and COG..." option before. The dashboard still displays the original SOG, but the bottom-of-screen status bar shows the accelerated (or decelerated) speed.

I'm not the OP, but I consider this behavior to be a problem. This isn't a fault with the VDR plugin, but the SOG should be calculated using GPS time, rather than the local computer clock. (I'm assuming that this is what is happening.)

For data, I'm using the "Pac Cup 2012 Start" file on the NavMonPc downloads page. The actual speed is around 7 kts, but at max playback speed the status bar speed varies wildly between 10 kts and 30 kts. Presumably this is because the VDR speedup varies with the density of NMEA sentences. Or perhaps not, I don't know what's under the VDR hood.

nohal · 18-05-2018, 15:15

Quote:

Originally Posted by Paul Elliott

Yes, I see that now. I've never enabled the "Calculate SOG and COG..." option before. The dashboard still displays the original SOG, but the bottom-of-screen status bar shows the accelerated (or decelerated) speed.

I'm not the OP, but I consider this behavior to be a problem. This isn't a fault with the VDR plugin, but the SOG should be calculated using GPS time, rather than the local computer clock. (I'm assuming that this is what is happening.)

For data, I'm using the "Pac Cup 2012 Start" file on the NavMonPc downloads page. The actual speed is around 7 kts, but at max playback speed the status bar speed varies wildly between 10 kts and 30 kts. Presumably this is because the VDR speedup varies with the density of NMEA sentences. Or perhaps not, I don't know what's under the VDR hood.

Well, for developing the feature, I used a circumnavigating boat with nothing but GLL sentences with empty 5th field were coming on the wire (Do not ask me why and no, replacing the GPS was not an option at the moment and place).
It is of course complete nonsense to enable this if you have better data available as is the case with the systems you have on Valis.

There is nothing at all under VDR's hood, all you adjust with the slider is the rate at which it emits the sentences so the speedup of course varies with the "density" of the sentences in the recorded stream. This is also not a bug but the way it was designed to work - a trivial tool serving a trivial purpose with the associated limitations.

**Paul Elliott** · 18-05-2018, 16:11

Quote:

Originally Posted by nohal

Well, for developing the feature, I used a circumnavigating boat with nothing but GLL sentences with empty 5th field were coming on the wire (Do not ask me why and no, replacing the GPS was not an option at the moment and place).
It is of course complete nonsense to enable this if you have better data available as is the case with the systems you have on Valis.

There is nothing at all under VDR's hood, all you adjust with the slider is the rate at which it emits the sentences so the speedup of course varies with the "density" of the sentences in the recorded stream. This is also not a bug but the way it was designed to work - a trivial tool serving a trivial purpose with the associated limitations.

I hope you're not taking my comments the wrong way! I have nothing but praise for the developers of OpenCPN and the various plugins. Thank you for your hard work and for the valuable tools that I use on my own boat. As the author of NavMonPc I certainly understand the thought and effort goes into projects of this type, and that you can't please everybody.

I also hope that we can discuss features and behavior of these tools.

As for VDR, if the variability of the playback speed is an issue, you might monitor the GPS time data embedded in the playback file and attempt to lock the playback speed to some fraction or multiple of that. On NavMonPc I implemented a primitive time-tracking feedback loop that speeds up or slows down the playback rate based on the GPS time. It does reasonably well at the 1x, 10x, and 100x settings, but because of its simplicity it's far from perfect.

On the other hand, if it's not important...

nohal · 18-05-2018, 18:13

Quote:

Originally Posted by Paul Elliott

I hope you're not taking my comments the wrong way! I have nothing but praise for the developers of OpenCPN and the various plugins. Thank you for your hard work and for the valuable tools that I use on my own boat. As the author of NavMonPc I certainly understand the thought and effort goes into projects of this type, and that you can't please everybody.

I also hope that we can discuss features and behavior of these tools.

As for VDR, if the variability of the playback speed is an issue, you might monitor the GPS time data embedded in the playback file and attempt to lock the playback speed to some fraction or multiple of that. On NavMonPc I implemented a primitive time-tracking feedback loop that speeds up or slows down the playback rate based on the GPS time. It does reasonably well at the 1x, 10x, and 100x settings, but because of its simplicity it's far from perfect.

On the other hand, if it's not important...

I read your comments with interest, they certainly make sense and if our primary use case was not real time navigation would be very viable to implement.
They just don't take me any closer to the sweet secret of whether this thread talks about a problem that really does exist or just about unrealistic expectations of what OpenCPN does, can do and is supposed to do.

**Paul Elliott** · 18-05-2018, 18:35

I assume that OpenCPN and related tools will do whatever the developers think it should do, with input from the users.

As a user, the variable speed-up and SOG behavior isn't critical to my use of the program. If I were a developer (which I am not), I would consider it more of a bug than a feature, but perhaps not important enough to work on unless I found it to be an interesting problem. Perhaps documenting the behavior would be appropriate. I can't see how it's going to get anyone in trouble.

So as a user, I say it's not important, and I'm not asking you to fix it.

There's one vote, let's see if the OP comments.

skipperearly · 18-05-2018, 22:14

I attach my log file, 2 daily tracks by ocpn and my backup track from iNavX (just for reference)
The AIS/GPS data have been gathered by my SeaNEXX stick and received by Win10 ocpn 4.8.4 via WiFi.
Could not get access to the internal seatalk on this delivery trip, so no wind or depth data got recorded.

Now back to the issue I raised. I had options/ship/calculate values SOG/COG ticked and 1 sec update. I was not aware that I had this option set and indeed, as nohal pointed out these values get no recalculated based on replay speed. Have now taken off this option and original SOG's are shown correctly again.

It is now a matter of taste/opinion/confusion if this behavior of VDR playback is a desirable feature or a bug - maybe both. I assume the "calculate SOG" option is a useful feature for the recording - but for playback I think it creates just confusion.

I would suggest to ignore the "calculate SOG/COG" option for playback.

In any case this behavior deserves mentioning in the manual.

Sorry if I have irritated nohal with my observations but I am only a enthusiastic user and not a programmer.

skipperearly · 18-05-2018, 22:42

have difficulties withe the size limits for attachments

https://www.dropbox.com/s/7bak78h9ya...racks.zip?dl=0

maybe this works

nohal · 19-05-2018, 04:36

Quote:

Originally Posted by skipperearly

I attach my log file, 2 daily tracks by ocpn and my backup track from iNavX (just for reference)
The AIS/GPS data have been gathered by my SeaNEXX stick and received by Win10 ocpn 4.8.4 via WiFi.
Could not get access to the internal seatalk on this delivery trip, so no wind or depth data got recorded.

Now back to the issue I raised. I had options/ship/calculate values SOG/COG ticked and 1 sec update. I was not aware that I had this option set and indeed, as nohal pointed out these values get no recalculated based on replay speed. Have now taken off this option and original SOG's are shown correctly again.

It is now a matter of taste/opinion/confusion if this behavior of VDR playback is a desirable feature or a bug - maybe both. I assume the "calculate SOG" option is a useful feature for the recording - but for playback I think it creates just confusion.

I would suggest to ignore the "calculate SOG/COG" option for playback.

In any case this behavior deserves mentioning in the manual.

Sorry if I have irritated nohal with my observations but I am only a enthusiastic user and not a programmer.

The calculated COG/SOG has absolutely nothing to do with recording the data using VDR, or anything else. All it does is calculate the internal SOG/COG values OpenCPN displays from position change when the position data is received, it does not produce any NMEA sentences that you could record and it does not change any NMEA sentences you could record.
It is a last resort feature providing at least something in case your system is broken and you do not get this information from your sensors or the information you receive from them is wrong (which is not your case).
It makes sense to use it only for real navigation where phenomena like time compression are rare to encounter in our universe. (Or playback at "exactly" the original speed, which is hard/impossible to achieve using the trivial VDR plugin we have and you should use tools like NavMonPc to achieve it)

rgleason · 19-05-2018, 10:03

Paul Elliot reports:
"And playing back one of my own logfiles shows the original SOG regardless of the playback speed. This is what I would expect."

So skipperearly there is no problem

skipperearly · 19-05-2018, 11:50

Quote:

Originally Posted by rgleason

Paul Elliot reports:
"And playing back one of my own logfiles shows the original SOG regardless of the playback speed. This is what I would expect."

So skipperearly there is no problem

agreed - as long as the option to calculate SOG is not ticked!
I still believe it would be less confusing if in the playback mode the calculate setting gets ignored - but I can live with what we have today, now that I know where to be careful.