SDI-12 USB adapter manual and logging script updated

Due to the discontinuation of data.sparkfun.com, I moved data logging to ThingSpeak.com

I have other updates that I rolled up in the manual, such as more details on telemetry. New manual is posted on SDI-12 USB adapter page as well as the updated data logging code. Here is a snapshot of data I logged to ThingSpeak.com:

The full data stream is here:

https://thingspeak.com/channels/359964

SDI-12 + GPS USB adapter

After a final revision, I am happy to release the SDI-12 GPS USB adapter! This adapter is the latest one to add to the line of SDI-12 USB adapters. In August 2015, I released my first SDI-12 USB adapter with this post. It was an idea that I thought about while traveling. I was working on data logger designs that use SDI-12 sensors and felt that interacting with SDI-12 sensors is not easy for agricultural or water resource researchers. Having an adapter that connects a computer to an SDI-12 sensor and reads measurements directly from the sensor would be very useful. So I made the adapter to simplify lab tests and data logger deployments. Since then, I’ve written free Python scripts for basic data logging (read the SDI-12 USB adapter main page). The demand for the adapter since then has been high enough to support my continued update on the data logging script, expanding from PC/Mac/Linux to single-board computers such as Raspberry Pi and Beagle Bone Bone. I have also expanded the adapter with an SDI-12 + Analog USB adapter that includes four high-precision analog inputs.

Later I found some need to add GPS modules to the existing SDI-12 USB adapter so that mobile data loggers such as those mounted on tractors will be able to produce with Geo-tagged data that can be made into maps. After some initial struggle using the new ATMEGA328PB processor that sports two hardware serial ports (one to talk to PC and the other with GPS), I realized that the GPS module actually interfered with the processor and caused program freeze-up. Then I made some hardware revisions and was able to prevent interference. It turned out that the new ATMEGA328PB processor that I used in my initial prototype was especially susceptible to interference when I used its second hardware serial port that have the same pins as the SPI pins that program the processor. So I switched to the ATMEGA1284P processor that I have been using on my open source physics laboratory design.

After extensive tests, I am happy to add this adapter to the product line. You can purchase (small quantity at the moment) at inmojo.com or on my blog (in the middle of the page). The adapter requires a separate purchase of the GPS module that Adafruit makes and sells, the Ultimate GPS module part number 746. You only need to solder four pins on the GPS module, the TX, RX, GND, and VIN, and the same pins on the adapter. Since the GPS module is relatively expensive, I can’t stock them up. But if you really need it assembled, you may have a GPS unit sent to me and a few extra dollars for assembly and testing. Just contact me once you make a purchase if you want assembly.

Adding Beagle bone to the mix

I was recently contacted by someone who was interested in using the SDI-12 USB adapter on a Beagle Bone Black single board computer. I’ve never used a Beagle Boards but I know that they are ARM-based computers running linux thus should operate similarly to the Raspberry pi boards that I’ve been playing since 2012. So I took the dive and got a Beagle Bone Black from MCM electronics and gave it a try. Right out of the box the board boots into a version of Linux. I was able to test its connectivity with the SDI-12 USB adapter successfully using the “screen” command. Later I ran a simple Python script under Python 2.7 and got very nice results:

There are a few differences that I noticed while exploring BBB:

  1. There is a “serial” module included in Python that is not available on other platforms, such as windows, linux, Mac OS, or Raspberry pi. It functions like the pyserial module used on all these systems.
  2. The board boots much faster than raspberry pi 3B, maybe in 15 seconds. RPI 3B takes about 30 seconds. This is a good thing.
  3. There are a lot fewer instructions on basic operations for Beagle boards than Raspberry pi, which was the primary reason I got my raspberry pi B instead of Beagle board back in 2012.

When I have more time, I will test my open-source python data logger on BBB to make sure it works just as it does on all other systems. For now, one more box is checked: “compatible with Beagle Bone Black”.

 

Free assistance on data logger projects

Summer is finally coming to my backyard and my spring semester is coming to an end. Thinking ahead (skipping over all the final papers to grade), with the whole summer ahead of me, starting 5/15/17, I can provide some free assistance to those that are working on your data logger projects using my devices, such as the SDI-12 data logging shield and SDI-12 USB adapters.

My goal is to get you started so you can quickly work on your own after my help. I’ve used Teamviewer to remotely help people install software, test their adapters with their own sensors, and modified my Python data logging code in the past. As long as I have some time to spare, I am willing to keep providing help. I appreciate it if you could help me spread the word. I might ask you to provide a blurb such as what sensors you use and what type of project you are working on etc. as a form of exchange for my free help.

