Weather packets not decoded correctly?

[hemna]

Weather packets not decoded correctly?

[hemna]

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.

[shackrat]

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.