SDI-12 USB adapter upgraded

2018-07-02 15.25.47

After some more firmware development and testing, I am happy to announce that the upgraded SDI-12 USB adapter is now available. The above is the first batch of these adapters and one hi-res analog input add-on board.

The upgraded board features the following:

  1. 4 analog inputs. 12-pole terminal block that features 4 analog voltage inputs. These are 10-bit or 5mV resolution inputs without differential reading. There are there to provide basic voltage inputs for projects that don’t require hi-res analog voltage inputs.
  2. Pulse counters. Alternatively, these 4 inputs can be used as pulse counters. Say you have a rain gauge or flow meter that outputs pulses, these pins can count the pulses. You may need additional filtering (one capacitor and two resistors) if the pulses are noisy. Each time you read the pulse counts, you get the counts since you last read and the adapter will start counting from zero again. This way, if you collect data every minute, the counts will be counts/min. Because each data point is accompanied with date-time information, you can always calculate the count rate with your data set.
  3. Extension port. There is now an 8-pin extension port for add-on boards. The first extension board I have designed and tested is a hi-res analog voltage input board. This board features the same four 16-bit auto-scaling inputs and differential inputs as the SDI-12 + Analog USB adapter, with an added benefit of address jumper. You can add as many as 4 such extension boards to the new SDI-12 USB adapter, with each extension board taking a different address. That is up to 16 hi-res voltage inputs.
  4. Serial port. There is also a serial port connector with RX, TX, etc. This port helps you connect the adapter to an arduino or a micropython board that don’t have USB connections but have serial ports.

With the added features, comes added costs of parts, quality checking, and development times. So I am currently offering two-tier pricing:

  1. The board with everything included and tested at $55
  2. The board without the 12-pole terminal block or these pins tested at $45
  3. If you need the serial port, I can solder the header and configure it free of charge.
  4. The hi-res analog add-on board is $35 each. If you want the 4 additional SDI-12 port soldered on it, I can do it for $5 extra.

The full-featured board has the additional terminal block and needs to be tested with all the analog pins to make sure they are all properly connected (reflowed). In the photo, the bread board and 4 blue potentiometer is the test rig I use to test hi-res analog inputs for the SDI-12 + Analog USB adapter. You CAN solder on your own 12-pole terminal block and test the pins yourself too. You will have to do a lot of screw/unscrew of a potentiometer or resistors though. The firmware is the same so once you solder the connector on, you can use the features.

2018-07-02 14.05.33

Although the analog add-on + new adapter costs the same as the original SDI-12 Analog USB adapter, the stack of two boards does add to its height so the board needs more space. My intention is to add flexibility to the adapter so I can later add more features to the ecosystem without scraping the existing devices. I did a custom board for someone that wants magnetometer, accelerometer, and gyroscope with SDI-12 sensors:

2018-06-17 12.15.47.jpg

I glued the sensor board on top of the adapter board and wired them together via the extension header. This way I didn’t have to spend time designing a new board, which will likely cost more time and money. Also, designing a new extension board is easier than designing a whole new adapter with the sensors on it. I can do more custom sensor boards even if there is only market for a few.

The purchase links to the full-featured adapter and the hi-res add-on board have not been established yet. I’ll get them up and running on my blog and at inmojo soon.

New data logging script

multiple sensor and adapter deploymentThe SDI-12 USB adapter data logging script has been updated to version 1.6.0. Here are the new features:

  • New configuration file format. I went from a basic format that is essentially the key strokes of the interactive inputs to a more human-readable, expandable, and future-proof dictionary-type of format.
  • The serial port is remembered in the configuration file by a unique ID instead of device name such as COM3. This makes it impossible to open the wrong serial port. You can also copy your configuration files to a different OS type and expect it to still work.
  • The data file name now includes the configuration file’s name, such as Liudr.cfg_20180709.csv. This makes it possible to distinguish different data that are collected using different configurations.
  • You can specify a different configuration file name in command line instead of the default. This makes it possible to run multiple adapters on the same system, each running its own configuration file. You can also set up different data logging scenarios and store them in different configuration files for easy recall.
  • There are also stability updates that prevent the script from quitting if, say, the sensor fails to return any valid response. Instead, the logger waits until the next data point and try again.
  • The logging script can now use multiple sensing commands per sensor, such as M!, M1!, M2! etc. besides reading multiple sensors. The interactive input has changed a bit to accommodate the upgrade.
  • Now if you run the script for the first time, it takes you to the interactive inputs to collect configuration parameters to save them into a configuration file. Then when you run it the second time, it automatically loads the configuration file. If you wish to make minimal changes, you can just edit the configuration file. If you want to run the interactive inputs again, delete the configuration file and run the script again.