SDi-12 + GPS USB adapter test

I was able to perform some tests on the new SDI-12 + GPS USB adapter. I don’t have the GPS module but do have an arduino shield that features the same GolbalTol GPS module so I used some jumper wires to connect the GPS to the adapter. I did tests last night and overnight. Things are looking good. Here are some results:

Commands:

To get longitude and latitude, you will issue “zM!”. The return values are z(long)(lat)\r\n. The longitude and latitude are both in standard NMEA format of 100*(degree.minute). For instance, a longitude of -9412.3411 means -(94 degrees 12.3411 minutes).

To get day, month, and year, you will issue “zM1!”. The return value is again in standard NMEA format of +DDMMYY. For example, a date of +190317 means the 19th of March, 2017.

To get hour, minute, and second, you will issue “zM2!”. The return value is also in standard NMEA format of +hhmmss. For example, a time of +123507 means 12:35:07 in 24hr style so it is 12:35:07 PM for those that use 12hr style.

Sample commands (in red) and returns (in green):

Single-sensor measurement:

zM!
z0012
z
zD0!
z-09456.1234+4578.9012
zM1!
z0011
z
zD0!
z+190317
zM2!
z0011
z
zD0!
z+065402

Concurrent measurement:

zC!
z00102
zD0!
z-09456.1234+4578.9012
zC1!
z00101
zD0!
z+190317
zC2!
z00101
zD0!
z+065713

SDI-12 + GPS module

After some development, I am glad to show a prototype of an SDI-12 + GPS USB module. This module incorporates the following features:

  1. USB connection
  2. SDI-12 translator with 4 SDI-12 connections (on a single SDI-12 bus)
  3. Header for a GPS module
  4. External power connection for sensors that need more than 5V from USB
  5. External power/5V USB selection jumper
  6. You can also use other serial devices or sensors such as Maxbotix serial sonic ranger, with some modification to the firmware
  7. Both SDI-12 senors and GPS are addressed like SDI-12 sensors, for easy integration of GPS signal into your existing SDI-12 logging scripts

Here is a picture:

I ran out of GPS modules. New ones are on the way. Once I get them, I’ll solder one on an adapter and do a demo video.

Sensing temperature

Sensing temperature seems to be an easy enough task using Arduino etc. You take a thermistor that changes resistance with temperature, such as a 10K ohm thermistor, which has a nominal resistance of 10K ohm at 25DegC. You take a fixed-value resistor, say 10K ohm, and make a voltage divider with the thermistor. You use analog input to sense the voltage of the divider and calculate the resistance from the voltage, then temperature from resistance. You can call this fixed resistor a serial resistor since it is in series with the thermistor. The following diagram is a voltage divider. The R_known is the fixed-value resistor. The R_unknown is the thermistor. A 5V voltage is applied to the resistors and a “sense” pin is sensing the divider voltage.

voltage divider

Then why am I wasting time to reiterate this simple task? Consider, the fixed-value resistor is made of a carbon film. What does carbon do at different temperatures? It changes resistance! So the “fixed-value” resistor you have is no longer fixed in value, especially if you live in places with temperature extrema, like where I live. I can get below 30DegC and above 30DegC outdoors in winters and summers. When you consider temperature, you can easily span almost 60DegC temperature range from a 25DegC nominal room temperature, where the fixed resistance values are specified, to a -35DegC where your data logger is logging data. If your fixed-value resistor doesn’t come with a temperature coefficient, well, it should! You can assume maybe 200ppm/DegC. This means 200 parts per million change of resistance per degree C. With -35DegC at 60 DegC below nominal temperature, you are looking at:

200*60/1,000,000=0.012=1.2% resistance change

This change of resistance could result in several percent of temperature reading error. The exact relation requires some calculus maybe I can discuss if there is interest. So you can expect to have several DegC or more error.

Here is what I noticed by driving two cars:

They both exhibit this behavior: After I park the car outside for several hours in cold temperature, I start the car, the “outside temperature display” says it is something like 10 degF. After several minutes, the temperature starts to drop to lower values.

Car 1: there is a few DegF drop. Say it will say 10DegF at startup, then it will say 7DegF after a few minutes

Car 2: there is as much as 15 DegF drop. If is says 10DegF at startup, it may say -5DegF after a few minutes.

Car 2 is newer than Car 1 but both cars are newer cars.

So my thought, although not tested (that might require disassembling the car computer), is that, the newer car is using a lower-grade serial resistor with the temperature sensor (thermistor) than the older car. This serial resistor must be inside the cabin, on the car computer’s board. When it is cold, its value increases considerably to maybe a couple percent higher than the nominal value. This trend of increasing resistance with decreasing temperature is shared between carbon and semiconductor (thermistor). So the effect of thermistor increasing resistance with decreasing temperature is countered by the effect of carbon increasing resistance with decreasing temperature. Then once the engine warms up the cabin enough, the fixed resistor warms up and the temperature display changes.

So how do you counter this effect i.e. temperature coefficient of fixed resistor? You can buy better resistors with less temperature coefficient, such as 20ppm instead of 200ppm. You will drop that effect to 1/10, which will be able to provide you the right accuracy. But these resistors aren’t exactly cheap. For instance, the 10K resistor I used as serial resistor in one of my designs has 10ppm/DegC:

279-RN73CA-10K

This resistor is about a dollar each. It is not only low in temperature coefficient, but also high in precision, 0.1% (i.e. it is at most 0.1% off from 10K when measured at nominal temperature)

 

When I don’t need this precision, just need a ~10K pull-up resistor for reset pin, I use this one:

652-CRT0805FZ1002ELF

This resistor is only 20 cents but it’s not too bad. 1% precision and 50ppm/DegC. I suspect the car 2 has something like this or even a bit worse! A 5% precision 200ppm resistor is only 10 cents. What would I use if I needed to make lots of cars?!

Python code for multiple SDI-12 sensors

As you probably know, the SDI-12 sensor logger code in Python can only log one sensor at a time. It is not a hardware limitation. I wrote the logger code as an example of how to do logging with the SDI-12 adapters and Python. To make sure people don’t have the wrong ideas that you can ONLY get one sensor logged, I have been working on the logger code for the past couple of days and have increased the number of sensors from one to any number you need. The improvement is backward compatible with the configuration file for Raspberry Pi logging, in case you wonder. All that is changed to the user interface is the prompt:

Original prompt:

‘SDI-12 sensor address: (0-9, A-Z, a-z)’

New prompt:

‘Enter all SDI-12 sensor addresses, such as 1234:’

 

So if you have 4 sensors you want to log together, then just enter all their addresses in a string, such as 1234 and hit enter. All sensor inputs will be saved to log file and sent to sparkfun’s data server. The only limitation on the code now is the sparkfun data server stream. The server stream is set up to only take 6 values so the logger code will send the first 6 values from all sensors to the server. If you wish to lift this limitation, you should create your own stream and set up as many values per data point as you need, and modify the logger code (see the magic number 6?).

Below are some sample data logs:

2/3/2017  12:15:25 AM 1 1.11 26 z 5.09419 5.09381 0.24388 5.09419
2/3/2017  12:15:56 AM 1 1.11 26 z 5.09325 5.0925 0.24388 5.09306
2/3/2017  12:16:28 AM 1 1.11 26 z 5.09363 5.094 0.24375 5.09438
2/3/2017  12:17:02 AM 1 1.11 26 z 5.09194 5.09269 0.24375 5.09306

As you can see, the data are separated by sensor address. The address z is the analog-to-digital converter’s address for SDI-12 + Analog adapter. As you can see, my computer outputs 5.09V instead of the nominal 5V on its USB port.

Here is a link to the new logger code. Give it a try and let me know how you like it.

sdi_12_logger_v1_4_1.py

Read analog sensors on SDI-12 USB + Analog adapter

Reading analog sensors are easy. The adapter has SDI-12 address of ‘z’, lower case. So reading the analog sensor just involves querying the SDI-12 address ‘z’. There are two sensing modes: single-ended, and differential. If you have mixed single-ended and  differential channels, read single-ended, then differential. Discard channels you don’t need. It won’t hurt the sensors or the adapter if you wire them in differential mode but read in single-ended mode. The reverse is also true.

The sensing commands are ‘zM!’ for single-ended readings, and ‘zM1!’ for differential readings.

In both modes, you use ‘zD01!’ zee-Dee-zero-!, to get data. Essentially, the adapter itself is an SDI-12 sensor that reports 2 or 4 values, depending on sensing mode. This makes it very easy to integrate analog sensors into your existing data logger that is based on the original SDI-12 USB adapter. It is still advantageous to keep the original SDI-12 USB adapter so it can split SDI-12 sensors with the SDI-12 + Analog adapter. In case one SDI-12 sensor gets broken and interferes with the rest of the sensors on that adapter, the SDI-12 sensors on the other adapter will be unaffected.

To make this complete, the SDI-12 USB + Analog adapter also responds to the following commands:

