wviewweather.com

AirBourn · Joined: 25 Dec 2005 Posts: 9 Location: Jordan, MN

Wview 1.9.1, SLAB_USBtoUART driver on MacOS 10.3.9 talking to USB Weather Envoy, listening to VP signal off the Davis wireless repeater. Works well for long periods of time, and then get sporadic periods of BAD Archive Records in the system.log.

Can this be attributed solely to bad/flakey reception of the repeated signal? Or, might there be some USB/driver communications trouble there? The station is just a hundred feet around a metal building or so, and the Envoy is 20 feet from the repeater, through a building. Although it's the solar wireless repeater and subject to some power fluctuations, I have a hard time blaming signal strength alone for these bad archive records.

Any similar experiences or ideas?

Bryan
Jordan, MN

mteel · Joined: 30 Jun 2005 Posts: 435 Location: Collinsville, TX

I included the User Manual section "20.4 Wireless Reception" to address this type of problem. Follow the instructions there to look at your rxcheck.png chart to see if your wireless reception is bad...

Make sure you have it enabled in wview.conf.

Mark

AirBourn · Joined: 25 Dec 2005 Posts: 9 Location: Jordan, MN

Yep, I'm familiar with the rxcheck graph, and first turned to that to begin to address the problem. What I find there is a very distinct pattern of good reception (90%+)followed by a spike of poor reception at regular intervals. Looking at the code, it appears that this occurs when the number of errors or bad packets exceeds some integer limitation (32767 or 65535), causing the percentage calculation to return an unusable number.

Overall, the reception appears to be quite good, and the graph will appear this way during periods of good and bad archive records. Also, as strange as it seems, I seems to notice more bad archive records during times of little or no wind. The signal reception and archive records seem to be the best when it's windy. Makes me think about marking an archive record bad when it sees a zero, or maybe the VP station is sending noisy data when its calm, or wview isn't expecting a zero or "---" or something along those lines. It just appears to be more than intermittent poor reception. Especially considering I'm just a hundred feet from the station...

mteel · Joined: 30 Jun 2005 Posts: 435 Location: Collinsville, TX

Unless you are running on a 16 bit machine, an integer has a maximum positive limit of 2,147,483,647 - that's 2 billion +. The calculations are done with integers as you know if you examined the code.

Further, see http://home.comcast.net/~mullicahillweather/img/rxcheck.png -
that is a wireless station that does not have these periodic "rollovers"...

Further, another guy using an envoy was having a similar periodic problem with reception.

Your graph is not displaying "unusable values", but periodic reception problems. An unusable value would not appear as 5%...

Bad RF reception is not just caused by wind or rain - many other things can come into play.

wview declares an archive record as bad if the temperature is set to 0x7FFF, which is the invalid value I have observed when my wireless unit's battery was low or had interference for an archive interval.

If you had a VP console you would be able to use it to display the RX stats (and all the errors) since you don't appear to trust the wview results.

AirBourn · Joined: 25 Dec 2005 Posts: 9 Location: Jordan, MN

Yeah, I'm familiar with RF and the usable percentage values - "Unusable" was a poor choice of words, sorry. Just pointing out that the reception spikes don't appear to be the cause of the bad archive records. The bad archive records don't correlate in time with the low points on the graph trace.

I see the periodic poor reception spikes all the time - even when the archive records are all good. I see the bad archive records frequently when the values for wind are small. Purely an observation.

