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.


Author: Danny Ayers

Web research and development, music geek, woodcarver. Originally from rural northern England, now based in rural northern Italy.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s