Command:’z!’

Response: ‘z\r\n’ This means that the adapter is responding to queries.

Command: ‘z!’

Response: ‘z13Liudr   SDITRD130\r\n’ This indicates that the firmware is in version 1.3.0.

Command: ‘zM!’

Response: ‘z0014\r\nz\r\n’ This means that the adapter needs 1 second to acquire 4 single-ended auto-scale analog values. The second ‘z’ indicates it completed the acquisition.

Command: ‘zM1!’

Response: ‘z0012\r\nz\r\n’ This means that the adapter needs 1 second to acquire 2 differential auto-scale analog values. The second ‘z’ indicates it completed the acquisition.

C0mmand: ‘zD0!’

Response: ‘z+1.23456+2.34567+3.45678+4.56789\r\n’ or ‘z+1.23456+2.34567\r\n’ These are single-ended or differential channel readings, depending on whether M or M1 was issued before D0.

 

Update on the SDI-12 + Analog USB adapter

sdi-12-usb-analog

Here is an update:

In case you wonder what all those green screw terminal blocks are doing, here is a graphical explanation:

Both the SDI-12 USB and SDI-12 + Analog USB are explained in this illustration.

To maintain the same compact size, I printed all the pin information on the bottom of the board again. So if you don’t know what a certain pin on a block does, just flip it around and you’ll see it. The jumper information is all on top side.

The SDI-12 + Analog USB adapter comes with a jumper to select either internal 5V or external voltage at the Ext. Power screw terminal block. You may connect a small 9V battery to the Ext. Power screw terminal block. You can also connect your  12V battery that powers your logger to this pin. The external power is only sent to the SDI-12 sensors. It’s not powering the adapter or sent to the analog inputs’ “+” connections. Those “++ connections are always from the 5V USB power. There are 3 pins on the terminal block and the center pin is not connected to anything. It makes it easier to separate the + and – of the external power and I don’t have to source 2-pole blocks besides 3-pole blocks.

All four SDI-12 blocks have “+ S -“. The “+” is either USB 5V or external power depending on the power jumper. “S” is SDI-12 signal. “-” is ground. All grounds should be connected together. These four blocks are all connected. They are not four separate buses. There is no way to transparently bridge one USB serial port to more than one SDI-12 bus. If you wish separate SDI-12 bus for each sensor, which is unnecessary, get a separate adapter for a separate SDI-12 bus. This need for separate SDI-12 bus may come from some suspicion that if a single SDI-12 sensor breaks, it may take the whole bus down with it. I have not been so unfortunate and broken SDI-12 sensors I have had didn’t affect good ones. In any case, a broken sensor needs replacement. Unless you deploy redundant sensors one set on each SDI-12 bus, you are OK with a single adapter that bridges a single SDI-12 bus for all sensors.

The four analog channels are as accurate as 0.02mV when the signal is small, below 0.256V. The adapter automatically uses the best scale to determine the signal. The highest signal allowed is 6.144V on any channel. There are 6 ranges (gain levels), with maximal ranges of 6.144V, 4.096V, 2.048V, 1.024V, 0.512V and 0.256V. Within each range of voltage, the analog input is turned into a numerical value between 0 and 32767. So if you have a signal that is 0.1V, using the largest range of 6.144V will give an smallest change of 0.1875mV. This sounds very accurate, because this change is 0.1% of the signal. But the real resolution of the ADC is not the smallest change. It is usually many times that. Plus there is fluctuation in supply voltage and noise in the signal. The result is likely in the neighborhood of 2mV. This becomes 2% of the signal magnitude. But if you use the 0.256V range, its smallest change is 0.0078125mV. The accuracy is about 0.02mV to be conservative. Since SDI-12 standard has no way to change scale, the adapter does it automatically.

The auto scale is done with a 10%~90% range. The adapter starts with the largest scale to protect the converter and reads the signal. It then calculates the smallest scale that will fit the signal within 10%-90% of the scale. It reads at this scale and returns the value. Each channel is auto scaled independently from the other channels so you may have some larger signals automatically read at a larger scale and smaller signals automatically read at a smaller scale.

The meaning of single-ended channel is that each one of the four channels is read against the common ground. This is less accurate for small signals over long wires. If you have a pyronometer or some other small voltage signal sensor, you may want to use two channels in differential mode. In this mode, the “+” wire is connected to say channel 0, and the “-” wire is connected to channel 1. The difference between these two are read and the difference may either be positive or negative. Range of the difference between these wires can be +-6.144, … +-0.256Vetc.

(to be continued)

 

%d bloggers like this: