Cermetek CH1724 Modem PTH Adapter Board

I need to solder pins to multiple CH1724 modems which look like this:

Image result for ch1724

I tried soldering header pins directly, but that was a cluster. So I designed this little adapter board:

You can layout header pins on a PCB, put the adapter board on the pins, then the modem on the adapter board like this:


and you end up with:


I’ve placed this adapter board on dirtypcbs.com so you can order your own. You can find it here.

If you need such a beast and you don’t want to order a minimum quantity of 10, check with me and I may have a spare I can send you cheap.

Posted in c-electronics | Tagged | Leave a comment

WiFi Target Spotting Scope

DISCLAIMER: If you build this device, I take no responsibility for any outcome. Make sure you are sighted-in well enough to be hitting the target everytime and place the equipment in a position to avoided being hit. Lithium batteries are particularly dangerous and hitting one with a bullet will have a nasty outcome such as this: https://www.youtube.com/watch?v=j2mYsBue_30

wtss-fig32A friend and I were looking at a very cool commercial WiFi target spotting scope. It lets you see easily see a shooting target from your phone / tablet and software tracks each shot. Cool but at $350, we weren’t really interested. We bounced around some ideas and found someone using a WiFi router and IP camera to do the same thing. Genius!

That guy’s rig was just a 20 second YouTube clip with no setup instructions. I’ve duplicated his effort, but documented exactly what you need to make this happen.

I’m using a D-Link DCS-920 WiFi camera because that is what I have laying around. It is very old and the video part doesn’t work with Java any longer; however, it will take still pictures fine which is all I really need (I just press refresh to update the picture). If you are a shooter and not a computer person, you should be able to find one of these used on eBay if you want to follow my instructions to the letter. As of writing, the going used price is $20-$50.

I’m also using a TP-Link TL-WR802N because that was just laying around as well. If I were trying to create a serious spotting scope, I’d go with a router that has external antennas so it has the maximum possible range. Since this project is expected to be used outdoors with no obstructions, the TL-WR802N is acceptable, at least as far as I am capable of hitting a target. As of writing, this is a current device that can be had on amazon for about $25.



  • Laptop and RJ45 Cable (for setup). Laptop needs both a WiFi connection and an Ethernet connection.
  • 5V WiFi Router (TP-Link TL-WR802N) and USB Type A to Micro USB power cord
  • 5V WiFi Video Camera (D-Link DCS-920)
  • USB Type A to 2.1mm Barrel Jack Power cord (Adafruit model 2697)
  • USB Lithium Phone charger to provide 5V power to router and camera.
  • Paperclip to reset devices

Configure the WiFi Router

The WiFi Router will be configured to be a wireless router which will allow your phone/tablet/PC to access the WiFi Camera via WiFi (note that android doesn’t support adhoc access, so a WiFi router is required).

These instructions are specific to configuring the TL-WR802N, but the same general configuration will apply to other routers.

  • Reset router to factory defaults. For TL-WR802N, press reset button and hold for 10 secs. Green light will go to fast blinking.
  • Wait for the light to flash slow again – then it is fully rebooted.
  • Using the laptop, find the router’s WiFi network which is called TP-LINK_090A and establish a connection to it. The WiFi password is on the back of the router.



  • Login to the router. For the TP-Link, the user / pass is admin / admin.
  • This takes you to the Quick Setup starting screen. Click on Next.
  • Operational Mode: Select wireless router and click on Next. Don’t use Access Point – it will not assign DHCP addresses properly.


  • WAN connection type. Select Dynamic IP and click on next.


  • MAC Clone: Select No and click on next.


  • Wireless Setup. Enter the SSID and password you wish to use then click on next.


  • In the review settings screen, verify all settings and click on finish.
  • The router will now reboot. You will need to reconnect to it using the new SSID, wifiscope:


  • You may notice an exclamation point for your wifi connection. This just means there is no connection to the internet, which is correct.


  • The router is now configured to use IP address Ping it to verify you can still get to it.

Configure the IP Camera

Next, the DCS-920 will be configured to use the WiFi router.

