Cumulus Support

I have a Davis VP2 with the Serial to USB data logger. I have used this setup for several years with the WeatherLink software. I wanted to try something new and have therefore been testing CumulusMX. I really like the looks and features of CumulusMX, however I am having one big problem. Everything will run perfectly for a period of time (sometimes it is a couple of days, sometimes it is only a few hours), then the data will simply stop updating. I usually first notice this when I look at the charts and see that they have all flat-lined. I have been able to get the correct data back by closing CumulusMX, editing today.ini with the date & time of right before the data stopped changing, and removing the bad data from the various data files. This however, is kind of a pain.

The following is a few lines from MXdiags from the time that the data stopped changing:
The 10:15:00 PM update was good, but the update 5 minutes later at 10:20:00 PM was the first one with bad data. If I close CumulusMX then restart it, it can talk to the VP2 data logger again as if there were no problems. It's almost like the serial port code gets bad data, crashes, and never re-initializes until CumulusMX is restarted. Maybe there could be some kind of watch dog in the software that resets things if it stops talking to the serial port. I found the following interesting discussion on the use of the .Net System.IO.Ports.SerialPort module:

http://www.sparxeng.com/blog/software/m ... serialport

If I need to turn on debug logging and/or data logging and submit more MXdiags, I can certainly do that.

It appears that something is causing the serial port to be closed - MX currently has no code to cater for this unusual occurrence, so as you say, you have to restart to get it to reconnect. When I get chance I could look at putting in some code to handle this. And MX currently has no 'restart if data stops' facility as in Cumulus 1, which is a kind of catch-all for problems like this. I have still to work out a reliable way of doing this in MX which works reliably cross-platform.

What version of the Silabs USB to Serial drivers are you using? There are later ones than the ones Davis supplies, direct from Silabs, which work better in Windows 10.

I've seen that web page before, but it does only applies to Windows. I had read elsewhere that the .Net serial port implementation is not very good, and I did start looking for cross-platform alternatives, but didn't get very far.

I've seen the same flat line problem running MX on Debian linux.
It has only happened twice in 2 months and I did not see anything in the logs other than as in the post above so I never reported it.
Strange thing about my 2 incidents is that it happened exactly at midnight.

jcowens14 wrote:I've seen the same flat line problem running MX on Debian linux.
It has only happened twice in 2 months and I did not see anything in the logs other than as in the post above so I never reported it.
Strange thing about my 2 incidents is that it happened exactly at midnight.

This is with a USB logger yes? And you got the same "System.InvalidOperationException: The port is closed" error message?

I am running this on a Windows 8.1 virtual machine (USB device is passed through). The Silabs USB to Serial driver (downloaded from Silabs website) is version 6.7.0.0 dated 3/19/14. I just checked and this is still the latest version they have on their website.

I can think of a couple of things I might try:

1) Write an AutoIT script to monitor the logfiles for this error and when the error is detected restart MX

2) Install Linux in another VM and see if I can get things to operate more smoothly in that environment.

Thanks for all your hard work--it is great software with a lot of potential.

steve wrote:

jcowens14 wrote:I've seen the same flat line problem running MX on Debian linux.
It has only happened twice in 2 months and I did not see anything in the logs other than as in the post above so I never reported it.
Strange thing about my 2 incidents is that it happened exactly at midnight.

This is with a USB logger yes? And you got the same "System.InvalidOperationException: The port is closed" error message?

The VP2 is connected to a Quatech serial device server. MX accesses it through a TCP/IP connection on port 5000.
The only thing I get in the logs is the "Data input appears to have stopped" message and MX just keeps recording the same data every 5 minutes.

I have been experiencing 'flatling' on charts and missing TEMP and HJUMIDITY data on the web console for about 6-months. We have a Davis stand-alone wireless panel and it always show the current temp & humidity, so I've ruled out that the Davis VP2 Weatherstation was not sending data correctly. I migrated from CU2 to CUMX thinking it would have better I/O handling but still the same exactly situation in the first post of this thread. However, I saw no conclusion or resolution on this issue on this thread or others I viewed.

Running VP2, MX build 3205, Serial to USB cable (Davis supplied with original VP@ system) between Davis' Envoy data collector and Windows 10 PC,
Davis recently sent me the Prolific USB-to-Serial Comm Port driver that should be used Windows 10. It is actually an earlier, but recommended version, to use in W10. Seems to work better but not cure the problem.

(small) MX Diag file. attached...

Bridge

@TheBridge the log file shows a few things...

1. It does not appear that your Envoy supports the LOOP2 command, nor does it respond to a firmware version request (is it very old firmware?).
I would disable the loop2 option in your station config to prevent the command being sent periodically.

2. Everything was OK from start-up at 12:44, until 13:06. At this point the station started sending...
Outdoor temp = 3,276.7
Outdoor hum = 255
Wind speed = 255
Wind avg = 255

The data packet checksums were OK, so there is no corruption on the comms link.

Those values are FFFF and FF, which Davis use to indicate there is no data available.

At 13:21 the outdoor temperature and wind data came back into the normal range, but the humidity was still missing.
Even so I'd expect the wind data to change every 2.5 seconds, but it stayed constant for long periods.

Later on the pattern repeats.

All those values come from your ISS, so I suspect the envoy has lost the signal ISS at this point - and only receives the odd packet from the first failure onwards. As your console is receiving the ISS data OK, we can rule out a fault with that. I'd try moving your Envoy to try and get better ISS reception.
Another test if possible is to move your data logger from the Envoy to the console, and see if it works OK there.

Hi Mark,
Thank you for the review of the log file and your comments.
From your comments, I’m doing/done the following:
1. Unselected ‘Loop2’ in setup. We’ll see how this goes.
2. In considering moving the Envoy (although it has worked fine until 8-9 months ago) the difficulty is the Envoy is teathered to an ‘always on’ PC and moving it to another location within the house is not easy as it sounds.
3. I did contact Davis late today. The support engineers who worked closely with the original Envoys have either retired or moved on. Anyway, there is no firmware update for my early edition model Envoy (it’s hell being an early adopter) HOWEVER the support person I spoke to was knowledgeable and did know of the ‘Loop2’ API call and believes it was supported in my early Envoy. He suggested I try my Envoy with Davis’s app and see if it responds (i.e. use Davis app as a test/debug tool). I don’t know Davis’s app so not sure it keeps logs that will capture loop2 events. I have to read their docs and see.

Bridge

VP2 consoles with firmware earlier that version 1.9 do not support LOOP2, that version was released Feb 18, 2010. So if your Envoy is older than that it is highly unlikely to support LOOP2.

Just moving your receiver a few inches can sometimes make all the difference at the frequencies these devices use. Just try and keep it as far away from any other electronics as possible, and maybe try a ferrite ring on the cable connecting it to your PC.

Thanks Mark,
After nearly 20-years of being in service, my Davis hardware could stand to be replaced. Firmware wise it is now apparent to be old. I am old(er) and think age is of value but for technology devices, which we can measure in dog years, this system is now 140-years.
I will work on replacing system elements, starting with the Envoy, which no doubt will bring better performance.

As always, thank you much for your time and insight!
Bridge