At some occasions in the dat files, the first value is NAN, with the following row containing data values with have shifted one column to the right. An excerpt is given hereunder
12:50:00 0.659819 0.691927 0.765095 0.764756 0.751707
13:00:00 "NAN" 0.691925 0.765097 0.764752 0.751710
13:10:00 0.659819 0.659790 0.691927 0.765096 0.764747
13:20:00 0.659821 0.691927 0.765096 0.764751 0.751707
13:30:00 0.659819 0.691927 0.765098 0.764747 0.751704
13:40:00 0.659818 0.691927 0.765097 0.764753 0.751705
13:50:00 0.659819 0.691927 0.765097 0.764752 0.751705
This occurs not frequently (few times a month), but the apparant random nature, and the cleanup it requires (in a further automated enviroment), annoys me.
What could be the reason? A timing problem between the measurement (VW sensors with AVW1 interface and AM16/32 mux) and the call to the Datatable? My technician suggested to include a delay in the logger (CR1000) program prior to the data table call.
Thanks for any help,
Jan.
Can you post all or part of your program ?
I consulted with a few of the "seasoned" AE's that
have experience with the AVW1.
The AVW1 uses a period averaging (pulse counting) method and
is therefore susceptible to NAN responses caused by spurious measurement noise. Could there be intermittent noise interference on the circuit ?
Of course, the rigorous way to solve that problem is to upgrade the AVW1 to an AVW200 series device:
http://www.campbellsci.com/avw200
If the NAN were caused by a programming error/problem, one would think an NAN would occur more than just every "once in a while".
You could also place a conditional(IF) and loop in your program and continue making the measurement (up to a reasonable limit) until a value other than NAN is returned.
One other issue that can cause NANs is that the sensor is not resonating for as long as expected or perhaps as it used to. The latter can happen due to ageing but also due to water ingress, so it may be worth checking the sensor and cabling.
If there is no evident problem then reducing the number of cycles to count can often help avoid the occurence of NANs. Do not reduce the number too far though as you then risk increasing noise and resolution problems.
As mentioned above the pickup of bursts of noise can also cause this too. Check the cables used are screened and the screens connected properly.
Thanks for all the replies.
The presence of the NAN as such is not a problem. It is rather that its presence apparantly disturbs the data table layout - in particular for the next row (corresponding with the next program cycle or loop). Or maybe I should look more closely to the data registers - they seem to be messed up after the NAN has appeared.
I also saw that the problem only persists for the first 16 values - this might be related with the 16 gauges connected to the mux.
Is there a way to attach the program file? Or can I copy and paste it in this window?
Yes -- just paste your program into your text entry window. If you feel it is too large, you can post just the parts being discussed.
This is interesting and I will have to go back to some files from two years ago. In my case it was just a simple program reading thermocouples on an AM25T. It too caused a shift of values by one column.
I would like to clarify the "problem" that exists in the record following the record which contains the NAN:
The NAN shows up in the record for 13:00:00, in the
first data column after the timestamp.
The real problem is with the record with timestamp 13:10:00.
It shows the right number of value columns (5) but appears to give two readings for the first column (presumably the one that was missed at 13:00:00) followed by three more readings that are shifted to the right. We see .659xxx in the column where we expect .691xxx. We see .691xxx where we would expect .765xxx, we see .765xxx where .764xxx is expected. Finally we see .764xxx where .751xxx is expected.
So the 13:10:00 record should really be:
13:10:00 0.659790 0.691927 0.765096 0.764747
or
13:10:00 0.659819 0.691927 0.765096 0.764747
and not
13:10:00 0.659819 0.659790 0.691927 0.765096 0.764747
as is given.
But even those two "fixed" versions of the record are still missing the 5th data column (.751xxx).
I needed to clarify this, since it took me a while to understand what was wrong with the output.
However, for us to make any sense of why this is happening, we need to see your program
Yes, actually it's the first 16 values that have been shifted, from the 17th this shift has disappeared (meaning also that the 16th value is missing in this row following the NAN value). Maybe this is linked to the 16 channels of the AM16/32 MUX to which the sensors are attached.
In total 16 MUX are attached to the CR1000 logger, they are controlled by a SDM-CD16D. And a AVW100 interface conditions the VW sensors.
The program is attached.
'CR1000 logger program for reading VW sensors in PRACLAY Gallery
'Created by CLe
'Declare Variables and Units
Dim i,j,mask(16)
Dim Lcount
Public Batt_Volt
Public PTemp_C
Public vibw(256)
Public therm(256)
Public src(16)
Units Batt_Volt=Volts
Units PTemp_C=Deg C
Units vibw=Hz
Units therm=Volts
'Define Data Tables
DataTable(Table1,True,-1)
DataInterval(0,10,Min,10)
Sample(245,vibw,IEEE4)
EndTable
DataTable(Table2,True,-1)
DataInterval(0,10,Min,10)
Sample(245,therm,IEEE4)
EndTable
'Main Program
BeginProg
Scan (10,Min,0,0)
Lcount =1
For i = 1 To 16
For j= 1 To 16
src(j)=0
Next j
src(i) = 1
SDMCD16AC (src(),1,0)
SubScan (400,msec,16)
PulsePort (4 ,10000)
Select Case Lcount
Case 1 to 176
VibratingWire (vibw(Lcount),1,mV7_5,1,Vx1,500,1200,150,-1,20000,250,0,1.0,0)
Case 177 to 221
VibratingWire (vibw(Lcount),1,mV7_5,1,Vx1,2000,3000,150,-1,20000,250,0,1.0,0)
Case 222 to 256
VibratingWire (vibw(Lcount),1,mV7_5,1,Vx1,450,1250,150,-1,20000,250,0,1.0,0)
EndSelect
ExciteV (Vx1,2500,0)
VoltSe (Therm(LCount),1,1,2,1,0,_50Hz,1.0,0)
Lcount= Lcount+1
CallTable(Table1)
CallTable(Table2)
NextSubScan
Delay (1,1000,mSec)
Next i
NextScan
EndProg
In your status table, are there any skipped system scans or skipped scans ? Any watchdog errors ? I'm interested in these items:
WatchdogErrors:
StartUpCode:
ProgErrors:
VarOutOfBound:
SkippedScan:
SkippedSystemScan:
MeasureOps:
MeasureTime:
ProcessTime:
MaxProcTime:
BuffDepth:
MaxBuffDepth:
SystemProcTime:
Could you send us the whole status table ?
(You can save it out as a text file from the Station
Status screen of LoggerNet, then copy and paste it
into this site).
If you are getting skipped scans or skipped system scans,(or unusual values for any of the above items),
you could try changing the step argument in your VibratingWire instruction from -1 to 150. Step values
above 180 can cause skipped system scans.
You have reported your output data like this:
12:50:00 0.659819 0.691927 0.765095 0.764756 0.751707
13:00:00 "NAN" 0.691925 0.765097 0.764752 0.751710
13:10:00 0.659819 0.659790 0.691927 0.765096 0.764747
13:20:00 0.659821 0.691927 0.765096 0.764751 0.751707
13:30:00 0.659819 0.691927 0.765098 0.764747 0.751704
13:40:00 0.659818 0.691927 0.765097 0.764753 0.751705
13:50:00 0.659819 0.691927 0.765097 0.764752 0.751705
This is not a standard representation of LoggerNet collected data within a .DAT file. Is it possible for you to collect
(perhaps using custom collect) into the TOA5 format and post the data as stored in that format ? (i.e. including all of the quotes and commas, etc.).
What process is it that is converting your data output from the standard representation to the format you have given here ? If that process is not LoggerNet, then perhaps that is what is not handling the NAN's properly and is modifying your data.
Are you using "Array Compatible CSV" for your output option in the Data files tab of the setup screen ?
Hello,
I'm not sure if this thread is too old - but I have begun to experience similar issues on one of my remote stations as mentioned in the thread above, and I am wondering if the final issue was ever discovered.
My program (for the single station, AVW200 command, I have eliminated the extra code to poll different stations) is below. The station consists of an AVW206 and an AM16/32B multiplexer.
Scan (60,Min,1000,0)
AVW200(Result201218,ComSDC7,-1,6,AVW201218(),1,1,5,1400,3500,1,_60HZ,1,0) For o=1 To 5 VW201218BUnits(o) = (AVW201218(o,1)^2)/1000 VW201218Temp(o)= (1 / (A + B * LN(AVW201218(o,6)) + C * LN(AVW201218(o,6))^3)) - 273.2 If VW201218Temp(o) < 0 Then VW201218Temp(o) = 5 VW201218PHead(o)= ((VW201218CalG(o)*(VW201218CalRo(o)-VW201218BUnits(o))+VW201218CalK(o)*(VW201218Temp(o)-VW201218CalTo(o)))+ VW201218CalEc(o))*6.8947 VW201218THead(o)= (VW201218PHead(o)/9.81/1.20)+VW201218CalTip(o) Next o
CallTable CoarseTailsPiezos
CallTable CoarseTailsBUnits
Next Scan
I am getting occasional (~once every few days) instances where it appears the raw data values are being "shifted" over by one piezometer in the raw output.
This wires at this station have been spliced repeatedly since installation (ongoing material deposition), and the station has been blown over more than once during strong windstorms, although all the equipment appears to be still functioning and sending data to the base station. The base station does not have skipped scans or watchdog errors (it is a CR800 polling an AVW206 through an RF401 radio).
The piezometers are rather old and are located in a corrosive environment (brine), and the SNR is variable - ranging from 1 to 500. However, it doesn't seem as noise is the issue - as all the raw data, including the noise measurements, are shifted in the corresponding data table. I will also note that multiple other stations are in the program and none of the others are shifting in a similar way - indicating that it is either something wrong with my code or something wrong with the AVW206 or wiring.
Thanks!