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.

http://www.ftdichip.com/Support/Utilities.htm#FT_PROG

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 serial.tools.list_ports  # For listing available serial ports
import serial  # For serial communication

my_ID='A817EQLG'
port_device=''
# List ports for user to select
a = serial.tools.list_ports.comports()
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))
else:
    print("Port with ID: %s is not found!" %(my_ID))

The following is a snippet that works on ALL OS:

import serial.tools.list_ports  # For listing available serial ports
import serial  # For serial communication

my_ID='A817EQLG'
port_device=''
# List ports for user to select
a = serial.tools.list_ports.comports()
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))
else:
    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]+": ");
    println(props);
  }
}

Results:

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 noaa.gov:

https://www.ngdc.noaa.gov/geomag-web/#igrfwmm

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:

x_field=(1.5mG/LSB)*(x_sensitivity)*(avg_max/x_max)*x_readout

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.

SDI-12 USB adapter and manual updates

If you have been looking at the SDI-12 USB adapters lately, you may have noticed that the manual got updated a bunch of times between February and March (latest version being 3/19/2018). I’ve been updating the manual to:

1. Introduce the newer SDI-12 USB adapter (black) that replaced the original adapter (green).

Original SDI-12 USB adapter since 2015:

slide2

Updated SDI-12 USB adapter:

SDI-12 USB + adapter

Notice that now the updated adapter is the same size as the other flavors of the adapters, such as the SDI-12 + Analog adapter and the SDI-12 + GPS adapter. These are the features the updated adapter has:

  • Four SDI-12 sensor connectors
  • External power connection and sensor power selector (5V USB or external)

2. I updated several sections of the manual to make the manual easier to understand.

  • Bookmarks in the .PDF file
  • More detailed description of the updated adapter
  • Details of how to configure an SDI-12 adapter
  • Other places have been tidied up as well

By the way, did I mention that I reduced all my adapters by $5 to $10?

  • SDI-12 USB adapter (updated) $45 ($5 cheaper)
  • SDI-12 + GPS USB adapter $60 ($10 cheaper)
  • SDI-12 + Analog USB adapter $80 ($10 cheaper)
  • There will be discounts for bulk purchases, such as 10, 20, 50 etc. Please contact me if you intend to buy more adapters so I can send you an accurate quote of prices with discounts and shipping cost.
  • If you still need the green adapter for its simplicity or form factor, you can contact me to do bulk orders, 10 adapters or more.
  • If you need something else to be on your adapter to connect to a particular sensor, contact me to see how I can help you achieve that. The sensor would definitely not be SDI-12 but I’ll make it so that reading from it is just like reading from any other SDI-12 sensor so your program needs little to no change.

Since I am assembling and testing these adapters myself and use trustworthy US parts vendors, I will have to get more efficient in my work to make up the difference. I made some improvements on a reflow oven that I will be using for new batches of adapters. I hope the effort pays off. I would be able to assemble a batch, load into the reflow oven, and assemble the next batch or do cleanup or soldering thru-hole components such as the screw terminal blocks while the oven reflows automatically. I’ve been using a manual control (Variac transformer) for reflow for the past several years, which requires constant attention.

One negative impact from the US postal service, since the end of January 2018, USPS will no longer ship merchandise via international first-class letter. The only alternative is first-class package, which is a much more expensive service. A package containing one adapter that used to cost less than $4 will now cost $9 to ship to Canada (come on!) or $14 to most of the rest of the world. I felt that I’m being squeezed out of the international market by the postal service. The only upside is that now the package seems to come with complete tracking in both countries. I made a small change to the first-item shipping cost and additional item shipping cost.

I am also considering designing a complete low-cost data-logging system so it would be more integrated than the adapters. The adapters have proved to be very successful indeed. It shows up as number-1 search for keywords “SDI-12 adapter” or “SDI-12 USB adapter”. I didn’t pay google anything for the free advertisement. Everyone that searched and read my blog helped spread the word! Thank you!

I plan to keep improving the adapters so that anyone that is integrating SDI-12 sensors will find it easy to just get an adapter and add SDI-12 sensors. For anyone else that is interested in low-cost data logging solutions but are more interested in a turn-key solution instead of investing time and effort in learning python programming or raspberry pi, this logger will make things easy for you!

Any comments, suggestions, your use case, including what sensors and telemetry solutions you want that you would like to share? Leave a comment! The design of the data logger is still very fluid so that your opinions WILL influence its development!

The development of a turn-key solution WILL positively affect the adapter development as well. I expect to have a 3-prone approach ultimately: USB adapters to add SDI-12 sensors to existing logger projects that use computers/raspberry pi, serial dongles/shields to do the same for Arduino-based existing logger projects, and a complete logger for those seeking turn-key solutions.

Have a nice spring/fall day!

JLCPCB – A new PCB fabrication house

I was recently approached by a new PCB fabrication house JLCPCB (technically they’ve been in business for some time but just started advertising to USA customers) to write some reviews on their service. Given my experience designing PCB and using PCB fabrication services (batchpcb, seeedstudio, iteadstudio, oshpark etc.) over the past decade, writing a review shouldn’t be too hard. If they are any good, I could use their service myself and recommend them to others in the hobby electronics community. So I sent them two of my designs and got them back relatively fast, with DHL. Since I still have some older versions of one of the boards, I could make a comparison with the two fabrication services. JLCPCB has offered their service free of charge for the exchange of a fair review. So I decide to not mention which competition I pitched JLCPCB against. What I primarily looked at was how accurately each layer of board is printed and how well they are aligned with one another from each fab service. JLCPCB‘s results are very good. Its competition, a long-standing name among DIYers, doesn’t look quite as good.

In case you’re still learning how to design PCBs, especially surface-mount components, here are some terms I’m going to use:

Top layer: this logic layer contains all copper traces, pads, and vias on the top side of the two-sided circuit board. A process is used to protect all aforementioned features specified in this layer when the entire board is etched in acid. If the process isn’t accurate, then your features aren’t exactly where they are supposed to be.

Top solder paste: this logic layer contains only pads for surface-mount components. It is a subset of top layer and is used to generate stencils for reflow soldering. Again if the fabrication isn’t very good, these features tend to not align with other features.

Top solder resist: this logic layer contains similar information to the pads and vias contained in top layer but the sizes of the features in this layer are slightly enlarged to a peel-back amount so they don’t accidentally apply solder resist on top of your pads where solder should go. Solder resist is a lacquer that prevents solder from adhering to the copper traces. They also protect the bare copper from rusting away. You will want them to be applied to all your traces and only leave the pads exposed so later process will cover them with a very thin layer of solder (the shiny looking stuff) and you then reflow solder your components to these pads. If the registration of this layer of lacquer is not well registered with the top layer, you will see visually under a magnifier. This is why fabrication houses usually do quite a bit of peel-back so they leave room for themselves to be less-aligned but still the lacquer won’t cover up the pads.

The following images are from an FTDI chip (FT232RL). The pitch was the finest on my board so I selected these pads for comparison of how well the different layers register with one another on these two service providers.

Top: JLCPCB Bottom: competition


They look similar. I’ve unfortunately scratched the pads on the competition’s board. I applied solder paste to that board and later cleaned the paste off so I could photograph its pads. My bad.
On a closer look there is a difference:

SMD pads (SSOP 0.65mm pitch):

Top: JLCPCB Bottom: competition
You can see that JLCPCB‘s boards (top) have SMD pads (shiny metal pads) that are very symmetrically situated inside the solder-resist masks (slightly larger dark rectangle). The solder resist also goes closer to the board than its competition. These are manufactured from the same designs! The engineers at the competition must have increased the peel-off (sizes of feature not covered by solder resists) to offset their less-perfect layer registrations and/or accuracy on each layer. As you can see, not all pads and their solder resist have the same offset. Some look better than others. This is clear with the second to the last pad and the last pad. The pads are not centered at all. This is very consistent across the board made by competition. JLCPCB has better overall registration than competition. Better registration translates into better chance to prevent solder bridges and less chances to reworking on your boards after you reflow them, that means time and money saved.

Thru-hole pads (o.1″ spacing):

Top: JLCPCB Bottom: competition