This version is still considered “experimental” while I hunt for potential problems. You can find the script under the download section along with “changes in V1.6.0” document:

Let me know what you think!

Open FTDI USB-serial UART port by ID

In this post, I will explain how to open serial port to your Arduino or SDI-12 USB adapter by its unique ID so you always open the correct port even when there are multiple such devices on your computer or raspberry pi.

For Arduino and SDI-12 USB adapter users, I have a nice trick to help you manage multiple Arduinos or SDI-12 USB adapters on the same computer or raspberry pi. On raspberry pi, as on a typical linux system, your device shows up as a serial port, such as /dev/ttyUSB0. This serial port designation is usually bound by the order that the device is discovered at boot time, which may not be the same even if you keep your adapter plugged into the same USB port. This means if you have more than one device on your raspberry pi, you may open the wrong port at times, which should be a big issue. To prevent your program from opening the wrong port, you need a unique ID for each device. Luckily FTDI chips already come with unique IDs. We just have to find those IDs and possibly change them into more meaningful things for us to remember. Assume for the moment you are making a data logger for your test fields. There is one field that can be called “NORTH”. The following steps will help you change the ID of the FTDI chip on your device so you can later open its port by that ID, instead of a port name. Here is a list of which devices are using FTDI’s chips that have the reprogrammable ID feature:

  • Liudr SDI-12 USB adapter (all types)
  • Sparkfun Redboard
  • Certain Arduino clone boards
  • Lots of other devices such as GPS etc.

Here is the FT_PROG tool FTDI provides. It’s windows only but I’m sure you can find a windows machine to run it. I’ve not tested it in a virtual machine whose host is linux or macos. I’ll do that when I have more time. If you are unsure whether your device has an FTDI chip, a quick scan using the program will tell you.

First, press the scan icon (magnifying glass). If you have a device with FTDI chip, it will show up. See the screen grab below:

So I have an FT232R chip with a chip serial number “A106DHE5”. I can open port with this serial number but I’d rather change it to “NORTH”. Click on the “SerialNumber” from the left side.

Uncheck the “auto generate serial no” so you can edit the serial number to “NORTH”. You have up to 16 characters to name the adapter. Once done, press flash icon (thunder bolt).

Now that you have programmed your chip, you can read the information back using “scan” again to verify that the ID has changed:

Now that you have this nice ID, let’s open port by this ID.

Here is a small complication. On linux, the chip ID is returned, such as “NORTH”. On window, the port ID is returned, such as “NORTHA“. The addition of the “A” indicates the port “A” on chip “NORTH”. This is because some FTDI chips have two serial ports. The port IDs will be “NORTHA” and “NORTHB“. Even for FTDI chips that have only one port, such as for our case, the “A” is still there. So I recommend comparing chip ID instead of port ID. If you only work on linux/rpi systems, this doesn’t seem to concern you. But if you wish to make your code platform independent, i.e. running on windows without an incident, you will only extract whichever ID you receive with the stored chip ID, up to the length of the stored chip ID. Note: in the platform-independent code, you can’t slice a port’s serial_number with your stored ID because some internal ports don’t have serial numbers thus returns empty that will throw an error when you try to slice an empty array.

The following is a snippet that works ONLY on linux/rpi systems:

import  # For listing available serial ports
import serial  # For serial communication

# List ports for user to select
a =
print('\nDetected the following serial ports:')
for w in a:
    print('Port:%s\tID#:=%s' % (w.device, w.serial_number))
    if (w.serial_number==my_ID): # Match ID with the correct port
        port_device=w.device # Store the device name to later open port with.
if len(port_device)!=0:
    print('\r\n%s is the correct port.' %(port_device))
    print("Port with ID: %s is not found!" %(my_ID))

The following is a snippet that works on ALL OS:

import  # For listing available serial ports
import serial  # For serial communication

# List ports for user to select
a =
print('\nDetected the following serial ports:')
for w in a:
    print('Port:%s\tID#:=%s' % (w.device, w.serial_number))
    if (w.serial_number.__str__()[:len(my_ID)]==my_ID): # Match ID with the correct port
        port_device=w.device # Store the device name to later open port with.
if len(port_device)!=0:
    print('\r\n%s is the correct port.' %(port_device))
    print("Port with ID: %s is not found!" %(my_ID))

Your choice, simplicity of code or cross-platform compatibility.

Here is the cross-platform code’s result on my windows machine:

Detected the following serial ports:
Port:COM23	ID#:=A817EQLGA
Port:COM3	ID#:=None

COM23 is the correct port.

As you can see, there is an added “A” at the end of the ID reported by windows, which the python code ignored to produce a match.

I’ve also attempted to do this using Processing 3.0. Unfortunately, the Serial.getProperties() function that should return similar information returns blank (possibly not implemented on windows and yet to be tested on linux). If you have tested Processing method with success, please reply below with your results. I’ll add your comment to the post.

Here is the code I used in Processing 3.0:

