Instromet logger and MX version 3047

[Hobbyist]

Mark, I saw that you had uploaded newer versions of MX than the V3043 I have been running successfully for quite a while on Intromet loggers and Raspberry Pi's.

This morning I cleared my 'test' logger and Pi of the old 3043 version and downloaded the newer V3047.

It seemed to load and start running as normal although the Instromet logger can take hours to catch up with new/old data.

I looked at the MXdiag file and noticed that it seems to be lost in a loop.

Normally the RDLG commasnd will read the data for the numbered packet and the advance to the next one.

If you look at the attached bit of the file it seems to start at RDLG

20190223-102537.txt

747800 and then 74798, 74798, 74799 & then 747800.

It may well be me but I cant seem to get it to carry on through the data count.

Any suggestions?

Cheers Dave

[mcrossley]

Is not you, but I think it's your logger. Cumulus just sends the logger a RDLG,1 which should return the current entry and advance the pointer by one. It does that until the pointer reaches the last entry. But your logger seems to have got itself confused and is looping around the same records.

Older versions of Cumulus did not set the current pointer correctly, so it ended up pointing at some random entry when Cumulus was restarted. This was fixed in b3047, so once you get this working then startups should be much faster in the future as it only downloads the logger records since Cumulus was stopped.

Back to your problem, I don't know enough to give you a definitive answer I'm afraid. Can you set the logger pointer to roughly where it should be manually with a terminal emulator, then try starting Cumulus again? Angus on this forum used to do that iirc before we worked together to fix the Instrument protocol handling in b3047.

[Hobbyist]

Hi Mark and thanks for the reply.

I have been running a few tests between v3043 and v3047 on a spare PI3 and Instromet logger that I have.
To be honest I can see no improvement on the 2 variants of CumulusMX as to the speed of 'catch' up.
I ran the set up on 3043 and 3047 and got restart times of 10m 10secs & 10m 19secs respectively.
The 'stuck in a loop' phenomenon is still there but interestingly although it appears to stay where it is in reality it eventually it gets to the end and starts Live data.
Can't see why that is.
I have attached a copy of the fully MXdiags file if it is any help.
It is a pain having to wait so long for an Instromet to catch up, I did try with my online system which has a significant history file with V3047 and it took 8 hours to reload!
I am using an old version of Mono as I also have a WH1080 test station running on another system, is the mono version still significant these days?
If I can assist in any way please let me know, Steve and I did exchange points a while back.
Thanks again
Dave

20190228-113602.txt

e

[mcrossley]

The problem is still with your logger I fear - is there any way to "reset" it? Once your logger is fixed you should see fast start-ups in Cumulus.

The version of Mono isn't an issue on newer versions of MX.

[Hobbyist]

Thank you once again for the info.

I have, in the past, rewritten the EEPROM read/write pointers back to a zero point using the WRST command in an effort to speed up my Web serving system..

This does indeed speed up the 'delay but as the records build up once gain the delay gradually increases as the older versions of CumulusMX did go through every record in order to reach the next valid 'new' reading.

There is also a loss in readings when CumulusMX is shutdown and restarted as the valid pointer of the logger is obviously lost.

I wonder what you have actually amended that is a more efficient way of sorting out the wheat form the chaff in version 3047.

I will do another reset on my standby system and report back on record numbers versus reboot time.

Cheers

Dave

[mcrossley]

Yes, b3047 fixed the pointer issues with Instromet loggers, I tested b3047 with another Instromet user, and pointer is now being set correctly, and on restarts it only reads the historic records since the previous shutdown, hence the startup is *much* faster.

Your logger however is behaving oddly, and looping round the same few records when fetching the historic data. I'd suggest some sort of "factory reset" on it if possible, if not then I think Instromet need to take a look at it, or at least be involved in diagnosing the problem? It looks like it is a hardware issue to me rather than Cumulus.

[Hobbyist]

Mark an update on this 'funny'

I have allowed my logger to store 2200 records after a pointer reset and last night stopped and restarted CumulsMX V3048 (have updated) and the logger took 78 minutes to catch up with historical data.

I looked again at MXdiags and again it looks as if it is indeed sitting in a loop of RDLG increasing and then resetting.

The actual count though must be progressing as it eventually starts running!

I see that another user is seeing a similar pattern as do I on my backup Instromet logger system.

I have sent a full Mxdiag file to Instromet to see if they can understand what is going on.

Thanks for the rainfall and sunshine display mods in V3048 for the Instromet that is very useful.

Regards Dave

[mcrossley]

I'm wondering if previous versions of MX have messed up the logger in some way. An error was causing older versions of MX to "randomly" set the logger pointer to various values. That's why I asked on the other thread if there was any way of re-initialising the logger and clearing its memory.

[Hobbyist]

I seem to remember asking Instromet this many yerars ago and being told that the memory could not be easily reset.
The only way of resetting things was to use the WRST command to move read/write pointers around.
I presume that the EEPROM could be reset but would probbaly require the manuafacturer to remove it from the logger PCB.
There is a coin cell on board I assume this only 'holds' data should main power be lost.
I will keep you posted on any feed back from Instromet.
Thanks once again
Dave