System.NullReferenceException:

[BCJKiwi]

System.NullReferenceException:

Win7Pro with a WinServer 2008 Network Login - This PC has previously run Cumulus1 but not currently.
.Net ver 4.5.2

Extracted b3001 files into C:\CumulusMX

Copied Data folder and Cumulus.ini and strings.ini into C:\CumulusMX
Edited ListWebTags to =0

Tried starting directly, by right click run as administrator, and from administrator command line. Same error each time.
Repeatedly get above error - MXdiag attached.

Have also tried installing in a different Win7Pro PC with the same result.

[BCJKiwi]

Just in case they may be useful, here are the Cumulus.ini and strings.ini files.

[steve]

Thanks - there's a bug in the code that reads the strings.ini file - fixed in the next build.

[BCJKiwi]

Thanks.
Deleted strings.ini and system ran but would not connect to station.

Updated to 3002
Reinstated List webtags=1
Reinstated strings.ini
Runs OK but still no connection to station.
Tried the UseDavisLoop=0 (did not expect this to make any difference and it didn't so removed it).

All this testing is taking place on a Win7 Pro PC previously used some time ago as the main Cumulus1 PC.
When I was using this I was also using a clone logger on the Vue. I subsequently purchased a Davis (post 'green dot') logger.
The Davis Logger is now in use on the VP2 on a different PC and am testing CumulusMX on the clone logger and the Vue on the older PC.

So I shut down Cumulus1 on the 'live' system and connected the VP2/Davis logger to the test system in place of the Vue/clone logger and everything showed up.

This clone logger is one I built myself following the information on WXForum prior to the 'green dot' saga and consists of a genuine FTDI USB to Serial cable connected (3wire) to an interface board which plugs into the Console. This board also has the Atmel AT45DB011D flash memory chip on it.

This logger works fine with the VUE and Cumulus1, WD, WUHU and BelfryBoy's logger config utility (WD and WUHU used for testing scripts I published).
So I presume there may be something different in the way the non-davisDLL interface connects to the logger.

There is a second message now showing on close down of the CumulusMX which was not there in build 3001 and appears to relate to this.

MXdiag attached.

[steve]

This seems to be the problem:

2015-01-06 08:37:56.657 Station type = Davis
2015-01-06 08:37:56.657 COM port = COM3
2015-01-06 08:37:56.657 The port 'COM3' does not exist.

Assuming COM3 is the correct port, and is a virtual port (?) then it seems that my code which opens the serial port does not cater for it. Presumably it's not a general problem with not being able to open virtual ports, as presumably the genuine logger also creates a virtual port?

[BCJKiwi]

Originally it was on COM5 and did not work.
Then changed it to COM1 still no go.

It was on COM3 when I tested it with the Davis Logger.
The Davis logger is connected by a USB extender so uses a different chipset and driver.

Did not change the port back to COM5 when I went back to the clone logger and sent you the daig.
Have again changed the port to COM1 and to COM5 and it is still the same problem.

However other things (currently Cumulus1, BelfryBoy's setting utility and WUHU are all working with COM1 and COM5
Does this suggest that there may be some issue with MX and the FTDI chipset?

The Com port appears to be found and opened;
2015-01-06 12:53:05.577 Station type = Davis
2015-01-06 12:53:05.577 COM port = COM5
2015-01-06 12:53:05.671 Connected OK
but then;
Unable to wake VP
2015-01-06 12:53:11.131 Sending DMPAFT
2015-01-06 12:56:26.681 Cumulus closing

Have completely shut down and de-powered PC before restarting - no change.

Attached the latest diag.

[steve]

It could be that my implementation of the serial protocol is not quite correct, but I get away with it on 'genuine' hardware. The "Weatherduino" seems also to be affected. In your case, it looks like it's not getting a response to trying to wake up the console. I think I'm doing what the spec says, for that part at least:

Console Wakeup procedure:
1. Send a Line Feed character, ‘\n’ (decimal 10, hex 0x0A).
2. Listen for a returned response of Line Feed and Carriage Return characters, (‘\n\r’).
3. If there is no response within a reasonable interval (say 1.2 seconds), then try steps 1 and 2 again up to a total of 3 attempts.
4. If the console has not woken up after 3 attempts, then signal a connection error

Could it be something to do with the serial port settings? My code assumes 19200, 8-N-1.

[BCJKiwi]

Using 19200 8 N 1
The thing that puzzles me is that the other programs are working fine (e.g. Cumulus1) on the same settings. - Only one at a time of course!

The diags don't indicate if it is retrying in but there is around 4 to 5 secs between the timed messages in the log.

Wondering why DMPAFT is sent if there is no response?

[steve]

Wondering why DMPAFT is sent if there is no response?

Good point. So it did subsequently get a response to the wakeup. It's not getting anything back in response to the DMPAFT. If it got an ACK it would say so - "Received response to DMPAFT, sending date and time" - and if it got something that wasn't an ACK, it would say so and say what the character was that it received.

[BCJKiwi]

Have downloaded and updated the FTDI driver (same ver number but later file date. Don't you just hate that ! - is the driver different or not?) Anyway there is no difference in the way it works. These are FTDI supplied drivers that are certified by M$oft

What part did/does the CP10xManufacturing.dll or the SiUSBXp.dll (and others?) play in Cumulus1? There does not appear to be any corresponding code in CumulusMX.
Since the FTDI chip already appears as a COM port I am just wondering what these things do/did as they appear (me guessing blindly here!) that they would be trying to interact directly in some way with the USB to do the conversion to COM.

I see these appear to be the same files as Davis Weatherlink uses so maybe the issues are something to do with FTDI?

Have seen some different info in the diag - not sure if it is relevant - see attached.

[steve]

What part did/does the CP10xManufacturing.dll or the SiUSBXp.dll (and others?) play in Cumulus1? There does not appear to be any corresponding code in CumulusMX.

I think the Davis DLL required them, they're not used by Cumulus 1 directly. I think they're part of the SiLabs virtual serial port stuff. They're no use to MX, it just requires a serial port (virtual or otherwise) to connect to.

[BCJKiwi]

Well it is either the clone logger itself or the FTDI chipset/driver.

Moved the PC to the VP2 console and plugged it in directly (instead of via the Cat5E USB extension setup which used some other chipset drivers of it's own). Silicon Labs CP210x drivers were installed automatically and Cumulus MX 3003 ran fine.

Moved it back to the Vue with the FTDI USB/Serial chipset and no connection to the VUE.
Have ordered a Silicon Labs CP2104 adapter but it will take a few weeks to arrive as it is not available locally as far as I can see.

Will CumulusMX b3003 run without a logger as I can knock up a quick and dirty non logger serial interface for test on the Vue in an hour or so?

Thanks

[BCJKiwi]

Found a decent Serial Port Monitor program (trial only!)
Logged the Port setup and data flow for CumulusMX, Cumulus1 and the logger config utility.

There appear to a number of differences in the way the port is set up, and, in the opening sequence to the Console logger.

The clone logger uses the official FTDI manufactured cable which has pull-ups internally for the control lines but does expose CTS and RTS. These are not connected so is configured to use a 3 wire circuit only. The CTS RTS could be linked but as this is not required for Cumulus1/Davis DLL etc, I doubt this is required.

See the attached - hope this may help.

Thanks again for your sterling efforts with this New program!

[steve]

This looks correct to me:

<LF><LF><LF><LF>DMPAFT<LF>

The first <LF> characters are presumably the attempts to wake the console. I don't know why they all appear on the same line, perhaps something is buffering them, or perhaps that isn't relevant. Perhaps that is why the clone logger doesn't respond correctly.

[BCJKiwi]

I know that is what you expected to see and is what you explained the Davis spec said should be done. However, if I read the monitor output correctly, it does not do the same job that the Cumulus1/Davis DLL startup sequence does. The Cumulus1/Davis DLL sets up the port quite differently and sends <LF><CR>s in place of just <LF>.

Cumulus1/Davis DLL does;

Code: Select all

DTR on
Data bits=8, Stop bits=1, Parity=None
Set chars: Eof=0x1A, Error=0x00, Break=0x00, Event=0x1A, Xon=0x11, Xoff=0x13
Handflow: ControlHandShake=(DTR_CONTROL), FlowReplace=(TRANSMIT_TOGGLE, RTS_HANDSHAKE, XOFF_CONTINUE), XonLimit=2048, XoffLimit=512
Set timeouts: ReadInterval=0, ReadTotalTimeoutMultiplier=25, ReadTotalTimeoutConstant=1200, WriteTotalTimeoutMultiplier=25, WriteTotalTimeoutConstant=2000
Set timeouts: ReadInterval=0, ReadTotalTimeoutMultiplier=5, ReadTotalTimeoutConstant=100, WriteTotalTimeoutMultiplier=0, WriteTotalTimeoutConstant=0
Set timeouts: ReadInterval=0, ReadTotalTimeoutMultiplier=25, ReadTotalTimeoutConstant=1200, WriteTotalTimeoutMultiplier=25, WriteTotalTimeoutConstant=2000
<LF>
[len=0]
<CR>
Set timeouts: ReadInterval=0, ReadTotalTimeoutMultiplier=5, ReadTotalTimeoutConstant=100, WriteTotalTimeoutMultiplier=0, WriteTotalTimeoutConstant=0
Set timeouts: ReadInterval=0, ReadTotalTimeoutMultiplier=25, ReadTotalTimeoutConstant=1200, WriteTotalTimeoutMultiplier=25, WriteTotalTimeoutConstant=2000

where CumulsMX does this instead

Code: Select all

DTR off
Data bits=8, Stop bits=1, Parity=None
Set chars: Eof=0x1A, Error=0x00, Break=0x00, Event=0x1A, Xon=0x11, Xoff=0x13
Handflow: ControlHandShake=(CTS_HANDSHAKE), FlowReplace=(TRANSMIT_TOGGLE, RTS_HANDSHAKE), XonLimit=1024, XoffLimit=1024
Baud rate 19200
DTR on
Data bits=8, Stop bits=1, Parity=None
Set chars: Eof=0x1A, Error=0x00, Break=0x00, Event=0x1A, Xon=0x11, Xoff=0x13
Handflow: ControlHandShake=(DTR_CONTROL, CTS_HANDSHAKE), FlowReplace=(TRANSMIT_TOGGLE, RTS_HANDSHAKE), XonLimit=1024, XoffLimit=1024
DTR on
Set timeouts: ReadInterval=-1, ReadTotalTimeoutMultiplier=-1, ReadTotalTimeoutConstant=-2, WriteTotalTimeoutMultiplier=0, WriteTotalTimeoutConstant=0
In/out queue size 4096/2048
Purge the serial port: RXABORT, RXCLEAR
Purge the serial port: RXABORT, RXCLEAR
Purge the serial port: TXABORT, TXCLEAR
<LF><LF><LF><LF>DMPAFT<LF>

using Diffmerge or something similar on these two files (from the .zip in my last post) makes the differences clear.