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
_______________________________________________
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
