-
Notifications
You must be signed in to change notification settings - Fork 38
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
Comments
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
Rain units in reports over the air are supposed to be in hundredths of an inch.
|
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
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
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.
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. |
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
Here is the output.
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
The text was updated successfully, but these errors were encountered: