I have only seen this a handful of times where the daily low temperature is reported at 0.0-degrees Celsius (see attached) even though the graph and data log don’t have equivalent data recorded. I think this spurious low temperatures also get logged in the monthly all-time low temperature records too as I currently have July (%recordlowtempjul%), August (%recordlowtempaug%) and September (%recordlowtempsep%) all of which reporting 0.0-degrees in 2016.
it could be a periodic fault in the temperature sensor?
you could try setting a minimum temperature value limit in WD as a test (control panel, offsets, limits)
Yes it could be - what I will do then is tap off the received VP2 RS232 data to another computer such that I have the raw data logged if and when it happens again for comparison.
How does WD manage the samples from the VP2 regarding temperature i.e. are the high/lows compared against each sample received and the current temperature logged (per minute) an average of the samples received?
I will setup a RS232 logger connected to the VP2 data to see if I capture anything, I have only seen this 3x times (i think) before, this was last year so I am not sure if I will capture anything of interest but I will try.
I saw this issue again on Sunday at 00:26hrs. Unfortunately I hadn’t setup my VP2 data capture #-o I have definitely set it up now and its capturing all VP2 data transmitted from the console to the weather PC interface.
So after quite a few days of logging Davis VP2 serial data using a standalone PC, I finally captured some data while a faulty 0.0-degrees (outside low temperature) was reported in WD.
And another one - this one also showed up on the WD graph :?
Currently running WD 10.37Sb59 (2017/11/05).
This one occurred Sunday at 04:23am (2017/11/05) and the previous one was Sunday 04:12am (2017/10/08), anyone know what could be happening at this day and approx time?
This one occurred Sunday at 04:37am (2017/11/12). I also had 5x other occurrences this week but I have been away so haven’t been able to report back here.
It feels like the problem has got worse since the updates for this http://discourse.weather-watch.com/t/64544 bug.
I am getting 0-degree glitches at least once a day following the recent WD updates (see previous reply).
I caught another glitch while recording the VP2 traffic using a separate PC, again tapping off the RS232 wire transmitted by the VP2 console to WD. After a few painful hours of processing the data I found this:
Look above where I have annotated the LOOP halt/continue. The VP2 console is stalling the transmission of a LOOP packet for approx 1…2-seconds compared with a normal transmission, note the date/time stamp is tagged by the capture software I am using. This effect is exactly the same when I captured the data from a previous glitch (see reply #8 in this thread). Another point to note is that the stalled LOOP packet has exactly the same content including CRC as the previous LOOP packet giving a clear indication that the VP2 console processor clearly paused the RS232 transmission, probably while processing a higher priority interrupt - I am guessing saving data in EEPROM due to the duration.
My VP2 console (#6312) is an older hardware revision (pre April 2006) with firmware v1.90 with a native RS232 data logger i.e. no USB.
Brian: any thoughts as this looks to be a WD issue handling the VP2 data port when LOOP packet transmission is paused mid-flight? I may contact Davis technical support and find out what the pause duration could be if that helps.
seems to be more of a hardware issue in the the first place (with your particular hardware version etc)
not sure how WD can handle your particular problem (with I do not have other reports of)
except for just using the temperature limits already in WD (i.e setting a lower temperature limit above zero so that WD will ignore this problem, sort of thing)
Yeah possibly. We will have to see what Davis technical support report back, that is if I get a response to my questions. The Davis VP2 Serial Communications Reference Manual doesn’t clearly clarify the packet transmission periods i.e. the idle time between data frames (byte transmission including start and stop bits).
Setting the temperature limit in WD is just not an option for my climate as I will end up masking the real world temperatures.