New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please add compatibility with input from a APRS receiver. #982
Comments
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 should be attractive to those who are running AIS equipment also as that speaks NMEA. |
Marqvist is adding Navit support for Open modem: |
Should be labelled enhancement. |
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. I have been in contact with the maker of the PicoAPRS V3 but no help from him. |
Have you uploaded the code somewhere? Then i could take a look at it. |
Good day everyone. I recently bumped in to Navit, while being on the hunt for navigation software. 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. 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: |
For this to work, Navit must accept moving objects, from another application. |
I think that mentioning APRS only confuses those who are not familiar with it already. 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. Daytime job is keeping me tied. Is stationary monitoring really a case of priority with Navit? 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? |
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. 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? 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. 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. |
Good day @Supermagnum. 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. |
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
The text was updated successfully, but these errors were encountered: