Sorry Steve, I know you don't want to spend too much time here, but I still don't feel like I understand the complete picture. Could I have one more go:

In the normal course of events, does the connection between logger and MX stay up? Or is every request for a new LOOP packet always bracketed by open and close connection commands? I'm guessing it's the former, ie the connection is usually up (BICBW I know).

I can certainly see that if MX were to handle any error resulting from the connection not being open then that would be an excellent step forwards because it could handle a number of potential fault states.

But the bit I'm not clear about right now is what caused the connection to drop where there is a connection error betwen MX and the logger with the present MX version?

I think the answer is that it was dropped either explicitly or 'inadvertently' by the logger (ie rather than by MX). So my point - and apologies for labouring this - is that if the logger could be configured when busy not to drop the connection but simply to delay sending the next LOOP packet then it wouldn't send MX off in a huff as happens at present. I'm not sure whether or not this is possible, but I can investigate further if it might provide an interim solution to the problem.

Yes, MX opens the connection when it starts up, and doesn’t close it until you close MX. There is the option to make it close the connection once a minute for a few seconds, and then re-open it, this is intended to allow a WLIP to upload to weatherlink.com.

I don’t know what causes the connection to be closed. But yes, if that could be discovered and somehow prevented, it should improve things until a version of MX is available which handles the disconnection.

Have been testing the WiFiLogger with both CumulusMX and Cumulus1.WiFiLogger configured as closely as possible to a stadard USB logger - i.e. No uploading or any other tasks being carried out by WiFiLogger other than those a standard Davis USB logger would perform.

In both cases there have been disconnects.MX and 1 handle the issue differently but it does appear that the connection is closed at random intervals at the logger end.

MX response is different.1. sometimes the log reports:- VP2: OpenTCPIPPort_V, res = 0 and closes2. other times it just stops with no detail in the log3. then we get this on occasions:- !!! loop data not received !!! loop data not receivedSystem.IO.IOException: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host *** Data input appears to have stoppedExiting system due to external CTRL-C, or process kill, or shutdown

For MX I have implemented an external shutdown/restart utilising #DataStopped tag and returned to USB logger.