Loops, Oops!

While I’m very familiar with handling audio-frequency signals in electronics and have a basic understanding of how radio circuits work, there are huge gaps in my knowledge around radio waves, their propagation and reception, and rather a key part of radio system design: aerials.

My planned aerial design for VLF/ELF reception was three air-cored coils positioned in orthogonal directions, like this :


(see also Hardware Issues)

Unlike, say FM aerials, these small loop antennas will pick up the magnetic component of the electromagnetic signal (as do the coils in typical AM radios). I assumed that the signal received on the N-S axis would be different from E-W and Up-Down. This seemed like the way to capture directional information, assuming the Up-Down direction would also be useful, ie. overall collecting as much information as possible.

Well, I’d had the Wikipedia page on Loop Antennas bookmarked for weeks, yesterday I finally read it, and got a surprise.  As Wikipedia puts it:

Small loop antennas are much less than a wavelength in size, and are mainly (but not always) used as receiving antennas at lower frequencies…

…Surprisingly, the radiation and receiving pattern of a small loop is quite opposite that of a large loop (whose circumference is close to one wavelength). Since the loop is much smaller than a wavelength, the current at any one moment is nearly constant round the circumference. By symmetry it can be seen that the voltages induced along the flat sides of the loop will cancel each other when a signal arrives along the loop axis. Therefore, there is a null in that direction. Instead, the radiation pattern peaks in directions lying in the plane of the loop, because signals received from sources in that plane do not quite cancel owing to the phase difference between the arrival of the wave at the near side and far side of the loop. Increasing that phase difference by increasing the size of the loop has a large impact in increasing the radiation resistance and the resulting antenna efficiency.

So my planned N-S coil would actually have nulls in those directions, similarly for E-W, and the Up-Down coil would in effect be omnidirectional NSEW. D’oh!

There is a lot to electromagnetic radiation! (eg. near vs. far field reception is something I need to read up on). It’s weird stuff.


Reading around the topic a little more, the null positions are the key to radio direction finding (RDF). A coil will have two nulls, 180° apart, which RDF gets around by adding a sense antenna, which may be a simple vertical whip aerial. This will be omnidirectional and (if I understand correctly) when summed at the right levels with the coil signal will effectively remove one of the nulls.

Luckily, hardware-wise I’m still at the planning/experimentation stage, so haven’t wasted too much time winding coils. Looks like I’ll have to change the design, provisionally having N-S and E-W coils plus a sense antenna, a la RDF. There are lots of designs for all kinds of aerials and receivers at VLF.it (I’ve just started assembling a list of reference links, that site is at the top of the list).




Hardware Issues

[work in progress 2017-04-15]

Hardware Overview

(I initially made a significant mistake in my radio reception plans, see Loops, Oops!)

I had hoped by now to have prototypes for a radio receiver and seismograph ready in hardware. What I have got on that front is an increased awareness of how tricky they are likely to be. I still think I’ve got a reasonable design for the sensor part of the seismograph.

Noise Annoys

On the radio side, the experiments I’ve done so far have only really shown that the signal/noise ratio I need to deal with is even worse than I imagined. This is largely due to my location. Although this is a very small village in the hills, everywhere you look are overhead mains power lines. To get a signal that won’t be swamped with noise I anticipate having to filter out at least mains hum at 50Hz and 100Hz (possibly even higher harmonics) in analog signal conditioning. A standard circuit that can do this job is the twin-T notch filter. By wrapping it around a couple of op-amps it can be bootstrapped, boosting the Q, hence the depth & narrowness of the notch can be increased. The big problem here is component tolerance. Metal film resistors are pretty good, having 1% accuracy, but capacitors are another story – anything better than 10% is quite specialist (and that’s not even taking into account effects of thermal variation). Some level of manual tweaking seems unavoidable, worst case 4 trim pots per filter (3 in the T, one for the feedback = Q).

My plan to make a receiver consisting of 3 orthogonal coils will have to remain on hold until I have some funds available (it sounds crazy, but wire looks like it’s going to be the greatest expense). I do have the bits to play with a single channel. And that’s also simpler.