import processing.serial.*;
import java.util.Map;
void setup() {
  String[] ports = Serial.list();
  for (int i=0; i < ports.length; i++) {
    Map<String, String> props = Serial.getProperties(ports[i]);
    print(ports[i]+": ");


COM3: {}
COM23: {}

Closing note: even if you work on Windows that assigns unique COM port number to your arduino or adapters, the assignment relies entirely on the currently available port numbers. If you develop your project on one windows PC and deploy on another windows PC, you WILL get different COM port numbers. On a Mac, the ID is embedded on the port name such as /dev/ttl.usbserial-A103RU9T so you are better off. But, will you be willing to shell out the money to get a mac and have it sit somewhere to collect data just because of this feature? If you are a linux wiz, you can bind names with serial numbers using some scripts. That’s beyond the scope of our general discussion, which assumes minimal experience with linux administration.

Calibrate a magnetic sensor

I recently worked on a project that required a magnetic sensor (MPU-9250) be calibrated to get best accuracy. I had some basic understanding on how to calibrate a magnetic sensor, although I’ve not done calibration before. The calibration turned out to be a bit complicated and took a while to understand. I got some help, including method to get best calibration, from the author of the MPU9250 Arduino library, Kris Winer. I thought that if I shared my experience here, others that are planning to calibrate their magnetic sensors may find it useful.

First of all, what is calibration? In a general sense, calibrating a sensor makes the sensor provide the most accurate readings allowed by the sensor’s own precision. As an example, let’s assume for a moment that the earth’s magnetic field and any other stray magnetic fields are shielded and you have a uniform magnetic field generated artificially for the sole purpose of calibration. Let’s say that the field strength is 400 mG (milliGauss), equivalent to 40,000 nT (nanoTesla). Now if you align one axis of your magnetic sensor parallel to the direction of the field, it should read 400mG. If you then carefully rotate your sensor so that the axis is anti-parallel with your field, it will read -400mG. If you didn’t do a good job in either alignments, you will read less values, say 390mG, if you’re off by about 13 degrees, because only a portion of the field, which is a vector, is projected along your magnetic sensor’s axis.

In the diagram above, the thick blue arrows represent the constant magnetic field of 400mG pointing to the right. The thin arrows represent various orientations your sensor could take. If your sensor + axis is also pointing to the right, you get the full 400mG. If your sensor + axis points to the left, you get -400mG. If your sensor + axis makes an angle, it reads a projection of the field, which is less. You can figure out the angle:

The above was assuming that there IS a constant magnetic field and the sensor’s reading IS symmetric along its positive and negative axis, meaning with zero magnetic field, the sensor reads zero. When not calibrated, the sensor reading will NOT be zero under zero field. It could read say 10mG. As a result, you might get say 510mG and -490mG with the field on. You know what that means. There is an offset (bias) of 10mG that should be subtracted from your reading to get the correct reading of +-400mG.

The above was the basis for calibration to remove the offset (bias) on each axis. In order to get the maximal and minimal value, you need to write your code to store max/min out of a stream of live data while you rotate your sensor in space, trying to maximize or minimize the readout. Then repeat two more times for a 3-D magnetic sensor. Since you don’t have a magnetic shield, you are relying on the earth’s magnetic field as the constant field. The earth’s magnetic field is not horizontal, or pointing from north to south. In most areas, the field either has a vertical up component, or a down component. And in most cases the field points from south to north as the rotational north pole (AKA the north pole) is near the magnetic south pole, where field lines go in, not coming out. In my area for example, the earth magnetic field points primarily downwards, only slightly towards north, making an angle over 70 degrees with the horizontal. The magnetic field has very little component in the east direction. The relative strength between East, North, and Downward is about 1:64:195. The angle the magnetic field vector makes with the horizontal is called magnetic inclination, with downward being positive. This is approximately atan(195/64)=72 degrees. The angle the magnetic field vector’s horizontal component makes with the true north is called magnetic declination, with east being positive. This is approximately atan(1/64)=0.9 degrees. The properties of magnetic field varies greatly from place to place and also changes from time to time. To find out the magnetic field in your area, visit

The following is from my area:

The next calibration is for sensitivity. The sensor either returns an analog voltage or a digital value. How do we convert this return into actual magnetic field in mG? This means finding the relation between the sensor readout and actual physical values. Say the sensor is digital and returns values between 0 and 32767, which represents magnetic field between 0 and 49150mG. Then you can use the conversion vactor 49150/32767=1.5mG/LSB to convert your readout. Here LSB means one digit (least significant bit). For an analog sensor, you will need an x.xx mG/V.

All sensors provide this factor in their spec sheets so you can just use this factor to get the actual magnetic field. But since not all sensors were made identical, some sensors should use larger or smaller values than the spec’s factor. Some manufacturers test their sensors at factory and store a correction factor for each axis in the sensor for better accuracy. For example, the MPU-9250 sensor (the magnetic sensor is AK8963) has digital magnetic field sensor output. One of the sensors I got has the following factory trims:

X-Axis sensitivity 1.18

Y-Axis sensitivity 1.19

Z-Axis sensitivity 1.14

So instead of a straight 1.5mG/LSB, the x-axis has 1.5*1.18=1.77mG/LSB. We’ll multiply this factor to the x-axis readout to get x magnetic field in mG. Same for y and z axes.

And yet sometimes these adjustments are still not able to make all 3 axes read the “400mG” value. They are very close to be identical already so we can apply a small correction. We average the maximal readings from all three axes, then divide by the maximal reading of each individual axis to get three factors. If say the x-axis reads slightly higher maximum than y and z axes. Then the avg_max/x_max will be slightly less than 1. We apply this factor to the the final result:


For one of my sensors, this yields 1.5*1.180*0.975*x_readout=1.726*x_readout(mG)

If the sensor you’re using doesn’t have the factory trim, then you’re out of luck unless you have both a magnetic shield and a nice uniform magnetic field inside the shield so you can find out the trim.

The following are steps for the AK8963 magnetic sensor calibration I did, using Kris Winer’s MPU9250 Arduino library:

  1. Extract factory sensitivity factor by calling initAK8963().
  2. Call readMagData() to extract raw data repeatedly enough to get accurate max/min for all axes.
  3. Calculate bias in raw counts by (max+min)/2, such as (510+ (-490))/2=10
  4. Combine factory sensitivity factor and Kris’s scale factor described above.
  5. Keep these biases and factors in program.

As a testimony to the method that works, here are two graphs.

This graph has three separate plots from raw data that represent mx vs. my, mx vs. mz, and my vs. mz. I rotated my sensor as much as I could for a few minutes before I got bored and couldn’t think of any other ways of rotation. The fact that all three plots are near circular means that the sensor’s three axes have very similar sensitivities. I was simply rotating the sensor around, giving all three axes opportunities to read the whole magnetic field. This means when the x axis reads the whole field, y and z axes read nothing. Some trigonometry can show that the result is a series or circles making a disc. But the discs were not centered as I expected, because the z axis had a very large bias (this means the blue is mx vs. my). After my bias calibration, here is what I got:

Now all three plots are centered at zero pretty well visually, although I didn’t multiple the factory sensitivity or the final factor from Kris’s calculation. This shows that bias calibration is the most crucial. If your sensor doesn’t have stored factory sensitivity factors, getting it calibrated for bias alone will go a long way.

FYI, this is my sensor board inside an enclosure. I found it much easier to hold and rotate when it’s in a box. The cable became much less of an issue when I was rotating the box. The black square board is my SDI-12 USB adapter. The purple board is the sensor board. I customized the SDI-12 USB adapter by gluing the sensor board to it and connecting it to the I2C bus on the adapter.

Second update on the new SDI-12 USB adapter

I found sometime to assemble a batch of the new boards. I populated the 12-pole terminal block on top and a row of headers on this one board for firmware development. Since not everyone will need these new features, the 12-pole block and the header for extension board or UART serial port will be optional and you can specify with your order that you need them. Adding these components adds more cost due to parts cost, assembly, and testing time. You could solder these headers yourself if you have some basic soldering skills. The UART serial port header is soldered on the underside of the board with a right-angle header to avoid the extension board and keep wires tidy.

If you need to use these boards over UART serial port such as connecting them to an Arduino or MicroPython board, please let me know with your order. I will place a solder blob between two pins on the USB serial IC so that it is placed in RESET mode to not interfere with UART serial communication with your microcontroller off board.

Here is the high-precision analog input extension board:

I assembled two extension boards, stacked them on top of the adapter, and set them to address 0 and address 1. These extension boards with come with a stacking header soldered on and four M3 standoffs, washers, and nuts. This ensures the proper spacing between boards to prevent short circuiting. I also need to trimming 20 pins on the underside of the board so that the underside of one extension board won’t touch the top side of another extension board below it. If you want, you can buy a set of 4 3-pole terminal blocks and populate them on the extension board to connect to more SDI-12 sensors, although I don’t recommend more than about 8 SDI-12 sensors from any vendor on the same adapter and extension board. A basic test running the SDI-12 + Analog USB adapter firmware on this adapter and extension board was successful, which was how I tested the extension board’s assembling quality.

My next steps are:

Extension board:

  • Expend the firmware to talk to as many as 4 such extension boards for a total of 16 high-precision analog inputs
  • Test address-setting jumpers (don’t expect any issues)
  • Populate SDI-12 headers on one extension board and test it (don’t expect any issues)

With one extension board and its address set to 0, getting high-precision analog readings is the same as using the SDI-12 + Analog USB adapter, by sending zM! and zM1! (differential reading), then using zD0! to retrieve data. With more extension boards, reading the 4 channels on board with address 1 will be zM2! and zM3! (differential reading) then the same zD0! to retrieve data. Board address 2 will have zM4! and zM5!, while board address 3 will have zM6! and zM7!. Then zM8! is reserved for the on-board basic analog channel read, while zM9! retrieves number of pulses from these channels.

Main adapter:

  • Develop firmware to read analog channels on the adapter itself (for basic analog signals at around 5mV precision).
  • Develop firmware to read pulses from the analog channels on the adapter itself (for rain gauges, flow meters etc. that output pulses).

Then I’ll test everything with a test rig. Stay tuned!

Upgrades to the SDI-12 USB adapter

I have been working on some updates to the SDI-12 USB adapter so that it would add more features to a data logging system. So far, I’ve updated the PCB (left board) to include additional connectors. The top of the board will have 4 analog channels. This is not as accurate as the red SDI-12 + Analog USB adapter boards. The SDI-12 + Analog USB adapter has practical accuracy of 20 microvolts and has differential input channels. The 4 channels on the basic SDI-12 USB adapter have accuracy of about 5 millivolts. Also there is not a voltage reference so the measurement will be affected by the USB voltage, which is only nominally 5V. Nevertheless, if there are some sensors that output voltages in 0-5V range you want to log with moderate accuracy, such as a potentiometer, or a thermistor for approximate temperature calculation, you can use these channels. The breakout looks the same as the SDI-12 + Analog USB adapter. There are no serial resistors so you have to add yours if you want to convert resistance to voltage.

I will release a new firmware version on these newer boards. At the same time, I am considering adding digital counting features to these analog channels so if someone wants to count pulses such as flow meters or rain gauges, they can use these channels for such purpose. I plan to develop this part in the summer.

Another connector (bottom one on left board) I have added will connect the adapter to an analog extension board (right board), which sports the same 20 microvolt accuracy as the SDI-12 + Analog USB adapter, in case you want to add these channels say for pyronometers or other low voltage and high precision measurements after initially getting the basic adapter. You can stack up to 4 such analog extension boards. Each board has an address jumper (right board, white rectangle) for one of the four addresses the analog-to-digital converter supports. That gives you a total of 16 high-precision analog input channels. Each extension board also comes with a few additional connectors for SDI-12 sensors as an option. You can more easily wire up more SDI-12 sensors to the adapter. I don’t recommend wiring up more than 6-8 SDI-12 sensors to the same adapter. Some sensors come with strong pull-down resistors. When too many of them are wired to the same adapter, they may prevent some other sensors from correctly communicating on the bus.

The last connector (left board middle) I have added will help developers using MicroPython platforms easily connect to it via serial ports, since most MicroPython boards don’t have USB hosts. I will start shipping these newer SDI-12 USB adapter boards soon although new firmware that makes use of these features will have to wait until later.

Will this affect your existing projects? Very unlikely. The new adapter has all the features of the old adapter. The SDI-12 + Analog adapter will still be around since it is a nice compact form factor. The new SDI-12 adapter plus the analog extension board will be approximately the same price as as the SDI-12 + Analog adapter.

More SDI-12 sensors tested with the adapters

As more researchers and developers are using my SDI-12 USB adapters, more sensors have been tested to run with the adapter. Here are some of the new additions recently:

Gill Instruments:

  • WindSonic Ultrasonic Wind Sensor (Thanks MG!)


  • HydraSCOUT multi-sensor soil moisture and temperature probe (Thanks Bertrand!)


  • Accubar SDI-12 Barometric Pressure Sensor, Model 5600-0120-3 (Thanks Meidad!)


  • Starflow QSD Ultrasonic Doppler Velocity And Depth sensor (Thanks Yiren!)

Since Decagon has merged with a German company UMS into METER Group, some of their product lines are renamed and other products are added to these new lines. Here is a list of tested sensors from them:

METER group (formally Decagon and UMS):

  • Atmos 22 (DS-2) (Sonic Anemometer)
  • Atmos 14 (VP-4) (temperature, vapor pressure, relative humidity sensor)
  • Atmos 41 weather station (solar radiation, precipitation, vapor pressure, relative humidity, air temperature, barometric pressor, horizontal wind speed, wind gust, wind direction, compass heading, tilt, lightning strike count, lightning average distance) (Thanks CD!)
  • PRI (spectral reflectance sensor)
  • NDVI SRS (spectral reflectance sensor)
  • GS3 (Ruggedized Soil Moisture, Temperature, and Electrical Conductivity Sensor)
  • TEROS 21 (MPS-6) (Calibrated Water Potential Sensor)
  • ECH2O 5TE (5TE) (Volumetric Water Content, Electrical Conductivity, and Temperature)
  • ECH2O 5TM (5TM) (Soil Moisture and Temperature Sensor)

If you are using the SDI-12 USB adapters, I’d love to include your SDI-12 sensors on my list of tested sensors. Leave me a message.

Careful with Python indentation

If you are like me, using the default Python integrated development environment, IDLE, you probably feel like me, desiring more features, such as line numbers, horizontal scrolling, code folding, etc. I am aware of a Python module called IDLEX, which has lots of these features. On the other hand, if you are already familiar with text editors such as Notepad ++ (Npp in short), which is excellent, you may want to just switch over to Npp for your Python script editing. You can either use their default color theme or edit it to look like IDLE. There is an essential feature you need to set in order to produce correct indentation though.

Because unlike other major programming languages such as C/C++, Java, etc. Python uses indentation to indicate structure. If you write an if-statement, you do this:

if (statement==True):
    print('It is true!')
    print('It is not true!')

I’ve learned a lesson of mixing tab characters and white spaces as indentation. It’s a bad mix. Although I love the tab character more than spaces, I consider spaces better in Python since it is the Python standard. Here is some tab vs. space discussion. They each have advantages. So how do we set up Npp to produce the Python standard 4-spaces whenever we press the TAB key on the keyboard? Here it is:

This “Preferences” dialog is under “Settings” menu. Just make sure you select “Language” on the left and then “Python” on the right (not the middle), deselect “use default value”, and select “Replace by space”. This produces Python 4-space indentations. Once you’re done, you may want to inspect your exist script to see if there are any tabs by selecting option “Show all characters” under “View” menu’s “Show Symbol” option. This way tab characters look like red arrows while white spaces look as red dots.

Now you are using Npp for editing, you can create a “Run” command inside Npp to run your Python code:

Under “Run” menu “Run…” option, you can type up the command python -i “$(FULL_CURRENT_PATH)”

Save a short cut such as Shift + F5. Then you can run the code with the shortcut.

Interesting indoor temperature data

As a demonstration for my SDI-12 USB adapter, I have a raspberry pi zero-w log temperature from a Decagon (METER group) 5TM soil temperature probe using the adapter. The probe is not buried in soil so it is just sensing the indoor temperature. The sensor is located away from direct sun light, just in case you wonder. Here are two snapshots of the data stream:



Except for the daily dip-and-rise combinations (why?), the temperature of my home is rather constant near 21.5 Degree Celsius. That is good to know that there is no issue with my thermostat in stabilizing temperature. So why the daily dip-and-rise combinations? The top graph was from Sunday. Notice two dip-and-rise combinations on the plot instead of one? The lowest points occurred around 2:30pm and 8:30pm but that’s not important. What’s important are when the dips started, around 1pm and 7pm. Those were the times we were cooking! The extra heat from the kitchen must have triggered the thermostat to turn off the heater, which made the room temperature drop before it kicked back in and heated the room back up. Without the heater on, the room drops steadily by 0.3 degC per hour. When heat is turned back on, the heater raises temperature at 0.5 degC per hour. You can also see that we were cooking dinner every night. Who would have thought that by posting room temperature online they are giving up a lot of privacy? 🙂

Data logging with Wipy and SDI-12 dongle

If you have heard of the Python programming language and its easy-to-learn and easy-to-use fyou’ll be pleasantly surprised that someone has successfully implemented Python on microcontrollers a few years ago, appropriately named MicroPython! He has developed his own MicroPython board and ported the code to a number of similar microcontrollers. Imagine a low-power microcontroller with “lots” of memory (compared with Arduino) happily running Python code that talks to the internet etc. I’ll start writing about MicroPython and how you may use it for DIY electronics and data logging in a number of posts but this post is an announcement related to MicroPython and the SDI-12 serial dongle:

This dongle has a similar set of features as the SDI-12 USB adapters but lacks the USB connectivity, just having serial connection to arduino. Since all MicroPython compatible boards have serial ports and library to run the port, you can connect a MicroPython compatible board to one of these dongles and run almost the same Python data logging code I provide to SDI-12 USB adapters. Here is the first successful attempt that made it happen. Jason is a developer on the Wipy platform, which is a microcontroller supporting MicroPython. He is developing a data logger. In order to talk to SDI-12 sensors, he got one of my SDI-12 dongles. The Wipy board has serial ports but at 3.3V logic. The dongle has 5V logic. I built a simple voltage divider on the dongle for him and he was able to communicate with it using the Wipy board. Here is the code that he wishes to share:

This script runs on Wipy (or similar MicroPython platforms) and logs data from SDI-12 sensors to the on-board SD card. Here is what a Wipy board V 3.0 looks:

%d bloggers like this: