Cumulus Support

I have a Meteobridge:

http://wiki.meteobridge.com/wiki/index.php/Home

In the most recent version of the firmware/software for this device it opens up port 22222 and allows software to access data from the weather station that is attached.

Cumulus works with this system and my attached Vantage Vue console - supply the IP address of the Meteobridge and you can collect data.

Cumulus MX does not seem to work - I get zeros in the display and no data seems to accumulate.

This may be a very niche application and product - is it worth troubleshooting. Given the vast array of devices/users in Beta test I do not want to add to the laod if it is not of value...

Guy

Well, since it should work, it's probably worth investigating. It may be a bug in MX. If you attach the diags file I'll have a look (but the problem may need extra diagnostics adding).

Just a thought... have you tried UseDavisLoop2=0?

If Davisloop2=1 then nothing displays, if =0 then zeros.

Let me let it run a bit and later today will provide the diags files.

Guy

A few items I have checked:

Windows Firewall - disabling does not change the issue
Running a fresh "install" of 3010 - same as 3009 (just in case, I realize nothing may have been done between the two builds to affect this issue).
Ran WeatherLink on the same PC - it finds the Vantage Vue console, can configure it and download data using the IP address and port 22222

Note this is a different PC than my server - running Windows 8.1

No data seen in the data directory after several minutes

Diags folder attached.

Guy

As I understand it, the way this new feature is supposed to work is that it gives the connecting program control of the station, i.e. it is transparent, rather than offering an emulation, as with Virtual VP, for example. So if MX works direct to the station, but not via the Meteobridge, then it seems to me that the connection is not transparent and the problem is with Meteobridge. When you connect directly using MX, is that via TCP/IP - i.e. is it an IP logger?

I did notice a while ago that MX does not obey the protocol spec completely, for TCP/IP connections. It doesn't send a terminating newline on the LOOP commands. This doesn't seem to bother a real directly connected station, or even VVP. And that isn't the problem here, as it doesn't get that far, it's not getting a response to the DMPAFT command (which does get terminated correctly).

You do connect via the IP address of the Meteobridge - and use port 22222. The description on the wiki talks about exposing the port - and does seem to describe it in terms of a "Virtual Vantage" program. Not sure that helps - I am not clear if its a direct connection or more of a pass through.

Here is how it is described by the author of the firmware:

Version 2.5 allows to share a connected Davis Vantage with a PC program, which is something very often requested.
Now you can have Meteobridge doing the standard tasks, while you still can run your PC weather program of
choice to do additional computations with your weather data. Meteobridge acts like a Davis IP data logger and
provides TCP/IP communication on port 22222 (like the original Davis IP data logger).

and


released January 17, 2015
allow daisy chaining of any Davis Vantage PC weather program. A Meteobridge connected to a Davis Vantage by an Davis data logger (regardless if serial, USB or IP) exposes the Vantage on port 22222 like a Davis IO data logger. This allows other weather programs to also connect to the Davis Vantage and to read data in parallel from it. Only one additional program can read data from the Vantage. Function is a bit similar to the "Virtual Vantage" program that has been offered as a PC solution. Difference is that Meteobridge also supports LOOP2 communication (which "Virtual Vantage" does not) but as a downside Meteobridge can handle only one additional client (instead of 8 like "Virtual Vantage")

Guy

steve wrote:And that isn't the problem here, as it doesn't get that far, it's not getting a response to the DMPAFT command (which does get terminated correctly).

Steve, you know what the diags mean better than me, but I read it that MX gets an ACK to DMPAFT as it then says it is sending the date/time, but then no response after sending the date/time?

Not sure what that means. But maybe a test would be to point putty at the port and enter the commands manually and see what the responses are (or aren't). It would mean pre-creating the checksums though.

Yes, you're right. It's sent the date and time (+CRC), waited half a second and then looked for an ACK and not got one. I should add some more tracing there to show the bytes being sent and whether anything came back - it might have got a CANCEL or a NAK back.

I've put the extra diags tracing in, if you'd like to give it another try.

Ran for a few minutes - diags attached.

Guy

It expects to get an 'ACK' (0x06) back when its sent the date and time, but it's getting an assortment of other characters:

2015-01-22 19:50:32.958 Received response to DMPAFT, sending date and time
2015-01-22 19:50:32.959 36-1E-9E-07-18-11
2015-01-22 19:50:33.459 Received 0x0A
2015-01-22 19:50:33.459 Received 0x0D
2015-01-22 19:50:33.459 Received 0x29
2015-01-22 19:50:33.459 Received 0x3A
2015-01-22 19:50:33.459 Received 0x0A
2015-01-22 19:50:33.459 Received 0x0D
2015-01-22 19:50:33.459 Received 0x0A
2015-01-22 19:50:33.459 Received 0x0D
2015-01-22 19:50:33.459 No ACK

If it thought that the CRC was wrong, it should send 0x21, and if it didn't receive the correct number of bytes it should reply with 0x21. The spec also mentions 0x15 as a valid 'negative acknowledge ' response. But not the characters that is apparently sending.

0x29 0x3A = ): That about sums it up

Yes, perhaps that's an undocumented 'negative acknowledge'

Sounds like I need to contact the Meteobridge code author?

Guy