Data Acquisition

I haven’t written it up yet, but once I’ve got usable analog signals from the radio, seismo and other* sensors, I want to use dedicated hardware to get them into the digital domain. Not only that, ideally I want this part of the system to make the raw data available on the Web. I think it makes sense to use a subsystem to collect the data independently of processing, to keep things modular. That way the subsystems can be developed in isolation and additionally the processing workload can be more distributed. So essentially I will have analog-to-digital converters (ADCs) attached to one or more small computers. The physical location of sensors is a consideration – away from sources of interference for the radio receivers, solidly attached to the ground for the seismic sensors. It is necessary in each case to have some of the signal conditioning circuitry local to the sensor (at least pre-amplification).

I then need to get the preconditioned signal from the sensors through the ADCs into the dedicated processing subsystems and on again to the part that will do the processing. The most elegant approach I can think of is also having the ADCs & dedicated computers local to the sensors, with the data being delivered to subsequent processing over WiFi. (Care will be needed in shielding the digital electronics to avoid interference).  An existing standard transfer protocol will be desirable (probably TCP or UDP), and from there it’s only a small step to proxying it onto the Web.

Given this setup, and the considerations of location, modularity and performance, it will make sense to use one ADC+computer subsystem for the radio receivers and one for the seismic sensors.

*  for reasons described below, I plan to eventually detect signals in 3D, ie. both the radio and seismic units having a N-S, E-W and vertical element. But most ADC boards have their number of channels as multiples of 2. Hence I intend to use 2 x 4 channel ADCs, and use the 2 spare channels for acquiring other environmental signals – provisionally acoustic noise (audio) and ambient temperature (again, there’s rationale below).

Two small species of small, inexpensive, general-purpose computers stand out from the marketplace: Raspberry Pi and Arduino. Now I’ve spent a lot of time around digital audio and rather naively assumed that suitable ADCs would be ten a penny. Not so.

For the radio signals, ideally I want to capture something roughly equivalent to fair quality audio, ie. say a bandwidth of 20kHz with 16 bit precision. ADCs that can do this are available of-the-shelf in the recording part of regular soundcards. Unfortunately, there doesn’t appear to be anything available that’s inexpensive and interfaces easily with either computer board (and I have read of issues with data transfer bottlenecks when using USB devices). However I have found a card that appears to fit the bill, for the Arduino : the Mayhew Labs Extended ADC Shield.

Progress (of sorts)

[work in progress 2017-04-15 – material was getting long so splitting off to separate pages]

General Status

In the last month or so I’ve done a little hardware experimentation on the radio side of things, along with quite a lot of research all around the subjects. I also had a small setback. About 3 months ago I ordered a pile of components, they never arrived, a screw-up by the distributor (I wasn’t charged). Unfortunately I don’t have the funds right now to re-order things, so although I do have the resources for some limited experimentation, I can’t go full speed on the hardware. (Once I’ve got a little further along, I reckon I’ll add a ‘Donate’ button to this site – worth a try!)

This might be a blessing in disguise. Being constrained in what I can do has forced me to re-evaluate the plans. In short, in the near future I’m going to have to rely mostly on existing online data sources and simplify wherever possible. This is really following the motto of Keep It Simple, Stupid, something I should maybe have been considering from the start.


Next Steps

Neural Network Strategies

[work in progress 2017-04-15]


Provisional Architecture



Provisional Network Architecture
A Critical Issue

If we assume that significant seismic events are indeed preceded by distinctive radio emissions generated by geological stresses, and that these patterns may be detected reasonably reliably, there remains at least one significant issue in applying them to the prediction problem. This the time delay between the radio event and the seismic event.

Reports in the literature describe a latencies anywhere between hours and weeks, and it seems likely that this may confound the association between earthquakes and precursors. There could be any number of unknown variables in the physical environment affecting the generation and propagation of the radio signal. For all practical purposes these are effectively random, and so probably best considered another form of noise – in this case in the temporal dimension.

