Telemetry with DAQFactory

Recommended Posts

A new white paper has just been posted describing a system created by Stevens Water for the US Army Corps of Engineers to monitor the Lower Fox river in Wisconsin. This project, and many of Stevens Water's projects include wireless telemetry. They've used DAQFactory's user protocol features to script up protocols for communicating with their various telemetry devices, which can include radios, cell modems, direct ethernet or serial. At the other end is their DOT logger, an ASCII terminal device. Some times they use a combination, such as a cell modem connecting to a radio base station, going wireless to the DOT logger.

Fortunately, they've designed some good protocol script to make this easy to do, and easy to carry into the next project. The protocol includes functions to call the cell modem, connect the radio and communicate with the DOT logger. They can pick any combination as needed. Since the script is generic enough, they are able to reuse the script in all their projects.

And now the guru pointer: if you are creating a single application and need to communicate with a serial device with a unique protocol, it is usually easier to create a serial / Ethernet device with the NULL protocol and then create your protocol script in a sequence. This makes it easier to debug and gives you a little more control. Even non-polling protocols can be done this way instead of using OnReceive. Just create a loop that reads until the end of the line:

private string datain
while (1)
	  // read until LF
	  datain = device.mydevice.readuntil(10)
	  // parse the data:
	  // for this example, lets assume its Data:43
	  datain = parse(datain,1,":")
	  // set time of data
	  datain.time = systime()
	  // add to a channel
	  delay(0.1) // just in case

The above script will read from a device that streams data out without polling, parse it and put it into the mychannel channel. It assumes that mydevice is a serial/ethernet device you created. The readuntil() function will pause until a LF (ASCII 10) is received, or the timeout has expired. If the timeout expires, an error is thrown, which is caught by the catch() and it repeat. Otherwise, it parses the data. Notice how I use the parse() function to separate the Data: from the 43.

Of course the whole story above Stevens was how useful user protocols can be, and they definitely are. User protocols should be used whenever you think you are going to use a protocol in more than one document, or on more than one port at one time. But they do require a little more work, mostly in planning to ensure that they can be used in multiple ports or documents. However, if you do end up using them on multiple projects like Stevens did, its a huge time saver. In many cases you can move script in sequences to a user protocol, so I usually recommend starting with sequences and then moving to user protocols as the need, and your experience grows.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.