Beta Test / Technical

[cagney]

Loading CM93 from May 2010, I could eventually see the two red crosses near Skärhamn. It looks like the 3m line, in this late edition, has been adjusted slightly closer to land so that the rocks are between DRVAL1 (3m) and DRVAL2 (6m) and thus shows up with a safety depth set to 3 m. With exactly the same settings they do not show in my earlier editions.

It seems natural to me to set Shallow depths to 3m and Safety Depth to 6m in this vicinity, as it fits nicely with the DRVAL values. This means, of course hat the red crosses will not show.

Thomas

[aart]

As a user of opencpn 1.3 I found something disturbing in the track names.
It is still there in the beta 2.4.423 therefore I make the suggestion.
If I start tracking there is a file generated with a name that has the time 2 hours off.
If I start tracking at say 14:00 of 1 may 2011 the file is named
2011-5-1 12:00:00.
As I live in the Netherlands it must have something to do with Paris/london and the summertime?
When I open the file with "properties" or "eigenschappen" the times of the data generated with my GPS (Haicom HI-204III-USB) are correct so it is only the name of the file that has a name that is 2 ours early.
Is this something to correct?

[PjotrC]

Originally Posted by aart

it must have something to do with Paris/london and the summertime?

The UTC timestamp of the first trackpoint is shown in Route Manager, if the track has _no_name_ (default condition).

I was considering to change this to zone time, when implementing some new functionality around tracks and RM, but left it as it was done originally. Not difficult to change, I suppose.

The recommended solution is to give real names to tracks as soon as possible, not relying on the automatic labelling ...

[Netsurfer]

Originally Posted by PjotrC

The UTC timestamp ...

And using this timestamp is the only functional and useful variant imo.

Think e.g. about a passage from Calais (France) to Dover (England) which is a rather short trip. In Calais you have MEZ/ MESZ and in Dover you have BT/ BST.

So there is one hour difference. What time would you use, BST or MESZ? When would you "switch" to the other timezone? And if doing so, you "jump" one hour back in time and therefor there might be entries with an earlier timestamp even though they occured after events with a later timestamp.

IMHO all timestamps (log, track, etc.) should always be UTC. There are good reasons why it is called Universal Time Coordinated.

Gunther

[HamishB]

Originally Posted by Netsurfer

IMHO all timestamps (log, track, etc.) should always be UTC. There are good reasons why it is called Universal Time Coordinated.

I humbly agree.

2c,

[idpnd]

Originally Posted by Netsurfer

IMHO all timestamps (log, track, etc.) should always be UTC. There are good reasons why it is called Universal Time Coordinated.

I assume this won't apply to on-screen display though? I've been enjoying having my tide in local time - v lazy!

[Netsurfer]

Originally Posted by idpnd

I assume this won't apply to on-screen display though?

Correct. This applies only to recordings with a timestamp.

Gunther

[PjotrC]

Originally Posted by Netsurfer

And using this timestamp is the only functional and useful variant imo.

It is the only universally unique method - yes. But convenient in everyday use - no. However, it is just a last-ditch effort to give a name to something that has not received an explicit name - so something not very important...

With the Automatic Daily Track, you should rather expect to see the daily tracks starting at subsequent midnights, not shifted by some hours back or forth...

In time zones distant from UTC, when you will be looking for that morning passage from A to B some days ago, you will likely remember that you started at 0900 LT, after breakfast, not the unique UTC timestamp, that may even have different date.

Not so obvious... good incentive to give explicit names as soon as possible.

PS. Please note, that I am talking here about the way RM displays track names, not the way internal timestamps are taken.

[aart]

Thanks PjotrC, Netsurfer, HamishB and idpnd,
Now I understand the problem better!
May I ask you another question about tracking.
It is there in 2.3.1 and in 2.4.423. When I start a track with points every 60 seconds I find gaps of 10 minutes or more sometimes it looks that the tracking has stopped altogether.
If I open the active track with the properties button or by double clicking should I not see the points appended?
Enclosed as example prob1.gpx, the file from this evening. I stopped tracking at 23:00 but the file stopped at 22:41 but also some minute points in between are missing.
I hope the problem is clear enough, the compu is an eeepc 900 on battery power.
Aart

[champ8242]

Aart,

Does your computer go into auto sleep/suspend mode while sailing? This may cause the the interruption of the tracking

Bart

[aart]

Hi Bart,
No even the screensaver is turned off.
This morning I started tracking at 9:08 and nothing happened. The file length stayed 0. After 10 minutes or so I pressed the start track button a couple of times. Only the time stamp of the file changed but the file length stayed 0. At 9:54 it started working (why??), I see now the points 9:54, 9:57 and 10:08. Why it does nothing in between I do not understand as the time is set to every 60 sec and I was drinking coffee in the sun outside . Since I am at home now, no change in coordinates, can it be that the program is checking the change in coordinates? Even if I instructed time only?
This afternoon I will start a new series with my desktop computer.
Aart

[aart]

After 10:08 I see now points at 10:25,10:27,10:28 and 10:29 so now it looks like the program works sometimes perfect. But why nothing between 10:08 and 10:25

[PjotrC]

Originally Posted by aart

no change in coordinates, can it be that the program is checking the change in coordinates? Even if I instructed time only?

That's how it is... there is a minimum-minimum distance between trackpoints, and if this is not exceeded, only the timestamp is updated. Probably an option setting is needed there. Also, maybe the VDR will take over the function of detailed logging, so a track will only be a drawing of past trail.

[aart]

Hallo PjotrC,
Thank you for your comment. Now I understand it a little bit better.
But enclosed you find my desktop data: prob5 desktop.gpx. Here you see only minor time gaps fi at 15:35. Why?? This is in contast with the file prob7 battery - screen off 930 - 1100.gpx where there is a gap at 9:40 and no points are appended after 10:18 even if I stopped the file at 11:00.
For test purposes it would be fine if there was the possibility to have a real once a minute data appending.
I also use the program WaypointsGPS on my eeepc 900 and enclosed is the file prob8..... here you see at a glance that the system is working.
I shall try again on the boat and let you now how it works in real.
Aart

[idpnd]

As per attached, minimizing and remaximizing breaks opencpn display on ubuntu 11.04 and I'm left with just the taskbar (fantastic stuff btw!) and gps icon