One of the more fascinating things about VLF are the natural signals that occur from time to time such as whistlers and auroral chorus. Unfortunately there's a fairly reliable law of nature which decrees that whenever you listen to the VLF receiver, you are unlikely to hear any whistlers or aurora. This is especially true when you've driven 100km to a remote part of the country to get some interference-free reception on a portable receiver. A corollary is that five minutes after you give up and switch off, a whistler storm will begin.
A solution to this problem is to run an automatic event (whistler or aurora) detector which will monitor your received signal and capture anything interesting. This is very easy to do using the vtevent program in vlfrx-tools. vtevent looks for falling tones which conform to the shape of a whistler. It also looks for rising tones, which occur during auroral activity, or when your neighbour is using an electric power tool or washing machine. When vtevent sees one of these kinds of signal, it captures a thumbnail spectrogram and a six second audio sample and stores them to disk, along with a short text file containing some information about the event.
It is easy to set up. First you need a data directory in which to save detected events. This can go on your data disk:
mkdir /d/events
The following command runs the event detector on channel one of your hum-filtered VLF signal:
vtresample -r 32000 @filtered:1 | vtevent -d /d/events
vtevent works best with a 32k/sec or 48k/sec sample rate, hence the use of the resampler.
Unless you're very lucky, the program will just sit there quietly, saying nothing while it monitors the signal. To run the detector automatically, we just need to add it to the radio start-up script. Edit /root/radio and add the lines highlighted in blue:
#!/bin/bash
killall -q vtcard
killall -q vttime
killall -q vtfilter
killall -q vtresample
killall -q vtvorbis
killall -q vtwrite
killall -q vtevent
if [ "$1" = start -o "$1" = restart ]
then
sleep 2 # Delay needed when using Octo, the driver is slow to initialise
vtcard -B -d hw:0,0 -r96000 -b32 -c2 -g-1 -L /run/vtcard.log -v @raw
vtwait -t @raw
vttime -B -m pulse+ -c2 -h 30 -L /tmp/vttime.log -v @raw @timed
vtwait -t @timed
vtfilter -B -a th=5 @timed:1 @filtered
vtwait -t @filtered
vtresample -B -r32000 @filtered:1 |
vtvorbis -B -ep -q0.4 -ktu shout,localhost,8000,/vlf,XXXXX
if [ -d /d/vlf ]
then
vtresample -B -r32000 @filtered:1 -- -,f4 | vtwrite -B -G 3600 /d/vlf
fi
if [ -d /d/events ]
then
vtresample -B -r32000 @filtered:1 | vtevent -B -d /d/events
fi
fi
Save and restart the radio system with
systemctl restart radio.service
and after the restart is completed, a vtps command should give you a listing like
PID RT %CPU %MEM COMMAND 26766 99 5.6 2.0 vtcard -B -d hw:0,0 -r96000 -b32 -c2 -g-1 -L /run/vtcard.log 27072 - 15.8 4.7 vttime -B -m pulse+ -c2 -h 30 -L /tmp/vttime.log 27141 - 17.0 2.4 vtfilter -B -a th=5 @timed:1 @filtered 27149 - 10.7 0.7 vtresample -B -r32000 @filtered 27151 - 5.0 0.4 vtvorbis -B -ep -q0.4 -ktu shout,localhost,8000,/vlf,XXXXX 27156 - 0.0 0.1 vtwrite -B -G 3600 /d/vlf 27159 - 10.5 0.3 vtresample -B -r32000 @filtered:1 -- -,f4 27161 - 12.3 0.7 vtresample -B -r32000 @filtered:1 27163 - 27.1 1.2 vtevent -B -d /d/events
You might want to run more than one copy of vtevent if you have multiple receivers to monitor. You must give each vtevent its own directory to put events into.
Now you will have to be patient and wait for it to detect some signals. From time to time, check the events directory with
ls -l /d/events
to see if any files have appeared. Frequency of events varies greatly from one location to another, and on the time of year. Much depends on how often there is an electrical storm near your geomagnetic conjugate. Wherever you are, you are likely to pick up 'events' caused by electrical interference. A common type comes from electric motors starting up. These produce a rising tone which triggers the riser detection.
Sooner or later then, your listing of the events directory will show some files have appeared. For example
-rw-r--r-- 1 root root 19027 Feb 15 03:28 1518665302.png -rw-r--r-- 1 root root 33 Feb 15 03:28 1518665302.txt -rw-r--r-- 1 root root 394368 Feb 15 03:28 1518665302.vt -rw-r--r-- 1 root root 17947 Feb 15 03:38 1518665900.png -rw-r--r-- 1 root root 33 Feb 15 03:38 1518665900.txt -rw-r--r-- 1 root root 394368 Feb 15 03:38 1518665900.vt -rw-r--r-- 1 root root 20170 Feb 15 04:08 1518667716.png -rw-r--r-- 1 root root 33 Feb 15 04:08 1518667716.txt -rw-r--r-- 1 root root 394368 Feb 15 04:08 1518667716.vt
The long number uniquely identifies the event - this is the unix timestamp of the event to the nearest second. There are three in this listing. Each event has three files: A png file containing a thumbnail spectrogram, a text file giving some information about the event, and a vt file which contains a six second sample.
You'll want to view the png files to see whether you've caught a whistler or a Black & Decker. There are many image viewers available for Linux. A most useful one to use is called 'feh'. Install it with
apt-get install -y feh
The simplest way to use feh is with the command
feh /d/events/*.png
It displays the first (oldest) png that it finds. Use the right/left arrow keys to move to the next/previous image. Some example images below:
|
|
|
|
|
|
|
|
|
|
|
The thumbnail spectrograms are size 194x97 pixels. If you like, view them double sized with
feh -g 388x194 -Z *.png
You're going to need a way to quickly and easily discard unwanted events. A simple way to do this is to specify an 'action' to be run by the feh viewer when you press a particular number key when viewing the spectrograms. For example
feh --action1 'rm /d/events/$(basename %N .png).*' -g 388x194 -Z /d/events/*.png
With this command, as you scroll through the thumbnails, if you see one that's just interference, then pressing the '1' key will remove the three files associated with that event.
You can manually remove the false detections above. But you'll still have a growing amount of disk space taken up by genuine events. If you don't want to keep them permanently, then you can clear them down when they reach a certain age, just as you do with the continuous recording files. The following will remove events that are more than 30 days old:
find /d/events -type f -mtime +30 -exec rm {} \;
You can run that manually from time to time, or add it into your /root/cleardown script so that it runs every hour.
If you want to keep events, they should be moved off the Pi data disk to some more permanent storage. You can do this from a Linux workstation easily with the rsync command. Assuming your workstation has a destination directory, say, /arc/events, then on your workstation shell, run
rsync -av -W --remove-source-files root@rp5:/d/events/ /arc/events
This will copy all the events in /d/events on the Pi, to /arc/events on your workstation, and then remove the originals. The command leaves /d/events empty. Note that in the rsync command the source directory is terminated with / but the destination directory isn't. This is important.
You cannot use the Audio Injector output side for playback, the card does not function in duplex mode. Therefore all the commands given in this section must be run on your Linux workstation. I'll assume that you've transferred the event files to say, /arc/events, on your workstation.
To listen to an event, use, for example
vtraw -ow /arc/events/1518786192.vt | aplay
You may find that the events play too quietly, even will full playback volume on your workstation. This is likely if you have the level of the VLF signal into the Audio Injector set correctly for best dynamic range. In that case, use a -g option to boost the gain in vtraw:
vtraw -g 5 -ow /arc/events/1518786192.vt | aplay
The gain is a multiplicative factor, so for a 20dB boost, use -g 10.
Often after a good whistler storm or some nice auroral activity, you will want to listen to all the events involved, and it is convenient to string them all together into a single WAV or MP3 file. You will have been through and deleted any falsely triggerred events, and you will have decided which events mark the start and finish. Let's say that you want to string together all the events between 1513201030 and 1513207080 inclusive. Then run the following command:
cd /arc/events ls *.vt | sed -n '/1513201030/,/1513207080/p' | xargs cat | vtraw -g5 -ow | lame -mm -b64 - ~/string.mp3
This command uses sed to pick out the required events from the directory listing of all the events, then uses xargs cat to concatenate the list of files it is given. This produces a single .vt stream which vtraw -ow converts to WAV and lame then converts WAV to an MP3 file string.mp3 in your home directory.
You can use a directory listing in this way because ls outputs the filenames in lexical order and the events are labelled by a timestamp which is always 10 digits. Therefore the listing will be in time order.
Actually the Pi itself has enough capacity to run that pipeline. You'll first have to install the lame mp3 encoder/decoder, with
apt-get install -y lame
Once you've got your MP3 file, you can put it on your Pi's Icecast server with
rsync -a string.mp3 root@rp5:/usr/share/icecast2/web
or if you created the MP3 on the Pi, just do a local copy
cp -a string.mp3 /usr/share/icecast2/web
The -a options preserve the timstamp of the file when it is copied. File modification timestamps are very useful so always when using cp or rsync, make sure you preserve timestamps with the -a option.
Now you can play the file from anywhere on your LAN with
http://192.168.2.37:8000/string.mp3