Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rate Thread Display Modes
Old 04-08-2015, 00:14   #1
Registered User

Join Date: Aug 2015
Posts: 4
APRS Plugin Development

First off, I'm new to the forum, and this is my first post. My name is Tyrell, KD7KUJ, and I'm a beginning Python developer. I have a background in Geographic Information Systems (GIS), and am training for the leap into web application development.

As part of an educational project, I am interested in building a proper plugin for APRS (Automatic Packet Reporting Service, similar to AIS but for amateur radio operators). For my purposes, "Proper" means support for the various Kenwood and AvMap sentences supported by the Kenwood series of APRS radios and the AvMap G5 and G6 APRS models. This will largely "solve" the problem of having to treat WPL sentences as EITHER static waypoints, or as dynamic, updatable ones...

Anyway, those are my goals... But I only speak Python, PHP, and JavaScript... So I would like to program my plugin in wxPython, and I will largely base myself off of functions from DIXPRS (https://sites.google.com/site/dixprs/), which is nothing if not a decent start at APRS support on Python.

I will be decoding an APRS stream (From a TNC and/or from APRS-IS), parsing it into currently unsupported proprietary sentences ($PAVP* and $PKWD*), plotting them on the chart display, and then forwarding them to OpenCPN's NMEA stream, where they can be sorted and sent off to a connected G6. I would also like to support messaging on the AvMap G6 as well, so I will need to be able to read FROM the NMEA stream, parse the NMEA sentences ($PAVP*) into APRS messages, and send them off to the air or APRS-IS interfaces.

Here's my question: What's the best way for me to connect with the NMEA stream?

I had two thoughts... 1) Try to write bindings to the plugin API header (But I'm not very good at C, and so I'm not sure how successful I would be; Also, I see functions in the API that write TO the NMEA stream, but I can't figure out how the sample plugin is READING it...), or 2) Forget the API altogether, and connect to OpenCPN's TCP socket (And be stuck with all of the TCP/IP overhead, and associated performance hit; Is there some way to connect to OpenCPN through a Unix-style socket?). It's entirely possible I'm over-complicating the problem... What would others suggest?Here's my question: What's the best way for me to integrate with the NMEA stream?
__________________

__________________
alawatsakima is offline   Reply With Quote
Old 04-08-2015, 08:40   #2
Registered User

Join Date: Feb 2010
Location: On the go. Not in Prague.
Posts: 4,016
Re: APRS Plugin Development

Tyrell...
What OpenCPN has now is an implementation of FS#964 : HAM Add APRS support to OpenCPN - wxfax, ais, wx, winlink - It is integrated into AIS code, which is part of the program core, not a plugin. To start with, even though I have written this code, I am not a radio guy and know close to nothing about APRS and for most part already forgot what I found out during the implementation.
What exactly is the difference between the kind of data in the sentences you talk about and what comes in the "abused" WPL? Did they replace it or is it just something specific to a couple of radios and the rest of the world still uses WPL?

OpenCPN does not embed Python - you can't currently implement a plugin in it. If you want to, you would have to implement the embedded Python part first, probably in one of two ways
- In the core, allowing pure python plugins. This involves quite some C++ coding
- In a minimal C++ plugin serving as a glue to your python code (either embedding python or exec-ing an external python program and communicating with it)
I'm not at all sure about how wxPython would play in the embedded scenario. For drawing on the chart you also need to be able to use the OpenGL canvas, never did that in python.

Now to the details of your implementation:
- If you are going to implement a plugin, you will get the NMEA messages pushed from the API and can inject yours through it (Look at the VDR plugin, which does just this and pretty much nothing else)
- If you decide to implement a separate program, forget about unix sockets - they are not portable to Windows. Implementing a network server/client in Python is simple and given the amount of traffic you can get from APRS, the overhead of network communication is unlikely important. You will also not be constrained to a single machine and your product will be reusable even without OpenCPN.

Being you, I would probably learn that needed bit of C++, to do this you need just some "informed copy/paste/modify" from other places

Anyway, whatever way you chose, just keep asking if needed, we will try to help you as much as possible.

Pavel
__________________

__________________
nohal is offline   Reply With Quote
Old 04-08-2015, 11:47   #3
Registered User

Join Date: Aug 2015
Posts: 4
Re: APRS Plugin Development

Wow, I really bit off a very ambitious project! It's all a bit overwhelming right now. But I'm more than willing to talk through this stuff, and maybe the current support can just get expanded. Maybe... I mean, lots of logic has to go into decoding the APRS stream into usable NMEA sentences.

The specification for these sentences isn't published to the internet anywhere I can find it, but it's publicly available if you know who to ask; I got it from Don, W6GPS, from the AvMaps G6 APRS Yahoo Group. I have it on my website (https://sites.google.com/site/kd7kuj/home/files?pli=1), and it can be downloaded directly at https://sites.google.com/site/kd7kuj...edirects=0&d=1

Basically, $PKWDWPL sentence replaces the $GPWPL sentence, and provides the stations location, altitude, bearing, speed, and their APRS Symbol. It was introduced on Kenwood's TM-D700 and TH-D71, and is now also supported by the TM-D710 (And revisions), the TH-D72, and (I believe) the TS-2000. It's also supported by the Byonics TinyTrak3 and TinyTrak4, as well as all(?) of Argent System's OpenTracker TNCs.

AvMap has several sentences that support APRS messaging from the AvMap G5 APRS and AvMap G6 APRS GPS units. These GPS units were designed for the purpose of supporting as many APRS features as possible, and so they use the $PKWDWPL sentence when it's available; To support messaging from the screen of the GPS, they use several $PAVP* sentences to indicate support for, and the sending of, messages to and from the GPS. These sentences are NOT supported by the Kenwood radios, but they ARE supported by the Byonics and Argent Systems TNCs when they are so configured.

I don't have any statistics, but based on an informal survey of hams I know, I would say that a VERY large majority of dedicated APRS stations are using Kenwood, Byonics, or Argent Systems TNCs, and therefore supporting these sentences provides a better experience for users relying on NMEA.

The only major manufacturer of APRS equipment that does NOT support these sentences is Yaesu; However, I might argue that they only skipped it because there was only 1 current GPS unit that supports them, the AvMap G6 APRS, and it's pretty far into it's lifecycle at this point.

There are NO software implementations that support these sentences, and I suppose mine would be the first... It frustrates me having to use an external TNC when I have a perfectly good sound card.

All of that said, the APRS specification doesn't list these sentences, and compliance has been voluntary with the intent of supporting the AvMap GPS units. It can only stand to reason that if a free software implementation got popular, the feature would be more widely adopted by manufacturers.
__________________
alawatsakima is offline   Reply With Quote
Old 04-08-2015, 20:00   #4
Registered User

Join Date: Feb 2010
Location: On the go. Not in Prague.
Posts: 4,016
Re: APRS Plugin Development

Tyrell...
Am I missing something obvious thinking that all we need is to implement the PKWDWPL sentence to be done with the position reporting part of APRS?
The PAVP* seem to be all heartbeat and messaging related, which IMO is kind of irrelevant for OpenCPN's purpose of being a navigation package and so if implemented at all, should very clearly be an optional plugin or a completely separate tool.

Pavel
__________________
nohal is offline   Reply With Quote
Old 04-08-2015, 20:49   #5
Registered User

Join Date: Dec 2013
Location: Gulf Breeze, Florida
Boat: Dufour 43
Posts: 39
Re: APRS Plugin Development

Interesting, APRS user here as well, I did not know OpenCPN had this weaved into the code with the AIS. I will have to dig deeper. On my boat I have APRS feeding into a separate serial port on the same computer that I run OpenCPN. I switch windows between the two programs.

Question to the OP, why use the G6 at all? The main advantage would be in a vehicle(boat) with no computer to have a map display and send messages. If you have a computer there would be no need for the G6. If you need to send messages, use the computer with available programs for APRS messaging?

Maybe I missing something? If you wanted to still use the G6 could you not bridge the serial ports from within OpenCPN? Then only pass all data between the ports without filtering? With no need to alter the CPN code for the message functions?

Again, thanks for re-bringing APRS/OpenCPN to light for me, I will be watching the conversation for developments.
__________________
sailsunfurled is offline   Reply With Quote
Old 04-08-2015, 21:50   #6
Registered User

Join Date: Aug 2015
Posts: 4
Re: APRS Plugin Development

Quote:
Originally Posted by nohal View Post
Tyrell...
Am I missing something obvious thinking that all we need is to implement the PKWDWPL sentence to be done with the position reporting part of APRS?
The PAVP* seem to be all heartbeat and messaging related, which IMO is kind of irrelevant for OpenCPN's purpose of being a navigation package
Seems fair to me; I thought it MIGHT fit in with AIS Area Messaging, but rereading the description on the AIS page, it really doesn't fit as cleanly as I had originally thought. (Support for APRS Objects may fit into the AIS Area Message paradigm, but I don't know of any good APRS Object over NMEA implementations)

Supporting only the PKWDWPL sentences directly in OpenCPN seems reasonable, and would support the widest range of "Talkers." Messaging certainly feels like a stronger fit in a plugin or external app anyway.

I think the hardest part might be adding in support for symbols, as APRS has it's own symbols, listed in two tables, which ARE part of the APRS standard, and I can provide links if anyone needs them.

Quote:
Originally Posted by sailsunfurled View Post
Question to the OP, why use the G6 at all? The main advantage would be in a vehicle(boat) with no computer to have a map display and send messages. If you have a computer there would be no need for the G6. If you need to send messages, use the computer with available programs for APRS messaging?
In the big scheme of things, I just hate switching windows (Much less switching devices) simply to achieve all my geo-spatially interesting things. If OpenCPN gets ANY support for APRS, then it might as well be complete, so people who don't REQUIRE a G6, can get away without one.

However, many boaters find a need for multiple chartplotters/terminals for their NMEA data; Maybe have a terminal at the helm, and another in the cabin. Maybe the G6 would fill a need somewhere in that usecase.

Additionally, I find value in being able to interface standard VHF and a high speed UHF radios simultaneously through two TNCs and feed both into the same G6. I suppose one COULD do that through OpenCPN currently, but if the sentences are passing through anyway, then why not add them to the display inside OpenCPN as well?

From a completely different angle, when I got my G6, I was rather annoyed at needing a TNC at all... I mean, the Raspberry Pi and a cheap soundcard is cheaper than a TinyTrak4... Why can't I pipe it through some software and spit out NMEA for the G6? No software yet exists, and if I'm going to write some, I feel that using OpenCPN seems a reasonable transport to target.

Finally, the big LCD display on my Raspberry Pi uses more power when it's on... So if I only need the features of the G6, there is value in turning the display off for a while.

But moreover... Once you decide that OpenCPN deserves such support, then supporting the G6 would seem to come almost automatically, so... Why NOT have both?
__________________
alawatsakima is offline   Reply With Quote
Old 21-09-2015, 08:46   #7
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 9,369
Re: APRS Plugin Development

alawatsakima
Any further thoughts or progress?
__________________
rgleason is offline   Reply With Quote
Old 21-09-2015, 10:45   #8
Registered User

Join Date: Aug 2015
Posts: 4
Re: APRS Plugin Development

I'm working my way through the C++ course on Lynda.com, and I have a book on wxWidgets that I'm planning on reading next. But I'm also a full time student, a dad, and I have work... So progress is slow.

My thought is that support for Kenwood style waypoints should be added directly into OpenCPN. In fact, this is important enough to me that I would be willing to put a bounty on the feature... But I'm a poor college student :/

So... I guess the short answer is... Nothing much has changed since my last post. Sorry :/
__________________
alawatsakima is offline   Reply With Quote
Old 21-09-2015, 13:21   #9
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 9,369
Re: APRS Plugin Development

It sounds like you are making progress to me. thanks for the tip: C++ course on Lynda.com
__________________

__________________
rgleason is offline   Reply With Quote
Reply

Tags
men, plug

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenCPN PlugIn Development bdbcat OpenCPN 78 29-07-2017 03:15
Display your boat on SpotWalla using callsign and APRS sinbad7 Navigation 1 04-03-2013 08:52
Plugin Development Question pelle2004 OpenCPN 3 04-07-2012 02:00
New Plugin Development on Linux globalkeith OpenCPN 5 03-05-2012 08:16
Ham Question: Satellite, Digital, Gateway, EchoLink, ILRP, APRS ? SaltyMonkey Marine Electronics 79 22-11-2010 14:07



Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 23:49.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.