The top one has less size solder resist layer, the edges of the red lacquer surrounding the shiny pads (almost same size as the thru-hole pads) and very symmetrical. The competition has again increased the solder resist layer and couldn’t keep the layer registered well with the pad.

The via to the right of the bottom right through hole pin hole will be compared next. On JLCPCB‘s board, its solder resist has 2.8mm diameter when displayed on my computer monitor. On the competition board, it is 3.1mm. The images were taken under a high-magnification lens and I checked the images to be exactly the same zoom, measuring the same across the same features on screen. What this means is that if you have a lot of vias in one area, very close to one another, you may get some solder bridges between the vias if there is not enough solder resist to separate them. Not a problem on this board but a problem if you happen to have vias very close and also close to thru-hole components. You solder the thru-hole and inevitably fill the adjacent vias with some solder. This could short vias.

Overlay (white texts):

The quality of the white overlay texts are about the same between the two fabricators, although at some places you see one board having better quality than the other board while at different places the quality is reversed. This is not a crucial feature to look at though.

JLCPCB: top, Competition: bottom

With the explanation above, you can easily distinguish these two photos. The bottom one has so much space between the edges of the shiny pads and the red lacquer (less qualty). The top one has so much less and so symmetric.

So the results are clear. JLCPCB is a pretty decent PCB fab house and I will order my next batch from them. The shipping cost is also slightly less than competition if you use DHL. I always use DHL. They do a good job delivering to small cities like the one I live in!

Here is a link to JLCPCB’s website:

www.jlcpcb.com

I am not getting any commissions for your purchases. The link has no “trackers” 🙂

P.S.: I had a research student hand solder this board (yes, every single chip resistor and the FTDI chip) as a good test of his skills and it turned out fine. This is a proof that having the right size solder resist helps, really. This is what the board looks like after assembly:

Augmented reality sandbox control box updated

This slideshow requires JavaScript.

I constructed a couple of these control boxes for my ARsandbox project using Arduino Micro and Adafruit Feather 32u4. The main goal is to make the interaction between a user and the software more intuitive. The two flashing buttons add and remove water from the simulation, which is pretty nice. I wanted to add another feature, to move the elevation up and down. Say you have a lot of sand in the box but you want to display some “water”. You have to remove a lot of sand (time consuming) from the box or edit a config file (near impossible for an average user). On the other hand, if I can change the base plane location in the calculation, I can achieve the above goal without removing sand or editing files. With help of the original developer Dr. Oliver Kreylos, I started messing with the source code. It took me a day to understand what I could do to change the base plane and how to do it. I ended up creating a tool to manipulate the plane. Now that the plane can be moved, I added a rotary encoder to the control box to emulate the keyboard keys assigned to move the plane. Voila!

The photo gallery above shows 5 shots of different elevation values. You can clearly see the “sea” on bottom right is shrinking after each turn of the knob.

Here is a short video. I was slowly raising the elevation so more and more land became above water. Then I quickly returned the land back into water:

Here is a photo of the inside of the box:

I added a breakout board for rotary encoder and buttons. It’s very tightly sandwiched between the two buttons. There is no space between the board and the buttons, not even a fraction of millimeter. I don’t know how these pieces just managed to fit. Here is the breakout board:

I made this a while ago as an interface for my phi-panels LCD backpacks. This breakout board is pretty simple. There are two encoder channels and one shaft button, plus six push buttons, which I am not using. I just connected to the encoder channels, shaft button, and the common. I had to cut off a strip on the right side of the board to fit into the box. I was using my phi_interfaces library to read the encoder and emulate a button push if the encoder is rotated one way, another button if the encoder is rotated the other way. I didn’t assign any function for the shaft button. I am thinking that I should use it to switch between elevation adjustment and water speed adjustment.

I haven’t updated the Adafruit Feature 32u4 version but will probably design a new printed circuit board so assembling will be easier, and not involving cutting off part of a board. Some code in case anyone wants to replicate it.


