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.

Open source data logger videos

Open source data logger videos:

Quick demo:

Features introduction 1,2,3

Assembling the logger

 

Open source data logger

I have been designing data logger for a number of years. This is my answer to lots of data logging needs. An Arduino Nano-based open source data logger:

ospl-th-on

The logger provides the following features (in green) including features of Arduino Nano (in black):

Microcontroller Atmel ATMEGA328P
Power 5 V via USB or 2X AA battery (internally)
Digital I/O 10 (4 PWM output, other Arduino pins used internally)
Analog Input 4 10-bit ADC (8 on ATMEGA328P, only 4 brought out)
DC Current per I/O Pin 40 mA max
Flash Memory 32 KB of which 2 KB used by bootloader
SRAM 2 KB
EEPROM 1 KB on ATMEGA328P, 32 KB on real-time clock breakout board
Clock Speed 16 MHz
MicroSD card 32 GB maximum
Real-time clock Temperature compensated (DS3231)
ADS1115 4-chn 16-bit differential ADC with up to 16X programmable gain
LCD 16 column by 2 row character LCD with back light on/off control
Input Rotary encoder with switch (when shaft is pressed)

Table. Specification of Arduino Nano and the rest of the modules.

Another photo:

red-version-assembled-lcd-removed

As you can see, the logger incorporates a number of breakout boards instead of including these ICs on a single circuit board. More to come…

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

%d bloggers like this: