With this program i get skipped records. The measuring frequency goes down to 9 Hz. Without "PakBusClock(2)" it works fine.
=================================
'CR6
BeginProg
PakBusClock (2) 'from CR1000 with GPS
SerialOpen (COMU9,115200,4,0,1000) 'Clockreport
Scan (100,mSec,10,0)
CSAT3 (csat,1,5,91,10)
LI7700 (LI7700(),1,2,2)
PanelTemp (ptemp,15000)
TCDiff (fw_in,1,mV200,U1,TypeE,ptemp,True,0,15000,1.0,0)
CallTable RawData
NextScan
=================================
Sample data (without sensors):
"TOA5","4031","CR6","4031","CR6.Std.06","CPU:version13.CR6","2205","RawData"
"TIMESTAMP","RECORD","Ux","Uy","Uz","Ts","diag_csat","LI7700_Methan","LI7700_press","LI7700_temp","LI7700_diag","LI7700_rssi","LI7000_CO2","LI7000_H2O","Inklino_x","Inklino_y","fw_in","Inklino(1)","Inklino(2)","Inklino(3)"
"TS","RN","","","","","","","","","","","","","","","","","",""
"","","Smp","Smp","Smp","Smp","Smp","Smp","Smp","Smp","Smp","Smp","Smp","Smp","Smp","Smp","Smp","Smp","Smp","Smp"
"2017-02-09 10:55:59.7",722507,0,0,0,0,0,"NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN",1869,0,0,0
"2017-02-09 10:55:59.8",722508,0,0,0,0,0,"NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN",1866,0,0,0
"2017-02-09 10:55:59.9",722509,0,0,0,0,0,"NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN",1863,0,0,0
"2017-02-09 10:56:00.1",722510,0,0,0,0,0,"NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN",1899,0,0,0
"2017-02-09 10:56:00.2",722511,0,0,0,0,0,"NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN",1889,0,0,0
"2017-02-09 10:56:00.3",722512,0,0,0,0,0,"NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN",1883,0,0,0
"2017-02-09 10:56:00.4",722513,0,0,0,0,0,"NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN",1878,0,0,0
"2017-02-09 10:56:00.5",722514,0,0,0,0,0,"NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN",1874,0,0,0
"2017-02-09 10:56:00.6",722515,0,0,0,0,0,"NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN",1870,0,0,0
"2017-02-09 10:56:00.7",722516,0,0,0,0,0,"NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN",1867,0,0,0
"2017-02-09 10:56:00.8",722517,0,0,0,0,0,"NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN",1864,0,0,0
"2017-02-09 10:56:00.9",722518,0,0,0,0,0,"NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN",1861,0,0,0
"2017-02-09 10:56:01.1",722519,0,0,0,0,0,"NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN",1863,0,0,0
"2017-02-09 10:56:01.2",722520,0,0,0,0,0,"NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN",1857,0,0,0
"2017-02-09 10:56:01.3",722521,0,0,0,0,0,"NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN","NAN",1855,0,0,0
What is the cause?
I am afraid this is a consequence of trying to set the time so often in this way. This is because the logger has two ways of dealing with external clocks.
The first method is where you use a GPS unit connected to the logger with the PPS signal. For most of our loggers the PPS signal is then effectively used as the master clock of the datalogger. This means after the initial sync, the logger never has to adjust its clock again...at least whilst the GPS clock is providing the PPS signal.
For all other adjustments of the logger clock, when a clock change is triggered the logger pauses running the current program at the end of the current main scan, adjusts the clock and then restarts the main scan and any slow sequences at the next appropriate clock tick. To stop, adjust the clock and restart the scans takes some while which means even the clocks agree exactly you risk skipping a scan (and the storage of a record in your case) in fast running programs. Even with slower programs you risk the same if the logger clock is running even a small amount slower than the master clock. This is because the clock in the logger could be pushed forward by the master beyond the time the logger was thinking it was supposed to store data, leading to the occasional skipped scan/record. This problem is worse when there is any jitter on the master clock or in the communications path.
To resolve your immediate problem you could add a GPS unit to the CR6 so they are both synced to GPS time. If the logger's are adjacent then you can probably even parallel up the outputs of one GPS to the two different loggers. Alternatively if you could live with a small amount of drift of the two systems relative to each other by setting the clock (calling the clockreport) at less frequent intervals, say once per hour. The amount of drift of the logger clock over one hour will be somewhat less than 100 ms (Our quoted figure of 3 mins/year allows for the full temperature range of the logger. In normal temperate temperatures the drift is much, much less than that.)
One other approach is to synchronise the scans of the CR6 logger to the CR1000 by sending pulses from one logger to the other (see the WaitDigTrigger) but it can be difficult to tie the data together because the timestamp written with the data by the CR6 with still be based on its own clock.
Thank you for the informations.
If the logger's are adjacent then you can probably even parallel up the outputs of one GPS to the two different loggers.
Unfortunately that does not work. Only one logger get the signals from the GPS. I will use two GPS.
It surprises me that you cannot connect the two in parallel as a logger control port inputs should not load the GPS output much at all. The one issue you could have is if you are using a new GPS16X sensor with a CR1000 without using some form of interface device.
Newer GPS16X sensors only output 3V signals whilst the CR1000 is designed for 5V signals. Sometimes the CR1000 will just work with the newer units but this is not guaranteed. I would expect a little extra load on the output signals might stop it working.
When Garmin made this change we developed a small interface called the A300 specifically to allow you to connect new GPS16X units to the CR1000. It converts the output signals to 5V. Note it is not needed for the CR6 which has 3V compatible control ports.
The GPS is an older system with 5 V output. It works at the CR1000 and the CR6, but only separate.