Davis Vantage Pro Issue with 3.9.5 b3100

[buffaloseven]

Hi,

I recently updated to b3100 and am now experiencing an issue with my Vantage Pro (original v1 station). The software connects to the station just fine, but after about 30 minutes, it loses the data connection. I've enabled the enhanced logging and can supply anything that could help identify the issue.

Haven't had this issue before and I've been using CumulusMX for several years now, so it does seem like something introduced recently. No aspects of my system changed between the prior build and this one.

[PaulMy]

Can you turn on Debug and Data logging and after a while zip up the MXdiags?

Enjoy,
Paul

[buffaloseven]

Sure thing. I've attached it. Prior to b3100 I was running b3086 and had no issues. I've popped back over to b3086 (archived it in a new folder) and it's running with no issues, so definitely something to do with b3100.

One time that I it stopped working that I noted was at 17:09 (as reported the CumulusMX GUI) in the

Code: Select all

20210118-163855

file.

[PaulMy]

Thanks for the files. There seems to be a number of "timed out", "Failed to get a response" in the 20210118-163855 MXdiags, and "*** Data input appears to have stopped" in 20210118-143038 but beyond me to understand the cause and how that would affect the running.

Hopefully someone else or Mark will have a look.

Enjoy,
Paul

[freddie]

Code: Select all

2021-01-18 17:42:39.251 Debug logging is disabled
2021-01-18 17:42:39.251 Data logging is disabled

You need to enable data and debug logging - that way, you end up with better diagnostic information in the log files. There are check boxes in the interface for switching these on (or just start MX with the -debug parameter).

Looking through your log files, MX is having problems communicating with your weather station. This is the case for both the new build(3100) and the build you were previously using (3086). Although the log messages have changed between these two builds, the intent is the same.

You could try a different USB cable between the weather station and the computer. You could also try plugging the USB cable into a different socket in your computer.

[buffaloseven]

Thanks freddie, I had forgotten that the checkboxes in the UI only persist for a single session. I launched b3086 with the -debug flag and let it run for a while. I'm now running b3100 with the -debug flag and once it fails I'll zip up the two logs and attach them to this post.

As for the communication issue, it wouldn't necessarily surprise me. It's an old VP data logger with a Serial → USB adapter hooking it into my computer. That said, perhaps the logs will enlighten more as to where exactly the problem is. That said, whatever it is, if it exists in both versions, it fails gracefully in b3086 with no discernible negative effects, and the data stream stops in b3100. We'll see how it goes.

Also, what's the best method for a totally clean install. Extract the new archive and copy in backup, data, and Cumulus.ini?

[PaulMy]

Also, what's the best method for a totally clean install. Extract the new archive and copy in backup, data, and Cumulus.ini?

Yes, and NOAA Reports.

Enjoy,
Paul

[buffaloseven]

Here are the new logs with the -debug flag set on launch. b3100 failed after about a half hour, and b3086 kept on trucking.

[AndyKF650]

Hi there

On looking at the debug logs my initial thought is that you are using an old version of mono. Many people seem to have this as an issue and the recommendation is that this is upgraded.
Maybe this will sort your issue.

[buffaloseven]

Hmm, you may be right.

Code: Select all

brad@Weather-Server ~ % mono --version
Mono JIT compiler version 5.10.1.57 (2017-12/ea8a24b1bbf Tue Apr 24 14:53:01 EDT 2018)

Is 5.10.x considered old enough to need to upgrade? I try to keep this machine as static as possible.

[freddie]

5.10 should be okay, but probably a good idea to upgrade to 6.

[mcrossley]

The USB connection seems to be very unreliable, and it is buffering responses whilst disconnected. Despite Cumulus attempting to flush the input stream, it still returns responses to previous commands.

I know nothing about MacOS - have you got any sort power management enabled on the USB port or internal hub?
On Windows it would be disabling the "Let Windows put this device to sleep" type settings.

[buffaloseven]

Thanks for that. It was connected via a hub, but I just switch things around so the USB > Serial adapter is now directly connected to the computer. We'll see if that makes a difference. If not, perhaps the next avenue will be seeing if there's any driver updates for the adapter.

That said, from a perspective of no idea what's happening under the hood, I find it interesting that it's failing on b3100 but not on b3086.

EDIT: I also noticed that it seems to be frequently timing out on BARRREAD

Code: Select all

2021-01-19 11:31:46.438 LOOP: 20 - Data packet is good
2021-01-19 11:31:46.438 Sending BARREAD
2021-01-19 11:31:46.438 WakeVP: Not required
2021-01-19 11:31:46.438 WaitForOK: Wait for OK
2021-01-19 11:31:46.450 WaitForOK: Found OK
2021-01-19 11:31:47.452 SendBarRead: Timed out waiting for a response
2021-01-19 11:31:47.452 BARREAD Received - 
2021-01-19 11:31:47.453 SendLoopCommand: Starting - LOOP 20
2021-01-19 11:31:47.453 WakeVP: Not required
2021-01-19 11:31:47.453 SendLoopCommand: Sending command LOOP 20,  attempt 1
2021-01-19 11:31:47.453 SendLoopCommand: Wait for ACK
2021-01-19 11:31:47.453 WaitForACK: Wait for ACK
2021-01-19 11:31:48.373 WaitForACK: (1) Received - 33
2021-01-19 11:31:48.373 WaitForACK: (2) Received - 30
2021-01-19 11:31:48.373 WaitForAck: timed out
2021-01-19 11:31:48.373 SendLoopCommand: Sending command LOOP 20,  attempt 2
2021-01-19 11:31:48.373 SendLoopCommand: Wait for ACK
2021-01-19 11:31:48.373 WaitForACK: Wait for ACK
2021-01-19 11:31:48.374 WaitForACK: (1) Received - 33
2021-01-19 11:31:48.375 WaitForACK: (2) Received - 30
2021-01-19 11:31:48.375 WaitForAck: timed out
2021-01-19 11:31:48.375 SendLoopCommand: Sending command LOOP 20,  attempt 3
2021-01-19 11:31:48.375 SendLoopCommand: Wait for ACK
2021-01-19 11:31:48.375 WaitForACK: Wait for ACK
2021-01-19 11:31:48.375 WaitForACK: (1) Received - 39
2021-01-19 11:31:48.376 WaitForACK: Discarding CR or LF - 0A
2021-01-19 11:31:48.376 WaitForACK: Discarding CR or LF - 0D
2021-01-19 11:31:48.479 WaitForACK: ACK received

Would this be related to forcing the 1 minute barometer updates?

[mcrossley]

The read time outs are just indicative of the unreliability of the connection.

I cannot see what firmware version your station has as all four attempts to read it across both logs failed

You only need that option if you have a really old firmware level.

[buffaloseven]

Well, it's an original Vantage Pro, so the firmware is quite old. Seems like the Serial adapter now just uses macOS' DriverKit stack and not the custom driver any more, so I'm not sure if I can even change that aspect of it. The USB port is always awake.

Just testing now, every timeout is associated with a BARREAD operation; I've disabled 1-minute updates and we'll see what happens.