A confluence of things helped me to finally make a decision:

• I had been using Single Board Computers (SBC) for small projects and utilities, and have watched these small affordable devices grow in capability with excitement.
• HardKernel was offering a case for its relatively powerful Odroid XU4 SBC that accepted two 3.5” drives along with a hardware RAID controller.
• A realization that folks were using Docker, and production server strategies used on the web for years, to build up their home server software solutions.
• Growing frustration, disenchantment, and general mistrust of mainstream cloud service providers motivated me to dive in and try something.

The XU4 CloudShell2 solution is small and affordable, a perfect platform to experiment and try things without a huge upfront investment. I felt that even if I quickly found myself wanting to upgrade, the experienced gained from running this little box would help me better understand my needs.

I’d like to detail some of the setup along with a few tweaks that improved my experience with this device. Hopefully this will provide a bit more information to anyone considering the CloudShell2, and perhaps some guidance to those who may be setting up their own.

Cost

For those interested, below is an itemization of my costs. These components were purchsed in the Spring of 2019, and prices will of course fluctuate (and I imagine reduce) over time. Links to the products are omitted over concern that they will eventually become invalid, but at the time of this writing they should be relatively easy to find.

                          |          |                          |__Total:__|__$351.80__

Of course this setup could be considerably cheaper if you went with some smaller drives or if you have some spares lying around. Drive cost aside, things come in at a very reasonable $150.

Comparatively you can purchase a driveless Synology DiskStation DS218+ 2 bay NAS for just shy of $300. Adding the cost of a couple 4TB drives and you’re looking at about $500. Granted this is a bit of an apples to oranges comparison, but I think it’s worth looking at something a least somewhat analogous in the consumer “plug and play” space.

Initial Setup

Generally I followed the easy install guide with only a couple of changes. Most notably, I didn’t bother with the IR sensor configuration, and I didn’t install the cloudshell-lcd package in favor of something more custom.

Assembly

Assembly is fairly straightforward when following the assembly guide. The only tool required is a phillips head screwdriver. Go slow and don’t try to force any of the acryllic fittings. They should slide together easily and you may break tabs if you use too much force (I broke two).

Drive Setup

After dialing in the RAID controller you will need to make some decisions about drive partitioning, file system type, and mounting location. Everyone will have their own preferences on this configuration, but I settled on RAID 1 formatted with an ext4 filesystem with only 1 partition mounted at /mnt/storage.

I am planning on managing everthing on this system with Docker, leaning on a docker-compose file that lives on the emmc (and backed up in a private repo). The thinking is that all volumes defined in Docker will be housed on the /mnt/storage RAID drive, and nothing else. This simplifies offsite backups and recovery. A backup script can run across the whole drive knowing that it will only be getting relevant data and no OS cruft. Further, if the RAID drive fails and needs replacement, new drives can be swapped in, formatted, and mounted. Afterward a simple docker-compose up command will build a fresh setup, or offiste backups can be restored, and Docker will chug along like nothing happened.

nmon on the LCD

CloudShell2 comes with a small (320x240) LCD screen attached. If you follow the Quick Setup guide from HardKernel it will be enabled with a simple script displaying some hardware stats. This is okay, but I’m much more interested in being able to see activity at a glance. Dave Burkhardt’s excellent work modifying nmon for the CloudShell display fits the bill nicely. Installation is straight forward, and it is well detailed in the project readme.

By default the script will show network activity, which when using Docker becomes a bit useless due to clutter. Mostly I want to see CPU and drive activity, so I’ve modified the nmon options in nmon-xu4 as follows:

export NMON=xtfcdG

These options will show CPU activity, drive activity, and a short top list of processes.

Fan Upgrade

The fan that ships with the Cloudshell kit is adequate but noisy. I don’t think this would be much of a problem if you are keeping the Cloudshell in a closet, or a good distance from you. However, I have it sitting on my desk and the fan noise began to slowly erode my sanity. Time for an upgrade! The kit takes a 92mm 5V 3-Pin fan and there are plenty of high quality quiet fan options out there that fit this spec. I settled on a Noctua NF-A9 and it has been a huge improvement.

Docker

There is a lot of documentation on the web about using Docker, and it is a bit out of scope for this document to detail its use. It has been a good experience managing things with Docker Compose and I can recommend doing so. There are a couple of XU4/ARM related issues I ran across while getting things installed that are worth mentioning:

Installing Docker

Installing Docker via apt on ARM does not seem possible at this time, resulting in the following error:

E: Package 'docker-ce' has no installation candidate

However using the Docker installation script from get.docker.com works just fine.

apt install curl
curl -fsSL get.docker.com -o get-docker.sh
sh get-docker.sh

Once the script has finished be sure to add your user to the Docker group.

usermod -aG docker <username>

Docker Compose Installation

Presently there is not a binary release for ARM64. It appears there is movement to get this into the official builds, so this may not be necessary in the near future. For now however, you can install via pip.

apt install python-pip libffi-dev
pip install docker-compose

Portainer

While I don’t wish to detail all of the containers/applications I have running, I feel that Portainer is worth mentioning. Portainer provides a nice web GUI where you can quickly see the status of all of your containers, volumes, networks, etc. Further, you can perform actions on them like restarting a container. I’ve found this very useful to quickly troubleshoot things without having to shell into the box to see what’s going on.

Traefik with Pi-hole DNS

Another very common application used in a docker setup is the traefik reverse proxy. While I have no intention of exposing this NAS to the greater web, I do want to be able to access the various applications using human friendly domain names. Thankfully my local network has a box running pi-hole for LAN-wide ad blocking. Pi-hole uses dnsmasq, and if you use pi-hole on your network you can set a config file to tell dnsmasq to wildcard a domain suffix. For instance on the box running pi-hole you can create a conf file in /etc/dnsmasq.d/, lets call it 02-nas.conf, and the file should contain the line:

# Wildcarding for domains to the NAS

address=/.nas/192.168.xxx.xxx

Where 192.168.xxx.xxx is the local ip of your NAS, then restart the dnsmasq service.

pihole restartdns

What this configuration does is direct dnsmasq to point everything on the LAN requesting a domain with the .nas suffix to the NAS. Now on the traefik side we can use .nas domains for our containers. For instance we could add this label for Portainer in our Docker Compose file:

labels:
  - "traefik.frontend.rule=Host:portainer.nas"

Now if you navigate to portainer.nas in a browser on a machine on the LAN, you will be presented with the Portainer application! I’ve found this to be incredibly handy, especially as the number of applications with a web interface I have on the NAS increases.

Impressions

As of this posting I have been using this setup for just over a year, and I am very pleased with it. The system itself is on 24/7 and has been very stable. Setting things up with Docker has also proven to be quite useful. It’s easy to spin up and try out new applications, conversly its equally trivial to completely remove applications I am no longer iterested in. This has made for an excellent self-hosted test bed.

It has been interesting to see what the stand out applications for me are. There are three I actively use every day, Nextcloud, Miniflux RSS reader, and ZNC IRC bouncer. I have my phone syncing images, contacts, and calendars with NextCloud and this feature alone has become indispensable for me. Since the demise of Google Reader I had been using Feedly to handle all of my RSS subscriptions. Happily, importing an opml file containing my subscriptions and tags from Feedly was simple. I was able to seamlessly begin using miniflux, and I haven’t looked back. Lastly, I went down a small rabbit hole after getting frustrated having multiple chat windows open to converse with people across various chat platforms (hangouts, slack, discord, irc). I wound up being able to let ZNC not only stay logged into IRC, but through the use of BitlBee, all of my other chat accounts as well. This means all of my chats can be consolidated into one IRC client connecting to my self-hosted ZNC instance.

This setup has also been useful in exploring new projects and experimentation. For instance, I’ve been working on local first/only home automation. Running node-red, Telegraf/InfluxDB, Grafana, and HomeAssistant has worked out very well in this box, and so far has proven to be an excellent ‘hub’ communicating to other SBCs running these automation projects.

The question that always seems to come up when I talk about this device is about performance. While I have not run any serious performance tests, for my somewhat modest needs, it has been more than adequate. The only place I’ve noticed any lag is when viewing very large NextCloud galleries, which I believe is more of a software issue. I have not setup something like Plex, Emby, or Jellyfin (though I have been considering it), so I cannot speak to the application performance there.

Overall the XU4 CloudShell2 has proven to be a capable little home server, especially for the price. I’ve learned a lot during its setup and use, and it has comfortably become a part of my daily workflow. If I were to do it all again I think I may attempt a cluster of ARM devices much like Nikhil Jha has detailed. This is not because I’m in any way disappointed with this device, but rather you can build up to a very robust machine one piece at a time. However, I am in no hurry to move off the XU4 CloudShell2, and I fully expect it to continue serving my needs for the forseeable future.

Resources

• The official Odroid Cloudshell-2 wiki.
• Dave Burkhardt’s excellent modifications to nmon for the xu4 and CloudShell LCD.
• Nikhil Jha’s blog post about self-hosting on an ARM cluster.
• A great self-hosting rundown from s-ol using Docker and some cool automatic deployment with git.
• Awesome-Selfhosted is a curated list of applications and services that can be hosted locally.
• The Self-Hosted Podcast is a fantastic source of ideas and inspiration.

After running the program on my own Commodor 64 and reading through what documentation there is, it became clear, like most things, that defMON would take practice, exploration, and experimentation to really grasp its capabilities. Unfortunately my home lab is small and cluttered, and leaving a Commodore 64 setup would take up a lot of precious space. However, a Commodore can be emulated, and a portable device with a keyboard like the Pocket CHIP would make for a handy way to practice defMON (and use the Commodore in general) without being tethered to a desk.

This post details the process I went through to setup and configure VICE (the VersatIle Commodore Emulator) on the Pocket CHIP to run defMON. While my end goal here is to be able to run defMON from the homepage launcher of the Pocket CHIP, you can follow this setup process (ignoring the defMON stuff) to have a working Commodore emulator. This will allow you to run any number of games, applications, or wild demo packages on the Pocket CHIP.

Vice Installation

VICE is available in the APT repositories, so you can install it via the package manager from Pocket CHIP’s command line.

sudo apt install vice

This package does not install the Commodore 64 system ROM due to copyright concerns (I think) and will not run correctly without it. To add the system ROM after running the apt installation, you need to download the full VICE install from http://www.zimmers.net/anonftp/pub/cbm/crossplatform/emulators/VICE/vice-3.3.tar.gz, unpack it, and copy the contents of its data/C64/ folder to /usr/lib/vice/C64/. I like working in a ~/src/ folder for stuff like this, but you can of course download this to wherever you want.

