Amateur Radio APRS Parsing Plugin

[Automated]

Amateur Radio APRS Parsing Plugin

How about a HS3 update for this? I have been running the HS2 version for the past year, and it works great.

[ORNVM]

Has anyone integrated aprs into hs3?

[Automated]

You can do it with this HS2 plugin, and then using Jon00's HS2-HS3 connector. It is not optimal for sure (and this HS2 version even has some bugs although is usable), but it seems the OP is missing in action.

I tried to email him a while back and he indicated being quite busy with real life.

EDIT: Actually, I see he has posted recently, so he is still around. If enough others came into this thread and showed support for HS3, then perhaps we can persuade him to update it for HS3! I would even be willing to pay for the plugin.

[mloebl]

Hey Guys,

I got your email, sorry been busy and lost track of the time Life has been pretty crazy since I started a new job and 2 weeks later had a kid so a lot less free time to tinker. I did start rewriting the plugin this weekend with the latest plugin sample and have it compiling and registering. I also repurposed an existing Linux box and finally licensed it for HS3 so I have a box to use. With the ability to enable/disable plugins in HS3, and using WinSCP, I can test the plugin pretty quickly which is nice. (Sort of funny as my main desktop is Linux, running Windows VM to do dev work, then using Winscp to copy the file to another linux box...)

I tried to port it last year when the HS3 beta was going on, got frustrated, and sort of threw it all out and started over again with the new plugin samples. Here's sort of the state of things I found so far.

1. Web pages require a total rewrite, since I opted for ASP.NET in HS2... I decided when I first started looking at this last year in HS3 to use their method to create web pages, needless to say a LOT of work here to be done. I may rethink some things and scale back support, we'll see.
2. My MS Access database library is blowing up spectacularly on Linux. Need to see what I can do to port it over, or, potentially make people mad at me and go SQLLite instead with a fresh clean database that won't port from HS2.
3. Core APRS decoding is unaffected unless there's something in there Mono doesn't like so should just work.
4. Need to check to make sure Geonames API still works and nothing changed on their side. Considering HS2 is still working, guessing this should also just work.
   
5. Events need to be totally rewritten from scratch using the new method. Need to wrap my head around how it works now.
   
6. Creating Devices is different as well, again need to wrap my head around how it works.
7. It will natively support Linux out of the box as well is the plan, so may need to rework some things as found files in a couple places that shouldn't be there.

Not going to be quick as I had hoped. Not great news, and no time line yet, but I'll try posted as I find / do things.

[ORNVM]

Awesome, that is great to hear it is a possibility!

[Automated]

Great news, and thanks for the update.

[mloebl]

Just a quick update on where I am.

• Believe I reworked all directory paths to support Windows or Linux automatically
• Moved file locations to be the HS recommended locations for config, database, binaries, etc to make installations much cleaner
• Updated my Database dll to support SQLite and currently testing and working out an Interop file dependency issue. Right now I am not planning on migrating the old access database over to SQLite, but not sure if that's really a huge deal anyways.

[mloebl]

Update:

• Confirmed new SQLite database calls are working. Will have to deal with Windows vs Linux versions of the DLLs when ready to public test / release
• APRS processing is now running. For some reason one of the thread calls I was using isn't working correctly (maybe a Mono thing?) but with it disabled seems to be working fine
• Device updating is now preliminarily working with APRS traffic. This means devices added will get updated automatically for their location when packets come in for them. Redid some of the device updates/searching to be hopefully more efficient and lower overhead.
• Plugin configuration web page is working for save settings as such. Simple triumph, yet satisfying

Next Steps:

• Clean up device updating and try to make updating device from FindU native from device itself
• Fix APRS icon locations
• Wrap my head around events and get it working...
• Redo mapping with current Google Maps API. Hopefully gutting the messy old stuff won't be painful

[ORNVM]

Awesome! Thanks for the updates. Can't wait to play with it. Does the app support aprs traffic from a local tnc on the hs3 computer, or is it just pulling from aprs-is, or does it work with either?

[mloebl]

Awesome! Thanks for the updates. Can't wait to play with it. Does the app support aprs traffic from a local tnc on the hs3 computer, or is it just pulling from aprs-is, or does it work with either?

Currently just APRS-IS/xastir (I'm actually running an javAPRSSrvr on a Beagle Bone Black in the attic.) One feature I was thinking would be the ability to support multiple interfaces within the plugin. Since the APRS packets are processed generically with a bunch of ingoing/outgoing queues, the plugin doesn't really care the source (whether IP or RS232). I think would just be a matter of adding another field for source/destination to track where it came from. I'll see if I can dig into what that would take and let you know.

Right now I only really have one TNC-X currently in use, and a Raspberry Pi TNC-X cape, so not a lot to test with. Somewhere in the basement I think I have an old KPC3 and TinyTrak3; just need to figure out where they ended up. I know *somewhere* in my SVN repo I wrote a simple RS232 app to communicate to an Arduino for sending messages back and forth, thinking I may be able to steal that if I can find it...

[mloebl]

Spent last few days rewriting the engine for handling multiple paths for traffic. Not done yet and actually split the code out to a test app so I can prototype it in case it's a major disaster Thinking of moving server information from the config file into the database to make managing multiple hosts easier.

Right now I have multiple APRS-IS connections, individually tracking APRS packets and connection status. Each one has it's own individually managed queue. Not sure if my logic yet has been thoroughly hashed out as a good or terrible idea, but the hope is messages can be easily sent to any server (or potentially comm port) without any crazy tracking of who and what goes where.

The real test will be when I add it back into the main plugin and start adding in the HS3 device and database updates and making sure they don't freak out...

Sorry for the long post and stream of consciousness.

[Automated]

Thanks for the update. I am happy to test something whenever you get that far.

[mloebl]

Thanks for the update. I am happy to test something whenever you get that far.

I'll let you know; at least a few weeks out before that I have a bad habit when looking at older code getting annoyed and refactoring it. At some point realize just go with what I got. Also really bugging me that it's VB, may later port to C# which I prefer.

[Automated]

Is there a beta ready? I can privately test it also if there is something alpha ready.

[Darth Vader]

I too would be willing to alpha test.

I am running HS3.

Trying to find a way to change my signature.