> Since it has become apparent that the format won't be able to be compatible with signalk-node, It is now just pypilotServer.
The jury here is still out on the top-heavy signalk specs anyway, so it may be that one day your version becomes the standard, like ldap succeeded dap, and json succeeded xml.
> If you are parsing additional nmea sentences for waypoints it should not be an issue.
I mean the pypilot sending a signal to the UI whenever a waypoint id changes. I don't see what additional nmea sentences you mean that could solve this?
> You would not want to drop to compass mode unless gps is actually lost. It is most desirable to hold the current gps course, or the course of the current segment.
That latter is actually what I mean, so on that we agree. But why is dropping into compass mode a no-go? It serves the purpose of maintaining heading - what's the drawback then? When confirmed I set the mode back to gps.
> I think that if you really want to build waypoint arrival into the autopilot in this way, it is going to need the receive the entire route. Otherwise, losing opencpn you will still not be able to go to the next waypoint.
Sorry don't agree. This solution goes way too far for me. My main goal for this feature request is that the pypilot core engine supports some waypoint confirmation mechanism accessible through the pypilotServer infrastructure so that custom UI implementations can make use of it.
> The only real advantage of this would be, you also want the confirmation from several different interfaces and for them all to work together than only be able to confirm waypoints from opencpn correct?
Good question. I only have OpenCPN, and am planning on no other plotter. But given that OpenCPN only seems to provide APB and RMB messages, without RMB arrival status, and that I still prefer this simple, standardised interface above a fully integrated, plugin based solution, yeah, the feature I request would indeed go beyond opencpn plotters. But is is not my primary goal.
Currently, I had to change the pypilot code to get what I wanted. This now prevents me from easily upgrading; last time it took me a day to upgrade to the latest version of pypilot, refitting my modifications into the changed code. It would be great if the mechanism that I described could be added to the core code. For the time being I'm pretty happy not to upgrade, but when the fuzzy logic machine learning pilot feature becomes available then I'm first in line to upgrade ;-)
BTW, how do you quote in your replies? I have not found out yet how to do that in the HTML interface to this forum.
The jury here is still out on the top-heavy signalk specs anyway, so it may be that one day your version becomes the standard, like ldap succeeded dap, and json succeeded xml.
> If you are parsing additional nmea sentences for waypoints it should not be an issue.
I mean the pypilot sending a signal to the UI whenever a waypoint id changes. I don't see what additional nmea sentences you mean that could solve this?
> You would not want to drop to compass mode unless gps is actually lost. It is most desirable to hold the current gps course, or the course of the current segment.
That latter is actually what I mean, so on that we agree. But why is dropping into compass mode a no-go? It serves the purpose of maintaining heading - what's the drawback then? When confirmed I set the mode back to gps.
> I think that if you really want to build waypoint arrival into the autopilot in this way, it is going to need the receive the entire route. Otherwise, losing opencpn you will still not be able to go to the next waypoint.
Sorry don't agree. This solution goes way too far for me. My main goal for this feature request is that the pypilot core engine supports some waypoint confirmation mechanism accessible through the pypilotServer infrastructure so that custom UI implementations can make use of it.
> The only real advantage of this would be, you also want the confirmation from several different interfaces and for them all to work together than only be able to confirm waypoints from opencpn correct?
Good question. I only have OpenCPN, and am planning on no other plotter. But given that OpenCPN only seems to provide APB and RMB messages, without RMB arrival status, and that I still prefer this simple, standardised interface above a fully integrated, plugin based solution, yeah, the feature I request would indeed go beyond opencpn plotters. But is is not my primary goal.
Currently, I had to change the pypilot code to get what I wanted. This now prevents me from easily upgrading; last time it took me a day to upgrade to the latest version of pypilot, refitting my modifications into the changed code. It would be great if the mechanism that I described could be added to the core code. For the time being I'm pretty happy not to upgrade, but when the fuzzy logic machine learning pilot feature becomes available then I'm first in line to upgrade ;-)
BTW, how do you quote in your replies? I have not found out yet how to do that in the HTML interface to this forum.