# Create a directory to work from
mkdir -p ~/src/c64/vice
cd ~/src/c64/vice

# Download and extract the ROM
wget http://www.zimmers.net/anonftp/pub/cbm/crossplatform/emulators/VICE/vice-3.3.tar.gz
tar -vzxf vice-3.3.tar.gz

# Copy the C64 system ROM
sudo cp -rv vice-3.3/data/C64/* /usr/lib/vice/C64/

You can now verify that this was all installed correctly by running the x64 command. Things will look a bit crazy on this initial run, but as long as you see the blue Commodore 64 ‘Ready’ screen (be patient it takes a few seconds), you have successfully installed VICE along with the Commodore 64 system ROM. You can exit VICE by pressing alt+q.

VICE Configuration

So VICE is installed but looking pretty broken. The emulator will be more or less unusable on the Pocket CHIP until you make some adjustments to the VICE configuration. All of these adjustments will be under the “Settings” menu, which is difficult to navigate to with the touch screen. I’ve found the best way to do this is to touch the top left corner above “File” and then use the arrow keys to navigate to the “Settings” menu. If you don’t see the top menu bar, you can press alt+b to toggle its visibility. If you would rather not mess with walking through the menu, and just want to use the configuration I’m using at this time, you can replace your vice configuration file at ~/.vice/vicerc with my configuration file.

cd ~/src/c64/vice

# Download, rename, and replace the config file
wget https://electro.pizza/2019/07/defmon-vice-chip/vicerc.txt
cp vicerc.txt ~/.vice/vicerc

I am still experimenting with some of the VICE configuration options, but so far the settings I’ve found that work best for the Pocket Chip and for defMON specifically, are as follows:

Settings > VIC-II settings

• Disable “Hardware scaling” (required)
• Disable “Double size” (required)
• Set “Render Filter” to “Unfiltered”
• Set “Enable fullscreen” in “Fullscreen settings” (or press alt+d)

Settings > Sound settings

• Set “Sound device name” to “alsa” (required)
• Set “Output mode” to “Stereo”
• Decrease “Sample Rate” to “22050Hz”
  (playback seems smoothest at this rate, though this could probably be tweaked)
• Ensure “Enable sound playback” is enabled

Settings > Drive settings

• Disable “Drive sound emulation”

Be sure to Save your settings before exiting.

A note on the keyboard:

By default VICE uses symbolic keybindings, and I’ve found that for the most part it is intuitive to use. However, there are a few keys that are special to the Commodore 64 keyboard with symbolic mappings that are not obvious. Most notably:

There is more information about VICE’s keyboard emulation and the VICE emulator in general in their very comprehensive user manual.

defMON

You can grab the latest defMON release from the defMON wiki. Once again this is probably best done from the Pocket CHIP command line.

Double check the defMON wiki for the latest version. You may need to change the filename in the following command to get the newest version.

mkdir ~/src/c64/defmon
cd ~/src/c64/defmon

# Download and extract defMON
wget http://toolsforscholars.com/defmon/lib/exe/fetch.php?media=download:defmon-20181101.zip
unzip defmon-20181101.zip

While you can select a ROM from the VICE GUI, I’ve found it more convenient to directly point at the ROM when executing the x64 command. So to run defMON:

x64 ~/src/c64/defmon/defmon-20181101.d64

Pocket Chip Homepage Launcher

Background Image: @mr.melville

Since I am wanting to practice with defMON somewhat regularly, I’d like to add an item to the homepage launcher to quickly fire up the program. If you are unfamiliar with customizing the launcher, you can do so by editing the /usr/share/pocket-home/config.json file. Simply replace one of the entries in the JSON file with a title, icon, and the command you wish to run.

{
  "name": "defMON",
  "icon": "appIcons/musicsequencer.png",
  "shell": "x64 /home/chip/src/c64/imgs/defmon-20181101.d64"
}

Of course, if you’d rather just run VICE without autorunning defMON you could replace the above shell command with x64.

Thoughts on Usage

Generally defMON runs well with this setup, but there are definitely some drawbacks.

Overall the sound is good, but not as good as running this on an actual SID chip (that’s to be expected). I’ve noticed the audio hiccuping sometimes when running more complex tracks. This hiccuping could potentially be resolved with further adjustments to the VICE settings, but as it is, it’s not too bad.

The keyboard has proven to be pretty awkward. defMON’s key commands make a lot of sense on a Commodore 64, but not so much when they are mapped to a modern keyboard layout. This, coupled with how awkward the Pocket CHIP’s keyboard already is, makes certain tasks feel clumsy. Therefore, I can’t recommend using this setup for any kind of live performance, or for any long term in-depth work. However, it is an excellent way to get more familiar with how to use defMON, and is proving especially useful in experimenting with and constructing instruments and effects in the SID tab.

Stepping back from defMON, VICE runs well on the Pocket CHIP. Most games don’t rely as heavily on the Commodore’s special keys, making the keyboard inconveniences less of an issue. The few games I have tried are responsive with smooth gameplay. This setup has also proven to be a fun way to quickly check out various demo scene creations.

Likely, one of the first things a radio hobbiest will want to do with this device is hook up an antenna, fire up Gqrx, and tune around. Recently I attempted just this, but had some issues getting things setup on an Arch Linux box. It wound up being a bit of a rabbit hole, so it’s worth a note on how I got this setup up and working.

As Github user alexf91 writes in a related gitub issue, the source of the problem is that the “stable” release of gnuradio-osmosdr is nearly 5 years old and horribly out of date. This is the version referenced in the community/gnuradio-osmosdr package, and probably the version most folks will install by default. Thankfully, as alexf91 points out, you can compile a more recent version of gnuradio-osmosdr and then compile gqrx using this newer library, all via AUR.

Compile and Install Gqrx and Dependencies

The order of installation is important here so that the appropriate libraries are available during compilation of the subsequent packages.

If you’re using an AUR utility (pacaur, yay, etc) you can of course do this all in one command, however I find it useful to break bigger things up to make any problems more visible.

1. Install soapysdr and soapylms7-git

soapysdr can be found at community/soapysdr so can be installed via pacmam.

pacman -S soapysdr

soapylms7-git is in AUR.

pacaur -S soapylms7-git

2. Install gr-osmosdr-git and missing libbladerf-git dependency

If you already have the “stable” version of gqrx and gnuradio-osmosdr installed, you will first need to uninstall them.

Before installing gr-osmosdr-git (at the time of this writing) you will need to install the missing dependency libbladerf-git from AUR. If you previously had gnuradio-osmosdr installed, you may be asked if you wish to replace bladerf with libbladerf-git, which you should do. Now you can install gr-osmosdr-git from AUR. If you previously had gnuradio-osmosdr installed, you may be asked if you want to replace airspy with airspy-git, and again you should do this.

pacaur -S libbladerf-git gr-osmosdr-git

This will kick off gnuradio-osmosdr compiling and it may take a bit while it does so.

3. Finally install gqrx-git

gqrx-git can be found in AUR.

pacaur -S gqrx-git

This gets gqrx to compile, this time with all of our updated dependencies. Like the gnuradio-osmosdr compilation, it may take a while.

First Run and Initial Config

If you’ve run gqrx before you may need to remove or archive your old config file

rm ~/.config/gqrx/default.conf

or

mv ~/.config/gqrx/default.conf ~/.config/gqrx/default.conf.old

At this point you should be able to plug in the LimeSDR Mini and fire up Gqrx. Be sure its plugged into a USB 3.0 port for an optimal experience, and if you’re using a USB cable be sure it’s compatible with USB 3.0. (I was puzzling over why things were weird with my setup for far too long. It wound up being the cable.)

On the first run you will be confronted by the “Configure I/O devices” dialogue. In the device dropdown you will notice an entry for “LimeSDR Mini”. I have had no success in using this option, nor have others on the web as far as I can tell. What does work, however, is telling Gqrx to use Soapy with the lime driver. For that you will need to configure as follows:

• Set device to “Other…”.
• Device string should be driver=lime,soapy=0.
• Initially it may be good to set the bandwidth to 5.00 MHz just to have better visibility of what’s going on, but you should be able to go up to around 30.00 Mhz.
• Everything else should be good as is.

Note: I have occasionally noticed things being a little buggy with subsequent runs of Gqrx, in which case I delete the config file and run it again.

Now you should be in the main Gqrx screen. Before you kick off the DSP you will need to set which antenna to use on the device. Go into “input controls” and set “Antenna” to LNAW, and you’re good to go!

Well sure!

Ground Plane Antenna

An antenna upgrade seemed like the best place to start. The little telescoping dipole is great for roughly adjusting to a frequency you may be interested in. However, its always a bit of a guess at getting the length just right, and reception is mediocre overall. Since I’m only interested in one frequency (1090MHz for ADS-B), it makes sense to try and construct a purpose built antenna. I settled on a quarter wave ground plane antenna for the build, as folks report good results with it for ADS-B reception. Further, I had the the stuff needed to build one on hand. There are several other antenna options that could work quite well here and rtl-sdr.com has a great rundown of the commonly used ones. It’s also an excellent jumping off point if you want to setup your own ADS-B recieving station.

A quarter wave ground plane antenna is a type of monopole antenna with a single conductor element and several evenly spaced ground plane elements (in my case 4). Each of these elements are cut to 1/4 wavelength of your target frequency. For this antenna we’re wanting elements around 65mm to hopefully resonate well with our target 1090Mhz signal. However, when constructing a wire antenna like this, its a good idea to cut the leads slightly long, this way you can trim the length back to an exact measurement once the antenna is constructed.

In this construction I cut the elements from solid 22AWG copper wire and soldered them directly to a panel mount SMA jack. They were then trimmed them down to exact lengths.

A Note on Calculating Wavelength

So where did the 65mm element length come from?

To know what the wavelength is for a given radio frequency, you divide the speed of light (in meters per second) by that frequency (in Hz). For this project we’re shooting for 1090Mhz, that’s (3.0x10⁸m/s)/(1090x10⁶Hz). To make things simpler you can reduce this to (300/1090). That gives us .275m (275mm) for the full wavelength; since we are after 1/4 wavelength we divide by 4. So about 68mm.

Wait, what? Didn’t you say 65mm?

Well, yeah… it turns out it’s a bit more complicated. I’ll try to summarize to the best of my ability. (tl;dr in the blockquote below)

Electromagnetic waves travel at a constant velocity in free space (3.0x10⁸m/s). However, RF energy on an antenna has a slightly lower velocity. This is because the relative permittivity of the antenna material (sometimes called its dielectric constant) is greater than that of free space (or vacuum permittivity). Since we have this difference in velocity between RF energy in free space and RF energy on an antenna, the antenna’s physical length is no longer equal to its electrical length. In other words, if you were to cut an antenna element to have an electrical length of exactly 1/4 wavelength, the physical length of that antenna would be slightly shorter than 1/4 wavelength. How much shorter? Again it’s a bit complicated. A large number of things can affect the relative permittivity of an antenna, but the most notable for an antenna made of thin wire is stray capacitance, often called “end effect.” As a general rule of thumb we can say:

End effect for a typical dipole of wire that is thin compared to its length is counteracted by making the physical length about 5 percent shorter than the electrical length…
- Practical Antenna Handbook 5th Edition (105)

So taking 5% off the 68mm we calculated above will give us about 65mm. To apply this to our original calculation (and be a bit more precise), we can slow the speed of light by 5% (285/target freq in MHz) to give us the physical wavelength on the antenna.

So to belabor our example of 1090MHz:
(285/1090) gives us a 261mm wavelength, then dividing by 4 for the quarter wavelength gives us 65mm.

Of course there are many online “antenna length calculators” that will do the math for you, but where’s the fun in that?

Low Noise Amplifier

Around the time I was working on the antenna, I noticed a nice filtered LNA package specifically designed for ADS-B reception being offered at rtl-sdr.com. It offered targeted filtering for 1090Mhz, and amplification for the signal touting a 27dB boost. Reviews looked good and the price was reasonable so I purchsed one. An LNA should be positioned as close to the antenna as possible, and requires 3v - 5v power provided inline. Powering something directly through coax is typically accomplished using what is called a bias-t.

USB Powered Bias-T

A bias-t (or bias tee) is a circuit that injects a biased DC voltage in one direction on an RF line, but blocks that DC voltage in the other direction allowing only signal AC to pass through. Typically you put a bias-t directly on the coax between your radio and whatever you want to power (in our case an amplifier). The bias-t will provide power “up” the line to the amplifier, but no DC voltage will be allowed “down” the line to the radio where DC voltage is not welcome.

Many newer RTL-SDR dongles marketed to radio hobbyists come with a 5v bias-t power source built in. However, since I’m using an old generic SDR stick (originally only intended for TV reception) I have no such luxury. Of course RTL-SDR sticks are fairly inexpensive, so I considered purchasing a new one with a built in bias-t just for this purpose (and I likely will in the future). However, as I started reading more on how a bias-t works and solutions that others had come up with, I decided it might be a fun diversion to attempt to build my own.

There are two main components that allow a bias-t to work: a capacitor that allows AC to pass through but blocks DC, and an inductor that allows DC to pass through, but blocks AC. These components can be seen in the top 1/4 of the following schematic. All the remaining components are for DC smoothing, power indication, and the power source.

Component values are chosen based on a number of factors, most notably the target frequency (or frequency range) and the DC voltage being used. It is at this point that I extend a huge thanks to LNA4ALL. There you can find a fantastic writeup for a diy bias-t where he outlines a design for a “good enough” wideband bias-t using common component values. The above schematic is taken directly from that post, adding only a power indicator and a USB power source. It seemed handy to source the 5v from USB, as the SBC that the radio is on has several USB ports to spare, and the RF line was in close proximity.

After plugging in a USB cable and doing some sanity tests, the bias-t was working as expected. 5v DC was observed on the right side, no DC voltages on the left, and after placing this inline with the radio and LNA it seemed to work like a charm. The LNA was getting power and the radio was receiving an AC signal with the DC voltage scrubbed. Excellent! Now admittedly this bias-t is a bit crude. It could probably use a shielded enclosure, and the components spaced much closer together. I had some concerns that there would be a lot of noise introduced, and at some frequencies that certainly may be the case. However, at 1090Mhz things seem fine. So for my purposes, this will do nicely.

What’s Up With That Circuit Board?

Now that the price of having a PCB manufactured for you is very low, the quality high, and the turnaround time reasonable, it’s becoming more difficult to justify making your own PCBs. For this experiment however, I only need the one device, I have all the supplies to etch a board, and I find the process both rewarding and enjoyable. I decided to forego the manufacturer this time and just make the board myself.

For the curious, I use the toner transfer method and etch with ferric cholride.

Results

To get a better sense of how things improved I needed a way to measure the range of reception over time. In this way I could get a rough benchmark for the original setup, and note changes with each addition. I decided to use PlaneFinder’s client software as it offers some nice statistics, and a visual representation of aircraft signals recieved over a 24hr period.

In the charts below each ring is a 50 mile radius from a rough geolocation of my recieving station. The area in blue represents where the flights were observed over 24hrs. The position of the antenna was the same for all tests.

Dipole Only

Groundplane Only

Groundplane with Filtered LNA

A significant improvement! The new setup’s range tops out near the outskirts of Houston and the Gulf Coast. These flights near the end of reception range are of course are very high altitue cross country flights. Reguardless, I’m quite pleased. It’s interesting to note that the antenna for this setup is hanging in an East facing window. To the West of the station is our house, a hill, and downtown Austin closely followed by a big elevation change at the Balcones Escarpment. This is well represented in the graphs, as reception to the West is greatly diminished. Placing the antenna outside as high as possible could potentially help improve the range in this direction. A weatherproof enclosure and maybe a PoE setup for the SBC would be good next steps for this little project.

Ken over at The Maker’s Box did a fantastic job with documentation, even offering a tindie kit to take the pain out of sourcing components. I took a few pictures while assembling the project, as well as discovering a few tips and alternatives for the build, so I figure it was worth a build log.

Build Tips

Solder the Bearing Before the Components

Perhaps the trickiest part of this build is soldering the bearing onto the board. The board needs to be centered vertically on the bearing, so you’ll need some kind of spacer to hold the board up while you solder. The build instructions suggest using a couple of coins for this task. This works well enough, however it is also suggested that the bearing is the last thing to solder to the board. I followed this method when building the first spinner, and I found it difficult to balance the coins beneath the board. The components kept getting in the way, so for the last two boards I decided to place the bearing first. This made things much easier.

I soldered two locations on the top and two rotated 90 degrees on the bottom of the board. There is so much thermal conductivity in the metal of the bearing that you will need to crank up the temperature of your soldering iron to make this job easier.

Alternative Parts

Texas Instruments DRV5023

When ordering components for the board, the specified hall effect sensor (the Melexis MLX92231) was out of stock. After some looking around and comparing datasheets I decided to give the Texas Instruments DRV5023 a try. It wound up working fine, and is suitable as a drop-in replacement. Remeber to test the orientation of your magnet!

Bearing Caps from Amazon

The initial build specifies 3D printed bearing caps. At present I don’t have a 3D printer at my disposal, so I had to look for alternatives. I took a chance on some simple bearing caps I came across on Amazon. They wound up working fairly well, however they are quite thin, making it difficult to glue in a magnet. After some thought, I decided to drill out a hole (slightly smaller than the diameter of the magnet) in the bearing cap and press fit the magnet into the cap. Overall I’m pleased with the solution.

Misc Notes

The minimum order from Osh Park is three boards, however I only needed two spinners as gifts. This gave me the opportunity to build a third spinner as an initial testing/prototyping device. On the extra board I socketed the chip so that I could easily swap the ATTiny in and out. This allows me to use a programmer shield I built a while back, and then reseat the chip into the socketed spinner to see how things looked. It wound up being very helpful in making sure everything in the program looked just right, and in the end I was really glad I built the third spinner.

In this shot you can see the press fit magnet in the bearing inserts from Amazon.

Aside from the bearings and magnet placement, this is a very straight forward build. It would be a great project for anyone new to soldering and wanting more practice. Overall the whole build took me about an hour at a very casual pace.

Useful, but not perfect. A big drawback of punch is that there is no obvious indicator of the timer’s state. To see if the timer is active and the elapsed time, you must issue a cli command. Because of this, I often find myself forgetting to punch in to a new task or out at the end of the day. This obviously leads to some inaccuracies and frustrations in my time keeping. I’ve seen a few solutions to this. The simplest solution would likely be some sort of widget to display the running timer somewhere on your windows manager. However, while messing around with some old panaplex displays, I began thinking of using them in a small desktop clock build. This clock could potentially have a serial input which would allow it to display information from the punch timer. So I’ve found myself thinking about what would it take to implement something like this.

CP2104

Last year I was interested in finding a solution for simple USB to serial communications. Through that research I stumbled upon the CP21x devices from Silicon Labs. Eventually I settled on the CP2104 USB to UART bridge and ordered a development board. These chips save a lot of work establishing onboard USB. They appear to an OS as a typical USB device, auto negotiate baud, and simply pass along serial communications to and from the USB port. There are some advanced configurations available to you if you wish, but by in large the CP2104 is a plug and play chip.

At the time I wrote a test in Python to echo keypresses from my computer to the device. It turns out the chip is as easy to use as promised, and is a perfect solution to interface my computer with a microcontroller in a potential desktop clock.

Python PoC

I thought it would be worthwhile to write a short proof of concept to output data from punch to serial USB. To display this data I used a SparkFun serLCD I had laying around. This wound up being a relatively simple task. I don’t think its useful walking through all of the code, but for the sake of my memory I want to point out a couple things that I learned along the way. If you’re curious you can check out the complete script on my github. Please forgive my clumbsy Python. The code can be cleaned up and there is certainly a more elegant solution.

Watchdog

Punch writes tasks and timestamps to a file, called punch.dat to catalogue time spent on tasks. In order for my program to be aware of active tasks and elapsed time, it needs to watch this file for changes. The Watchdog library handled this task nicely.

Watchdog establishes an API to monitor file system CRUD events. After digging in a bit, I found it to be friendly and effective, and can be summarized in a few lines of code:

eventHandler = PunchDatEvent()
observer = Observer()
observer.schedule(eventHandler, '/path/to/watch')
observer.start()

# When you're done watching.
observer.stop()

Observer is a thread class to which you can schedule monitoring of a given path, and assign it an event handler to act on filesystem CRUD events observed in the given directory. Starting and stopping this thread is as easy as firing the respective methods. Most of the heavy lifting is handled by the event handler you extend from the included FileSystemEventHandler class (PunchDatEvent in the above snippet). Watchdog handles everything else. Quite nice.

Threading

A thread has been established for the Watchdog observer to handle filesystem monitoring, but what about the serial communications? While I could likely handle this in the main program loop, I thought it could be a good opportunity to spin off another thread just for this purpose. Painful memories linger of C/C++ multithreading from days gone by, but I have no experience with it in Python. The task here seemed simple enough to dip a toe in and give it a try.

After spending some time with the core threading library documentation I was surprised to see just how simple this could be (granted this is a very basic application). To sum up in a couple of lines:

tickTockThread = Thread(target=eventHandler.tickTock)
tickTockThread.start()

Instantiate a thread object and give it a target object to run. In this case the target is a method I’ve defined within the same event handler used with the observer thread. Then simply start it. It will run until the target method terminates, at which time the thread is destroyed.

Reading through the docs, I can see how this can get more complex in a hurry. However, I was pleasantly surprised with how simple this was for my small task.

Fine, for now…

I now have a decent mechanism for sending my time tracker data via serial over USB to an eventual desk clock. There are a few critical things to add to the code as I move forward with the project, such as:

• Daemonize the script for Systemd.
• Establish some methods of detecting the presence of the USB device.
• Rework the serial packets sent to fit whatever protocol is eventually used for the clock, rather than the one built into serLCD.

However, for now, this is fine.

What is a Panaplex?

Knowing nothing about the requirements of this display, a bit of research was in order. Panaplex is a type of gas-plasma display; they work much like the coveted nixie tubes. A small chamber is filled with low pressure neon gas. Within the gas filled chamber there is a single common anode, and multiple wire cathodes making up the segments of a digit. When sufficient power is supplied to the cathodes, they will light up with an orange plasma glow. Panaplex saw widespread use from the 1970’s through the 1990’s, but fell in popularity when low power super-effecient LED displays became ubiquitous.

The particular displays I picked up (pictured above) have “Beckman SP-353” etched in the glass on the bottom left corner. As luck would have it, the internet yeilded a datasheet for the very same model. I found it listed in the tube-tester.com archive.

The datasheet revealed what it would take to get this thing glowing. A supply voltage of 160Vdc (minimum) drawing about 330μA would do the trick.

Wait, 160 Volts minimum?!

My bench top power supply can only produce 30 Volts. How are we going to power these things?

Boost Converter

The first solution that jumped to mind was a switched-mode power supply (SMPS), specifically a boost converter. A boost converter will step up a given DC input voltage to a higher output voltage at the cost of stepping down the input current. They are small, cheap, and effecient. Its a great fit for this situation.

Typically you can find a cheap “good enough” boost converter to fit your needs on ebay, Banggood, or even Amazon. However, after some thorough searching I could not find anything reasonable for voltages as high as this. Attempting to design and build my own SMPS was a possibility. Their basic function is remarkably simple, but I knew this could quickly lead down a rabbit hole of tuning, testing, and iterating over prototypes. What I needed was an existing solution just to verify these displays were in working order.

The de Smith SMPS

After some thought, it dawned on me that nixie tubes have very similar power requirements. Maybe a solution lurked there. Broadening the search a bit, I started looking through nixie hobbiest communities to see what their solutions were. The “de Smith Power Supply” was frequently mentioned, and after finally landing on Nick de Smith’s page detailing his solution, I was convinced. The de Smith SMPS takes a 12V - 15V input and boosts to a 150V - 220V output. He gives a detailed explanation of how his SMPS works, the thoughts behind his design and component choices (including a BoM, complete with digikey callouts), and even catalogues some performance testing results. On top of all this, he was generous enough to include the Eagle cad files for the board. With this information, all that was left to do was place an order with OSH Park & Digi-Key and wait.

Everything arrived, and I eagerly populated the components. Now let’s see if this thing works! I connected my bench power supply to Vcc and GND on the SMPS per de Smith’s instructions. The bench power supply was set to 14Vdc, and I happily observed around 160Vdc output from the SMPS. There is a small potentiometer on the board that allows you to make adjustments to the MAX1771 switching controller chip, thereby controlling the output voltage. Excellent.

After some fiddling, I dialed the power supply in to around 165V and turned my attention back to the panaplex display.

Does it work?

Everything up to this point was done just to see if these displays were in working condition. They seemed to be in good shape and the vendor at the hamvention asssured me they were in working order. However, I had no way to verify these claims in a muddy field in Ohio, nor when I arrived home with a measly 30V bench top supply. So, with boost converter in hand, it was finally time to see if I had a working display.

Success!

I used some small jumper wires to connect the 165V output on the de Smith SMPS to the anode of one of the digits, and all of the cathodes to a pin header on a breadboard. This allowed me to sweep another jumper, connected to ground, across the header pins to test individual segments. I repeated this for each digit of the display on the two displays I had. Everything worked as expected, and I found myself basking in the warm plasma glow of nearly 50 year old technology.

What’s next?

Now that we know everything is working, the next step is to design and build a board to make these displays more friendly to modern extra low voltage digital controllers (Arduino, Raspberry Pi, Odroid, etc). I’ve begun narrowing down my transistor selection, and sketched some preliminary scematics in KiCad. However, that will all have to be fodder for a future post.

Dat was developed with the idea of making sharing large files or folders securely an easy task. Without the need to rely on a central “cloud” service (like dropbox) or through semi-cumbersome means like rsync or scp, Dat can make it easy to store, share, and track large volumes of data. This is accomplished through a peer-to-peer (p2p) network (much like BitTorrent). This brings along several of the benefits of a p2p architecture. There is no central host where availability (or security/privacy leanings) would be a concern, you can share across a local network (LAN), and bandwidth scales with the growth of demand as downloads will be distributed across the peers.

Scientists and researchers were the initial target audience for Dat, allowing them to easily archive and share data. I first caught wind of Dat in Februrary of 2017 when it came to light that the data stored at open.whitehouse.gov was being inexplicably deleted. Data from open.whitehouse.gov was scraped and stored in a Dat archive so that the information would not be lost. You can see this and a few other endeavors cataloged on the Dat website.

You can read more about Dat, and forgo further clumsy explanation from me, in their documentation.

Beaker Browser

So Dat is a protocol to serve files. Viewing a website is nothing more than files served to a browser that then renders them. So what if we pipe files recieved via the Dat protocol to a browser for rendering? Well you got a peer-to-peer web goin’!

Clearly it’s a bit more complex than that, but that is the gist of what Beaker Browser does. Beaker is a project developed by Tara Vancil and Paul Frazee, and is a self described peer-to-peer web browser. Its still under very active development, but after some semi-regular use I’ve found it both useable and exciting.

Recently Tara and Paul did a talk for the local group Bleeding Edge Web here in Austin. The talk is enlightening; it gives a window into their vision of the project. If you have some free time, its worth a watch.

Paul also has a brief video introduction to Beaker:

The peer-to-peer web is, arguably, still in its infancy. However, seeing and using a working model is exciting, with potentially far-reaching ramifications. Since many of the current “gatekeepers” to the web are taken out of the equation in a peer-to-peer model, I think there is a potential to reclaim a lot of the magic and excitement present in the early internet. In this spirit, I’ve made this site available to Beaker via Dat at dat://electro.pizza or
dat://485d1f5c6cc1970ee29318f3be66c6c9bd0fb5894e757fdc926785ae6a725346 if you like hashes.

While setting this simple site up a few things stood out to me and I’d like to note them here. For the sake of time (and the length of this post), I’m not going to touch on all of the features with both Dat and Beaker. Rather, I will try to limit the focus to what I encountered while setting up and publishing this simple site. Many of these features are quite interesting and exciting in their own right, and if you are interested I encourage you to check them out on the relavent project pages. Most notable of these to me are:

• Built in versioning on the history of changes in a DAT site.
• Forking of Dat sites (along with new potential workflows when working with a team).
• New Web API’s in Beaker to build peer-to-peer applications.

But for now, some Beaker basics:

Site Generation

Initial creation of a site/hash is extremely simple; the dialogues in the browser walk you through things. Beaker handles setting up the .dat folder and keys behind the scenes so you don’t have to futz with it. If you don’t want to keep the site code in the default location (/home/<user>/Sites in Linux), you need to take the extra step of changing the directory to point at the public files of your site.

Here is an example of the process:

Live Reload

Live reloading should be nothing new to most web developers, however its nice to have this ready to go “out of the box”. It behaves like you would expect, watching site files for changes and refreshing. This makes pairing with something like a static site generator in a watch mode quite nice.

Publishing

This was glossed over in the site generation example above, but the publishing mechanism may be the most exciting (in the context of workflow) with Beaker. As you would expect, when you make changes to site files locally they are reflected locally in Beaker. Traditionally, when you are ready to publish these changes to the web, you would perform a push of the code through various mechanisms, ie. pushing to a CI system or manually scp/rsync/sftp files to a centralized server somewhere. However, with Beaker all you need do is click the big green publish button, and the file changes are then propigated through to all peers. No server concerns at all. Refreshing!

In this example Beaker is on the left and Firefox on the right. Changes published from Beaker are reflected via a remote peer serving over HTTPS to Firefox.

dathttpd

Now wait a minute. Firefox? HTTPS? A *gasp* SERVER!? Weren’t we talking about a peer-to-peer web? Well we are, but we don’t have a widely adopted peer-to-peer web yet! So, we need a stop-gap to solve a couple of issues:

First, electro.pizza isn’t wildly popular. Often my local Beaker Browser installation will be the only peer, thus the only source for anyone to view the site. Therefore, for this site to have constant “uptime”, I would need my Beaker installation to always be running with a network connection. Not ideal.

Second, the vast majority of people surfing the web are using more traditional browsers (Firefox, Chrome, Edge, etc.), and I would like those folks to be able to view my site through the (currently) standard HTTPS web protocol.

Dathttpd solves this problem by acting as both a peer for a Dat site, as well as a small web server. This allows you to keep a Dat site up without having to leave Beaker running. Further, you get the added bonus of being able to point DNS at that server which allows for shortnames for your site. Configuration is simple and detailed on the projects github page.

Hangups

I was caught up in a couple of small snags while setting up dathttpd. Nothing crazy, but its probably worth a note.

Node Installation on the Server

Once the dathttpd config is set up and things seem to be working as expected, it is suggested to use add-to-systemd to daemonize the process. This works quite well, however I’ve found add-to-systemd works best if nodejs is installed on a system level (rather than something like NVM). Use your distro’s package manager to install nodejs greater than version 6.0. On distros like Ubuntu, you’ll likely have to add a PPA for the newer nodejs version.

Firewalls

After having dathttpd running for a few days then returning to Beaker to make site updates, I found that dathttpd and Beaker had trouble reconnecting with each other to propigate updates. I watched traffic for a bit, and it seemed to be a firewall issue with the server. Turns out the machine that is running dathttpd needs to have port 3282/tcp open. After making this adjustment everything worked as expected. I have a bit of a nagging concern that any machine running Beaker also needs port 3282 opened. So far this does not seem to be the case, but I’m not completely convinced.