[Xastir] Davis weather not posting rain totals properly (Curt, WE7U)

Tue May 8 13:44:21 EDT 2012

On Tue, May 08, 2012 at 09:41:10AM -0700, we recorded a bogon-computron collision of the <aa9vi at yahoo.com> flavor, containing:
> Hi Curt, correct.? If you see the Third item you quoted? "2009-05-19 13:47? tvrusso"? below I am running the 6540 Weatherlink and the meteo/db2APRS interface is not needed.? The 6540 from Davis spits out a pure APRS text line that Xastir is supposed to process directly, similar to the Peet data where it does not require a 3rd party interface program. 
> 
> I think there is something in wx.c that is not processing the rain portions of the data string from the Davis 6540 serial interface properly.? Since I didn't write the code I don't quite understand exactly where that issue resides.? 

I wrote that code.  A local user who had the APRS Data Logger helped me test 
it back then (and in fact was the person for whom I added the feature).  It
worked when we tested it out, but then we live in a desert and rain is almost
always 0.  This person still has the data logger, but no longer runs Xastir,
so I can't enlist his help in finding the issue (he may still be subscribed
to this list, though, and maybe will volunteer to get Xastir running at
home again --- but our rainy season is still months away and that might not
help).

The code itself does attempt to decode rain data.  The line in question is:

           if (sscanf((char *)data,
                       "%*27s%3s/%3sg%3st%3sr%3sp%3sP%3sh%2sb%5s.DsVP",
                       weather->wx_course,
                       weather->wx_speed,
                       weather->wx_gust,
                       weather->wx_temp,
                       weather->wx_rain,
                       weather->wx_prec_24,
                       weather->wx_prec_00,
                       weather->wx_hum,
                       weather->wx_baro) == 9){

where it's looking for the rXXX pXXX and PXXX components and parsing out
the fields.

> The changelog indicates a patch.? Is there a new wx.c?? The version I have is "wx.c, v 1.73 2010/08/14? 23:21:18 we7u Exp $"

The patch refers to the change created by that commit.  Some folks who were 
not running CVS Xastir could install the update without switching to CVS
by applying the single set of diffs.

> I am willing to be a guinea pig and run a patch to test it if you guys can give me one to test.? Can you or Tony please take a look at the data being processed for the r, p, and P parts of the data string for the Davis 6540 Weatherlink section of the code??? Like I said, the wind, temp, humidity, barometer parts of the data are being processed properly.? The rain parts are the only ones in question.

I have no patch for you to test, or even any idea what can be going wrong
yet.

Please try enabling debug level 1 (File->Configure->Change Debug Level)
and watching for the following debug output in your terminal window (this
assumes you're launching Xastir from a command line window not a desktop
shortcut, so that Xastir's output will show up somewhere):

              if (debug_level & 1)
                fprintf(stdout,"Davis APRS DataLogger Decode: wd-%s,ws-%s,wg-%s,t-%s,rh-%s,rt-%s,h-%s,ap-%s,station-%s\n",

                        weather->wx_course,weather->wx_speed,weather->wx_gust,
                        weather->wx_temp, weather->wx_rain,
                        weather->wx_rain_total,weather->wx_hum,weather->wx_baro,
                        weather->wx_station);

This should show all the decoded data immediately after it's received from 
the weather station.  If that all looks correct, then the problem is not
specific to the Davis APRS Data Logger code, but is happening downstream and
may be difficult to track down.  If it's wrong, then the problem is in the 
decoding right in this block and should be easily fixable.

Please post the results.

The inversion of pXXXPyyy to PyyypXXX you observe is not specific to the
Davis device.  Once Xastir has the weather data parsed from any weather
station, a single function re-assembles the data into a new packet for
transmission.  This code is in the function wx_tx_data1 in wx.c, and
it explicitly puts the rain_00 and rain_24 data in that order rather than
the order that the Davis delivers it.  This is acceptable in APRS, though,
and should be received properly --- the spec says:

  Note: The weather report must include at least the MDHM date/timestamp,
  wind direction, wind speed, gust and temperature, but the remaining
  parameters may be in a different order (or may not even exist).

So the puzzle of pXXXPYYYY turning into P000p000 is only in where the
actual XXX and YYY are getting lost, not the order change.

By looking at the debug level 1 stuff as weather data comes in, you should
be able to determine if it's the Davis APRS Data Logger code that's screwing
it up, or if it's happening later.

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236        http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick