getting rid of teamviewer and its awful restrictions

I’ve been using Teamviewer for years now to remotely pilot my half-dozen or so Windows boxes that are at remote sites, mountaintops, and other places where I want to do radio monitoring, control amateur radio links, run weather stations, whatever.

About 18 months ago I started getting a regular amount of “COMMERCIAL ACTIVITY SUSPECTED” notices when I’d connect to one of my sites. Repeated missives to Teamviewer would sometimes get me back my connectivity, but it’d be just a few months before I’d be a suspect again.

Now, with my starting to really take advantage of Raspberry Pis everywhere, I’m planning on building out a VPN system where the router at home will be the server and the RPis in the field will be clients. I’m sure I can get this to work, but I don’t know (yet) too much about the intricacies (or even basics) of VPN connections.

I started working on this idea this past week but with the failure once again of the Windows box on White Tank and the subsequent loss of monitoring audio, replacing that became the higher priority. Now that that RPi is installed and working, it’s time to turn back to the VPN thing.

Should be cool and allow me to have all my remote radios on a private network that’s an extension of my home net.

More soon.


Hopefully you’ve been able to get darkice running and throwing your favorite railroad voice radio channel to

In terms of how much overhead it costs to run darkice, at least on this RPi2B it’s about 12% on average. I also have gpsd running on the RPi so that I can get good time no matter what’s going on with the network connection. This is not necessary by any means, but for me it’s exercise.

I’m using for the scanner radio an old RS PRO2052 scanner (Figure 1). I have a number of them in various stages of decay, but they were a bargain way back when they were liquidating them. These have a serial port connection that, if configured and queried properly, will give the radio frequency/scanner memory channel that the scanner is on at that moment; it’d be cool if I got the tap working so that I could send a tag to railroadradio telling the listeners what freq the radio is stopped on during a transmission.

Figure 1 – PRO-2052 Scanner, pressed into service

Tomorrow I’ll take this RPi up to the radio site atop the White Tank Mountains west of PHX and swap out the Windows box, hopefully ridding me forever of the need to care and feed a Windows box on that remote site.

Check into the UP/BNSF Phoenix-area feed sometime soon!


The code below is the contents of the darkice.service file. Once you’ve created this file (it didn’t exist before you do this), you’re that much closer to having a darkice auto-run system.

#supposed to prevent darkice.service from starting before network is up and running

ExecStart=/usr/bin/darkice -c darkice1.cfg
#need the -c since config file is not where exec file is, note the darkice#.cfg

#this is where the darkice config file resides, i suppose it could be anywhere, like /home/pi

#I’m not sure how or if this works, but need to figure that out
#necessary because default is 100ms, and something makes it fail if not stretched out
#not sure this is necessary but belt-and-suspenders, doncha know.
#default user


Save the above file contents as darkice.service. Then move this file to the folder /etc/systemd/system with

sudo mv /etc/darkice.service /etc/systemd/system/

Now, run the command

sudo systemctl enable darkice.service

Once you’re done with that, it’s time to reboot.

sudo reboot

At least on my RPi, it takes about 23 seconds from boot to the point it connects to PDC.

Auto-start darkice on raspberry pi

I just built a brand-new out of the package sdcard using the instructions I posted earlier, and except for some fat-fingering, it all worked.

Now it’s time to mess with systemd and get it to auto-start darkice when the RPi is rebooted or after power’s been reapplied after an outage.

This site is your friend for this work. Read it repeatedly.

We want the RPi upon power-up to auto-start darkice. If we can get that to work, then even when your 3-hour-drive remote monitoring site dies from lack of power, when and if the power returns darkice will come up again, and attempt to connect to

darkice is pretty simple, at least in terms of the basics. Invoking “darkice” at the command line is easy – but darkice needs to know where the darkice.cfg file is. As you may remember, in the last post I’d left the modified darkice.cfg file in the /etc folder, which is fine for me. The full command, to invoke darkice, is “darkice -c /etc/darkice1.cfg”.

Easy peasy, right? (Apologies to Richard Small for stealing his line)

I found it much harder to get systemd (not local.rc, or some script workaround) to invoke darkice reliably. And that’s because “that’s supposed to be the way it’s done in ‘modern’ Raspbian, so it seemed high time to learn it.

I want darkice to run as a system service, so the command line doesn’t get locked up running one app. I studied other xxx.service files on the web, and figured out what might be needed here. And here is it!

Make sure the following file is saved in /etc/systemd/system as darkice.service

When it’s saved there, you’ll need to remind systemd that it’s there, so next do

sudo systemctl enable darkice.service

While I don’t really know what this is doing, I imagine it’s setting a flag in systemd, or something more complicated, that lets systemd know that darkice.service is there and that it’s part of systemd.

Here’s the actual file contents for darkice.service

Having some technical difficulties, please stand by!

railroad radio audio streamer on raspberry pi

While a lot of people use Broadcastify or RadioReference for their audio streams, I’ve had a couple of streams on (or not on) for a long time. Sadly, all these streams originate from remotely located WIndows boxes, running the fantastic RadioFeed streaming client.

Why sadly? Because Windows boxes at remote sites (like 3 hours-drive time away) are troublesome. I don’t need 99% of what Windows brings, and it pulls a lot of electric power just to run a simple app.

I have been employing Raspberry Pis for so many of my interests, and learning more about *nix than I’d ever known (or thought I’d want to know). What I’ve found is a wonderful, powerful language, capable of making incredible things happen. The depth of knowledge that’s in *nix today is as rich as any modern spoken language; there’s so much to learn that digging into any one command shows the tens/hundreds/thousands of *nix engineers, developers, and hackers who each spent countless hours making this language (and its variants) become the basis of modern technology.

Enough of the praise. (But it’s f*’king cool, and I constantly feel like I get a dullard’s glimpse into the minds and personalities of engineers, computer scientists, and old-school hackers back in the 60’s who started all of this.)

First, shout-outs to Martin Higgins and to Jim Groenke. I don’t know Martin, and he don’t know me, but his post started me on this journey. Oh, and to Ray Lewis, a serviceman at Luke AFB nearby who has been extremely generous with cash donations to me to get and keep the White Tank monitoring site going. It’s nice to know somebody’s enjoying the data!

Alrighty. How to install and get streaming device running on an RPi. This is not for the faint-of-heart. It’s a good idea to know a bit about RPis and Raspbian, or to have Google at your side, their evil dark heart notwithstanding. Take your meds before starting.

  1. Start with a fresh RPi. I have RPi 3B+ and 3B units, but for this one I happened to find an unused RPi2B, which I was about to turn into a VPN server, so I don’t know (yet) whether there’s any difference between the different hardware platforms for this little project.
  2. Download the most recent Raspbian image; for this project I used the desktop version, but without all the apps. Burn that to an appropriate microSD card. Before undocking that sdcard, write a zero-length file called ssh to the root directory. Literally, create a file that has only a name “ssh”, no content, no suffix, nada. RPi will see that file and think you’ve enabled ssh already, so no need for monitors, keyboards, etc.
  3. Move the sdcard to the RPi, apply power, make sure you know the RPi local network by checking your router’s DHCP tables.
  4. I use PuTTY to talk CLI to the RPi. Do an ssh session to the RPi, at the network address derived from 3 above.
  5. Username and password, then you’re at command line in home/pi/ directory.
  6. If you haven’t yet, run passwd and create a good password, length 10 characters min, and use numbers, upper/lower case alphas, and a symbol or two. Yeah, it’s harder to remember, but once this thing goes remote, you don’t want it easily hijacked.
  7. Do run sudo apt-get update and sudo apt-get upgrade. Make sure you’re at the most current build.
  8. There’s several things needed to make the RPi into an audio streamer. A USB soundcard, setting up alsamixer, downloading, installing, and configuring darkice. Use this link for instructions: RadioReference Broadcastify Build. You’ll use Method 1, for me I stopped at “Enable the feed to start broadcasting at boot”, partially because I couldn’t get the subsequent instructions to work, but also as we’ll be modifying the .cfg file so that it works for Shoutcast, which is what RailroadRadio uses.

So, about now you should have an RPi running the most recent version of Raspbian (this build used Buster and updates/upgrades current to about 25 Aug 2019), a nifty USB sound card (my dongle cost $6), and might look vaguely like this one.

Figure 1 – Raspberry Pi 2B with USB sound card installed

It should behave like any old RPi, but until we get the darkice config updated, and make darkice a service that auto-starts when the RPi is rebooted (which can happen when the remote location loses power or the cat chews through the power cord), we’re not ready to stream!

The instructions in 9) above put the darkice1.cfg file in the /etc directory. That’s fine, but it can be somewhere else if you prefer.

Log in, go to the /etc directory, and sudo nano darkice1.cfg to open the file. One should see something vaguely like the following (which has already been modified):

# darkice configuration file
# Copy this configuration file to /etc/darkice#.cfg
duration = 0 # 0 means forever
bufferSecs = 10
reconnect = yes
# this can be used if darkice is the sole user of audio capture device:
# Import notes for the “device =” setting on this preconfigured image
# Most configurations with one additional USB sound card added will
# use “plughw:1,0” as the setting for the device.
# When adding 2 or more USB sound cards, your first USB sound card will
# start at plughw:0,0 and work it’s way up n+1 (hw:1,0 hw:2,0 hw:3,0 and so on
# If adding just a single USB sound card for a broadcast, simply use the following:
# device = plughw:1,0
# You can verify card and device numbers by running the arecord -l command

device = plughw:1,0 # hw:0,0 then hw:1,0 then hw:2,0 etc
sampleRate = 44100 # don’t know if there’s any value to changing this
bitsPerSample = 16 # again, i tinkered with this but only got silence or chipmunks
channel = 1 # 1 for mono, 2 for stereo

[shoutcast-0] # this is critical difference from the default .cfg file, which had “icecast0-1” here.

bitrateMode = cbr
format = mp3
bitrate = 24 # this is the one that defines the over-the-wire data rate, to me 16 sounds as good as 24
quality = 0.5 # don’t notice much difference between 0.1 and 0.9
channel = 1
lowpass = 4000 #important to get rid of the HF hiss, tried different values but 4000 sounds good

server = # Your Master Server Name
port = nnnn # whatever inbound port (1 less than the public connect port) has been assigned at railroad radio for the stream
password = yourfeedpwhere # Your Feed Password
name = YourFeedName # Your Feed Name
url =
# URL related to the stream
genre = Rail Scanner # genre of the stream
public = no # advertise this stream?
irc = # IRC info related to the stream
aim = # AIM info related to the stream
icq = # ICQ info related to the stream

You should notice that there are many similarities, but a few significant differences, between the default Broadcastify darkice.cfg file and this one. RailroadRadio demands either 16 or 24 kbps bitrate, even though to my deaf ears 8 kbps sounds acceptable.

Before you modify the .cfg file, save a backup by

sudo cp darkice1.cfg darkice1.cfg.bak

Now, you’ve got the original in case something really gets messed up. Once you’ve edited darkice1.cfg file to have the parameters above, save it. And assuming you already had a RailroadRadio stream port and password assigned, and entered that in the config file, and have a sound source attached to the USB sound card dongle, typing

sudo darkice -c /etc/darkice1.cfg

should get you connected and streaming to the server and you should shortly hear your audio stream coming back at you. Now’s a good time to take a break and savor the success…

Next, I’ll describe how to get systemd to make darkice auto-start on power-up.

BTW, here’s another site that has a pretty nice darkice.cfg file for your perusal, complete with some references to both icecast and shoutcast.

WarPig 1.0

I do a lot of wardriving for fun. I’m currently using Vistumbler on a Windows PC in my truck, or on the work PC. I have a DIY Wi-Fi / GPS dongle that I built a few years ago. At, i have contributed over 4.4 M APs.

The challenge is that, especially traveling for business, I don’t like to have to drag the PC along with me everywhere. This past week, in LA, I decided to look at building a new rig from an RPi to scan networks and make files readable to WiFiDB. I was originally thinking a script using iwlist and some gps calls, but then got derailed by the magic of kismet. This is that story.

I began here with the info from expecting to build a warpi box. However, i ended up using a stock distro build of kismet instead.

I call it WarPig 1.0 since it gobbles up storage like a pig, and the structure is likely a mess.

This RPi3B+ uses a USB GPS that cost me about $6 from eBay, and is currently using just a Ralink RT5370 Wi-Fi dongle because that worked. I’m ordering an Alfa dual-band device or maybe a pair, and when I get those I hope to expand the amount of frequency space I can monitor concurrently. I chose not to use the on-board Wi-Fi since it apparently needs a hack to put it into monitor mode, and this effort was yet another thing to do. Also, the on-board Wi-Fi doesn’t appear to allow an external antenna.

Start with new imaged SD card with Raspian buster with desktop but no apps

Through the raspi-config tool, give it a unique hostname, enabled SSH and VNC access

sudo apt-get update
sudo apt-get upgrade

Set eth0 fixed IP address, you can change this as required for your own situation.

sudo nano /etc/dhcpcd.conf

# Example static IP configuration: interface eth0
static ip_address=
static routers=
static domain_name_servers=

now modify /boot/config.txt to allow USB ports to output maximum current

add new line to the end of the file


sudo apt-get install gpsd gpsd-clients python-gps

get rid of some old files that are no longer needed

sudo apt autoremove

Now, prevent systemd from running its own gpsd incantations.

sudo systemctl stop gpsd.socket
sudo systemctl disable gpsd.socket
sudo gpsd /dev/ttyAMA0 -F /var/run/gpsd.sock
sudo reboot

You may ask why all the reboots, they’re partially for caution to make sure I haven’t fatally corrupted something along the way. And believe me, I spent a good fraction of the day reflashing the SD card after corrupting something.

The following works on buster for a USB GPS device:
sudo /etc/default/gpsd
Add to gpsd the following:

sudo dpkg-reconfigure gpsd

sudo reboot

The following came from the teambsf link, maybe there’s a different way to do this, but this seems to work fine.

sudo nano GPSTimeUpdate

#extracts time from GPS
GPSLINE=`gpspipe -w | head -10 | grep TPV | head -1`
#pull date and time from valid TPV line
GPSDATE=`echo $GPSLINE | sed -r ‘s/.*”time”:”([^”]*).*/\1/’`
#set system time to GPS time
date -s “$GPSDATE”

sudo chmod +x GPSTimeUpdate

sudo cp GPSTimeUpdate /usr/bin/.

sudo reboot

More from the teambsf group, this to make sure GPSTimeSet starts at boot.

sudo nano /etc/rc.local

#!/bin/sh -e #
# rc.local
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will “exit 0” on success or any other
# value on error.
# In order to enable or disable this script just change the execution
# bits.
# By default this script does nothing.
# Print the IP address
_IP=$(hostname -I) || true
if [ “$_IP” ]; then
printf “My IP address is %s\n” “$_IP”


exit 0

And as always, do a sudo reboot

Set up a usb drive permanently for kismet log storage. I’m concerned about the thrashing to the RPi’s SDcard. In fact, this is just the beginning of an effort to eliminate all writes to the SDcard.

Insert a fresh USB thumb drive

ls -l /dev/disk/by-uuid/ gets the lists all connected drives, including the USB thumb drive.

sudo mkdir /media/usb-drive make a mount point

sudo chown -R pi:pi /media/usb-drive so that pi has access to this folder.

Make the drive an auto-mount at boot

sudo nano /etc/fstab

UUID=18A9-9943 /media/usb vfat auto,nofail,noatime,users,rw,uid=pi,gid=pi 0 0

put the UUID found from the ls command before. This appears to limit my ability to use any old USB thumb drive, dunno yet.

Install kismet from distro, I tried to compile it locally per the teambsf instructions, while it worked, it didn’t seem to be worth the extra effort.

Add some configuration details to kismet

in /etc/kismet/kismet.conf insert (or uncomment)

cd /usr/local/etc sudo nano kismet.conf

sudo mkdir /home/pi/kismet

sudo chmod 777 /home/pi/kismet

cd /etc/init.d

have not yet implemented the below, which is from teambsf and is a way to auto-start kismet on boot. I don’t want this quite yet.

sudo nano kismet

#!/bin/sh #
# Provides:              kismet
# Required-Start:     $all
# Required-Stop:     $local_fs $remote_fs $syslog $network
# Default-Start:         3 4 5
# Default-Stop:         0 1 6
# Short-Description:     Start kismet at boot time
# Description:         Starts kismet at boot time
case “$1” in
start) echo “Starting kismet”
/bin/sleep 30
/usr/local/bin/kismet_server –daemonize
echo “Stopping kismet”
killall kismet_server
echo “Usage: /etc/init.d/kismet start|stop”
exit 1

exit 0

sudo chmod +x kismet

Best way to start kismet at CLI

kismet_server >/dev/null 2>&1

starts kismet server and sends all output to dev/null

sudo update-rc.d kismet defaults


APRS Telemetry Watcher is a simple, slick interface that connects (in my case) via a network connection to an RPi in my shack running dire wolf APRS software. APRS-TW looks for telemetry packets, then displays them in a nice graphical format.