/*
 * Credit: Dr. John Liu
 * Purpose: This sketch emulates keyboard keys "1" and "2" with two push buttons with LEDs. It also flashes the LEDs
 * If a rotary encoder is present, it will emulate '5' and '6' if you rotate the encoder's shaft. This combined with my modification on ARsandbox source code will shift color mapping up and down.
 * This version uses p-channel mosfets and open drain with 10Kohm pull-up to 5V to control LEDs with the 3.3V Adafruit Feather32u4.
 * Notes: On Adafruit Feather 32u4, pin 9 is connected to battery sensing voltage divider.
 * 2018-01-28
 * Visit https://liudr.wordpress.com for more information
 */
#include "Keyboard.h"
#include <phi_interfaces.h>
#define USING_MICRO
#ifdef USING_MICRO
const int button_1=2; // 11 for Adafruit feather 32u4, 2 for Arduino Micro;
const int button_2=3; // 10 for Adafruit feather 32u4, 3 for Arduino Micro
const int EncoderChnA=7;
const int ChnCommon=8;
const int EncoderChnB=9;
const int ShaftBtn=10;
const int EncoderDetent=18;
#endif

#ifdef USING_FEATHER
const int button_1=11; // 11 for Adafruit feather 32u4, 2 for Arduino Micro;
const int button_2=10; // 10 for Adafruit feather 32u4, 3 for Arduino Micro
#endif

const int led_1=6;
const int led_2=5;
const unsigned long led_on_ms=300;
const unsigned long led_off_ms=1700;
const unsigned int button_1_key='1'; //KEY_LEFT_ARROW;
const unsigned int button_2_key='2'; //KEY_RIGHT_ARROW;
const unsigned int UpKeyOut='5';
const unsigned int DownKeyOut='6';

int prev_1=HIGH;
int prev_2=HIGH;
int led_stat=LOW;

unsigned long prev_1_ms=0;
unsigned long prev_2_ms=0;
unsigned long blink_timer_0_ms=0;
unsigned long blink_timer_1_ms=0;

int debounce_ms=25;

char mapping[]={'U','D'}; // This is a rotary encoder so it returns U for up and D for down on the dial.
phi_rotary_encoders MyEncoder(mapping, EncoderChnA, EncoderChnB, EncoderDetent);
//multiple_button_input* dial1=&my_encoder1;

void setup()
{
  // make pin 2 an input and turn on the
  // pullup resistor so it goes high unless
  // connected to ground:
  pinMode(button_1, INPUT_PULLUP);
  pinMode(button_2, INPUT_PULLUP);
  pinMode(led_1,OUTPUT);
  pinMode(led_2,OUTPUT);
  pinMode(ChnCommon,OUTPUT);
  digitalWrite(led_1,LOW);
  digitalWrite(led_2,LOW);
  digitalWrite(ChnCommon,LOW); // Using this pin as ground since some prototypes don't have enough gnd pins.
  Keyboard.begin();
  blink_timer_0_ms=millis();
}

void loop()
{
  unsigned char ch=MyEncoder.getKey(); // Rotary encoder emulates two buttons.
  if (ch==mapping[0])
  {
    Keyboard.write(UpKeyOut);
  }
  else if (ch==mapping[1])
  {
    Keyboard.write(DownKeyOut);
  }

  switch (led_stat)
  {
    case LOW:
    if (millis()-blink_timer_0_ms>led_on_ms)
    {
      blink_timer_0_ms=millis();
      led_stat=HIGH;
      pinMode(led_1,INPUT); // Open drain to let pull-up resistor pull drain to 5V.
      pinMode(led_2,INPUT); // Open drain to let pull-up resistor pull drain to 5V.
    }
    break;

    case HIGH:
    if (millis()-blink_timer_0_ms>led_off_ms)
    {
      blink_timer_0_ms=millis();
      led_stat=LOW;
      pinMode(led_1,OUTPUT); // Pull drain to GND.
      pinMode(led_2,OUTPUT); // Pull drain to GND
    }
    break;
  }

  if ((digitalRead(button_1) == HIGH)&&(prev_1==LOW))
  {
    if (millis()-prev_1_ms>debounce_ms)
    {
      prev_1_ms=millis();
      Keyboard.release(button_1_key);
      //Serial.println("1 released");
    }
    prev_1=HIGH;
  }

  if ((digitalRead(button_1) == LOW)&&(prev_1==HIGH))
  {
    if (millis()-prev_1_ms>debounce_ms)
    {
      prev_1_ms=millis();
      Keyboard.press(button_1_key);
      //Serial.println("1 pressed");
    }
    prev_1=LOW;
  }

  if ((digitalRead(button_2) == HIGH)&&(prev_2==LOW))
  {
    if (millis()-prev_2_ms>debounce_ms)
    {
      prev_2_ms=millis();
      Keyboard.release(button_2_key);
      //Serial.println("2 released");
    }
    prev_2=HIGH;
  }

  if ((digitalRead(button_2) == LOW)&&(prev_2==HIGH))
  {
    if (millis()-prev_2_ms>debounce_ms)
    {
      prev_2_ms=millis();
      Keyboard.press(button_2_key);
      //Serial.println("2 pressed");
    }
    prev_2=LOW;
  }
}

