navit

navit copied to clipboard

APRS, and what it is: https://en.wikipedia.org/wiki/Automatic_Packet_Reporting_System

These links are provided as examples of software: Here is an open source client: https://www.ka2ddo.org/ka2ddo/YAAC.html A open source tracker: https://hackaday.com/2011/04/20/trackuino-%E2%80%93-an-open-source-arduino-aprs-tracker/ A open source modem: https://github.com/wb2osz/direwolf And: https://github.com/markqvist/OpenModem Maybe it's possible to look at Dire Wolf APRS software or similar, and enable communication with a local installation of LibAPRS or similar software, as this may be the simplest route.

The information received from a APRS receiver should result in APRS symbols and callsigns showing up in the map. The APRS stations visible should be determined by a adjustable range filter(display only units that is inside xx kilometers range. Some stations that doesn't beacon that often needs to be stored in a database that could expire after a set time. I suggest 3600 seconds.

For a example of moving stations, go to: https://aprs.fi/moving/ (Click on any of them to show the map ) Map showing many stations: https://aprs.fi/#!mt=osm&z=4&call=&others=1&timerange=3600&tail=3600

Documentation on the APRS message format and the APRS symbols that should be used: http://www.aprs.org/doc/APRS101.PDF http://www.aprs.org/symbols.html The APRS symbols are standard for APRS stuff.

Many radios has a KISS TNC built in: https://en.m.wikipedia.org/wiki/KISS_(TNC)

In its most widely used form, APRS is transported over the AX.25 protocol using 1200-bit/s Bell 202 AFSK on frequencies located within the 2 meter amateur band.

Something about the protocols that some radios may use:

$GPWPL, NMEA generic with only location and name.

$PGRMW, Garmin, adds altitude, symbol, and comment to previously named waypoint.

$PMGNWPL, Magellan, more complete for stationary objects.

$PKWDWPL, Kenwood with APRS style symbol but missing comment.

Many manufacturers use custom fields (Identified with a $P, followed by a three digit manufacturer code, followed by 2-5 digit data type code; In the case of Kenwood, this is a $PKWDWPL for the Kenwood custom waypoint sentence) that fix these oversights in the spec. Unlike the $GPWPL sentence mentioned before, the $PKWDWPL sentence is designed to specify a temporary waypoint, one that gets deleted when the next waypoint from that callsign gets sent.

I think that it should be possible and best to add support for full NMEA as this also may be attractive for the AIS users, and Kenwood sentence and supported the AvMap sentences. Also, some radios speaks that language.

Also, read: https://tyrellberry.blogspot.com/2013/10/nmea-sentences-kenwood-sentences-and.html?m=1

https://www.reddit.com/r/HamRadio/comments/fg1jys/advice_on_a_aprs_transceiver/?utm_medium=android_app&utm_source=share

Hmm, the first thing I read on the linked pdf is that even the name "aprs" needs to be licensed, and the pdf is only good for non commercial. I think this disqalifies "aprs" from introduction into Navit. Whatever "aprs" actually does .

It would be really great to get APRS support!

It would be really great to get APRS support!

It should be attractive to those who are running AIS equipment also as that speaks NMEA. https://en.m.wikipedia.org/wiki/Automatic_identification_system

Marqvist is adding Navit support for Open modem: https://github.com/markqvist/OpenModem/issues/1

Should be labelled enhancement.

I'm working on APRS to Navit functionality using Dire Wolf. Depending on exactly what your expectations are—it's totally doable.

The issue I'm running into is getting Navit to refresh the screen. If you're constantly moving then no problem; just configure Navit to follow your vehicle, and the screen will periodically refresh and bring in APRS updates with it.

But if you're stationary, and simply want to monitor APRS clients, then it's not so easy. I've got a hack that works based on Navit's pipe functionality, but it's not ideal. If anyone knows how to config Navit to periodically refresh (re-import the POI file) INDEPENDENT of the GPS source, then let us know.

Thats very nice!

I know that PicoAPRS runs this firmware, but for some reason it is not possible to get it to send APRS messages/sentences via the USB cable. At least, here is a link to the firmware: https://github.com/markqvist/LibAPRS https://unsigned.io/

I have been in contact with the maker of the PicoAPRS V3 but no help from him. I dont think that he has full knowledge about LibAPRS, at least the "ping- pong" game that it comes with could be removed so a virtual serial port that relays received APRS sentences could be sent to NAVIT for processing.

I'm working on APRS to Navit functionality using Dire Wolf. Depending on exactly what your expectations are—it's totally doable.

The issue I'm running into is getting Navit to refresh the screen. If you're constantly moving then no problem; just configure Navit to follow your vehicle, and the screen will periodically refresh and bring in APRS updates with it.

But if you're stationary, and simply want to monitor APRS clients, then it's not so easy. I've got a hack that works based on Navit's pipe functionality, but it's not ideal. If anyone knows how to config Navit to periodically refresh (re-import the POI file) INDEPENDENT of the GPS source, then let us know.

Have you uploaded the code somewhere? Then i could take a look at it.

Good day everyone. My name is Christian.

I recently bumped in to Navit, while being on the hunt for navigation software. My original plan, was to run Xastir or similar, in the background, and then navigate separately.

As i could not have imagined that something like this combo, was worked on.

Great News!

@Exscotticus I actually just hooked up a handheld to my laptop, and tested direwolf, for the first time. I think what makes Direwolf extra interesting in this case, is the approach to only be tied to the soundcard.

In my personal oppinion.

This makes it alot easier, for those out there, who are not necessarily licensed amateur ops themself, but still would like to receive & track, to use something like a dedicated receiver, or scanner, that is equipped with a 3,5mm jack.

Im gonna check in here again, at some point, as i get a bit more time.

Take care, and keep up the good work.

73s de OH6FOR, Christian.

This looks like a nice TNC: https://github.com/EnhancedRadioDevices/HamShield

For this to work, Navit must accept moving objects, from another application. Reference: https://github.com/wb2osz/direwolf/issues/262#event-4158601313

I think that mentioning APRS only confuses those who are not familiar with it already. The basic requirement is to display objects provided by another application and allow navigation to them. These objects could be in fixed locations or they could be moving. (e.g. car transmitting its location from a GPS receiver) Properties would include latitude, longitude, altitude, speed, direction, name, comment, time last heard, and symbol (house, weather station, car, boat, airplane, etc.)

This looks like an interesting hack to get us going in the right direction: https://github.com/N2ZLC/dire_wolf_to_navit

I was thinking more in terms of UDP messages over the network to feed in only the changes in objects. Generating a complete file of all objects, every time anything moves, doesn't seem like a good idea.

Probably some sort of key/value pairs so only the relevant properties would be reported and it would be extensible. JSON perhaps? Stationary object locations might report their locations every 10 to 30 minutes. Moving objects will report their locations much more frequently, depending on speed and changes in direction. Objects would disappear after not being heard from for some amount of time. perhaps a cay or user configurable.

I think there would be a lot of value to this. For example, you might be chasing a descending scientific balloon and use the navigation system to guide you to its most recent changing position. If you wanted to get really fancy, the current location could be estimated from the last known location, speed, and direction. The normal APRS mapping applications don't have navigation capability so they are not too useful if you want to travel to one of the objects.

I think that mentioning APRS only confuses those who are not familiar with it already. The basic requirement is to display objects provided by another application and allow navigation to them. These objects could be in fixed locations or they could be moving. (e.g. car transmitting its location from a GPS receiver) Properties would include latitude, longitude, altitude, speed, direction, name, comment, time last heard, and symbol (house, weather station, car, boat, airplane, etc.)

This looks like an interesting hack to get us going in the right direction: https://github.com/N2ZLC/dire_wolf_to_navit

I was thinking more in terms of UDP messages over the network to feed in only the changes in objects. Generating a complete file of all objects, every time anything moves, doesn't seem like a good idea.

Probably some sort of key/value pairs so only the relevant properties would be reported and it would be extensible. JSON perhaps? Stationary object locations might report their locations every 10 to 30 minutes. Moving objects will report their locations much more frequently, depending on speed and changes in direction. Objects would disappear after not being heard from for some amount of time. perhaps a cay or user configurable.

I think there would be a lot of value to this. For example, you might be chasing a descending scientific balloon and use the navigation system to guide you to its most recent changing position. If you wanted to get really fancy, the current location could be estimated from the last known location, speed, and direction. The normal APRS mapping applications don't have navigation capability so they are not too useful if you want to travel to one of the objects.

I agree!

@Exscotticus Thank you for confirming this. I really had no other way of trying to get involved, than the output data i grabbed from the feed in my area, and gave to Jkoan in Navit Discord group.

Daytime job is keeping me tied.

Is stationary monitoring really a case of priority with Navit? But indeed something like being able to set a static refresh interval could be nice.

I mean for something like emergency or support operations for example, possibly requiring realtime positioning, something like Xastir or Ui-View 32 is there, with very many handy solutions, originating from "deeper" within aprs.

I think mobile operation in any form, might be the priority with Navit? But here as well, if staying stationary with a mobile unit, we would indeed need a way to update.

Force feeding the gps position was a nice solution anyway, for achieving what you looked for. Nice work.

@wb2osz I just actually thought about balloon operations as well.

I have never been involved myself around any of them in my area, but i know a bunch of skywatchers, who have done alot of balloon experiments.

And asked the local radio amateurs to get involved, with setting the balloons up with aprs etc.

The ability to be able to navigate to station position would really come to life here i guess, when the question is rather retrieving the unit.

Another really interesting topic was brought up by Jkoan in Navit Discord. The fact that alot of stations, actually transmit Wx "Weather-Data" could be something of great benefit to Navit.

Who knows, maybe in these times, when amateur radio overall is not seeing its most active days, we could add some flavor, by keeping weather data available from the different stations, in car?

Its all here around us anyway, just gotta grab it, and make it human format ; )

@jkoan You are in to the "low end" iron as well right? like raspberry, arduino, and whatnot?

is there some special stuff that we have to have in mind here, with refresh interval etc ?

That is true, stuff like loading maps, or even a tile is slow in Xastir. I never tested on something like Raspberry.

But stations movement is semi "smooth"

Being able to navigate, with aprs combo, is what brought me to Navit, so i cant say i do not see your point.

Any progress on this?

Good day @Supermagnum. At least from my part, there has been no progress on the Navit side of things, with this.

Although, it is for sure not forgotten.

Any progress on this, or has it stalled completely?

It may also be an idea to use the Polaric Server backend. It has a REST API and Websocket interface.

https://polaricserver.readthedocs.io