Figure 1 – APRS-TW GUI showing two of my APRS stations’ telemetry values

It’s a simple piece of software, runs in a Windows environment, and the individual telemetry values, names, units, etc., can all be filled in the GUI so that the data that appears is already in engineering units. (i.e., instead of a telemetry value of “491”, it’s actually 12.73 Vdc.

This is handy. Is a nice complement to

how not to be seen

With apologies to Monty Python.

While I’m not Mr. B. J. Smegma, I want to build another Desert Machine that I can place somewhere in the local desert.

Ok, so what’s a Desert Machine?

A long time ago, the original Desert Machine was conceived of, designed, built, tested, and placed out in the Mojave Desert by a group of us, some place in the Mid Hills / New York mountains area, next to an abandoned mine.

A simple box, consisting of a crystal-controlled 40-m transmitter producing maybe 1 W, connected to a “found” abandoned phone line wire strung along multiple decayed telephone poles, aligned in a row more or less allowing the transmitter to feed the NE end of the wire and the SW end of the wire pointing toward LA. A really simple telemetry circuit made of a pair of 555 timers, with one using a thermistor in the timing RC circuit, created a device that would wake up every ~30 minutes, send 10 dahs at a 5 wpm (or so) rate, and then return to sleep.

The timing between the dahs was based upon the ambient temperature; a little math at the receiving end would allow us monitoring the channel (something like 7043.0 MHz) to calculate the temperature at the box. It was loads of fun. Of course, this is completely against Part 97 rules, no ID, no person at the controls, etc., but it was super-cool to be able to tune in on the frequency back in LA, and if conditions were decent, be able to hear the transmission.

It turned out to be about 27 minutes between transmissions, and that drifted slowly over temperature. The crystal transmitter didn’t control the frequency too well; each dah was more of a doo-weep as the transmit frequency shifted a hundred Hz or so during the dah.

The whole thing was powered from a pair of 6 V lantern batteries (the carbon-zinc kind) and housed in some kind of plastic box that was reasonably closed.

Most surprisingly, the whole shebang lasted for about 6 months, growing steadily fainter and chirping worse and worse, until it was no longer hearable.

The device, in a pretty remote and obscure location, was not tampered with. The device was recovered eventually. Some kind of field mouse had built a home inside one of the compartments. The wire was left in place.

Now, how to do something similar but using a solar panel so that the battery lifetime issue is minimized?

Mysterious GPSD

I’ve followed a number of different directions, and each time I get results that differ. However, in the past 24 hours I’ve been using an ntp.conf file that I found here. This one has proved more reliable than the one that I got from’s site. There’s little difference that I can see, but something made enough difference that I’ve been able to let the box reboot (pull power, or sudo reboot) several times and each time it comes back up properly. gpsd, ntpd, dire wolf, and the HP ADDC all start running orderly and without mysteriosities.

I did discover that the fudge value for ntp seemed to be important – the link above used a time fudge of 0.5 seconds, and it was not reliably syncing on that. I moved time fudge to 0.3 seconds, and suddenly reliable. So I figure the offset between the GPS reported time and the pps from the GPS was tighter than the author at the above link was using (he was at 4800 baud, my GPS is at 9600 baud). I tried a time fudge of 0.0 and that seemed to work, but not all the time.

Figure 1 – ntpq -pn output showing ntp using my local GPS pps (“little o” at the beginning of the line)

Figure 2 is the results of the top command for the setup running all those processes.

Figure 2 – top command output

The unit is an RPiB3+, with USB sound card, GPS wired in on serial0, and the High-Precision AD/DA board as a hat. 15% CPU usage is pretty decent. dire wolf is definitely the most power hungry. I still haven’t connected a transceiver to this, so I’m just processing inbound received packets from a scanner’s audio output.

I have a Baofeng UV5 transceiver, and just liberated the mic cable from one of the $5 speaker-mics available on Amazon, so I’ll breadboard up a PTT interface now. The important thing with the PPT is that the RPi is 3.3 V logic level, and I need to pull down the Baofeng PTT line. I will use a 2N3904 NPN transistor as an open collector switch to do the job. I’ve also ordered some CMOS 555 timers in order to build a PTT timeout circuit, so that if the RPi hangs for some reason the radio won’t transmit indefinitely. Maybe 2 seconds for a PTT timeout?