Davis VP2 inventing Rain

[MCQ]

I have a Davis VP2 that has been functioning fine for the last few years. I just noticed that early this morning, it invented 0.70" of rain in the 5 minute period between two readings. It appears that the rainfall counter also incremented by this amount so I assume rainfall counter value is being incorrectly transmitted from the VP2. At the same time Rainfall Rate is zero for both readings, which looks even stranger if both rain rate and rain counter values come from Davis:

21/05/14,03:50,43.1,94,41.5,0.0,0.9,326,0.00,0.07,29.754,7.01,66.4,24,0.0,43.1,43.1,0.0,0,0.000,0.000,41.2,0,0.0,326,0.00,0.07
21/05/14,03:55,43.2,94,41.6,0.0,2.6,40,0.00,0.07,29.753,7.01,66.4,24,0.0,43.2,43.2,0.0,0,0.000,0.000,41.3,0,0.0,71,0.00,0.07
21/05/14,04:00,43.3,94,41.7,0.0,2.6,66,0.00,0.08,29.757,7.02,66.2,24,0.9,43.3,43.3,0.0,0,0.000,0.000,41.4,0,0.0,69,0.00,0.08
21/05/14,04:05,44.3,94,42.7,0.0,1.7,70,0.00,0.08,29.755,7.02,66.6,24,0.9,44.3,44.3,0.0,0,0.000,0.000,42.6,0,0.0,69,0.00,0.08
21/05/14,04:10,44.4,91,41.9,0.0,1.7,70,0.00,0.78,29.755,7.72,66.4,24,0.9,44.4,44.4,0.0,0,0.000,0.000,42.6,0,0.0,69,0.00,0.78
21/05/14,04:15,44.4,91,41.9,0.0,0.0,0,0.00,0.78,29.755,7.72,66.2,24,0.0,44.4,44.4,0.0,0,0.000,0.000,42.6,0,0.0,195,0.00,0.78
21/05/14,04:20,44.3,91,41.8,0.0,0.0,0,0.00,0.78,29.755,7.72,66.2,24,0.0,44.3,44.3,0.0,0,0.000,0.000,42.4,0,0.0,196,0.00,0.78

I looked back over the last 6 months of data and it appears the same thing happened on Jan 30th with 0.59" between two readings and on Jan 31st with 0.73" between two readings. I didn't pay that much attention back in January because it was snowing and I ran into the snow melt/spike issue when I first installed the Davis. However, in this storm it was well above freezing so snow could not have been an issue and those snow melt numbers are usually a couple tenths not .6-.7 inches and not all in 5 minutes.

I installed Davis F/W v3.12 but I don't remember exactly when I did that, so I don't know if that is a factor. Anyone seen anything like this happen with a Davis before?

My other question is how to fix the logged data. I looked at the wiki and I can see how to edit the records, but not what to do with the monthly data logs. It looks like the Davis has been reporting a non-zero rainfall counter since the beginning of this month. It seems if I edit that to zero in my Cumulus log, then the next download from Davis will just show a giant spike. Do I have to reset it on the Davis side somehow? For the Total Rainfall, that appears to be calculated by Cumulus so I assume I have to edit every record in the May14log.txt file from the time the spike occurred until midnight of the same day?

Thanks,
Mike

[steve]

The "total rainfall counter" is only in the log file for 'internal' and diagnostic purposes, you don't need to edit it, and doing so is quite tricky as you can't make it consistent for both the values that came before and the values which came after. In the case of Davis stations, it's the annual total at that point as supplied by the console. Cumulus calculates the daily rainfall based on the increase in that counter.

The rain counter can show an increase in the logs between entries but the rate still be zero, as it is determined by the time between tips and returns to zero quite quickly after the last tip. However, I think it takes 15 minutes, so that doesn't quite explain it in this case.

It could be that your reed switch is registering false tips, or perhaps something is causing the buckets to tip. You could have a look at the mechanism to see if there's an obvious problem.

Was Cumulus running at the time this occurred, or was the data downloaded from the logger later? If you zip up the diags folder and attach it, I'll have a look to see if I can see anything odd going on.

[MCQ]

Steve -

I looked through the diags folder files and didn't see anything unusual in there. Cumulus was running each of the times I had a rain spike. I run it on a server so it is almost always up. I had several more rain showers yesterday afternoon and it worked fine for each of those, so I doubt there is a problem with the reed switch unless it was really flaky but only rarely.

I am leaning towards some issue with the Davis firmware since the incoming Davis rainfall counter value is clearly jumping from one entry in the log.txt file to the next. I did a little digging and found I installed f/w v3.12 on 12/4/13 and this problem started in January 2014. There is a new f/w v3.15 available so I am going to load that and see if it fixes the problem. The Davis f/w changelog is not very informative and released versions jumped from 3.12 to 3.15.

The only commonality I can possibly see is the error always occurred on a day when there was a prolonged lack of sunlight to charge the ISS. I have my ISS quite a bit away from the house so it isn't influenced by the surrounding terrain and landscaping. The wireless signal is adequate, but not extremely strong. I have all the station parameters like battery status, packets received/missed, CRC errors and good packets on the bottom of my main weather page. This info isn't logged but I look at it periodically. I have noticed that when there is extended cloud cover here, my good packets % drops from the mid90's to only 55-60% at worse. I assume this has something to do with the wireless signal strength when the voltage drops, but not low enough to trigger a battery alarm. I live in the desert, so there are not a lot of days where sunshine is an issue (and not a lot of rain), but it had been overcast for over 24 hours when the problem occurred yesterday. The sun is out today but with scattered clouds so my good packet % is still low, although from past experience I know it will improve as the ISS charges back up.