Augmented reality sandbox control using Arduino Feather

It’s been a while since I completed this project. I promised the Augmented reality sandbox community to write something in details so someone can replicate it. Here is the gist of it:

The Augmented reality sandbox (ARsandbox) is an awesome simulator that blends sand landscaping with augmented reality. A projector casts color-coded elevation, contours, and simulated water flow over regular sand. A 3D sensor measures the sand landscape in real time so the computer knows where sand is high and how it slopes down and renders color and contours according the the 3D data. You can rain over the landscape by pressing a button or hold out your palm over a certain area.

Here is a video of one of my builds:

This is where the control box comes in. The sand box is a 40″ by 30″ box with up to 200lb of sand. The function to rain over the augmented terrain is to press the “1” key on a keyboard. Sand and keyboard shouldn’t mix, not to mention if the system is deployed in a museum, the keyboard probably should be hidden from patrons. So a box with rain and dry buttons will be most convenient. You can make these buttons by following this forum post. You buy and assemble a USB gamepad kit and doing some scripting but it’s not that easy to follow if you are a Linux beginner. I want a plug-n-play solution so that anyone that wants to add a button box can add it without any knowledge of Linux and minimal skills in circuit assembly. In order to achieve my goals, the electronics inside the box has to emulate keyboard keys “1” and “2” for rain and dry. This ensures that the control box requires no software setup on the Linux system. As a bonus, the buttons should flash blue and orange so it would invite patrons to press and is color-coded for rain (blue) or sun (orange). Enter the ARsandbox control box:

Here is a short video of the box in action:

Features of the box:

1. Two buttons. Blue button on the left emulates the “1” key. It starts the rain in the main simulation, and is used in the projector calibration program to enter tie points, and can be assigned other functions in other programs such as extracting plane. Orange button on the right emulates the “2” key. It drys the rain in the main simulator, and can be assigned functions in other programs.

2. Both buttons have LEDs that flash to invite patrons to press. My 5-yr old son figured out what they do simply by the colors they flash because he knew the rain and dry features already but wasn’t told what these buttons would do.

3. No software setup is needed. This box works like another keyboard, with only 2 keys though.

 

Here are the parts I used, in case you want to build your own:

  1. Adafruit Arduino feather 32u4 basic board (1)
  2. LED push buttons 16mm from adafruit (2)
  3. USB-micro cable (1)
  4. USB extension cable (1)
  5. P-channel MOSEFT BS250 from mouser (2)
  6. 330 ohm resistors (2)
  7. 1K ohm resistors (2)
  8. DuPont 30cm female-female jumper wires (4)
  9. Prototype board or my printed circuit board. Click here to download (1)
  10. Enclosure SK-15 and flange kit SK-99 from polycase (1)
  11. Cable gland M3198GBH from Heiland for pre-assembled cables with USB connectors (1)
  12. Arduino sketch. Click here to download

Here is the schematic of the circuit:

Since the ATMEGA32u4 microcontroller on Adafruit Feather 32u4 is operating at 3.3V, I had to use two transistors to ensure that the LEDs inside the buttons light up with sufficient brightness. Currently the code only blinks both button LEDs at the same rate. In the future, I may update the code to blink more rapidly on the button that is depressed.

