WX decoding; velocity speed; ra log export

[DL2MF]

Hi Georg,

since a few days I'm using your great APRSdroid app after using another OS on my mobile phone during the past few years.

It's really a great app and I like to use APRS for special purposes on a phone, the implementation of SmartBeaconing works perfect, my other devices (handheld and mobile TRX from both vendors currently supporting APRS on ham devices) can't compete with this on my Android.

We had a great event with our High-Altitude-Amateur-Radio-on-Balloon HAAROB 2012 last weekend, where APRS was used at it's best. This is one of these special purposes, where APRSdroid is a very valuable tool - and it gives some ideas for further improvements.

It would nice to have:

• decoding of WX-Sensor data like Yaesu/Kenwood support this in FTM-350 / TM-D710
• tracking of a single callsign-ssid would be possible on a full-screen (to monitor the balloon)
• velocity speed would be calculated and dsiplayed depending an ascending/descending rate
• logging of raw packets of a single call (sensor data of an object) might be also nice (to SD card?)

If I did miss some features, that maybe already included, please give me a hint. If you like to discuss some of the ideas, I'll be glad to support you. Some improvements to the GUI already have been discussed, so I don't rather mention to this.

73 de Meinhard, DL2MF

[ge0rg]

Thank you for the feedback, Meinhard.

I have plans to make a major UI redesign, which will also include decoding of station info. Tracking of a single station works already by tapping the "Map" button on the station details page. However, meta data is not shown there (yet). I will think about implementing a special balloon tracking mode as well, I had already some suggestions for doing so.

Raw packet logging was no priority for me yet, as you can obtain most data from APRS-IS anyway, and there are desktop tools available. If you want to export the live data APRSdroid got via AFSK, and your phone is rooted, you can grab /data/data/org.aprsdroid.app/databases/storage.db from the phone, it is an SQLite3 file containing the raw log as well as parsed positions and messages.

[motormayhem]

Any update on decoding WX station info? Since APRSdroid works with backcountry navigator I use it a lot for off highway/camping messaging and position reporting. It would be great to decode the weather data from surrounding weather stations and be able to read it.

[ThreeSixes]

+1 on WX reports. That's an important feature for a lot of APRS users, and are some of the most common stations you get reports from.

[arodland]

I don't know Scala, I don't know Android dev, and I barely know GUI, but I do know Java, and parsing, and how to read the APRS spec. If I implemented WX decoding in javAPRSlib would that make this more likely? :)

[ge0rg]

@arodland that would be a great addition and a prerequisite for support in APRSdroid. @ab0oo is currently working on a large refactoring that will also affect APRSdroid, but should make the integration of WX less complex: https://github.com/ab0oo/javAPRSlib/issues/15

However, this is only the first step of the task:

1. Have a parser for WX packets in javAPRSlib
2. Interpret parsed WX packets in APRSdroid
3. Store the interpreted data into a yet-to-be-defined database format
4. Create a dedicated UI to display weather data

[ab0oo]

I don't know Scala, I don't know Android dev, and I barely know GUI, but I do know Java, and parsing, and how to read the APRS spec. If I implemented WX decoding in javAPRSlib would that make this more likely? :)

Ping me over on https://github.com/ab0oo/javAPRSlib/issues/15 and we can work through it. The v2.0 branch that's checked in should completely handle WX decoding.

[penguin359]

I have been working on WX for a little bit, though not much progress. However, I have a few ideas on how to best implement it, but should discuss the best approach to it. And, yes, this part should probably be first discussed on javAPRSlib. I had implemented TDD in that a while back and was going to use that to start testing out different implementations of WX. The biggest question I had was how to structure the class hierarchy. There are 3 WX formats, if I recall correctly, one of which is a direct extension of regular location reporting. While it might be nice to have a since [abstract?] class for WX reports that give a common interface, I think we'd still want them to match code looking for location packets if and only if it is that format. But the other formats that don't extend location reports, it would also be nice if they implemented the same interface so they can be equally handled for the basic WX reports despite having a completely different on-wire representation/packet type.

This is just me pulling from the top of my head and what I remember, but I would like to get back to this and work together to find the best solution.

[arodland]

Yeah, the three basic options are:

1. A full position-and-weather (and maybe time) packet. Not terribly common on the air, but when CWOP reports get passed to APRS-IS they come out in this format.
2. A station which is separately beaconing its position sends a positionless weather packet. The most common thing for digis and home stations with associated weather stations.
3. A station sends an object report for a named object with a position and also a weather report. Most commonly used with the storm track objects (hurricane or tropical storm) with their unique wind/gust/central pressure format (e.g. see current object MINDY), but can also be used with the regular weather report format.

Cases 1 and 3 are pretty much self-contained and just require a way to hang weather off of a position or an object (which already have lots of attributes in common); case 2 requires a way to associate the two packets, somewhat (but not exactly) like the way an AFRS frequency is remembered for a while even if it wasn't sent in the most recent position.

[Wi5eJ4rl]

Hello,

Two years and still no WX in human readable format. It shouldn't be so hard?

Please add this simple and functional feature.

[ab0oo]

Step one can be taken care of here:

https://github.com/ab0oo/javAPRSlib

I look forward to reviewing your Java code submission, please make an attempt to follow the established formatting and conventions in the existing code, as it makes it easier for the other devs to review your code and merge it into the mainline. There are some ambiguities in the APRS Spec regarding wind speed, I think.  When you get to that part of the parser, please feel free to bring them here or to the primary APRS reflector for discussion.

de John Gorkos AB0OO

On 6/25/23 01:40, Wi5eJ4rl wrote:

Hello,

Two years and still no WX in human readable format. It shouldn't be so hard?

Please add this simple and functional feature.

— Reply to this email directly, view it on GitHub https://github.com/ge0rg/aprsdroid/issues/39#issuecomment-1605941732, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC7HEKHC2UXMIVLQH5ES4TXM72PFANCNFSM4AAQHEHQ. You are receiving this because you were mentioned.Message ID: @.***>