For example, here is what I am displaying right now at the bottom of my web page:
davis station stats
packets received: 7131 | packets missed: 5749
resynchs: 0 | consecutive packets: 11
crc errors: 3568 | good packets: 55.4%
console f/w: 3.12
tx battery status: 1-ok 2-ok 3-ok 4-ok 5-ok 6-ok 7-ok 8-ok
last station read: 5/22/2014 1:24:00 pm
page updated 5/22/2014 1:24:02 pm
powered by cumulus v1.9.4 (1085)
this page will refresh every 60 seconds

I'm wondering if Davis changed something in f/w v3.12 that caused problems when there are a large quantity of missed packets or CRC errors?

[steve]

I don't think it's likely to be the firmware, as lots of people are using 3.12 and have been for some time, without apparently having this issue. I do think that your low power/poor transmission is a factor. Perhaps when the ISS is running on low power, it is misbehaving and adding spurious rain clicks. I don't understand why the battery isn't taking over - have you changed it recently? You should also check the supercapacitor on the ISS board for signs of leakage (although it does sound like yours is working OK if it charges up OK).

[MCQ]

I have had my VP2 for 3 years and I have never replaced the battery. I have never seen a low battery alarm and I've never lost any data at night, so I assumed it was fine. This spurious rain issue has only occurred in the last six months, which roughly coincided with my f/w upgrade, so that's why I was looking at it as a probable cause. If you haven't heard of any problems with v3.12, then that sounds less likely.

Perhaps my ISS battery has just degraded to the point where it is fine for powering the unit overnight, but only provides marginal power for longer periods of time when there is insufficient sunlight during the day. And, during those longer periods, the power drops enough to cause communications problems and the spurious rain clicks. BTW - with full sunlight over the past few days my good comm packets are back to 97.3%.

I will replace the ISS battery this week.

[Paragon]

I had rain measurement problems with my VV. The problem was a spider building a web on the tipping spoon. Sometimes it added extra tips, other times it was held and didn't tip. Now I clean it at least two monthly, removing the buildup of dust in the spoon and the dead insect shells and spider webs from the housing. I haven't had much trouble from bird droppings - perhaps the adjacent spinning anemometer puts them off.

Have you looked at the tipping spoon housing? For cleaning I remove the whole unit from the ISS.

[MCQ]

I have to get a ladder out to change the battery since my VP2 is mounted on a pole, so I'm planning to check the rain collector assembly at the same time. It seems unlikely to me that it could be a spider or something like that unless it could affect the way the water was presented to the tipping bucket assembly. I say that because this problem only occurs during a rain event, and only once during that storm, and the rain counter value in log.txt jumps consistently between 0.6 & 0.7 inches in between my 5-minute log entries (7.02 -> 7.72 in my previous example). That would be 60-70 tips in five minutes. I never see a rate anywhere close to that even with snow melting in the collection cone.

[MCQ]

I wanted to follow-up on this issue in case someone else is searching for answers to a similar problem. I think enough time has expired now to know that my problem is fixed, so here is the update.

I went up the ladder and could find no problems with my rain collector or tipping bucket assembly. So, I emailed Davis Instruments and I received a reply within a couple of days. Davis told me to change the Remote Transmitter ID to something other than the default of 1. They suggested 3 and sent complete details on how to make the change at the station and in the console.

I made that change and since I have never seen my good packets count drop below 97%. I have had several rain events, cloudy days, etc. that always seemed to generate poor good packet counts in the past and those are now gone. I have no idea what might have been causing interference with my wireless signal in those instances or why that would cause wild excursions of the rain counter only (and not the other station values as well) or why this only started occurring in 2014 - but I'm happy it's fixed!

[archae86]

To me that sounds like Davis speculated your receiver might be mixing data received from your transmitter and that of a neighbor. I had that happening when I first installed my VP2, and the results were odd but there was no rain in the time before I figured it out and changed ID numbers. So I have no direct experience to confirm that symptoms like yours might result. But it definitely was not a simple case of "the stronger transmitter wins".

Have you noticed whether your console indicates the presence of a transmitter on channel 1 even though you are no longer transmitting there yourself?

[snapper]

One other thing that can cause this is if your rain sensor is mounted on a pole that sways in the wind. The wind sway causes the tipping bucket to move enough for the reed switch inside to register.

Happened a few times on my Vantage Vue, but I actually separated the rain bucket from my VP2 ISS, so don't get now...

[MCQ]

Have you noticed whether your console indicates the presence of a transmitter on channel 1 even though you are no longer transmitting there yourself?

I've been checking periodically for the last couple of days and I see no activity on Channel 1.

[nicp01]

Had a similar problem this week August 30th 2015, raining when its dry, spurious readings,

You'll never believe it!!

following the recommendations on here checked the data then got the ladder out, there was an inch of water on top of a piece of bread blocking the hole.

there was also a dead spider in the works and the beginnings of a web, one strand on the bucket!

we have some big crows, magpies and squirrels visiting the bread on the bird table, I shout at them to let the small birds have a share
perhaps its revenge...

alls well now I hope

Many thks
Peter..