It may be that the radio signal patterns of precursors have recognisable correlation with not only the ensuing seismic events but the length of time before those events. Another (optimistic) possibility is that the neural networks applied will learn this correlation.

At this stage, the best bet seems experimentation…

Localising Online Data – baby steps

While I’m intending to build a simple seismometer in the near future, there’s a lot of data already available online. Generally this seems to be available in two forms : near real-time output of seismometers and feeds of discrete events. I’ve not yet started investigating the former as the latter seems an easier entry point to start coding around.

I’m based in northern Italy, and as it happens there are some very good resources online for this region (hardly surprising, as earthquakes are a significant threat to life & property in Italy). A hub for these is the Istituto Nazionale di Geofisica e Vulcanologia (INGV).

Web Services

The service with the snappy name Event Federation of Digital Seismograph Networks Web Services  allows queries with a variety of parameters, returning data in a choice of three formats : QuakeML (a rich, dedicated XML), KML (another XML, Google’s version of GML) and text. Hat tip to the folks behind this, it’s Open Data (CC Attribution).

The INGV also offers a preset translation of the previous week’s events in Atom format (augmented with Dublin Core, W3C Geo & GeoRSS terms for event datetime and location). This is a minimal version of data from the Web service, but contains all I’m interested in for now: event magnitude, location & time. (I also have a personal bias towards Atom – it’s the first and I think only RFC in which my name appears 🙂

Relocating the Event

The potential utility of this project is about the risk of seismic events felt at a specific location. The feed gives the magnitude of the event at epicentre. It may be reasonable to process the raw data to reflect this.

Whether or not it will be better to use such data raw (i.e. separate  inputs for magnitude, latitude & longitude) or pre-processed as input to neural nets remains to be seen. But to flag up high risk at the target location, some combined measure is desirable.

The true values depend on a huge number of factors (for more on this see e.g. The attenuation of seismic intensity by Chiara Pasolini). As a first attempt at a useful approximation I’ll do the following:

  1. restrict data to events within 200km of the ‘home’ location
  2. apply an inverse-square function to the magnitude over the distance

Both are guesstimates of the relative event significance. Although major events beyond 200km may well have significant impact locally, for the purposes of prediction it seems reasonable to exclude these. For these purposes the data is going to be fed to a machine learning system which will be looking for patterns in the data. Intuitively at least it seems to make sense to reduce the target model to that of local geology rather than that of the whole Earth.

The recorded magnitude of events (as in the Richter magnitude scale) is more or less a log10 of the event power. Compensations to this made by measuring stations to allow for their distance aren’t exactly straightforward. But seismic shaking is very roughly similar to sound, and the intensity of sound at a distance d from a point source is proportional to 1/d^2. This may be wildly different from the true function even under ideal conditions. But it does introduce the distance factor.

(If you’re interested in looking into the propagation side of this further, the ElastoDynamics Toolbox for Matlab looks promising).

Anyhow, I’ve roughed this out for node.js, code’s up on github. A bit of tweaking of the fields was needed (e.g. the magnitude appears in the text of the <title> element). It looks like it works ok, but I’ve only done limiting testing, shoving the output into a spreadsheet and making a chart. The machine I’m working on right now is old and has limited memory, so is a bit slow to do much of that.


The red dot is the home location.

Jam Jar Seismometer and a Springy Coincidence

One key aspect of this project is the detection of seismic events. Yes, I want to play with the online data from proper seismo stations, but as I’m primarily concerned with the earthquake risk at a given location, some kind of local system is very desirable.

A quick search of the Web for seismographs shows that one design seems most popular, essentially a heavy weight on the end of a swinging arm, with some restraint (& damping).


It’s relatively simple, but, is rather large and only captures earth movement on one axis. Amongst my project aims/constraints (which I’ve yet to write up) are to keep things small and to capture as much info as possible, within an emphasis on simplicity.

Yesterday, while enjoying a pint on a sunny afternoon in Maryborough, Victoria, I wrote down what I have in mind for my Version 1 sensor. Call it the:

Jam Jar Seismometer


(Erm, ignore the top-left text, that was Mish brainstorming some unrelated promo text)

So essentially a ball of steel dangling from a spring in a jar of oil. On the horizontal axes it should act like a (damped) pendulum, on the vertical like a (damped) weight on a spring. Minimal physics.

To measure the movement of the ball, the obvious setup would be a coil and magnet, like an electric guitar pickup. But as it happens, the other day I bought a Hall Effect sensor, just out of curiosity on what natural magnetic fields it could pick up. (It has a built-in preamp and gives a linear output, sensitivity 1.3mV/G. Given the earth’s magnetic field is in the region of 0.5 Gauss, it should be sensitive enough to be interesting). These things are very small and fairly inexpensive (~$7). Having each backed by a little rare earth magnet should give a reasonable output. Not sure where I’ll source a big ball bearing, must have a suitable spring around somewhere. While veggie oil would probably be inert enough, mineral oil may be wiser. (Italian hardware shops sell a food-quality mineral oil for air-sealing demijohns of wine, that’ll be my plan A).

Trying this setup out will likely reveal silly or subtle flaws I’ve not thought of, but there are two sources of potential problems I can see right away. First is that the magnets will pull the weight towards themselves. Hopefully the physical issues should be fixable by using a different spring; electromagnetic, fixable in electronics/software.

The second thing that came to mind is the effect on the output of the Hall Sensors when the magnetic field is off-axis. I couldn’t see a mention of this in the data sheet. If the resting position of the ball is (0,0,0) in physical space, and a hella quake hits and pulls it to (1,1,1), will this be reflected in the output of the sensors?

I suspect that this would definitely be a problem were the goal to be to record the x,y,z signals as individual, absolute, calibrated values. But presumably the true measures will be some weird, probably non-linear function (over time) of the 3 detected values, so this shouldn’t cause information loss. As I intend to use a fairly deep neural net on this data, any weird polynomials will (hopefully) get flattened out so the processing system just sees the perturbations of interest.

Magnitude 3.0 Coincidence

enough to be noticed, but not weird enough to trigger a psychotic episode

So I sketched my plan yesterday morning. In the afternoon we visited a charity shop (Op Shop here down under) and I bought this book.


I’ve looked at these kind of sums before, mostly around about 1987 when the book was published. But my maths is seriously rusty, and this is stuff I should really be fluent with. I did cover such material in school (in the contexts of analog electronics & acoustics) but in the days before Chaos Theory stuff threw a spanner in the works. After that I did a bunch of informal research & even magazine writing on chaos in analog systems, but never went far with the maths. Now, of 9 chapters in this book, 7 of them are written from a post-chaos perspective.

I digress. The coincidence is between my sketches above and what appears in the first chapter of this book:


Page 6/277. I’ve a way to go yet…



Signal Generator for Free; Notch Filter Progress

So I’m trying to put together an analog filter to cut the mains hum from a ELF/VLF radio receiver.
The sig gen built into the BitScope DSO is very limited, only offering certain fixed frequencies. This isn’t a huge amount of use for evaluating a notch filter circuit. Neither was the use of a white noise source as input to the circuit with a freq domain trace at the output, the notch wasn’t visible (had a bit more smoothing been available in BitScope DSO, this should have worked).


I thought my easiest next step would be to put together an analog sweepable oscillator on the breadboard. But then, while falling asleep, I had a Eureka moment: the laptop I’m using for the DSO display has a soundcard! I’m running Ubuntu on the lappie, and the Audacity audio recording/processing tool has the facility for generating swept-frequency signals. So I attached jumper leads to a mini jack plug and stuck that in the headphone socket, bingo!

By generating a 1 second sweep, 20Hz-200Hz, in Audacity and loop-playing it, I got a reasonably respectable view of the filter response in the freq domain display of the DSO.


Next up I just need to tweak the resistor values to focus the notch bang on 50Hz. Putting pots in parallel with the current values will allow me to find these values. However, silly me, I don’t have a multimeter to check the pot values. I did see one in a hardware shop for AUS$11 the other day, and given that’s about the price of a pint of beer here, I guess I have no excuses.