Skip to content
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

Weather packets not decoded correctly? #80

Open
hemna opened this issue Apr 10, 2023 · 2 comments
Open

Weather packets not decoded correctly? #80

hemna opened this issue Apr 10, 2023 · 2 comments

Comments

@hemna
Copy link

hemna commented Apr 10, 2023

Hey I'm looking at decoding and dumping weather packets to a DB and was decoding streams of packets from aprsis.

I noticed that it seems the wind speed and gust speed isn't part of the weather dictionary as decoded by the lib, even thought it looks like it should be.

Here is my sample script

import aprslib
import datetime
import time


pkt = "KC7WRB>APRS,TCPIP*,qAC,AMBCWOP-2:@101832z3849.38N/11920.70W_150/012g015t075r000p000P000h25b10233L618AmbientCWOP"

decoded = aprslib.parse(pkt)

print(f"Raw = '{pkt}'")
print(decoded['packet_type'])
print(decoded)

Here is the output.

Raw = 'KC7WRB>APRS,TCPIP*,qAC,AMBCWOP-2:@101832z3849.38N/11920.70W_150/012g015t075r000p000P000h25b10233L618AmbientCWOP'
weather
{'raw': 'KC7WRB>APRS,TCPIP*,qAC,AMBCWOP-2:@101832z3849.38N/11920.70W_150/012g015t075r000p000P000h25b10233L618AmbientCWOP', 'path': ['TCPIP*', 'qAC', 'AMBCWOP-2'], 'via': 'AMBCWOP-2', 'messagecapable': True, 'raw_timestamp': '101832z', 'timestamp': 1681151520, 'format': 'uncompressed', 'posambiguity': 0, 'symbol': '_', 'symbol_table': '/', 'latitude': 38.823, 'longitude': -119.345, 'course': 150, 'speed': 22.224, 'comment': 'AmbientCWOP', 'weather': {'wind_gust': 6.7056, 'temperature': 23.88888888888889, 'rain_1h': 0.0, 'rain_24h': 0.0, 'rain_since_midnight': 0.0, 'humidity': 25, 'pressure': 1023.3, 'luminosity': 618}, 'raw_dict': {'raw': 'KC7WRB>APRS,TCPIP*,qAC,AMBCWOP-2:@101832z3849.38N/11920.70W_150/012g015t075r000p000P000h25b10233L618AmbientCWOP', 'from': 'KC7WRB', 'to': 'APRS', 'path': ['TCPIP*', 'qAC', 'AMBCWOP-2'], 'via': 'AMBCWOP-2', 'messagecapable': True, 'raw_timestamp': '101832z', 'timestamp': 1681151520, 'format': 'uncompressed', 'posambiguity': 0, 'symbol': '_', 'symbol_table': '/', 'latitude': 38.823, 'longitude': -119.345, 'course': 150, 'speed': 22.224, 'comment': 'AmbientCWOP', 'weather': {'wind_gust': 6.7056, 'temperature': 23.88888888888889, 'rain_1h': 0.0, 'rain_24h': 0.0, 'rain_since_midnight': 0.0, 'humidity': 25, 'pressure': 1023.3, 'luminosity': 618}}, 'from_call': 'KC7WRB', 'to_call': 'APRS', 'packet_type': 'weather', 'wind_gust': 6.7056, 'temperature': 23.88888888888889, 'rain_1h': 0.0, 'rain_24h': 0.0, 'rain_since_midnight': 0.0, 'humidity': 25, 'pressure': 1023.3, 'luminosity': 618}

As you can see the wind_speed is missing and the wind_gust is set to 6.7056 and speed is set to 22.224.
I would expect the wind_speed to be set to 12 and wind_gust is set to 15. I was able to confirm this from
what aprs.fi decodes the packet from as well.

According to http://www.aprs.net/vm/DOS/WX.HTM
The format looks like it should be

   _CSE/SPDgXXXtXXXrXXXpXXXPXXXhXXbXXXXX%type NEW FORMAT APRS793 June 97
                                              NOT BACKWARD COMPATIBLE



Where: CSE/SPD is wind direction and sustained 1 minute speed
t is in degrees F
r is Rain per last 60 minutes
p is precipitation per last 24 hours (sliding 24 hour window)
P is precip per last 24 hours since midnight
b is Baro in tenths of a mb
h is humidity in percent. 00=100
g is Gust (peak winds in last 5 minutes)
# is the raw rain counter for remote WX stations
See notes on remotes below
% shows software type d=Dos, m=Mac, w=Win, etc
type shows type of WX instrument
@hemna
Copy link
Author

hemna commented Jul 13, 2023

The course and speed is in mph as well. confirmed this from the WX.TXT document comment.

http://www.aprs.org/APRS-docs/WX.TXT

The on-air APRS WX protocols, however, 
still will be in MPH and F.  Also, the ALARMS are compared to MPH 
and F values.

Rain units in reports over the air are supposed to be in hundredths of an inch.

RAIN VALUES:  Rain is counted in increments of 0.1 or 0.01 inch or 1mm.
but reports all values in 0.01 inches over the air.

hemna added a commit to craigerl/aprsd that referenced this issue Jul 13, 2023
aprslib incorrectly decodes weather packets and doesn't provide
wind_speed or wind_direction from the CSE/SPD 7 bytes in the APRS
packet.  This patch puts a temporary fix in place until the
aprslib pull request lands and is released.

rossengeorgiev/aprs-python#80

rossengeorgiev/aprs-python#81
hemna added a commit to craigerl/aprsd that referenced this issue Jul 13, 2023
aprslib incorrectly decodes weather packets and doesn't provide
wind_speed or wind_direction from the CSE/SPD 7 bytes in the APRS
packet.  This patch puts a temporary fix in place until the
aprslib pull request lands and is released.

rossengeorgiev/aprs-python#80

rossengeorgiev/aprs-python#81
shackrat added a commit to shackrat/aprs-python that referenced this issue Sep 17, 2023
Unroll proposed weather packet parsing fixes for PR#81 (Issue rossengeorgiev#80).

Course and Speed are ignored by parse_data_extentions() by when either value is '000'.  I.e. 000/000 is considered not relevent an is ignored.  When either value is 000, course or speed is set to None.

It is possible for a weather report to have a speed of 0, meaning no wind.  This should still be captured as it's relevent for a weather report.  Course can also be 0, since some weather stations will report 0 for direction when speed is also 0.

The core of the issue is that parse_data_extentions() ignores course and speed as noted above, AND it trims the course/speed from the body string.  parse_weather_data() still looks to parse course/speed, but cannot when it's been removed by parse_data_extentions().  This change duplicates the contents of "body" so both parse_data_extentions() and parse_weather_data(body) have the appropriate body to parse.
@shackrat
Copy link

I understand the intent of the proposed PR however it doesn’t completely solve the issue..

It is possible for a weather report to have a speed of 0, meaning no wind. This should still be captured as it's relevant for a weather report. Course can also be 0, since some weather stations will report 0 for direction when speed is also 0.

What is happening is that parse_data_extentions() ignores course and speed as for position reports those values are considered to be not valid, thus it trims the course/speed data from the body string. However parse_weather_data() still looks to parse course/speed (000/000), but cannot as that portion of the message was been removed by parse_data_extentions().

My proposed change duplicates the contents of "body" so both parse_data_extentions() and parse_weather_data(body) have the appropriate message string to parse. This causes parse_weather_data() to return proper wind_speed & wind_direction values 100% of the time, even if they’re zero, which is valid data for WX reports.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants