How to Prevent Skipped Scans and a Sunburn

by Jacob Davis | Updated: 06/17/2015 | Comments: 3

Search the Blog


Subscribe to the Blog

Get an email when a new article is posted. Choose the topics that interest you most.


Area / Application

Product Category

Activity

Corporate / News

Enter your email address:



Suggest an Article

Is there a topic you would like to learn more about? Let us know.

Leave this field empty

Through programming, relatively slow SDI-12 measurements can coexist, without problems, alongside fast measurements. To illustrate the need for accommodations in your data logger program, I will share the story of the worst sunburn I ever got.

Jacob Davis in Peru

Southern Peru is near the Pacific Ocean, yet is home to the driest place on Earth. In these deserts are some of the world's largest copper mines. Mines need water to operate, so it is critical to closely monitor the available water supply. Campbell Scientific equipment is used by mines for monitoring the water supply as well as to collect data for environmental compliance.

I made a trip to southern Peru to provide training and customer support for a mining customer. On my last day in the area, I went with the customer to a weather station on a peak in the Andes with an elevation above 10,000 ft. The view and the elevation were both breathtaking. The station on the peak, however, was skipping scans, which resulted in some missed measurements.

The weather station was running on a 1 second scan interval and had an SR50A snow level sensor connected to it. When all sensors were connected and things were running well, the data logger was able to complete all the measurements within the 1 second interval. The problem exhibited itself when the SR50A was removed during the summer. With the SR50A removed, the data logger spent extra time retrying communication to the missing sensor. This meant that the data logger took more than 1 second to complete all of its measurement tasks, and thus skipped scans.

There was nothing wrong with the hardware, and the problem could be resolved with a small change to the data logger program. I took out my laptop, sat down, and began modifying the data logger program right then and there.

This is where the sunburn happens. The sun was at my back. I was wearing a long-sleeved shirt and a full brim hat for protection. Earlier in the day I had applied some sunscreen. However, the sun is more intense when you are near the Equator. Also, at high elevation, sunlight travels through less atmosphere, and a greater portion of ultraviolet light makes it to the surface. Leaning forward to look at the laptop screen, the shadow of my hat moved up and left the base of my neck exposed to the sun. The back of my hands also had direct exposure to the sun.

With the program working perfectly, later that day, I headed to the airport. On the way, I began to feel the effects of the sunburn. The base of my neck and the back of my hands turned bright red. They were red like the primary color. My hands didn't burn as badly as my neck, as they were occasionally shaded by my body. The skin on my neck, however, blistered and peeled. After a couple of days spent applying lotion to the burn every couple of hours, I was able to sleep through the night again. My neck remained red for another week.

Accommodating SDI-12 and Fast Measurements Painlessly

To avoid the same sunburned fate as me, you can proactively write your programs in a way that won't skip scans. There are two ways to run SDI-12 sensors at a slower rate than your other measurements.

The simplest way to do this is by using the "C" SDI-12 command. The “C” command is the concurrent command and allows other measurements to occur while a data logger is awaiting the sensor's response. The CR1000 datalogger has a multitasking operating system that handles the SDI-12 communications as a task separate from your analog measurements. Not all sensors support the use of the “C” command. Refer to your sensor manual to see which SDI-12 commands are supported.

An example of using the “C” command:


'CR1000

'Declare Variables and Units
Public BattV
Public PTemp_C
Public AirTemp
Public SR50A(2)
Public TCDT
Public SnowDepth

Alias SR50A(1)=DT
Alias SR50A(2)=Q

Units BattV=Volts
Units PTemp_C=Deg C
Units AirTemp=Deg C

'Define Data Tables
DataTable(Hourly,True,-1)
	DataInterval(0,60,Min,10)
	Average(1,SnowDepth,FP2,False)
	Sample(1,AirTemp,FP2)
EndTable

DataTable(Daily,True,-1)
	DataInterval(0,1440,Min,10)
	Minimum(1,BattV,FP2,False,False)
EndTable

'Main Program
BeginProg
	'Main Scan
	Scan(1,Sec,1,0)
		'Default Datalogger Battery Voltage measurement 'BattV'
		Battery(BattV)
		'Default Wiring Panel Temperature measurement 'PTemp_C'
		PanelTemp(PTemp_C,_60Hz)
		'107 Temperature Probe measurement 'AirTemp'
		Therm107(AirTemp,1,1,1,0,_60Hz,1,0)
		'SR50A Sonic Ranging Sensor (SDI-12 Output) measurements 'DT', 'Q', 'TCDT', and 'SnowDepth'
		SDI12Recorder(SR50A(),7,"0","C1!",1,0)
		TCDT=DT*SQR((AirTemp+273.15)/273.15)
		SnowDepth=2.5-TCDT
		'Call Data Tables and Store Data
		CallTable Hourly
		CallTable Daily
	NextScan
EndProg

The other way to run SDI-12 measurements at a slower rate is by placing any SDI-12 measurement in a slow sequence. A scan in a slow sequence behaves like your main scan, except it pauses whenever the data logger is busy with the main scan. The SDI-12 measurement process takes several steps, and these steps would be broken up and scheduled to take place between main scans.

An example of SDI-12 measurements in a slow sequence:


'CR1000

'Declare Variables and Units
Public BattV
Public PTemp_C
Public AirTemp
Public SR50A(2)
Public TCDT
Public SnowDepth

Alias SR50A(1)=DT
Alias SR50A(2)=Q

Units BattV=Volts
Units PTemp_C=Deg C
Units AirTemp=Deg C

'Define Data Tables
DataTable(Hourly,True,-1)
	DataInterval(0,60,Min,10)
	Average(1,SnowDepth,FP2,False)
	Sample(1,AirTemp,FP2)
EndTable

DataTable(Daily,True,-1)
	DataInterval(0,1440,Min,10)
	Minimum(1,BattV,FP2,False,False)
EndTable

'Main Program
BeginProg
	'Main Scan
	Scan(1,Sec,1,0)
		'Default Datalogger Battery Voltage measurement 'BattV'
		Battery(BattV)
		'Default Wiring Panel Temperature measurement 'PTemp_C'
		PanelTemp(PTemp_C,_60Hz)
		'107 Temperature Probe measurement 'AirTemp'
		Therm107(AirTemp,1,1,1,0,_60Hz,1,0)

		'Call Data Tables and Store Data
		CallTable Hourly
		CallTable Daily
	NextScan
	SlowSequence
	Scan (5,Sec,3,0)
		'SR50A Sonic Ranging Sensor (SDI-12 Output) measurements 'DT', 'Q', 'TCDT', and 'SnowDepth'
		SDI12Recorder(SR50A(),7,"0","M1!",1,0)
		TCDT=DT*SQR((AirTemp+273.15)/273.15)
		SnowDepth=2.5-TCDT
	NextScan
EndProg

I invite you to review your existing programs for stations that use SDI-12 sensors. Consider if these programs need changes to account for potential delays caused by SDI-12 retries.

Recommended for You: For assistance configuring an SDI-12 sensor, watch our Transparent Mode video and our Watch or Sniffer Mode video.

Proactively make accommodations for SDI-12 in your program and don't get burned!

Jacob Davis in Peru with hard hat


Share This Article



About the Author

jacob davis Jacob Davis is the Director of Client Services and Support at Campbell Scientific, Inc. He works with the worldwide technical support teams. His specialties include serial communications and advanced data logger programming. Jacob has a master’s degree in hydrology and worked with large irrigation projects before coming to Campbell Scientific, Inc.

View all articles by this author.


Comments

JDavis | 09/01/2015 at 08:50 AM

Anything that makes the scan take more than the scheduled interval can cause skipped scans. The Status table has MeasureTime, ProcessTime, and MaxProcTime values that indicate how much time the scan actually takes. There is also a special InstructionTimes instruction that can be added to a program to narrow down what is using up time.

KH | 09/07/2015 at 05:05 PM

Hi Jacob,

Very good advice. Thank you. Can you explain what the C and R command differ each other? Do they require different time to get data from same SDI device? If yes, which one needs shorter second?

Best Regards

KH Hong 

JDavis | 09/08/2015 at 08:34 AM

In SDI-12, the R command is continuous mode. Sensors that support it will continually run, updating the measurement result internally. The R command just retrieves the result.

The C command is for concurrent mode. Concurrent mode allows multiple sensors on the same channel to be performing their measurement sequence at the same time. The CR800, CR1000, CR3000, and CR6 handle the C mode a special way. These dataloggers will send the C command to the sensor and retrieve the result on a following scan. The measurement might lag a scan behind the other measurements, but the datalogger won't be delayed. For more information about this behavior, refer to the help for SDI12Recorder in the CRBasic help.

Please log in or register to comment.