A note before you begin: This is not a
configuration I currently use to receive the VLF band, due to
limitations I discovered after its' construction. Instead, this is a
record of the challenges and design choices that happen with this type
of remote receiver. Hopefully, these notes will help someone else
considering a similar project.
Motivation.
After relocating to a spot southwest of Lynchburg VA, I began to
consider the design limitations of my original VLF receiving setup, shown here. One of
the primary limitations of a VLF receiver in a suburban or semi-rural
environment is the presence of power lines and transformers above and
below ground. Aside from direct near field reception of AC hum and
harmonics, one of the biggest sources of domestic interference is
carried into the receiver via the cable that connects the receiver to
the building that houses the computer and soundcard or A/D converter.
The cable acts as an antenna, but also carries noise current produced
by the (likely) different ground potential between the receiver and
the building. You can read more about that effect here.
One way of working around this is to feed the output of the VLF
receiver into an FM transmitter. The problem with using an FM
modulator is that strong sferics can tend to over-modulate the
transmitter, and the FM link itself can add noise and intermodulation.
Also, the bandwidth and dynamic range of the FM link can be a problem.
One potential way around the limits of FM modulation is to digitize
the VLF signal prior to sending via radio. After some promising
discussions on Yahoo's
VLF_Group, I decided to build a new setup that digitized the
VLF, and transmitted it via 802.11 wireless IP link.
The
Reception Environment. The part of central Virginia in which
I live is located in the foothills between Lynchburg and the Blue
Ridge Mountain Range. The area is mostly forest and farmland,
woven with many streams, rivers and several large lakes. It is dotted
with low density housing and sparsely placed small cities. It has the
occasional high voltage power line, but most of the power lines follow
streets and highways. The soil is predominately a red clay, with
granite, limestone and volcanic formations underneath.
The location in which we were living had two runs of power lines,
separated by about 500-600 feet, running parallel to the front and
rear of the property.
Receiver
Location. The AC mains hum, it's harmonics,
and interference from other local sources can set up standing patterns
with 'local' maxima and minima. Through careful study and observation,
you can select a location that minimizes (relatively speaking) that
interference. Following the technique outlined here,
I found a location not quite equidistant between the power lines that
was my best possibility for reception: a trade off between being
within a local hum minima, but well within the electromagnetic shadow
of a row of 100+ foot pine trees. It is interesting to note that the
AC mains were only one of two significant problems: many samples
showed I had equally strong interference between 40-47Hz, mirrored
rather nicely around 60Hz, re-appearing at approximately 100Hz. The
harmonics from this source did not extend nearly as high as those from
the AC system, but they were rather strong in the low end of the band.
I have a preliminary theory that it has to do with a railroad yard
about 1 mile from my location, which I based on hearing activity
aurally and correlating it with what I saw on spectrograms. Regardless
of the source, it was a strong mess, and I needed to address it.
Receiver
Design and Operation. The additional low-end interference
prompted me to develop a "split" version of my original
VLF receiver, which includes enhanced low-end filtering, and is
detailed here.
System
Description. Based on bench experiments, I discovered
that putting the VLF receiver in close proximity to the GPS board and
embedded PC (a modified ALIX
2d3) injected all sorts of digital hash into the receiver. I
found that moving the receiver at least 10 feet from the ALIX and GPS
and including a little extra power filtering eliminated that problem.
Based on my previous experience with solar panels, and advice from
members of the VLF_Group, I also decided to place the charge
controller and solar panels some distance from the receiver - which
brought the total number of enclosures to three. The result is shown
in the diagram below.
WiFi System Diagram. Click for larger image.
The ALIX 2d3 was installed with a version of Voyage linux, running Paul Nicholson's vlfrx-tools. The 'sound card' I chose was an E-MU
0204. The 802.11n connectivity was provided by a $5 dongle
purchased on eBay. The GPS was the Mikroe Smart GPS module I had used
in my prior installation.
Here is a small gallery showing the waterproof tubs with the various
components in them (click for larger images):
System Performance.
The noise performance of the split version of the receiver is very
good, and below the desired VLF signal. You can see more details about
it's noise performance here.
As part of re-designing the system, I no longer wanted to be
constrained by a 48kHz sound card, so I opted to run the E-MU 0204 at
a 96kHz sample rate. I was able to see a number of interesting VLF
stations that I never been able to observe before - which was quite
nice. However, there were a number of disadvantages to the system that
eventually caused me to switch back to a hard-linked system:
USB Soundcard Support.
While there is full ALSA support for the E-MU 0204, the USB hardware
and drivers for the ALIX (and the Raspberry Pi, and the Beaglebone...)
don't seem to be quite up to the task of continuous, high-speed use. I
had frequent vtcard reset cycles and lost samples. Others have had
similar experiences with the Raspberry Pi. Some of the problems can be
eliminated by careful pairing of the USB soundcard and embedded PC and
using specific, lower, sample rates. In the end, I was interested in
expanding my reception beyond 48kHz, and this setup was simply not up
to the task.
Energy Equilibrium.
When you bundle a receiver (12-15ma), a GPS (~90ma), and an ALIX
(300-550ma, depending on processing), your power budget easily exceeds
half an amp or more. It takes a significant investment in solar panels
to make the system completely independent. Frequently, when we had
extended runs of cloudy days, I would have to swap batteries when the
one in use went flat. I could have added more panels, but by that
point I had already decided to abandon this approach.
Crowded 802.11 Bands.
One of the side effects of enabling 802.11 connectivity on phones,
set-top boxes, cordless phones, etc. is that the 802.11 bands have
become crowded. It can be difficult to achieve consistent, high rate
data flows (especially at the rates required for 96Khz, stereo, 16bit
data). I forced the use of 802.11n, did a site survey and selected an
unused channel, turned off 40Mhz channels (an 802.11n enhancement),
and tried various other forms of creating a dedicated virtual circuit.
In the end, the interference and lack of reliability was too great to
overcome. I was baby sitting the system entirely too much.
Processing
The Signal. Once you get the signal indoors, there are quite
a number things you can to do with it. Just to name a few:
To accomplish any of these, however, you will need to be able process
and store the signal in various ways. The two primary software
packages available for doing this (that I'm aware of, anyway) are
fortunately both very good, and free:
Windows: DL4YHF's
Audio Spectrum Analyser. If you're a ham, you're probably
already familiar with Wolf's software in other contexts.
I utilize vlfrx-tools for initial processing and storage, as well as
streaming and post processing (SID detection, etc.) I also use
Spectrumlab on the same signal, forwarded from vlfrx-tools, for it's
enhanced real-time display.
For information on my vlfrx-tools setup, please see this
page.
End
Notes. Overall, developing and deploying this type of
reception system was a good learning experience. I'm sure that with a
lower sample rate and very careful tuning, the system could be made
more reliable. My interests and needs, however, ended up ruling this
system out.
The content presented here is the original work of Mike Smith unless
otherwise shown. Please contact me
for comments or errors.
This site was built using Emacs, GTML and CSS.
