Solar anomalies in WD

Blackbirds are rare here, have seen a male twice this winter. Pigeons are more likely and have had poo on the Davis solar sensor on one occasion with obvious results - actually quite difficult to clean off. However, I can’t see that being the cause of the glitches I’ve catalogued.

Both systems are behaving themselves just now.

Several glitches on the WH3083 system. The attachment shows them clearly. At 19:12 there was a positive to 1662.88 with UV index rising to 1. From 22:34 to 23:03, there was a smaller positive, constant for


as explained in my post above, for the WH3081 station, WD has to read the data from a different memory address on the console, to normal weather data
sometimes that will get out of sequence and so bad data will be returned
(what I need to do is check for the data being bad, e.g check on date or times in the data), so as to ignore that data

so trying to use a WH3081 station with the WD software to show that the davis solar glitches are not real etc is not really going to work
I would instead be using the cumulus software for both

I have though made WD ignore glitches in the data at night for the WH3081 station in the latest update of WD

I’m sorry, Brian, we seem to be at cross-purposes. Please allow me to try and clarify the position.

Several years ago, I added the Davis solar device to my VP2 installation. From the very start, I was getting anomalous glitches, which I blamed on the device as everything else worked with WD. Davis could not understand the anomalies, no matter what we tried. I gave up on solar. Since then, I’ve tried it again on 2 occasions when I changed computers and operating systems, always with the same kind of glitches, but only on solar. I just cussed Davis!

A couple of months ago, my Davis anemometer gave up. As my Davis system was old, I decided to retire it and I bought the WH3083 because my pension would not run to a new Davis system and, at 85, my mind is not as active, so I decided to run it on the WD I was familiar with. I was flabbergasted to find that the solar system on it, with freshly installed WD software (no legacy errors), did exactly what I experienced for years with the Davis solar; it glitched totally unpredictably but only on solar. IOW, I have problems with WD with two independent sets of weather systems on two independently installed versions of WD and have had so (with Davis only) for many years.

In your last post, you suggest I use Cumulus for both. This is NOT what I want to do. If you were in the habit of driving a Rolls Royce, would you want to use a Mini as your main car? In any case, I have not been able to configure Cumulus as a second system with Davis AND WH3083. Also, I use other features in WD that Cumulus does not have. I’ll continue to use WD with both systems, knowing that it’s not perfect for solar/UV, at least here.

Out of curiosity, I did start Cumulus to see how it behaved at the time of a known glitch in WH3083. The attached graph shows the curve was smooth. The red is a freehand rendering of the same time data from WD as in the table.

Finally, the thing that flummoxes me the most is that there are no ‘me too’ responses from other WD users. How can it be that I have had the problem for years and no one else has seen it?


I have just realised something about your solar sensor readings shown in your log files earlier in this thread, they all seem to show 2 decimal places. This is simply not possible with a Davis solar sensor as it only passes integer values, I’ve checked my log files and they all show values with .00 on the end. So we need to understand why yours have two decimal place values which are non zero.

Stuart

Stuart

Good thinking. However, you are right but with WD/Davis. The decimal points are only in WD/WH3083.

I did wonder after I had posted but was not completely sure whether or not those logs were Davis ones so left the comment to make sure.

Stuart

as I have explained, the solar glitches from the WH3081 solar data will be to WD not handling when the data gets of sync very well
I have for now added to ignore that when its night time, but I need to come up with a way to know if the solar data (which is a different memory location) is out of sync and so ignore it, for the WH3081 data

Thanks, Brian. It would be great if you could do that; I’d be very grateful. However, it is not just on the WH system that it happens, but also the Davis over several years. In fact, as I write (on a different computer; the weather one is dedicated), I’ve just seen a typical glitch on the Davis system as per attachment. This is a short one over 2 minutes, but I’ve seen occasional glitches lasting up to an hour, on both systems. On the attachment on the message of 24 April 2017, 14:13, there is a


Just to be completely clear on this … you are saying that on the 24th April you saw the exact same anomaly for the exact same time frame on both your Davis system AND your WH3081.

If true this would tend to indicate that at least on the WH3081 WD is actually reading the correct value from the sensor and it is highly likely that since both sensors are reading almost exactly the same values there has to be an external effect coming from somewhere to cause this.

This would be extraordinary since I am not sure how any of us could explain the external effect which could cause this at least not by the sun. I suppose it could be some electrical interference but again very difficult to explain.

Stuart

Sorry, Stuart, I express myself badly. I have never seen anomalies on both systems at the same time. They seem to be random on both systems. E.g., this morning’s glitch was only on the Davis system, but one I did not report here yesterday was only on the WH system, as some above. They happen at totally random times, day and night (except for Brian’s suppressing night time ones on WH).

I’ve not done any software development for well over 20 years, so have forgotten more than I ever knew, but my guess would be loss of sync over the 100 bytes transfer. Just one extra or missing bit would do the job. If it happened once at random, that is easily understood: less easy for my feeble brain is the same thing happening over many minutes.

I think that’s what is flummoxing all of us, how do you get such wrong but sometimes consistent errors over a few minutes, which is why we are clutching at straws. I suspect Brian is correct over the WH system. The Davis system is a different kettle of Surstr

maybe you could try covering the solar sensor on the Davis
and see if the spike still occurs
(also note that WD does use the CRC error check in the Davis LOOP data …i.e they needs to pass before WD will accept the data)

…and the console does a CRC check on the data packet from the ISS. It’s virtually impossible for couple of rogue bits to get into the data :?

@Devil: Have you always had the same Davis hardware, or has some of it been swapped out over the years?

The WH and the Davis are “chalk and cheese” as the Brits say. I think it’s confusing the situation to be looking for similarities…

I changed the Davis system for the same type at the same time as I bought the solar sensor: before that I didn’t have solar. It is a wired type with a fairish length run of Davis’ black cable (guess ~25 m) which is unscreened (unshielded for the US). Of course, the other system is wireless.

Regarding the Davis:

There are two separate CRC checks on the data before it hits WD making data corruption in transit extremely unlikely.

Solar is only present in 1/24 of the total data packets and yet solar is the only parameter affected. Statistically unlikely in a data corruption situation.

The spikes are very close to the full scale reading from the solar sensor that would result from the sensor output being equal to the supply voltage.

The sensor/ISS hardware has not been changed.

My conclusion is that there is a hardware problem either with the sensor, the sensor cable/connector, or in the solar measurement circuitry on the ISS.

I think Niko is correct
because in checking my code in WD for handling the solar data, I put in there that if the reading is over 2000 for 2 data points in a row, then WD set the reading to 0
which explains the zero readings after a spike

As there is so much in common in the software on the two systems, e.g., in the registry but also some functional parts of the two systems, I’ve decided, for clarity, to separate them entirely. I’ve uninstalled completely the WH system and Cumulus from my weather computer. I have therefore ONLY the WD/Davis system on my weather computer. On another computer, I have ONLY the WD/WH system, no Cumulus, with a totally clean installation. The only thing in common between them, now, is a stand-alone UPS.

Since the divorce and separate households, there has been no glitch on either.

Didn’t the Davis have spikes for a long time before you had the WH?

Yes, indeed, but I had a feeling (unsubstantiated) that it had become more unstable when both were on the same computer, sharing the same registry and some other items. Maybe a kind of symbiosis! :slight_smile: