Display TTG in KIP

[Techstyle]

ETA, yes, but TTG, I don't see it. I hope I'm wrong. Unless it's part of "Course DTG, XTE, BRG, etc (based on courseGreatCircle.nextPoint / previousPoint)". Perhaps I'll dig into Scott's code on GitHub and see if TTG is in there.

I wrote the ETA calc code, if you define what you want I can add it?
it is just text so KIP doesn't handle it well, but it works.

I have the plug-in installed and selected navigation.courseGreatCircle.nextPoint.estimatedTimeOfArrival

The SignalK data browser is showing the data but as the boat is on the marina, there is no SOG,  so data is just --
In Kip it does not appear in the drop down for the path but I typed it in manually.  However I did not realise that it was only txt and chose time.

It would be nice if Kip could display in addition to ETA at next waypoint also Time to go.  Similar for time to go to end of route and ETA there.
Thanks Jodel

So:
Next Point
Time of Arrival at next Point (an actual time of arrival eg. 19:37)
Time to the next point (Hours remaning, eg. 8:52 - 8hrs and 52mins)

Route
Time of Arrival
Time to Arrival

is that what you were thinking?

Exactly.  It is the kind of information, particularly in coastal cruising that is very nice to know.

Also I think that KIP does not display the Path of derived data in the drop downs when configuring the data to display.

I have it working in KIP for ETA, you just have to set it up as text first

[Techstyle]

I haven't got a testing environment setup right now, and I am not at my boat, but if you want to test this and report how it goes, please see the link below:

eta2.js.txt

Find eta.js in the calcs directory of Derived Data plugin and back it up.  then rename the file above to eta2.js and restart Signal K.  you should have 'navigation.courseGreatCircle.nextPoint.TimeToArrival' and it should be "HH:MM:SS" or "--"

the route ones are a little trickier, the calcs use Velocity Made good to Course (next point), and VMG to next point is not necessarily VMG to route, we may use this but I am not sure it will be representative.  Also, I need to find what we can use for distance - route length (not distance to the end point) - I will work on these but let me know your thoughts?

[Jodel]

I haven't got a testing environment setup right now, and I am not at my boat, but if you want to test this and report how it goes, please see the link below:

eta2.js.txt

Find eta.js in the calcs directory of Derived Data plugin and back it up.  then rename the file above to eta2.js and restart Signal K.  you should have 'navigation.courseGreatCircle.nextPoint.TimeToArrival' and it should be "HH:MM:SS" or "--"

the route ones are a little trickier, the calcs use Velocity Made good to Course (next point), and VMG to next point is not necessarily VMG to route, we may use this but I am not sure it will be representative.  Also, I need to find what we can use for distance - route length (not distance to the end point) - I will work on these but let me know your thoughts?

I probably will not get back to the boat until Monday coming 11th. Dec  I'll do as you suggest and let you know how I get on.
I can see the difficulties in picking a velocity to use.  I would suggest that the route distance remaining be divided by the current speed over ground.  Then you would know that if you maintained the same velocity and stayed on the route the ETA and TTG would be reasonably accurate.  I realise that if you had a leg where you had to tack or speed over ground was reduced by tide/current that the times estimated would be incorrect.  However as these events would be in the future it would be unreasonable to expect an accurate estimate.  That is why I think it best to used the current "knowns"

[Techstyle]

I haven't got a testing environment setup right now, and I am not at my boat, but if you want to test this and report how it goes, please see the link below:

eta2.js.txt

Find eta.js in the calcs directory of Derived Data plugin and back it up.  then rename the file above to eta2.js and restart Signal K.  you should have 'navigation.courseGreatCircle.nextPoint.TimeToArrival' and it should be "HH:MM:SS" or "--"

the route ones are a little trickier, the calcs use Velocity Made good to Course (next point), and VMG to next point is not necessarily VMG to route, we may use this but I am not sure it will be representative.  Also, I need to find what we can use for distance - route length (not distance to the end point) - I will work on these but let me know your thoughts?

