support for waypoints?

[tve]

Have you tried entering waypoints from a GPX file into a hex dump? I'd like to enter a couple dozen waypoints into the radio and don't really feel like doing it manually...

[cr]

Hey @tve,

I started looking into waypoints and wrote the required low-level codecs and it seems to be working fine. If you can live with a strict CSV-based format, I can add an import/export function for you.

However, I am wondering whether this would work for you as I am not aware of you Python skill level. At this point the hx870 tool is still rather experimental and thus geared towards Python hackers who are comfortable with figuring out the handset's TTY device, changing the code accordingly, and then hacking along in an IPython session (essentially knowing what they're doing). Although certainly on the mid-term roadmap, I won't have any time soon to make the tool really end-user friendly with nifty shell argument parsing, automatic device detection, etc.

[cr]

@tve, there's another feature request for waypoint export in issue #6 now, and I'm trying to get the discussion started about which export format to choose for a start. Have you perhaps formed an opinion on that by now?

[johannessen]

I’ve started work to address this issue over at johannessen/nav-command. Dumping waypoints and routes from the radio to GPX is already implemented. I hope to add flashing from GPX to the radio within the next few days.

The new functionality is accessible through a new CLI command for hxtool. I propose to use the term nav because it is short and a common abbreviation for the umbrella term “navigation”, which the HX870 manual uses for waypoints and routes.

Proposed CLI (not yet implemented):

hxtool nav -g data.gpx --dump
hxtool nav -g data.gpx --flash  # append GPX data to existing nav data in radio
hxtool nav -g data.gpx --flash --erase  # replace existing nav data in radio with GPX data
hxtool nav --erase  # erase all nav data from radio

For starters, I’d like to concentrate just on GPX, as it is easy enough to work with and can combine waypoints and routes in a single file. Other formats, such as plain text, CSV or GeoJSON, could conceivably be added later, in a similar fashion to the existing gpslog command.

@cr, do you happen to have any unpushed local changes this work might conflict with? Anything else you think I should rework, or consider going forward? Any feedback is appreciated.

[cr]

do you happen to have any unpushed local changes this work might conflict with?

Definitely, let me land these first before we move on.

[cr]

@johannessen, have a look at #29 that just landed on master. I hope it doesn't break too much of your code. I think the new classes should be easier to work with.

[cr]

I like the proposal to bundle all waypoint functionality under a nav subcommand. The GPS log-related subcommand could at some point be renamed to log, and I don't think clarity would suffer.

[cr]

I second the focus on GPX. It it a nasty format, but I think gpxpy supports GPX 1.0 well enough to easily work with waypoints as well.

[johannessen]

The GPS log-related subcommand could at some point be renamed to log, and I don't think clarity would suffer.

The primary function of the radio is still making calls. A future subcommand named log should therefore probably be used for accessing the DSC call log rather than the GPS position log.

[johannessen]

Thanks for pushing #29. No changes affecting nav subcommand. Will work on this next.