If you wish, you can watch both my rxcheck graph ( http://67.137.107.234/WX/rxcheck.png) as well as a graph of the data out of the Envoy ( http://67.137.107.234/StatusGraph.php ). When I have a bad archive record, I draw a red box with an X through the wind trace, as well as an X across the other temperature values out of the Envoy. At the moment (12/26 18:25 CDT) they're all good - about 10 hours worth. There doesn't appear to be any correlation between the low reception spikes (they're always there) and bad archive records.

mteel · Joined: 30 Jun 2005 Posts: 435 Location: Collinsville, TX

Bad archive records are received when there was insufficient data during an archive interval to generate a valid archive record. The correlation is that because your reception is much worse than normally observed at certain points in time, it will occasionally result in a bad archive record. It is not unrelated.

I am not at all surprised that your RX quality graph isn't "90%+" except when you get a bad archive record. That is not a real-life scenario. Somehow you have semi-periodic interference that occasionally rises to the level of causing a bad archive record.

You can add a debug message where the rxcheck calculations are done and print out the raw rxcheck response from the envoy - which will include the error values. I wonder if the envoys are succeptible to interference.

Fundamentally if the outside temp value is 0x7FFF in an archive record, it is a "no value" archive record. Wind is not part of that decision procedure. You might want to ask Davis why you get so many bad archive records with your envoy.

AirBourn · Joined: 25 Dec 2005 Posts: 9 Location: Jordan, MN

Stuffed some debug messages into vpinterface-be.c to look at how the packet receive percentages are calculated. Here's a result chunk that shows one of the poor spikes. There are three calculations shown, five minutes apart (archive interval), at 100%, 3%, and 100%.

mteel · Joined: 30 Jun 2005 Posts: 435 Location: Collinsville, TX

It concerns me that your number of CRC errors is so high - I believe 120 in a 5 minute period is the maximum number of possible packets (every 2.5 secs) so how you get 3038 CRC errors in 5 minutes is goofy. This may definitely be an envoy thing. You might want to shoot Davis a question about what is the meaning of the RXCHECK fields for an envoy and if it differs from the VP/VP2. I would also ask why you periodically receive archive records with a temp value of 0x7FFF on the envoy.

Yes, I am aware of their method for calculating ISS quality but the formula looks a bit cheesy to me and the protocol provides a direct command to retrieve the info - that is why I used the RXCHECK command method.

Even if the wind is calm that should not effect the number of wind samples your ISS collects. A zero reading for velocity is a valid reading.

Mark

AirBourn · Joined: 25 Dec 2005 Posts: 9 Location: Jordan, MN

Yep, concerns me too. Doesn't make much sense. I sent a note to Davis support - we'll see if they get back to me. Do you think it's possible that the RXCHECK fields have a slightly different definition on the Envoy? Another tidbit of information there: I do see large negative values in that CRC field, too. That also seems strange. Here's a list of the RXCHECK strings received over 3-4 hours:

mteel · Joined: 30 Jun 2005 Posts: 435 Location: Collinsville, TX

Yeah, that's kinda what I'm thinking too...

AirBourn · Joined: 25 Dec 2005 Posts: 9 Location: Jordan, MN

Well, still no word from Davis. Also, another observation. As strange as it seems, the wind has been calm here most of the day, and I've received nothing but bad archive records for the last 5 hours. Two good ones in that entire period. Nothing else in the receiver setup has changed. I look over at the anemometer, and it's not moving in the slightest. Only the vane wiggles a touch now and then. I'm going to have to look into what the Envoy is sending wview during this condition....

AirBourn · Joined: 25 Dec 2005 Posts: 9 Location: Jordan, MN

The only thing Davis had to say was to suggest that there's some 900MHz interference in the area. Doesn't sound all that plausible to me. I occasionally see bad archive records for hours and hours, and sometimes overnight. I have 2.4 and 5.8GHz transmitters in the area, but nothing on 900MHz. And, I highly doubt my neighbor is sitting on his 900MHz phone for 8 hours over night. Possible, but not probable. I asked them to further clarify the definition of the RXCHECK fields for the Envoy, but haven't heard back on that one.

AirBourn · Joined: 25 Dec 2005 Posts: 9 Location: Jordan, MN

Davis had this to say:

AirBourn · Joined: 25 Dec 2005 Posts: 9 Location: Jordan, MN

Brett at Davis had this to say about negative values for the CRC field, and large increases in CRC errors:

mteel · Joined: 30 Jun 2005 Posts: 435 Location: Collinsville, TX

I just added the logic for negative CRC counts - will be in the 3.0.0 release soon.

That still doesn't explain why you are getting so many...

Thanks for the updates.