This camera can be a bit confusing. Although it has both an ethernet and wifi connection, they BOTH are assigned to the same IP address. Remember that as you go thru the configuration.

  • Provide power to the camera.
  • Reset camera to factory defaults. For DCS-920, press reset button and hold for 10 secs.
  • Set up laptop’s ethernet port to the same default subnet as the WiFi IP camera. For the DCS-920, this is, so my laptop is given the address


  • Connect camera to laptop via RJ45 cable.
  • Laptop’s ethernet port should now be in connected state.


  • Determine IP address of the camera.
    • By default, DCS-920 is assigned IP address of
    • I determined this by running a TCP port scanner on the laptop against the network.
    • Typically the default address will be on the label of the device or in the manual.
  • From the laptop, ping the camera ( to verify you can reach it.
  • Now connect to the camera via your web browser using the IP address:
    • HTTP://
    • You will be asked for the camera’s user/password. for the DCS-920 this is admin and the password is blank.
    • Once logged in, the main screen is displayed:


  • Click on the Setup Tab, then on Network Setup on the Left tabs. Assign the camera a static IP address. I will use the default of here. Then click on Save Settings.


  • Now go to the Wireless Setup tab. Enable wireless, and specify SSID, security mode, and the password. Then click on save settings.


  • Go to status screen and keep pressing refresh until you see the link come up:


  • For the DCS-920, I left the image settings as defaults. I went into the video setup and changed resolution from 320×240 to 640×480 and quality to high.


  • Now I can see a reasonable image in the browser.

Test WiFi Access to Spotting Scope from Laptop

Now let’s make sure everything works properly.

  • Disconnect the Ethernet cable from the camera.
  • Make sure the laptop is connected to the wifiscope SSID.
  • From the laptop, ping, the camera.
  • From the laptop’s browser, connect to, the camera.

Test Phone / Tablet

If the laptop is working, time to connect using your phone.

  • Connect to the WiFi SSID wifiscope and enter the appropriate password. For my version of android, I got a warning there is no internet connectivity which is correct.
  • While in the list of networks, click on the 3 dots (submenu) and then on advanced.  Verify you have an IP address assigned to your phone.
  • Note: I’ve had some issues getting the phone to receive DHCP (the router says it sends it). If this is a problem for you, you can configure your phone to use a static IP address on this network (say
  • In the phone browser go to
  • Enter the user / password for the camera (still admin / nothing for my DCS-920).
  • You will now see the camera website.

Create a link to just the Picture

I’m using firefox on my phone, so this is how to create a link to just the picture.

  • Long press the picture on the website until you get a menu.
  • From the menu select view image.
  • You will now see just the picture, not the entire web page.
  • Bookmark this page and call it something like wifiscope.
  • Because this is NOT a video, it will only update if you press the browser refresh button.

Field Setup

Setting the camera up in the field is pretty straight forward. Plug everything in, and go to the bookmark you saved above with your phone/tablet. Using the phone, you can position the camera as you need it.

Obviously, position the camera where it can’t get hurt. More importantly, make sure the battery pack CANNOT get hit. As already pointed out, hitting the lithium battery would result in a fire.

When I’m ready to use this, I will use a barrel jack extension cord to separate the camera from the router and battery pack so both can be position well out of the line of fire.

Note that the DCS-920 has a manual focus ring.

Here is my test setup (done inside because it is miserable out today):


Clean Up

Don’t forget to reconfigure your laptop’s Ethernet interface back to it’s original settings.

Posted in c-Misc | Tagged | Leave a comment

Tip o’ the Day: Gaffer Tape instead of Duct Tape

Duct tape is renown for its usefulness.  No argument there – I keep rolls in my vehicles, snowmobiles, ATVs, etc. for emergencies.

Interestingly, it sucks for use on actual ducts. I tried that many years ago only to have the tape completely fall off after several months.

I was introduced to Gaffer Tape many years ago by a professional photographer friend. It is typically my go to tape these days.

It is easier to tear, a bit more like cloth so it conforms better if you aren’t taping flat surfaces, and best of all it doesn’t leave a mess when you remove it.

It is more expensive than duct tape, so I still keep cheap duct tape in my vehicles for emergencies. But around the house, gaffer tape is my go to tape.


Posted in c-photo | Tagged | 1 Comment

Cleaning Flux from Printed Circuit Boards (PCB)

I got some professional looking PCB boards manufactured for a project recently. The boards look great compared to anything I could do myself.

Problem is, after I solder on the components and try to clean the flux off, I’m always left with a mess. My great looking boards end up with white stains from trying to remove the flux.

In researching this problem, I’ve learned about water soluble solder and no clean solder. I will be trying those in the future, but I’m still left with my most recent board which needs to be cleaned.

After looking around the interweb and doing some experiments here is what worked very well (though not quite perfect).

  • Apply all liquids with the board vertical to avoid getting anymore than necessary on the front side of the board.
  • Apply 99.9% isopropyl alcohol with a toothbrush to remove the flux. I don’t seem to need to scrub long or hard to get it loosened up.
  • Apply Simple Green with a sprayer. Brush the whole board again with a toothbrush. It may help to apply plenty of Simple Green to help flush the flux away.
  • Spray the board repeatedly with distilled water until the simple green & flux are flushed from the board.
  • Blow excess water off board with compressed air.
  • Finally, dry the board with a heat gun or hair dryer, taking care not to let it get too hot.


Posted in c-electronics | Tagged | 2 Comments

Automating Testing Using Video

I found myself needing to verify caller ID operation of a couple of troublesome telephone handsets. To properly test, I want to run 1,000 calls to the handsets and verify they decode caller ID every single time.

During early testing, I would manually call the handsets about 20 times to see if they looked good. Typically the error occurs every 3rd-4th call so that was a little slow but do-able. But there is no way I’m sitting still to watch 1,000 calls.

I could video record the handsets, but watching the video is no faster and trying to fast forward was going to be clumsy as well.

What I really need is a way to toss out most of the video frames then I could just advance a few frames to see the next call.

I recorded the video off a webcam using VLC using this procedure:


After some research I found a utility call ffmpeg which does many things, but for my current need, you can tell it to extract <n> frames per second and save them as a file.

ffmpeg can be found here:


My first test was to extract one frame per second which I did with this command:

    ffmpeg -i myfile.mp4 -vf fps=1 c:\tmp\pics\out_%%03d.png

This created a PNG file once a second (1 frame per second), reading myfile.mp4 and creating a series of PNG files called out_001.png, … .

This worked pretty well, but a complete test cycle takes about 20 seconds so I was ending up with 20 PNG files / cycle to flip thru. That’s too many.

I watched the testing process, and both phones’ displays are on for about 10 seconds from the time the CID message comes thru. If I were to capture a frame every 5 seconds, that would be about perfect.

So I ended up using this command:

    ffmpeg -i myfile.mp4 -vf fps=0.2 c:\tmp\pics\out_%%03d.png

Now I end up with about 5 frames per test call.

Using picasa to view the first file, I can go to the first picture showing the caller ID message. Then I just press the right key 5 times and I’m on the same spot in the next test. That I can do very quickly.

I can process roughly 1 test every 2-3 seconds flipping thru 5 pics verses having to watch hours of video which just isn’t going to happen.



I’ve went thru this process quite a few times now. Works well, but having to constantly click thru still images is a pain.

So using ffmpeg again as directed here:


I created a video to watch. I can then stare blankly at the video and just pause when I think an event has been missed.

When I did the extract, I was extracting 1 frame from the original video every 10 seconds. When I create the new video, I want to see each of those extracted frames every 1/2 second (2 frames per sec). This is the command I used to construct the video:

"\Program Files\ffmpeg\bin\ffmpeg.exe" -framerate 2 -i f11b_%%04d.jpg -c:v libx2
64 -r 30 -pix_fmt yuv420p outx.mp4

My input file is f11b_0001.jpg, f11b_0002.jpg, …

My output file is outx.mp4

I’m reading these jpg files at a rate of 2 / sec (-framerate 2).

The output MP4 file contains 30 frames per sec (-r 30).


Posted in c-Misc | Tagged | Leave a comment

Migrating Raspberry Pi Version 2 SD card to Raspberry Pi 3 Hardware Platform

My development RPI has been an RPI version 2 since version 2 was first released. Further, everything except the boot files have been moved to a USB-based hard drive to increase performance (using a procedure much like this: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=44177)

I needed a new RPI for a project and found version 2s are more expensive than version 3s so I purchased a 3 to be my new dev machine and I’ll use the old hardware for the new project.

The problem with upgrading my dev hardware is the last thing I want to do is screw with the software on it. It has taken a lot of time to get it where I want it.  So it is important that I can just transfer the SD card and USB drive to the new hardware.

Here is the procedure I followed which worked just fine. I won’t waste time describing each step blow-by-blow. If you need to know the details, you can google them as I did.

Backup The System

If something goes wrong, you will want a backup. Expect to spend a few hours backing everything up (at least if you have a very big USB drive).

  • Poweroff the old RPI2 system.
  • Backup the SD card using Win32DiskImager
  • Mount the USB drive to a PC based linux system.
  • Zero free space on the USB drive:
sudo cp /dev/zero /mnt/usb/bigfile.zer
sudo rm /mnt/usb/bigfile.zer
  • Unmount the USB drive
  • Use fdisk -l to determine the device of the USB drive
  • Use dd to backup the entire drive to a location of your choosing:
dd if=/dev/sdb conv=sync,noerror | pv | gzip --fast > sdb-dd-yymmdd.gzip

In above example, I determined my USB drive was /dev/sdb so that is my source. I like to name the output file the drive name + backup type (dd or ntfsclone usually) +  date.

  • At this point, I put the SD card and USB drive back on the old version 2 RPI and restarted it.
  • I then did a DUMP of all files to a remote location so I can recover individual files if necessary.
  • Finally, I created a list of all installed packages using:
dpkg --get-selections | grep -v deinstall > //mnt/netdrive/tmp/installed-packages.lst

Upgrade the Operating System

My RPI Version 2 was running Raspian version Wheezy. You MUST be running Jessie (or later) OR do the following dist-upgrade.

As I understand it, dist-upgrade doesn’t upgrade you to Jessie, but makes sure you get ALL available packages (apt-get upgrade may hold back packages). My RPI 2 is using Wheezy, I followed this update and it worked fine for me.

  • Update the list of packages:
sudo apt-get update
  • Do the dist-update:
sudo apt-get dist-upgrade
  • Reboot to load the changes:
sudo reboot
  • Make sure things are working, then power off your RPI 2:
sudo poweroff

Upgrade The Hardware

At this time, pull the old RPI2 out. Transfer it’s SD card and connections to the RPI3. Power the RPI3 up.

Mine came up flawlessly following the procedure.

Good luck!


Posted in c-rpi | Tagged | Leave a comment

Making a Data Only Cable For Teensy/Arduino/Nano

Been working on a complicated teensy project that is going to the other side of the state for testing. So I’ve been building a testing platform that consists of a Raspberry Pi connected to the Teensy via USB. I can connect to the RPI and monitor/update the Teensy.

One of the requirements is that I be able to cycle power on the teensy just in case duty hits the fan. I’ve got this great little device for that very purpose:

found at http://www.digital-loggers.com/iot.html

The one problem I’ve realized with this idea is I cannot just remove power from my device to reset it because the RPI will continue to feed power to the Teensy via the USB cable. (Actually there is a way to have RPI kill power to its USB hub but it also kills power to the ethernet module. It has worked in testing but seems a little dicey to really rely upon).

I need to kill power from the USB cable. The obvious way to do this is to slice the USB cable open and cut the power line. Not too hard to do, but I really don’t want to send a unit out to the ‘customer’ with electrical tape around one of the cables. That’s not cool.

I was looking around for data only USB cables (which are available but kind of expensive) and stumbled across someone that was doing the reverse of what I wanted – he was getting rid of the data signal. BUT, his method was perfect. See http://www.instructables.com/id/USB-Condom/?ALLSTEPS.

I applied the same idea and cut a tiny piece of clear packing tape and applied it to the +5V contact on the A side of the USB cable:

dataOnlyYou should be able to see the tape covering the contact on the far right.

This works great and now when I kill power to the device, it actually turns off.

Nov 2016 Update:

The size of tape is pretty close to 3mm x 25mm.

Posted in c-arduino, c-rpi, c-teensy, Uncategorized | Tagged | 1 Comment

Remote Monitoring and Upgrading of Arduino/Teensy via Networked Raspberry Pi

This post covers how to remotely monitor / upgrade an Arduino or other MCU behind a firewall.

(Jump down to the Dec 2016 Update for Notes about the Duplicity Service that will easily and quickly allow remote access to an RPI)

Let’s look at an example:


On the far right of the diagram is an Arduino ‘in the field’ and I want to access it from a local PC which is on the far left.

The first step to accessing the remote Arduino is to connect it serially to a networked computer. I propose using a Raspberry Pi for this purpose since they are cheap. I then wish to use putty and VNC to access remoteRPI to finally access the Arduino. But just adding remoteRPI doesn’t make either accessible.

There are a couple of problems with this solution. First, remoteRPI will most  probably be assigned a private IP address by DHCP. There is no direct access of remoteRPI due to the remote firewall, remoteFW. A hole is going to be needed in the firewall.

Putting holes in ‘customer’ firewalls is a difficult proposition, at best. Having the ‘customer’ create the hole is probably impossible. Gaining access and doing it yourself is equally impossible.

The usual way to get around the firewall access issue is to have the remoteRPI create the connection back to the local network. The remoteFW has no issues with outbound connections. We create and use that connection when necessary.

Using remoteRPI to create the connection is the access method I will implement here. This will be done using an SSH reverse tunnel.

At boot time, remoteRPI will open an SSH reverse tunnel to localRPI. I’m using a Raspberry Pi for localRPI, but any linux system will work. This tunnel remains open continuously. When you want to gain access to remotePRI, you make an SSH connection to localPRI which forwards to remotePRI.

I was unable to find any references that fully showed implementing the diagrammed solution from begin to end. This blog will cover all of the config changes and commands to implement this tunnel but not the whys. You can google all of the commands and learn the why easily enough so I won’t try to duplicate the effort.

Allocating TCP Ports

We are going to need to define 3 TCP ports for our project. I like to use a random number generator (google random number generator) to select a port between 10,000 and 32,767.

27045 – Local Firewall NAT Port

This is the port that will allow remoteRPI access to localRPI via SSH (port 22).

27046 – SSH forwarding port

We will connect to this port on localRPI when we want to access SSH on  remoteRPI.

27047 – VNC forwarding port

We will connect to this port on localRPI when we want to access VNC on  remoteRPI.

Create NAT Rule on localFW

remoteRPI needs to connect to localRPI via SSH (port 22). We will create a port forward rule on the localFW to allow this access; however, we will expect port 27045 to be the destination port on the firewall and we will translate that to port 22:

Application Protocol Source Net Port From IP Address Port To
sshRevTun TCP 27045 [localRPI] 22

This rule states any inbound packet with destination port of 27045 will be sent to IP address (localRPI) using destination port 22.

Activate the firewall rule.

You can then do a simple test on the rule by using a remote port check utility such  as http://ping.eu/port-chk/ and enter the external IP address of your firewall and port 27045 to verify the port is open.

Enable Global Port Forwarding

By default, any reverse SSH tunnel built on localRPI will only be available to localRPI. My requirement is that I be able to use any PC on my local network to access remoteRPI, so we need to allow others the ability to use the reverse SSH tunnel.

On localRPI, in the file /etc/ssh/sshd_config, add the following line anywhere:

GatewayPorts yes

Save the file and restart SSH with

service ssh restart

Make Scripts to Create the Tunnels

We need two scripts to build the two SSH reverse tunnels – one for each protocol (SSH and VNC).

I create these using the standard pi user and simply place them in pi’s home directory.

Put these commands in a file named sshRevTunSsh:


sleep 60

while [ true ] ; do
  ssh -p 27045 -N -R \*:27046:localhost:22 -o "ServerAliveInterval 30" \
    -o "ServerAliveCountMax 3"  pi@localfw.mydomain.com
  sleep 30

And put these commands in a file named sshRevTunVnc:


sleep 60

while [ true ] ; do
  ssh -p 27045 -N -R \*:27047:localhost:5900 -o "ServerAliveInterval 30" \
    -o "ServerAliveCountMax 3"  pi@localfw.mydomain.com
  sleep 30

don’t forget to make them executable:

chmod 577 sshRevTunSsh sshRevTunVnc

These scripts will connect to localRPI by routing to the localFW (localfw.mydomain.com) and then being forwarded by the firewall to the localRPI system where they will attempt to log on as the pi user.

I am using a DNS name localfw.domain.com. You can use a DNS name or the external IP address of your router as well. If your router is assigned its WAN IP address using DHCP, you should seriously consider using a dynamic DNS service such as afraid.org. Otherwise, when your ISP finally forces the IP address on your router to change, the SSH reverse tunnel will fail, and it will be be difficult to fix.

Test Scripts

You might want to comment out the initial sleep 60 command as this is really only necessary when the script is executed at boot time.

To start the SSH reverse tunnel for SSH, type


You will be asked for the pi user password for localRPI. Then there will be no further output, it just runs.

Now from a local PC, run putty. For the hostname/IP address, enter the hostname for localRPI and specify 27046 as the port:

	localRPI		27046

This will connect you to remoteRPI. Enter a user/password for the remoteRPI system.

Should the script fail, you can place -v in the SSH cmd of the script to get debugging output.

Now run the script for sshRevTunVnc. From a local PC, run VNC and login using


This will connect you to VNC on remoteRPI.

Create SSH Reverse Tunnel without Requring a Password

The scripts to start the SSH reverse tunnels allow automation, but having to enter a password prevents us from actually automating the process.

There are many locations on the web explaining this process. I will do a very brief example of it.

On remoteRPI, logon to the pi user and type:

cd ~/.ssh
ssh-keygen -t rsa

This creates a public/private key pair for password-free logins.

Now copy the public key to remoteRPI:

scp -P 27045 id_rsa.pub pi@localfw.mydomain.com:.ssh/authorized_keys

Rerun the scripts and they will no longer require passwords.

Fully Automate the SSH Reverse Tunnels

Everything is now in place to allow the SSH reverse tunnels to be created at boot time. Should the tunnel go down, the script will automatically restart it.

We will run the scripts at boot time using cron:

sudo crontab -e

and add the lines

@reboot su pi -c "/home/pi/sshRevTunSsh " >/dev/null 2>&1
@reboot su pi -c "/home/pi/sshRevTunVnc " >/dev/null 2>&1

Don’t forget to restore the ‘sleep 60’ commands in the script files if you  commented them out.

Reboot the system. You can verify the scripts are running:

pstree | grep sshR
        |      `-cron---sh---su---sshRevTunSsh---ssh

Finally, again test that you can access remoteRPI from your local PCs.

Issue Programming Arudino Nano from Raspberry Pi

I’m sticking this note here because I don’t have a better place for it yet.

Now that I’ve got the remoteRPI operational, I’m starting to experiment with actually controlling / updating an Arduino.

I started with a Nano and have found there is a problem with Nanos. When you first connect the Nano to the RPI via USB, it will come to life and populate /dev/tty properly and you can access it via /dev/ttyUSB<n>.

But, when the RPI is rebooted, the Nano disappears. Nothing seems to bring it back short of unplugging the USB cable and reconnecting. Not acceptable.

This problem appears to only occur with Nanos due to a design mistake when implementing FTDI. This is covered here: https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=59420.

I have since moved on to an Arduino Uno for testing and it works fine – when the RPI is rebooted it is reconnected properly to the USB port.

Dec 2016 Update:

Reverse Tunnel Status:

I’ve been using the aforementioned scheme to access a remote RPI for 4 months now and in general it works great. The only issue I have is for some reason the local linux server where the ssh tunnels terminate periodically has an issue such that I can no longer SSH into the tunnel. The only solution has been to reboot the local system which then causes the RPI to reestablish the tunnels and all is fine.


I recently learned about dataplicity.com, a 3rd party service to allow remote access to your RPI.

It is super easy to get your RPI up and running on this service. They give you a command to type at the RPI’s bash prompt and it fully installs and starts the duplicity service. Then you go to your devices at duplicity.com and can get to a shell prompt on their web page.

They also provide ‘wormholes’ that allow you web access and VNC access to the RPI. But this access requires manually installing all the necessary services, etc.

The service is free, at least at the moment. How they do this for free is puzzling. I’m not complaining, but if I were going to use this for anything ‘production’ I would want to know they aren’t going to go out of business because they are giving the service away. It might be a royal pain to recall devices and come up with a different mechanism if they were to vanish (or start charging more $$$ than I could justify).

At the moment I don’t see a way to transfer files TO the RPI. It may be this needs to be done by creating a webdav directory that allows write access. FTP/SSH access, like I can use with the reverse tunnels I create in my scheme is not possible as far as I can tell.

Still, for easy remote access of the shell, this is a fantastic alternative.

I decided to use dataplicity for an emergency backdoor to remote RPI in case the sshtunnels completely fail. I’ve also noticed there is no way to cut/paste in their terminal emulator which is makes it not quite as useful as one would hope.

Another update for Dataplicity:

My ‘puzzlement’ has been answered quickly. I just received an email that they will be charging between $2 – $3.50 / mo.

Posted in c-arduino, c-rpi, c-teensy | Tagged | Leave a comment

Refurbishing a Skimmer Weir Gate

A weir gate is attached to swimming pool skimmers to keep the rubbish collected by the skimmer from floating back out into the pool.

The ones I’ve seen use a Styrofoam float to keep the gate up.  I noticed my pool has been hard to keep clean lately, and I realized the old weir gate was no longer floating properly.

OK, I should say there is very little good reason to refurbish a weir gate because they are really cheap. Unless you are really cheap (nothing wrong with that), OR, as in my case, the new one you ordered doesn’t quite fit.

The weir gate I ordered was just a smidge too large. I was going to need to trim maybe a 1/4″ off. But first I needed to get the old one out which was kind of a mystery. All instructions I have found talk about installing the new one not removing the old one.

As I looked carefully at it I looked like I could get a very thin screw driver under the ‘post’ I was seeing and maybe pry it out.  Sure enough I was able to work the ‘post’ out of its socket and I realized it wasn’t little pins holding the weir gate in place, but the posts set in shallow sockets.

I don’t know if they all work the same, but the weir gates I have have a rod inside them that is like a compression curtain rod as you can see from the picture.


If you can remove the weir gate intact, it is perfectly easy to refurbish.

Once the weir gate was out I could remove the Styrofoam and sure enough it was badly water logged. It weighed as much as a small brick (pictured at the top).

As I looked at the Styrofoam, I realized I had extra Styrofoam in my parts bins I’d saved from packing material – it comes in handy once in a while. I located my stock and it has the same texture as that in the new weir gate, so I decided to use it (leaving the entire new weir gate for future use should I need it).

I cut my stock down to the same dimensions (2nd block of Styrofoam above) and inserted into the weir gate.

Now to reassemble. The new weir gate has pins holding the compression rod in place. I had tiny picture nails of about the same size. I stuck one nail in on one side, then used a dowel to compress the rod into place so I could get the 2nd nail positioned (having a helper here is very, well, helpful).

Once the pins were in place my old weir gate looks just like the new:


Note the nails are sticking out on the flat side – this is the side you will be able to access with pliers once the gate is positioned properly.

At this point, installation is simple – position the gate so the posts are aligned roughly with the sockets. Pull the first nail, check alignment again, then pull the 2nd nail and you are done.

Try not to drop the nails in the pool!

Posted in c-Misc | Tagged | Leave a comment

Upgrading Teensy Code in the Field

I’ve got a few Teensy projects in ‘production’ now and I know I’m going to have to update the software onsite. In fact, I need to be prepared to allow an end-user to upgrade the software as one Teensy that is located 1000’s of miles away now.

In the back of my head I figured this must not be too hard since the Teensy has a nice windows based programmer. Sure enough, it is slam dunk. Well, pretty close.

This procedure assumes that the necessary files will be gathered together, sent to a remote site, and a reasonably technical user there will be responsible for doing the install (not necessarily someone familiar with programming arduinos, but one able to do normal PC maintenance).

Put Together the Files

To update a Teensy in the field, you are going to need the Windows serial installer, the Teensy programmer application, and the binary code for your own program which consists of a .HEX file and a .ELF file.

On the Teensy download website, https://www.pjrc.com/teensy/td_download.html, you will find the Windows Serial Installer, get a copy of it to install on the PC that will handle the update.

The programmer is called teensy.exe and can be found in <ardinuoDir>\hardware\tools. Here is its location on one of my development systems:

[C:\]dir \arduino-sj\hardware\tools

 Volume in drive C is c140527        Serial number is D467:78F2
 Directory of  C:\arduino-sj\hardware\tools\*

 5/03/2016  14:50         <DIR>    .
 5/03/2016  14:50         <DIR>    ..
 5/03/2016  14:50         <DIR>    arm
 5/03/2016  14:51         <DIR>    avr
 2/06/2016  17:25               0  .keep
 2/06/2016  17:25          45,608  listComPorts.exe
 3/10/2016  22:09          33,448  mktinyfat.exe
 3/10/2016  22:09       2,486,456  teensy.exe
 3/10/2016  22:09          24,744  teensy_gateway.exe
 3/10/2016  22:09          26,280  teensy_post_compile.exe
 3/10/2016  22:09          28,328  teensy_reboot.exe
 3/10/2016  22:09          21,672  teensy_restart.exe

Now you need the binary code for your own program.

  • Start the arduino IDE (which has Teensy support).
  • Do a Verify/Compile (ctl-R) to create the hex file of your code.
  • The hex file is created in the temp directory for your user. For windows 7 (at least for my installation), this is in c:\users\<username>\appdata\local\temp.
  • In the temp directory you should find a directory starting with the word build:

 Volume in drive C is c140527        Serial number is D467:78F2
 Directory of  C:\Users\xxx\AppData\Local\Temp\*

 6/06/2016  15:28         <DIR>    .
 6/06/2016  15:28         <DIR>    ..
 6/06/2016  15:24         <DIR>    build1e37ea4638dee8a2fbba645dea41b283.tmp
 6/06/2016  15:23         <DIR>    hsperfdata
 6/06/2016  15:23         <DIR>    jna-3075831
 5/27/2014  21:40               0  FXSAPIDebugLogFile.txt
              0 bytes in 1 file and 5 dirs    0 bytes allocated
153,325,252,608 bytes free

  • Go into this directory and you will find the hex file (if there is more than one build directory, the one with the most recent date is probably the correct one):
 6/06/2016  15:24         <DIR>    .
 6/06/2016  15:24         <DIR>    ..
 6/06/2016  15:24         <DIR>    core
 6/06/2016  15:23         <DIR>    libraries
 6/06/2016  15:23         <DIR>    preproc
 6/06/2016  15:23         <DIR>    sketch
 6/06/2016  15:23             661  build.options.json
 6/06/2016  15:24              13  test.ino.eep
 6/06/2016  15:24         790,716  test.ino.elf
 6/06/2016  15:24         226,676  test.ino.hex
  • If you cannot find the file search for <project>.ino.hex. I prefer to do this in the cmd box as windows 7 search only finds files I KNOW exist about 1/2 the time:
dir \users\xxx\appdata\Local\*.hex /s
  • Once you have located the .HEX file, the .ELF file will be in the same directory. You will need it as well.
  • Now I have all the files ready to take to the Teensy to be updated:
 6/06/2016  16:09         117,936  serial_install.exe
 6/06/2016  15:54       2,486,456  teensy.exe
 6/06/2016  15:24         790,716  test.ino.elf
 6/06/2016  15:53         226,676  test.ino.hex

Install Serial Driver

Once ready to update, Install the Serial Driver First!

Assuming the PC used to to the upgrade doesn’t already have the Arduino/Teensy software installed, we are going to install just the files necessary to perform the update.

Right click on the serial_install.exe file and run as Admin to let it install the virtual serial driver.

Connect to the Teensy

  • Plug the Teensy into the PC’s USB port.
  • Windows should see the device and start looking for drivers. Skip searching the internet for the update.
  • Once the driver is installed, there is no indication I can find that device manager sees the Teensy (it won’t update the serial port list). But you should still hear the sound effect when you unplug/plug the teensy in.

Update the Code

  • Start the Teensy.exe program
  • Click on Help | Verbose – You will see a screen which will indicate the program is ‘listening for remote control’.
  • In Teensy.exe, do a file | open and open the HEX file. The log indicates the file has been opened.
  • Press the ‘Auto’ button in teensy.exe.
  • Press the reset button on the Teensy.
  • You should see messages in the log indicating the download and reboot were successful:
16:55:40: Board is: Teensy 3.2 (MK20DX256), version 1.03
16:55:40: File "test.ino.hex". 80576 bytes, 31% used
16:55:40: File "test.ino.hex". 80576 bytes, 31% used
16:55:40: elf size appears to be 262144
16:55:40: elf binary data matches hex file
16:55:40: Code size from .elf file = 262144
16:55:40: begin operation
16:55:40: flash, block=0, bs=1024, auto=1
16:55:40: flash, block=1, bs=1024, auto=1
16:55:40: flash, block=2, bs=1024, auto=1
16:55:41: flash, block=76, bs=1024, auto=1
16:55:41: flash, block=77, bs=1024, auto=1
16:55:41: flash, block=78, bs=1024, auto=1
16:55:41: sending reboot
16:55:41: begin wait_until_offline
16:55:41: offline, waited 2
16:55:41: end operation
16:55:41: redraw timer set, image 14 to show for 1200 ms
16:55:41: HID/win32:  vid:05A4 pid:9881 ver:0120
16:55:41: HID/win32:  vid:05A4 pid:9881 ver:0120
16:55:42: redraw, image 9

Maintaining Executable Code

Once I had this process working, it became evident I no longer have to recompile programs every time I want to use them.

This is most helpful on my current project. There are quite a few hardware subsystems involved. After I build a new PCB, I want to make sure all of the hardware is fully functional, so I have a hardware test suite I use.

I can now download and execute the hardware test suite w/o compiling. Once the hardware is tested, I can then download and execute the stable version of the software without having to go back to the source and recompile it.


Nov 2016 Update:

Periodically, I have an issue getting this process to work. When I do a file | open in teensy.exe and specify the HEX file, I will get an error indicating file too large.

It seems teensy.exe defaults to an older model of teensy with less program space. Supposedly if you have both the HEX and ELF files available this isn’t supposed to be an issue, but sometimes it is.

It seems that if I build the HEX file by doing a sketch | upload this problem will not occur. But sometimes I don’t want to upload the version I’m compiling to the teensy that I have connected so I do a sketch | compile. I don’t know why that would make a difference, but so far my observations have been it does.

What to do when this happens? Today I seem to have stumbled across a solution. I have not been able to replicate the failure so I’m not 100% I got the correction sequence right:

  • After doing the file | load, you see the file too large error in Teensy.exe.
  • Double click on teensy_reboot.exe – this will upload the file anyway.
  • Then double click on teensy_restart.exe – this will restart the teensy.


Posted in c-teensy | Tagged | 4 Comments