Cumulus Support

Doesn't seem to have made any difference. I'm afraid I have no idea why this is happening now, when it was getting further than this previously.

Thanks Steve very frustrating.

Just in case I completely wiped my PI SD card and reinstalled Jessie/Mono V4 etc and reran just in case I had corrupted something in all the reloads of MX versions.
Unfortunately the end results were the same.

One of those 'funnies' of software and hardware.

Dave

Steve I have an update on MX which may or may not be a help!

Having been trying to get MX to run on a Raspberry PI as it seemed a great step forward in a stand alone system and reaching a stone wall.

I thought that it may be an idea to try the PI on Windows IOT just in case Jessie was the 'problem' however I read on one of your forum posts that you did not think that IOT net framework would work being a bit limited.

So long story short I fired up a windows 10 laptop, Windows 10, CumulusMX 3038 and the Instromet logger.

It all worked first time, all web updates seemed to happen where and when they should and the dashboard runs perfectly.

So the query is why does Windows 10 cope when the PI and Jessie don't.

Does that help at all?

Dave

Perhaps some difference between the serial port code in Mono and .Net - the code in Cumulus is exactly the same. Or a difference in the USB hardware or drivers.

Thanks Steve.

I know that there have been several instances of folk with various Weather stations having connection problems due to MONO versions.

At present on the PI2 I am running Mono version 4.0.2.

Is it possible that a earlier version or a later version of Mono may actually work?

If you think Mono could be a possibility for my problem can you suggest a range of version to try out?

Thanks

Dave

I'm afraid I have no idea whether one version of mono would be better than any other version. And there are so many differences between the Windows platform and the Pi that it's difficult to suggest where to start. It really requires someone with an understanding of serial port operation, particularly where USB converters are involved, to look at the raw serial communication to determine what the difference is, and why it is different.

Steve I have been having a 'play' and seem to be making some progress.

I have fitted a raspberry pi3 with a 32GB Samsung micro SD card.

Loaded MX 3038 and set up Jessie with Mono Version 3.2.8.

When I fired the system up with NO old data in the data folder and resetting the Instromet EEPROM pointer using the WRST command the system seemed to run. I was able to watch the gauges on a browser window. The data flow on the logger flashed as normal. I allowed the system to run until it also loaded a correct web page and then shut it sown. The attached zip file ending 114646 shows that data.
I then tried to update the Data folder with a copy of all my old data from my Cumulus1 data folder but this seemed to fail to run although data flow seemed to be happening as the led was flashing on the logger. The attached zip file 112927 is a copy of the failing MXdiags file.

I then reset the logger EEPROM pointer and retried the system, it once again seems to be running. So far an hour or so. The MXdiags zip file 180628 shows this run.

It maybe the fact that I have gone back to an early version of Mono 3.2.8 from 4.0.2 or a combination of the resetting of the Logger EEprom pointer.

When you get a 'spare' minute you may get a clue from the attached files.

Many thanks

Dave

It was apparently getting the same archive log back from the station every time - as if the 'progress logs' command was having no effect - this is the command which is supposed to move the pointer on to then next archive record, as you may know. This is an issue I have seen several times before, and Instromet have sent me a station to investigate this kind of problem (it hasn't arrived yet). I'm pretty sure the problem is with the station and not Cumulus, but we will see. The logger is actually acknowledging that it has seen the command, so that seems pretty conclusive to me that the problem is in the logger. This evidence has been presented to Instromet previously, but for some reason their hardware guy is unable to fix it, or doesn't accept there is a problem, or whatever.

Don't forget that there is a bug in MX which causes it to set the logger interval to seconds instead of minutes - this may have some undesired affect (although the station should in theory cope with this, it's allowed in the protocol spec).

Assuming you know how to drive the logger using a terminal program (that's how you reset the pointer?) you could try this yourself - do a RDLG,1 to read a logger entry, then do a PRLG,1 and another RDLG,1 to get another logger entry. You should get a different entry, but when Cumulus does it, it gets the same one again - entry 266301 timestamped 11:55:02 12/05/2106.

Thanks Steve for the fast response and I am glad that Instromet have shipped the 'test' logger that should help in diagnosis.

As for the RDLG & PRLG commands I can certainly hit the logger with those commands using my Windows based machine that Cumulus 1 is running on but I suspect that it will possibly just work!

I have a suspicion that there is a funny between the Instromet and CumulusMX when 'talking' on the Raspberry pi set up.

I am not really sure how to interrogate the logger using the PI as my understanding of Pi/Raspian is not too good.

I will see what I can find out.

Thanks again
Dave

.

Steve an update on Instromet logger commands.

The RDLG command works in all modes, RDLG produces a complete log line by line.

RDLG,1 produces the first line of the log.
RDLG,3 produces the first 3 lines etc etc.

LGCT produces the number of logs available with its checksum.

The PRLG command does not seem to progress the log count at all.

In a test using a Windows PC connected to the logger I received the following data......

RDLG,1 produced rdlg,266450,1,600, - - - - - - - - -
PRLG,1 produced PRLG,1,193
RDLG,1 produced rdlg,266450,1,600, - - - - - - - - -

It would seem that the advance log after reading command is not working, although occasionally reading through an MXDIAGS file, I can see an increment of 1 in the log count before it returns to the original value.

Instromet have been sending me various loggers for testing - there are (at least) two versions of the board, and there are also different versions of the firmware.

The 'old' logger I have also exhibits problems with the PRLG command, so the board is unusable.

I have a new logger where they have tried reducing the baud rate to 19200, and I have been testing that with Cumulus 1.9.4 and Cumulus MX. This new logger has been working fine, both on Windows and on the Pi. I have reported this back to Instromet, so I expect I will be hearing from them on Monday.

I will need to release new versions of Cumulus 1.9.4 and MX to work with the 19200 baud rate boards., and I should be doing that in the next few days, once I have heard back from Instromet.

That is sounding very encouraging Steve and would tend to answer some the queries raised when connecting to the Instromet logger.

There is potentially light at the end of the tunnel.

Thanks for the update.

Dave

Hi

I too have an Instromet station and logger since February this year, i sent back the logger last month as was not working at all since ive had it and running with the new version of cumulus. Its the new board not the old which apparently have been told, the old board was working fine. I have posted on this forum before about the datalogger not working and its interesting to see what is happening as i don't hear nothing from Instromet on this problem which at times makes me frustrated. I have had my weather website setup and linked to WOW since February now and still cant get the live data and download because of the logger problem.
I have a PI and im hoping when the logger returns working i can use mx and have the live data running continuous as the pi will be on and not the pc.

Instromet have asked to me tell anyone having problems with their logger to get in touch with Instromet, and they will swap their logger for one of the new ones which run at 19200.

I'll be uploading versions of Cumulus 1.9.4 and MX which work with these new loggers shortly.

I've uploaded new builds of Cumulus 1.9.4 and MX with support for the new loggers which run at 19200 baud. The MX build also fixes the bug where the logger interval is set in seconds rather than minutes.