I probably will not get back to the boat until Monday coming 11th. Dec  I'll do as you suggest and let you know how I get on.
I can see the difficulties in picking a velocity to use.  I would suggest that the route distance remaining be divided by the current speed over ground.  Then you would know that if you maintained the same velocity and stayed on the route the ETA and TTG would be reasonably accurate.  I realise that if you had a leg where you had to tack or speed over ground was reduced by tide/current that the times estimated would be incorrect.  However as these events would be in the future it would be unreasonable to expect an accurate estimate.  That is why I think it best to used the current "knowns"

I think VMG to course is better than STW or SOG.  I will just extrapolate that.

I did set up a test and it didn't work but I fixed it
   

and then here it is in KIP:
   

I did find that the latest KIP sees 'timeToArrival' as "Text Display" and 'estimatedTimeOfArrival' as a "Date Value Display".  I did find that when there is no valid ETA I set it to go to "--" which then results in an error that I will talk to the KIP guys about:
   

---

The Previous link has been updated with new code:

[Techstyle]

Updated again Sunday 12/10/2023.

the Variable was changed to timeToGo and its in Seconds, so in KIP, add it as Numeric and then select HH:MM:SS and it will convert it.  set the timeout value low (2s) and it will go to "--" if no value for 2 seconds

for estimatedTimeToArrival, add it as Date Value Display, set the format and timezone, set the timeout low as well.

As for the "Route" stuff.  The route distance is not sent out by OpenCPN, only the next point distance.  if we can work out a way to get it from OCPN, we can use it, but it might be a feature addition request

[Jodel]

Brilliant. That is what I was trying to display. Thanks for that.

[SCarns]

Updated again Sunday 12/10/2023.

the Variable was changed to timeToGo and its in Seconds, so in KIP, add it as Numeric and then select HH:MM:SS and it will convert it.  set the timeout value low (2s) and it will go to "--" if no value for 2 seconds

for estimatedTimeToArrival, add it as Date Value Display, set the format and timezone, set the timeout low as well.

As for the "Route" stuff.  The route distance is not sent out by OpenCPN, only the next point distance.  if we can work out a way to get it from OCPN, we can use it, but it might be a feature addition request

Awesome! And you've done a pull request already, so that will soon be in the Derived Data plugin! Thanks Techstyle!

[SCarns]

So here's a follow up:

If we can get ETA and TTG for next waypoint, is it possible to calculate ETA to destination (end of route)? From a practical standpoint, TTG to next waypoint is all you kind of need, as that the next time you have to "do something". However, knowing what time you'll arrive at a destination could be useful, based on current VMG.

Thoughts?

[Techstyle]

So here's a follow up:

If we can get ETA and TTG for next waypoint, is it possible to calculate ETA to destination (end of route)? From a practical standpoint, TTG to next waypoint is all you kind of need, as that the next time you have to "do something". However, knowing what time you'll arrive at a destination could be useful, based on current VMG.

Thoughts?

I would love to do that, however, OpenCPN does not output any data back to Signal K that carries the distance to the last waypoint, route distance, etc.  To get that we would have to see if we can get the OCPN team to output that.  I am not even sure there is a NMEA0183 for the RMB talks about "Range to destination in nautical miles", but that is the next point, not end point.  They could possibly use an alternate to RMB, like BEC:


BEC - Bearing and distance to waypoint - dead reckoning
Category: Autopilot

Example: $GPBEC,220516,5130.02,N,00046.34,W,213.8,T,218.0,M,0004.6,N,EGLM*11

Field# Example Description
1. 220516 UTC Time, HHMMSS format
2. 5130.02 Latitude of waypoint
3. N (N)orth or (S)outh hemisphere
4. 00046.34 Longitude of waypoint
5. W (E)ast or (W)est from central meridian
6. 213.8 True bearing in degrees
7. T True bearing indicator
8. 218.0 Magnetic bearing in degrees
9. M Magnetic bearing indicator
10. 0004.6 Distance to waypoint in nautical miles
11. N (N)autical miles indicator
12. EGLM Waypoint name

we would have agree some way of differentiating