`WeatherInfo` separates out additional information in the comment field for easy reference

[CBielstein]

Description

Currently, the WeatherInfo info field object saves the packet comment as the full contents of the APRS comment, including the encoded weather information. This makes it somewhat difficult for the client to access. In the future, consider making the WeatherInfo object trim the encoded weather measurements out of the saved comment string on decode so that the comment can be displayed separately.

Using an example from the APRS 1.01 spec, we could have the following encoded information field for a "complete weather report" (weather report with position): !4903.50N/07201.75W_220/004g005t077r000p000P000h50b09900wRSW

In this case, the comment string begins after the encoded coordinates and symbol information: 220/004g005t077r000p000P000h50b09900wRSW.

Weather information runs through the end of the barometric pressure reading: 220/004g005t077r000p000P000h50b09900.

This leaves wRSW remaining. In the APRS 1.01 spec, this is used to convey the software and hardware used to send the report (w = WinAPRS, RSW = Radio Shack).

However, in practice, hams often put more information in the comment string about who runs the station or other comments.

With our current implementation, WeatherInfo decodes the weather information but leaves the value of Comment as everything after the position (in this example, 220/004g005t077r000p000P000h50b09900wRSW).

For this issue to be complete, we should consider trimming that down so that the weather information is decoded in to the properties and trimmed from the comment, resulting in a Comment value of wRSD.

Notes:

• Barometric pressure is not guaranteed to be the end of the measurements, nor is it even guaranteed to be present. If it is present, it can be a null value with b..... or b. The implementation should support all of that.
• The packet should re-encode exactly as it was before. This shouldn't cause any information to be lost.
• It could also be acceptable to create a new property such as AdditionalComment or OriginalComment to help separate out the comment as it was sent vs. additional information. Only do this if necessary as the goal here is to simplify and make the client understand only as much as absolutely necessary about the APRS protocol.

Acceptance Criteria

• [ ] WeatherInfo decodes comment as just the extra text in the comment field that isn't used for weather content which is decoded by our software
• [ ] Packet still re-encodes to the same thing (i.e. no data is lost by trimming out of the comment)
• [ ] Update the tests and remove any TODOs around this issue

[martelro]

Hi. I'd like to work on this issue (please assign to me!), and I have a question. Hopefully I'm not overthinking this...

From what I've read in the spec and seen in practice, the user comment comes at the end of the weather info string. For that I can write code to figure out where the weather "data" stops and the comment begins. Theoretically, however, it's possible that someone could put text in the comment that could be construed as weather data:

...b10232wRSWs123 or ...b10232ws123RSW

Perhaps "s123" was meant to be some type of versioning, but it could also be interpreted as a snowfall measurement. Is it correct to assume that once the weather data ends, the remaining text is the user comment?

So, in the examples above, the user comments would be:

wRSWs123 ws123RSW

I think currently the software will process it as a measurement, but I'm not sure what to do with the text if it's "in the comment".

Granted, this is a bit of an edge case, but throught I'd ask for guidance with the user comment being free form text and all.

Thanks!

[CBielstein]

@martelro Great questions. I wish I knew the answer here. I wrote this up thinking it'd be nice to do but not being sure how to do it. 😅

It's tricky because some packets are nice and use a space or a non-alphanumeric character to delineate additional comment and some don't. It just doesn't appear to be standardized in the 1.01 spec. (Though it's possible that the APRS 1.1 or APRS 1.2 updates do cover this, but I'm much less familiar with them as we haven't even covered the original 1.01 spec yet. 😅)

To answer your question, I'd suspect we can be pretty safe in saying that the comment is after the data, not in the middle of it. But since it isn't standardized, I think it's open to some interpretation, trial, and error. The short of it is, I'm open to suggestions here. 😊

For additional musings... The more I'm thinking about it, perhaps the best approach is to be conservative (especially as this packet is in prerelease versions and we can tinker). So perhaps it's a new property (WeatherInfo.AdditionaComment or something similar), let the data try to parse out from everything and then detect the comment. So if we hit something like "b10232 This is my packet! s123", then we would parse out:

• Barometric pressure: 10232
• Snow: 123
• Additional comment: "This is my packet! s123"

So that "s123" is used twice...but at least we don't discard something or make a call and lose context...but feel free to propose something else if it makes more sense.

[martelro]

@CBielstein That works for me. 😊

If measurement data is in the comment, I will preserve it in the comment and let it also be treated as a measurement. Thanks!

[CBielstein]

@martelro Awesome! I'm looking forward to seeing what you come up with!

I also just merged #136 to resolve the issue of flaky unit tests due to timeout. If you're bumping in to that, ensure you pull the latest from the main branch to resolve the problems. 😃

[CBielstein]

Resolved by #137 . Thanks so much @martelro !