%mintemp% Sometimes Reports 0.0 Degrees Unexpectedly

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.

This is a similar to this discussion here: http://discourse.weather-watch.com/t/64318

I am not sure why this happens, is there anything I can do to test this further?

Any thoughts, thanks guys?


what weather station type?

Davis VP2 connected via native RS232.

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?

Thanks

all the data received over a minute is averaged for the data/log file
but each data point received is used for the max/min of the day

That makes sense.

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.

Background
Note, this issue doesn

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?

And another (running WD 10.37Sb59 - 2017/11/05).

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:


2017/11/12.17:13:23
06                                              | ACK (COMMAND)
4C 4F 4F 3C 00 86 09 23 75 B4 02 32 B3 01 0F 07 | LOOP
42 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF 4E FF FF FF FF FF FF FF 00 00 00 00 00 2B 00 
11 B5 07 00 87 00 62 0B 23 00 20 00 2E 02 FF FF 
FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 33 03 06 4B CC 02 59 06 0A 
0D 80 50 
4C 4F 4F 3C 00 86 09 23 75 B4 02 32 B3 01 0F 07 | LOOP
42 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF 4E FF FF FF FF FF FF FF 00 00 00 00 00 2B 00 
11 B5 07 00 87 00 62 0B 23 00 20 00 2E 02 FF FF 
FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 33 03 06 4B CC 02 59 06 0A 
0D 80 50 
4C 4F 4F 3C 00 86 09 23 75 B4 02 32 B3 01 0F 07 | LOOP
42 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF 4E FF FF FF FF FF FF FF 00 00 00 00 00       | Loop halt

2017/11/12.17:13:24
                                          2B 00 | LOOP continue
11 B5 07 00 87 00 62 0B 23 00 20 00 2E 02 FF FF 
FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 33 03 06 4B CC 02 59 06 0A 
0D 80 50 

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.