Hello,
I am having an issue with how Loggernet Admin 3.4.1 collects data. I have five CR10X stations, two which are causing problems. These two are connected by NL100s via Ethernet extenders which are unfortunately run a long way over pretty low quality twisted copper pair phone lines. Due to these poor phone lines, the once a minute scheduled collection from these two stations can often not connect for anywhere from a few attempts to several hours. Usually this isn't a problem, but sometimes once it finally manages to collect, LN acts as if it is a first collection and collects data which have already been downloaded. This causes a bloated dat file with redundant data, and makes the data being displayed in my RTMC tables and graphs go back to whatever is currently being retrieved, not the most recent data. What makes LN think that it hasn't collected from these dataloggers in the past? Is this related to the number of retries or some other setting which I can change to stop this from occurring?
I have another question possibly related to this problem. I recently upgraded to RTMCpro 3.2 and cannot find the "Attempt to Stay Connected to This Station" feature (or whatever it is called). I used to use this for the one station I had permanently connected by phone modem and I was wondering if it might help solve the problem above. I do remember it being a well hidden option, but now I can't find it anywhere and I'm wondering if it has been removed.
Thanks,
Alex
The software keeps track of a pointer in the datalogger so that it knows what final storage location it last collected data from. When it does a data collection from mixed array dataloggers, it goes to that pointer, backs up four values, and compares those four values with what it knows it last collected. If the values do not match, then it collects all data in the datalogger. In the logs you will see a message similar to "last four do not match".
There are at least two instances where this will happen (1) the datalogger has "rung around" and begun storing new data over old and (2) the software thinks it is connected to one datalogger when it is actually connected to a different one (a fairly rare occurrence).
On the datalogger's FS Area tab in the Setup Window of LoggerNet, there is a set of controls for Collect Mode. The number of arrays to collect on a first call to the datalogger is set under the "Arrays to collect on first call" (note that a "rung around" datalogger is considered first call). You can collect 10, or 100, or 24, or whatever value you want. This won't really take care of duplicate data (for instance if you collect 100 records, and 50 of those 100 were already collected), but it will reduce the number of duplicate records and the amount of phone time used on the call. On the flip side, if the datalogger really has rung around you will not collect all available data in the datalogger.
If the issue is that the software is connecting to the wrong datalogger, you can set a unique security code in each of the dataloggers. The datalogger will refuse the connection if the software issues the incorrect security code.
The feature you are describing in RTMC was Connection Management. It has been removed from the software.
Dana W.
Thanks for your reply Dana. Neither of the instances you described sound like the problem. The datalogger definitely hasn't rung around since it often does this less than ten minutes after a failed data collection. No data is being lost. Loggernet isn't connecting to the wrong datalogger either, but I have gotten the "last four data points mismatch" (or something to that effect) message in the transaction log. I'd like to try adding a security code, but the instructions between Edlog and LoggerNet's Setup are a bit confusing. Does "Program Security Level 1" in Edlog correspond to "Hardware: Advanced: Security Code" in Setup?
Could it be that if the connection is poor, there may be transmission of data that is garbled at the end of the previous connection so that the 'last four data points' do not match, hence the recollection of all data? To the best of my knowledge, the data should go through error correction but maybe not. I might try a slightly slower baud rate to see if this helps on those two dataloggers.
Alex,
As LarryT suggests, it may be that your raw data file is being corrupted. Are you opening the *.dat file in an application and saving it in that format? For example open the *.dat file in a spreadsheet then save in spreadsheet format?
Janet
During data collection, even the first four values are error checked so the chances of a corruption slipping through are small. Loggernet should re-request that data if it detects a corruption.
The values from the last collection that are used to check continuity are stored in a separate file, as well as being written to the data file you access on the PC. If you had deleted the data file the check should still work.
I would recommend setting the security in the logger and in Loggernet (different for all stations) just in case Loggernet has gotten mixed up with which station it is talking to. Setting the security level 1 and matching it to the setting in LN is what you need to do.
When I look at the dat file in a text editor after it has redownloaded all the data on the logger, the last line of data before the dump always seems to have some part of the timestamp from the next line tacked onto the end of it. Based on that it seems that the data may in fact be getting corrupted.
I'll try setting the security level 1.
My stations are connected via IP through NL100s, so to my knowledge there isn't a way to slow the baud rate. I've tried different maximum packet sizes, but I don't know if that has had any effect. Any recommendations for that setting?