The following is a prototype that I built with the parts on a perfboard. It’s a bit messy and also took almost 2 hours to complete. I had to solder 16 wire leads and a bunch of jumper wires on the back side of the perfboard. I wouldn’t recommend this to a beginner.

Here is the printed circuit board that I designed (3 boards, two on the right showing the top, 1 on the left showing bottom):

The board is fairly simple and straightforward to solder. Only 8 wire leads and soldering the rest on the printed board, which is very easy. I also cut in half 4 30cm female-female Dupont jumper wires so I can just use the female side with male pins on the board to cut wire leads in half.

Here is a photo of the assembled guts including the microcontroller soldered to the button box board. Notice the black female Dupont connectors :

Here is the assembled board placed inside the enclosure. This enclosure is not cheap but nice and easy to use. It has various knock-outs so I didn’t have to drill a single hole.

Here is the completed box:

Although I am not aiming to sell a lot of these boxes, I think that designing the printed circuit board was the right way to go. I probably spent a few hours designing and proofing my design but I saved about one hour for each subsequent box I made. Plus, if YOU are interested in making this box, it will save YOU at least that much time.

SDI-12 data logging on Beagle Bone Black

In my previous post, I wrote about my initial success reading SDI-12 sensors using my SDI-12 USB adapter and a Beagle Bone Black (BBB), via a simple linux command “screen”. Upon further testing, I had trouble running my open-source python data logging script on BBB, because a number of python modules including pyserial and urllib3 are missing and I couldn’t install them the way I used to do on a Raspberry Pi. So after searching online for the past few days, I finally found how to solve the problem and here is a screen shot of the data logging script happily logging data on BBB:

BBB_logger_screenshot

The SDI-12 sensor I was using was the GPS sensor from my newest SDI-12 + GPS USB adapter. It has an on-board GPS module (separate purchase from Adafruit and its vendors). I was logging coordinates.

Here are the steps to prepare your BBB to run the data logging script:

  1. Install pip for python3: sudo apt-get install python3-pip
  2. Upgrade pip: sudo pip3 install –upgrade pip
  3. Install pyserial module: sudo pip3 install pyserial
  4. Install dropbox module: sudo pip3 install dropbox

The reason that I installed dropbox is because that I can use it to send data files from remote logger to my desktop, and installing it upgrades urllib3, which I use to generate URI-safe address for sending data to sparkfun’s phant server. If you are not doing telemetry or you prefer logging into your BBB to get your data files, you don’t have to install dropbox or upgrade urllib3. Now all I have to do is to update my documentation and welcome BBB to the club!

Ordering PCB from seeedstudio.com

This is an updated short tutorial on how to order your PCB from seeedstudio.com

I am not associated with seeedstudio but just a satisfied customer. They have competitive pricing and decent quality. They also recently automated design file submission process, although there is still some kinks.

