[Xastir] Peet Bros U500 w/xastir

[Rick Green]

On Tue, 4 Sep 2007, Rick Green wrote:

> xastir is reporting '360' for wind direction all the time.  I'm running 
> xastir 1.8.2 on that machine, just in case a later release changed this 
> behavior.
>
   I see a new development releasse has just been issued, so I thought I'd 
scan thru the current source for a clue or two.  I'm not a C programmer, 
so I'm just guessing at the meaning of most of it, but I used to program 
in several other languages, so mebbe they're good guesses...

>From the Peet bros. FAQ:

DATA LOGGING MODE - RECORD STRUCTURE

     *
       Header = !!
     *
       Data Fields  (All data fields are four ASCII characters representing 
hex digits, most significant first)
           o 1. Wind Speed (0.1 kph)
           o 2. Wind Direction (0-255)
           o 3. Outdoor Temp (0.1 deg F)
           o 4. Rain* Long Term Total (0.01 inches)
           o 5. Barometer (0.1 mbar)
           o 6. Indoor Temp (0.1 deg F)
           o 7. Outdoor Humidity (0.1%)
           o 8. Indoor Humidity (0.1%)
           o 9. Date (day of year)
           o 10. Time (minute of day)
           o 11. Today's Rain Total (0.01 inches)*
           o 12. 1 Minute Wind Speed Average (0.1kph)*
     *
       Carriage Return & Line Feed


Then, in wx.c, I find this block of code, which I think is decoding this 
structure:  I may not know C, but I can read comments!

         ///////////////////////////////////////////////////////
         // Peet Brothers Ultimeter 2000 in data logging mode //
         ///////////////////////////////////////////////////////
         case (APRS_WX3):

  /snip a few lines/

            /* wind speed */
             if (data[2]!='-') { // '-' signifies invalid data
                 substr(temp_data1,(char *)(data+2),4);

  ...so here's how I'm reading this:  The input line is in an array of 
characters 'data', and data[2] would refer to this array at offset 2. 
Bytes 0 and 1 would contain the identifiers '!!', so wind speed would be 
in the four bytes beginning at offset 2.  Here's where my C ignorance 
shows.  I don't understand how you can refer to the same string as an 
array of bytes (data[2]), and also in the aggregate, as you are using a 
substring function to pick our four consecutive bytes starting at data+2, 
which is the same location as data[2]?

...so we skip down a few more lines...

            /* wind direction */
             //
             // Note that the first two digits here may be 00, or may
             // be FF if a direction calibration has been entered.
             // We should zero them.
             //
             if (data[8]!='-') { // '-' signifies invalid data
                 substr(temp_data1,(char *)(data+8),2);
                 temp_data1[0] = '0';
                 temp_data1[1] = '0';

   It's a four-byte field, but the first two are bogus, and should be 
ignored.  The field actually begins in data[6], but you ignore the first 
two and grab two bytes starting at data+8.  But then you overwrite those 
two bytes with zeroes!
   The older sources I looked at (1.4.0 and 1.7.1) both just ignore the 
first two bytes, and grab two from data+8, but they lack the comment about 
the calibration factor, and the two assignments that clobber the data.
   Before you laugh too hard, remember I'm not a C programmer, but I'd be 
tempted to try something like this:

            /* wind direction */
             //
             // Note that the first two digits here may be 00, or may
             // be FF if a direction calibration has been entered.
             // We should zero them.
             //
             if (data[6]!='-') { // '-' signifies invalid data
                 substr(temp_data1,(char *)(data+6),4);
                 temp_data1[0] = '0';
                 temp_data1[1] = '0';

  So I went ahead and did it.  I downloaded and untarred the current 1.9.1 
source tree, then `apt-get build-dep xastir`, which brought down 38MB of 
various libraries and header files.  Then, after CD'ing to the 
xastir-1.9.1/ directory, I issued a `./configure`, which told me I had all 
the recomended stuff except map caching, and even all of the 'adventurous' 
stuff except geotiff and GDAL/OGR.  `make` and `make install` were 
successful.  Compiling from the tarball installed into a different 
directory than the default Kubuntu RPM, but as it turns out, 
/usr/local/bin is ahead of /usr/bin in the path, so it superceded the old 
version without any intervention.  I restarted xastir, and the new version 
appear to work, at least it opened the interfaces and displayed a map.  I 
didn't really explore too much, only enough to check 'help/about' to make 
sure I was indeed looking at the new version, then 'view/own wx data' to 
verify that I was still getting the constand 360's.
   Enough of that.  I went into the source tree and edited the two lines 
mentioned above, then went back to the top directory, and issued `make && 
sudo make install`.  It didn't take very long at all this time.
   I re-launched xastir, waited a few seconds until 'decoded wx data' 
appeared in the status window, and checked 'view/own wx data'. Wind 
direction is showing as '112' which is close enough to the current 
position of the arrow on the LCD display, so I think I might just have 
fixed it!

Will you accept this long ramble as a 'bug submission with patch 
attached'?


-- 
Rick Green, N8BJX

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
                                   -Benjamin Franklin