Cumulus Support

Actually, the Davis does more things good than any other station I know of. So may be it is my expectance here...But here it goes.

I use a vantagePro2 wireless in the field with a datalogger (gemini Ultra2 calibrated) alongside. In a week time it was clear that the responsetime of the Davis is slow. On one night the datalogger logged 4,5 C. Davis 5,0 C. The Davis has been calibrated so in monotoneous and grey weather, the read within 0,1 C of eachother. When it becomes bright the difference amounts 0,4 C. As an aside: the original Davis setting would have meant that the difference would have been 0,8 C.

Solution: I though I'd buy a second temperature station with a stainless steel probe in it as it is a much faster responder. Problem: the Davis concept allows this but it will only note these second sensor with a resolution of 1 F or 0,55 C! I don't know why this is but this of course does not help me at all. I can't understand this at all.

I wonder if cumulus reads out the weatherlink software or if it reads out the sensors. if the last thing is true than will it register in 0,1 C or still in 0,55 C??

Thansk for the answer.

Cumulus doesn't use the Weatherlink software, it reads the data from the console, using a DLL provided by Davis. As far as I am aware, the data is supplied according to the stated resolution; i.e 0.1C for the 'main' temperature, and 1C for 'extra' temperature sensors.

I'm rather confused by your question, though, you started off talking about response times, and then you seemed to move on to accuracy, and then resolution. I don't think Cumulus can help you with any of those, they seem like hardware issues to me.

Sorry I wasn't clear. Let me keep it simple and straightforward: the Davis sensor I have now is not accurate (but it is calibrated by me). it is also sluggish. No calibration will help with that, as it seems to be the construction. Cumulus can't help with that either. I merely wrote this to indicate my need for an extra, fastresponse probe that Davis does deliver.

So: Davis has it. Davis however only lets us have that second, third etc sensor but it will only read it out with a resolution of 0,55 C. If you would use the very same sensor standalone, it would read 0,1 C. It is not that the sensor can't do it. for some reason, Davis does not allow that. And 0,55 C is not helpfull if someone like me is aiming for better accuracyl. So I wondered if this was done by the Davis software. I thought that would be possible. If I would use the very same temperaturestation standalone, it would now note things in 0,1 C. So it has something to do with the software. Now is this done in the receiver or is this done in WL 6.x software? if the latter is true and you don't use it, it is likely the two sensors would simply be registering in 0,1 C. If not, Cumulus can't solve this either.

Thanks again.

Right, I understand. The rounding of extra temperatures to the nearest whole degree is an attribute of the receiver. The protocol for reading data from the console specifies a whole number for extra temperature sensors. So there's no way for any software to read the temperature to any greater resolution (unless someone has found an undocumented 'hack') using standard Davis hardware.

steve wrote:Right, I understand. The rounding of extra temperatures to the nearest whole degree is an attribute of the receiver. The protocol for reading data from the console specifies a whole number for extra temperature sensors. So there's no way for any software to read the temperature to any greater resolution (unless someone has found an undocumented 'hack') using standard Davis hardware.

Thanks, it is clear to me. it is beyondm e why Davis does this. Might be a good reason for it, don't know. Oregon Scientific lets you use 10 sensors and they all will note at 0,1 resolution. I will contact davis about this though.

Just to add:

The data from supplementary VP2 temp sensors is transmitted to 0.1degF resolution. As Steve says, it's a limitation of the standard VP2 receivers that they don't make these particular data values available to better than 1degF.

(I think that this was probably done to keep the loop data packets as compact as possible, so the supplementary temp values are encoded in a single byte rather than 2 bytes - there are 15 additional temp values that are included in the loop, so it would have added to overall size significantly if all temps had been taken up to 2 bytes. Of course, the loop packets were originally specified some 12 years ago now for the VP1 stations with - I suspect - more limited CPU power for real-time processing. Better temp resolution would be almost certainly be possible if the loop packet were respecified today but of course that would break backwards compatibility.)

Note that the Envoy8X VP2 consoles can receive supplementary temp data to 0.1degF resolution, though the 8X API remains unpublished AFAIK.

However, I'm not sure that a stainless steel encapsulated temp probe would necessarily show any different a response time. Are you sure that you're not confusing response time inside a shield with response time for a 'naked' sensor. On some clear calm nights, a bare sensor will often show a lower min (which you might perceive as as faster response) because of radiation cooling of the sensor, which won't be possible for a sensor inside a shield.

Edit: To correct gibberish