Providing increased water flow for a 5G Bucket Evaporative Cooler

I recently built a 5G bucket swamp cooler very similar to this:

I used a tack like he does to puncture the water supply hose and I simply could not get enough water to keep the pad moist. I went back and used a much larger nail and still the water supply was too constricted to do the job.

I ended up using a razor to slice the hose and that finally started producing reasonable water flow.

To do this:

  • Lay the tube flat, letting it naturally coil so you are working with the existing coil.
  • Using a sharpie, run a line along the top of the tube for the length of it so you are cutting only the bottom (I don’t want water shooting up, just down).
  • Make another mark on the hose indicating where the cuts need to stop – beyond that point, the hose goes down into the pump.
  • Now that the hose is marked, use a razor to slice the hose perpendicular to its length.
  • I made each cut a little less than 1/2 the diameter of the hose.
  • I separated the cuts by about 1/4″.

After you do this, you should find the water only shoots down toward the pad and there is enough flow thru the slits to keep the pad moist.

BTW, I am generally seeing a 10 degree temp difference with my cooler. I expect to field test it next week.

Posted in c-Misc | Tagged , | Leave a comment

Forcing Accelerator Key Labels ALWAYS ON in Linux Mate

Need to file this one away for future use.

In Linux Mint / Mate, the underscores for accelerators keys is only on when you hold down ALT. I invariably forget this because they aren’t obvious, and don’t make use of them which slows me down. I *hate* having to use the mouse.

Tonight I went looking to see if they could be forced to stay on.

The few instructions I’ve found tell you to set the gnome setting “automatic-mnemomics” to false. I tried that repeatedly w/ no luck.

Eureka! I am using MATE not gnome. Doh! went looking in the Mate section of dconf settings and found the exact same setting. Set that to false and now underscores are always on.

Note: install dconf-editor. This is much easier than using gsettings and typing everything by hand.

The specific tree to this setting is:

org.mate.desktop.interface automatic-mnemonics

Posted in c-Misc | Tagged | Leave a comment

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 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:

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:

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

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

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 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"
  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"
  sleep 30

don’t forget to make them executable:

chmod 577 sshRevTunSsh sshRevTunVnc

These scripts will connect to localRPI by routing to the localFW ( 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 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 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 remote RPI’s public key to the local RPI

scp -P 27045

On the local RPI, you want to append that key (in the file temp.key) to the authorized_keys file:

cd ~/.ssh
cat temp.key >> authorized_keys

Rerun the scripts and they will no longer require passwords.

Dealing with IP Address / Key Changes

Since originally writing this, I’ve had to deal with changing the local RPI host. SSH knows the host has changed which causes a message along the lines of

Someone could be eavesdropping on you right now (man-in-the-middle attack)!

To fix this problem, you need to use ssh-keygen to reset the key:

ssh-keygen -R <ipaddress>

Because a non standard port is being used, it appears you must specify that as well for this specific type of access, so specify that as

ssh-keygen -R [<dnsname>]:<port>

Once the old key is deleted, follow the procedure above to regen and redistribute keys.

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:

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, 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 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.

Oct 2017 Update

I have three RPIs that maintain a reverse SSH tunnel as outlined, but they have driven me crazy because if the local firewall router is rebooted, the tunnel is not re-established and I have to do back flips trying to restart the tunnels (either have the user reboot the RPI which is risky since they can only remove/reapply power OR use dataplicity).

I finally had time to work on this issue and I believe I have solved the problem. There is a utility called autossh that will monitor the tunnels and restart them if they go down. I would think the keep-alives would do that, but they don’t.

Install autossh. Then in your startup script, use:

autossh -M 0 <user>@<dnsName> -p <sshPort> -N -R <inputPort>:localhost:<outputPort> \
 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 \
 -o ServerAliveCountMax=2

Using my example above, this would be setup as:

autossh -M 0 -p 27045 -N -R 27046:localhost:22 \
 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 \
 -o ServerAliveCountMax=2

So far, this has worked without problem.

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