Let’s assume that you have finished designing your PCB with EAGLE CAD, you should use seeedstudio’s CAM file to export your design into several files. The CAM exports many files but only the following are useful and should be zipped in a .zip file, per their instruction (http://support.seeedstudio.com/knowledgebase/articles/1176532-how-to-generate-gerber-file):

Copper traces:

  • Top Layer: pcb_name.GTL
  • Bottom Layer: pcb_name.GBL

Solder masks to apply solder resist around pads and pins so solder bridges don’t form and short circuits:

  • Solder Mask Top: pcb_name.GTS
  • Solder Mask Bottom: pcb_name.GBS

White text information for human assemblers and end users to read

  • Silk screen Top: pcb_name.GTO
  • Silk screen Bottom: pcb_name.GBO

Drill file for drilling pads and vias:

  • Drill Drawing: pcbname.TXT

The boarder of the circuit:

  • pcb_name.GML

Once you have a .zip file, direct your web browser to https://www.seeedstudio.com/fusion_pcb.html  and you will see their PCB printing service:

Seeedstudio PCB

There are a lot of options on this page. I will list what they are below:

Seeedstudio PCB options

  • Add your gerber file: Pick the .zip file that contains your design. You may examine your design after the upload. As of the writing, they are experimenting with a new gerber viewer that has some bugs. For instance, a board I designed 178mm wide only shows about 155mm of area. If I view with the old gerber viewer, everything shows up.
  • Material: typical boards are made of fire-retardant materials (default FR-4)
  • Layer: You will pick 2 layers. This means you will have circuits both on top and bottom of your circuit boards. I don’t see many single layer PCB any more but they were popular decades ago.
  • PCB Dimension: This is the rectangular size that encloses your PCB. Typical sizes in their price tiers are 5cm*5cm (about 2″*2″) for $10 (10 boards), and 10cm*10cm (about 4″*4″) for $25 (10 boards) although they usually run discounts on them. In the past, the board dimensions are taken automatically from your PCB design files but not anymore. You have to supply it yourself now. But you also get a “gerber viewer” after you upload your design.
  • PCB Qty: Seeedstudio PCB service doesn’t make one PCB, the least amount is 5 although 10 usually has the deepest discounts. Go ahead and pick 10, unless you want 50 or 100. Sometimes if I want 20 and the price of 20 doesn’t make sense, I would just go with 10 and then add another PCB design, which is the same as the first 10 and just order another 10.
  • Different design(s): you don’t want to change it to anything other than 1.
  • PCB Thickness: Go ahead and pick 1.6mm. Most common thickness is 1.6mm. If you want some added mechanical strength on your larger boards, you can go with 2.0mm.
  • PCB Color: Green is the default and other colors used to cost $10 extra. Now with smaller 10 QTY board all color cost the same, more or less. Your PCB will be painted with color paint although text is always white. I’ve never tried white or yellow but I assume the text may be black. I’ve used green, red, blue, and black. They all come out fine.
  • Surface Finish: Pick HASL (Hot Air Surface Leveling). It’s a technique that plates holes with hot molten solder and the excess is removed by hot air. You can also pick lead-free HASL if you want to go ROHS. You may upgrade to ENIG, which is Electroless Nickel Immersion Gold. Holes will be covered by a thin layer of gold to prevent oxidation.
  • Min Solder Mask Dam: I don’t know this enough so I’m going with default 0.4mm.
  • Copper Weight: this is the weight of copper clad per square foot. 1oz is a typical choice. Thicker copper clad offers less resistance with the same trace size. It’s simple physics.
  • Min Hole Size: this is the least drill size. 0.3mm is good enough. We are talking about very small via holes. Only multi-layer boards with a large IC that has lots of pins or ball grid array ICs will need more vias and smaller vias.
  • Min Tracking/Spacing: this is the thinnest copper trace width. 6mil is good enough. Unless you have multi-layer board and ICs with hundreds of pins, you don’t need any thinner traces.
  • Blind Vias: oh my, just go with default NO.
  • Half-cut: go with NO. Never done it.
  • Impedance Control: unless you have specifically designed your board to control impedance of your traces, go with NO.

After everything is selected and the service is added to cart, I would proceed to check out. You need to set up an account with seeedstudio and have a paypal account. Regular shipping is slow and not that cheap. I average about 3 weeks between design submission and delivery (to Mid-west, USA). You can also pay DHL and save maybe a week or more, although I never used it. I guess that’s it.

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.

Temporary connections?

I bet once or twice in the past you wish that you could find a simple way to just hold a module with male headers like this Adafruit GPS module in the pin holes of a circuit board without soldering the pins so you can later take the module and put it elsewhere. Here I found a neat solution, wedging the module with some ESD foam. You get ESD foam pieces from buying ICs so they come for free and have some springy-ness. Then you put in between the module and the board and push in. The force from the foam will make the module form a wedge and there is enough strength to tlit the pins against the holes to make connection. Here are some photos:

The first photo shows the underside of my new phi-3 shield. The GPS module is supposed to be on the top side but unless I solder it to the shield, there is not enough space to make a wedge with the module while it is under the display. So I hang it below the shield board and stuck a piece of ESD foam between the module and the shield board. Here is a side view. You can’t see the foam, which is too dark but you do see the pins are all tilted and thus pushed hard enough to make electrical connection. I only recommend this on a temporary basis. Tomorrow the GPS module is going on another board, the SDI-12 + GPS USB adapter. I’ll solder this time.

%d bloggers like this: