Cumulus Support

Cheers Steve, well I have rebooted the Pi and disconnected the serial/USB connection to no avail. Exactly the same report back.

I reconnected the Instromet to a Windows 7 PC running Cumulus 1 with no problems they talked straight away.

This morning I downloaded and fired up MX3034 and unfortunately I am getting exactly the same non communication as MX3033.

Any further tips I can try?

Dave

It's baffling because this was previously working. The Instromet code only has a very minor change between 3032 and 3033/3034, and that is just to check the returned data for empty fields. Just to be sure, do you still have a copy of 3032 to try?

Have you done any updates on your Pi? What version of Mono are you currently using?

steve wrote: Do you still have a copy of 3032 to try?

Have you done any updates on your Pi? What version of Mono are you currently using?

Thanks Steve once again.

Yes I believe I do have a copy of 3032.

As for the PI update, yes and no.

I did buy another Pi so that I could devote 1 to my FineOffset for experimentation with Mx and the second one to devote to the Instromet so that when I get a software update I did not forget things like port settings etc.

I copied the SD card from one Pi to the other so assumed that the Os and Mono versions were maintained without corruption.

After your last post I will go away and play with all combinations and report back on progress.

Thanks again for your assistance

Dave

Ah, so this is actually a different Pi to the one that was getting further than this before? Is the serial port device name still valid, for example?

Indeed yes, I did the insertion/removal 'test' this morning and received ttyUSB0 when inserted and it disappeared when removed.

I will move the original unit from the Fine Offset and just see what actually happens, if anything.

Dave

Steve as promised I have been experimenting with CumulusMX, Pi and Instromet unfortunately with little success.

I downloaded Raspbian and mono onto the NEW PI just in case I had corrupted the files when copying the SD card between NEW & OLD.

The comms error seems to have been sorted so maybe the logger was locked from previous connections.

I then ran the New Pi with the Instromet using MX versions 3032, 3033 & 3034 all produced the same results, logger has no data flow and just hangs.

I then transferred the Instromet to the OLD PI running MX 3034 and it too produced the same result logger has no data flow and just hangs.

I have attached a multitude of MXdiag files under their respective MX versions if it is of any help.

Thanks

Dave

They're all the same - it's now getting a response from setting the logger interval, but no response (or not the response it's expecting) from setting the clock. So something with the station has changed, as it was getting further than this before and this code hasn't changed (and you're getting the same with 3032 anyway). I'll add some more logging to the next build. You don't have debug logging on, so, please turn that on, and while you're editing Cumulus.ini please also turn on data logging.

One thing you could try in the meanwhile would be to disable clock synchronisation in the station settings, then we can see how far it gets after that.

Hi Steve and Good News from Ghent Kent

I did as you suggested and turned off the Time Synchronisation and after that things started to happen.

The data flow light on the logger showed there was a data flow in progress.

I was able to actually view 'true' data on the gauges panel.

The Diags file showed significantly more information.

Apart from a few checksum errors at the start of the file the rest seems to be 'normal'

I have attached the latest file to this post.

I think progress is being made.

Thanks

Dave

Thanks - those checksum errors are the ones I added the logging code for a few builds back so I could investigate, before we got sidetracked by other issues, so I can investigate that now. It won't download any archive entries until I can get that working.

It looks like trying to set the clock causes problems - I'll look at the code to see if I'm doing anything wrong, otherwise the extra logging I'm putting in for the next build will hopefully throws some light.

Having asked you to turn on data logging, you may want to consider turning it off again for now, as the diags log will get very big now that it's reading live data, if you intend to leave it running for any length of time.

Thanks Steve and yes I will turn off the Data Logging as I had noticed a rapidly increasing file size.

Thanks again for your assistance.

Dave

The invalid checksum message is caused by the response to the 'get log count' command:

2015-11-26 13:24:52.320 Response from LGCT=lgct,6890,3
2015-11-26 13:24:52.322 !!! Checksum invalid !!!

It's correctly flagging that, as the correct checksum is actually 38 rather than 3 - I wonder if a byte has got lost from the end of the response. I'll add further logging for that which may help.

Thanks for the update Steve an interesting observation.

If you need any tests done at any time just post.

Dave

Hi Steve, I have tried MX version 3035 and have attached the latest MXdiags file for your perusal.

It still seems to hang but there is probably more data for your diagnosis.

Thanks

Dave

I can see why it thinks the checksum for the lgct response is invalid, and I can fix that. But I can't see any signs of it hanging, it seemed to be reading live data fine, right up the point where you closed it down? What exactly did you see, from the point where you started it up, to when you closed it? Does it ever display any data in the web interface?

steve wrote:I can see why it thinks the checksum for the lgct response is invalid, and I can fix that. But I can't see any signs of it hanging, it seemed to be reading live data fine, right up the point where you closed it down? What exactly did you see, from the point where you started it up, to when you closed it? Does it ever display any data in the web interface?

Hi Steve and humble apologies for my terminology. Looking at that data file I thought that the system was looping as I did not see what I thought were updates.

Having looked in detail I can indeed see changes so I obviously was wrong.

When I run 3035 I get the gauges on the Web browser showing real data.

I will reconnect the Instromet Logger, the Pi and run CumulusMX3035 on a prolonged test and see if I can infact upload data to the web.

As you know the Instromet logger does take a long time to transfer data updates if Cumulus/CumulusMX is restarted so I was probably jumping the gun!

Bear with me and I will update this post when I have more data.

Thanks again

Dave