VP2 archive read timing out

[freddie]

MX lost connection to my VP2 last night. I restarted it first thing this morning, and it failed to read the archive. So I restarted again (after copying backup data files back to the data folder). Same thing happened again. This is what gets logged in the diags file:

Code: Select all

2019-07-25 06:33:42.203 Woken
2019-07-25 06:33:42.203 Sending DMPAFT
2019-07-25 06:33:42.404 Wait for ACK
2019-07-25 06:33:42.404 ACK received
2019-07-25 06:33:42.404 Received response to DMPAFT, sending start date and time
2019-07-25 06:33:42.404 Sending: F8-26-AD-08-C4-C2
2019-07-25 06:33:42.604 Wait for ACK
2019-07-25 06:33:42.605 No ACK in response to sending date and time
2019-07-25 06:33:42.605 Get Archive Data
2019-07-25 06:33:42.605 Rollover hour = 9
2019-07-25 06:33:42.605 Last Archive Date: 24/07/2019 22:21:00
2019-07-25 06:33:42.605 Date: 9976
2019-07-25 06:33:42.605 Time: 2221
2019-07-25 06:33:42.605 Waking VP
2019-07-25 06:33:43.006 Woken
2019-07-25 06:33:43.007 Sending DMPAFT
2019-07-25 06:33:43.207 Wait for ACK
2019-07-25 06:33:42.605 Time: 2221
2019-07-25 06:33:42.605 Waking VP
2019-07-25 06:33:43.006 Woken
2019-07-25 06:33:43.007 Sending DMPAFT
2019-07-25 06:33:43.207 Wait for ACK
2019-07-25 06:33:43.207 ACK received
2019-07-25 06:33:43.207 Received response to DMPAFT, sending start date and time
2019-07-25 06:33:43.207 Sending: F8-26-AD-08-C4-C2
2019-07-25 06:33:43.408 Wait for ACK
2019-07-25 06:33:43.408 No ACK in response to sending date and time
2019-07-25 06:33:43.410 Logger archive reading thread completed
2019-07-25 06:33:43.410 Updating highs and lows
2019-07-25 06:33:43.413 Midnight rain reset, count = 219 time = 06:33
2019-07-25 06:33:43.414 Reset sunshine hours, yesterday = 0
2019-07-25 06:33:43.417 Start normal reading loop

Looking at the log times for waiting for ACK after sending date/time of last record, it doesn't appear to wait for long enough. I don't have this problem for short outages (<10 minutes) but it does appear to be a recurring theme for longer outages. Can anything be done about increasing the wait for ACK after an archive data request? Perhaps a bit of intelligence put in - maybe scale the wait to the anticipated download size? Something like this:

Code: Select all

waitTime = ((dateTimeNow - lastArchiveDateTime) / logging interval) * some constant

which will give the number of anticipated records scaled by some constant.

What do you think?

[mcrossley]

The timeout is waiting for an acknowledgement of the command, each record it sends is separately acknowledged.
Is this a Davis Logger?

[freddie]

Is this a Davis Logger?

Yes, it is. Only occurs with lengthy archive downloads, though. Hence me thinking that the timeout is too short - not for the download of the data but for the ACK to be sent back when the date and time are sent and there are a large number of records to return.

[mcrossley]

The timeout is set at 200 milliseconds. But in general it seems to work, even when people have mismatching logging intervals which causes the logger to download the entire logger contents.

I guess I could increase this just for the DMPAFT date and time command and see if it improves things. Say to 500ms?

[freddie]

The timeout is set at 200 milliseconds. But in general it seems to work, even when people have mismatching logging intervals which causes the logger to download the entire logger contents.

I guess I could increase this just for the DMPAFT date and time command and see if it improves things. Say to 500ms?

Definitely worth a try. I've had this problem with MX almost since its inception. Doesn't affect me most of the time as I generally have very little downtime - but on those rare occasions when I don't notice the dropout for a while I always have this problem