Hey All,
I'm already working with folks from CSI about the following issue, but I'm curious if anyone else out there has had a similar problem.
We're using a smart sensor to measure water flow in rivers. SDI12 is used to communicate with the CR1000s. Prior to updating one of our CR1000s to OS16, everything worked great w/ OS15 and OS14. Now, however, our data logger seems to stop communicating with our sensor at midnight on the same day of starting a new program. Literally, the last scan was at 23:59:44. Then nothing. The smart sensor stops (doesn't seem to be getting a measurement command from the CR1000.
Anyone else seen this with OS16 for the CR1000?
Cheers,
Dave
Hey All,
Addendum: it seems the issue is not isolated to a smart sensor (ADCP - for measuring water velocity and flow) that uses SDI-12. This issue also occurred to another ADCP of ours (different manufacturer) which is communicating in serial (RS-232) with the CR1000 with OS16. Uggghhh...
Is anyone having problems with OS16 for a CR1000 causing your instrumentation to stop taking measurements after midnight on the first day that you start a new program up?
Cheers,
Dave
Well I guess I'm not alone!
We been using cr1000's for a couple years now with smart sensors as well, mostly YSI sondes using concurrent command, the reason being the YSI sondes can put out a serious data string of up to 25 parameters, the regular aM! command can handle only 9 to 12 at most. However, with each OS release the Measure/Display command routine has changed requiring extra lines of special code for it to work. So, we have just about givin up on the SDI protocol and started to concentrate on RS232 interface as much as possible.
The issue now is that one particular system type (eight in all) that consists of two cr1000's each, one runs profiling code the other runs metereological data gathering code, both loggers are connected to the same power supply via the same fuse, interlinked via the RS232 port, Pakbus addressed with two CS105's comms either direct or via modem on the CS io port.
The issue is every so often the profiler unit will RESET, while the Met unit continues to work. The folks at CSI are convinced its power related, I'm 99.9% certain its not because I have a good Fluke DVM monitoring power and it simply does not indicate a power drop of any sort, neither does the cr1000 Status monitor! The OS in these units is 16.02 which runs much better then previous OS 16.
The Reset is random, it may work a day or a week and then reset, however a pattern is emerging that seems to coincide with serial port open/close time frame.
Below is a few lines logged to the event log file on a regular power up, followed by an error event followed by the logger Status
-------------------------------------
TOA5 cr1000 SMast pkb 10 winch CR1000
TIMESTAMP RECORD EventMsg
TS RN
Smp
40:12.3 0 ***** Datalogger Reset *****
41:10.3 1 [04/27/2009 13:41:10.26] WARNING: Unable to verify sonde's time.
41:10.3 2 (Setup Mode)(F3) - Manual Fixed Reference reading (1.768).
41:10.3 3 (Setup Mode) (F5) - Manual RS232 reading.
41:10.3 4 (Setup Mode) (F6) - Manual read sonde information and update time.
41:10.3 5 [04/27/2009 13:48:25.01] *** Start of profile [1]2, 1, 1) ***
41:10.3 6 [04/27/2009 13:48:30.76] New parameter order found 00013D07; Sonde (00013D07).
---------------------------------
33:06.0 7981 [06/15/2009 21:33:26.24] (RS232) - 'data' command sent. - WakeSonde(0); BytesCheck(0);
33:06.0 7982 [06/15/2009 21:33:26.75] (RS232) - Elapsed time(0); BytesCheck(91);
33:06.0 7983 [06/15/2009 21:33:30.86] (RS232) - 'data' found at Loc(1); Parsing from(91);
33:06.0 7984 [06/15/2009 21:33:31.89] ERROR: (Move Error check) - Unable to move correctly, aborting profile.( _ContPFL(2))
35:37.5 7985 ***** Datalogger Reset *****
36:35.3 7986 [06/15/2009 21:36:35.32] WARNING: Unable to verify sonde's time.
36:35.3 7987 [06/15/2009 21:55:11.63] WARNING: (SondeReading) - Depth location is not yet known. (Hourly Sonde Data setup Mode)
-----------------------
Status Summary
6/18/2009 9:08:20 AM
Datalogger Information
Station Name: 9798
OS Version: CR1000.Std.16.02
OS Date: 090116
OS Signature: 40616
PakBus Address: 10
Security Settings(1): 0
Security Settings(2): 0
Security Settings(3): 0
Panel Temperature: 17.69 °C
Memory: 2097152 bytes
Watchdog Errors: 0
Program Information
Current Program: CPU:511small step fixRefTopToBottomTable.cr1
Start Time: 6/15/2009 9:35:37 PM
Run Signature: 10471
Program Signature: 49446
Compile Results for Last Program Sent: CPU:511small step fixRefTopToBottomTable.cr1 -- Compiled in SequentialMode.
Program Errors
Skipped Scans: 0
Skipped Records in PFL_Step: 0
Skipped Records in DFinder: 0
Skipped Records in ParamOrder: 0
Skipped Records in DbgMoveSequence: 0
Skipped Records in FixedRef: 0
Skipped Records in SondeHourly: 0
Skipped Records in EventLog: 0
Skipped Records in SystemInternals: 0
Variable Out of Bounds: 0
Battery Information
Battery Voltage: 13.24
Lithium Battery: 3.48
Number of times voltage has dropped below 12V: 0
Number of times voltage has dropped below 5V: 0
Card Information
Card Status: No Card Present.
Bytes Free: -1 bytes
-----------------------------------------------
Any ideas what may cause this will be greatly appreciated
fred
Fred,
How did you obtain OS 16.02? Just last week I downloaded CR1000 OS 16 from the CSI website and according to my Status Table:
OSVersion CR1000.Std.16
OSDate 081029
OS 16.02 would be a beta version (when released it will be OS 17).
I am curious about the "Datalogger reset" string above. I don't think that would be coming from the datalogger -- perhaps it is soming from the sensor? If the datalogger were resetting, your watchdog counter in the status table would be incrementing.
Dana W.
Both of the users above were using the concurrent command from the SDI-12 instruction. OS16 mishandled the concurrent command when the return exceeded nine variables.
Recently OS17 has been released, and fixes this error.
Give it a try!