## 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 :

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).

Are you new to blogging, and do you want step-by-step guidance on how to publish and grow your blog? Learn more about our new Blogging for Beginners course and get 50% off through December 10th.

WordPress.com is excited to announce our newest offering: a course just for beginning bloggers where you’ll learn everything you need to know about blogging from the most trusted experts in the industry. We have helped millions of blogs get up and running, we know what works, and we want you to to know everything we know. This course provides all the fundamental skills and inspiration you need to get your blog started, an interactive community forum, and content updated annually.

## 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.

## Neural Network Strategies

[work in progress 2017-04-15]

### Provisional 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…

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.

## Seeing the Signals (& BitScope BS10, first impressions)

### tl￼;dr

The BitScope BS10 and associated software makes a useable but basic scope, but its real potential is probably in its other facilities: simple data acquisition across various platforms (including Raspberry Pi) and the ability to monitor logic levels alongside analog signals.

Trying to do any signal-oriented electronics without an oscilloscope is like trying to drive blindfolded. OK, it is possible to develop audio systems with just a multimeter and an amplifier, but you are literally missing a sense. I did have an old analogue, CRT scope years ago, but gave it away when I moved to Italy. I’ve only done a tiny bit of electronics dev since then (simple guitar effects) and have got away with ears, just.
But my latest project will involve a lot of unknown signals, there’s no way I can make progress without a scope.
Standard scopes nowadays are Digital Storage Oscilloscopes (DSOs). The storage side is sweet, it’s possible to save snapshots of traces and often capture the raw data contained in them. But with Digital comes a caveat. Analog scopes tend to give a fairly true representation of the signal, in the given context (bandwidth, levels etc). Anything spurious, such as over-level clipping is immediately visible. Digital scopes rely on analog to digital conversion (A/D), which introduces factors such as the sample rate, filtering and resolution. Out-of -range signals presented here can produce misleading displays.

### Requirements

Most of what I want to look at is in the audio frequency range, which is well covered by pretty much any scope worth its salt. For example, my old analog one went up to a 1MHz timebase, comfortably encompassing the nominal 20Hz-20kHz of audio. But because I’m going to be looking at circuits that may pick up radio frequency signals, a higher bandwidth could be useful. Being able to go down to DC will be useful too, for lower frequency signals and detecting unwanted offsets etc.
The signal levels I’m interested in are relatively low voltage, so there are no special requirements here (at circuit input some signals will be very low amplitude, but as the target systems will need to amplify these anyway, this shouldn’t be an issue).
For convenience, I want at least two simultaneous traces to be available – most circuits I’m likely to be looking at will feature an input and output.
Additional it will be pretty essential to examine signals in the frequency domain.
Finally, the scope has to be affordable.

### Options

#### Benchtop DSO

This is the most obvious solution. These are available starting at around \$500 – not a trivial amount, but definitely worth considering for such a vital piece of kit.

#### Computer Soundcard

Right at the low budget end is the use of a computer sound card and appropriate software. Remembering now, I realise I fibbed about developing guitar effects without a scope, I did actually use a soundcard and various (free) VST plugins to look at the signals.
But this approach is quite limited, and, well, clunky. It isn’t really viable to make accurate measurements, there’s no range changing switches built in, bandwidth and resolution can be overly limited (e.g. few sound cards go down to DC).

#### BitScope

This is an A/D converter which attaches to a USB port and has dedicated DSO software. The BS10 has excellent specs on paper, though they are dependent on host computer performance. The software will run on MS Windows or Linux and notably a Raspberry Pi. An Android version appears to be in the pipeline. Physically the BS10 is a small box which comes with a bunch of clip leads. It has two analog inputs, an analog output and and 8 logic inputs. A variety of applications were downloadable from the site, the key one being BitScope DSO. Once I’d realised this had to be run with sudo (to give access to /dev/ttyUSB0) it worked a treat.
The controls in the application aren’t entirely intuitive, after a couple of days getting used to them I’m still unsure e.g. how to adjust offset. For equipment like this, I’m afraid an on-screen user interface will never be as convenient as hardware knobs you can twiddle.
The DSO application also offers a frequency domain display (for one or both channels) as well as a basic signal generator. The freq display is very nice to have, though control of parameters is rather limited. For example, an arbitrary zoom would have been good, as would a variety of smoothing/averaging options.
Similarly the built-in signal generator is nice to have, but even more limited. It offers a range of fixed frequencies, producing a sine or square wave. This is OK for quick checks, but that’s about it.

Fortunately there’s a fairly trivial way of providing a versatile sig gen in the same setup at virtually zero cost. Whatever the host machine for the BitScope, chances are it has a soundcard. Hook a couple of jumpers leads to a jack plug, pop it in the headphone out socket, fire up Audacity and bingo!

So as a substitute for a benchtop DSO, the BS10 is adequate but not outstanding. Call it 7/10. Given the price compared to dedicated hardware this seems reasonable.
However, chances are anyone working with analog signals in this day and age are likely to have digital aspects to their circuits. I haven’t tried this yet but from the docs the 8 channel logic monitor capability of the BS10 looks like it should be very useful in future.
For my current project, while I need the DSO facilities for circuit development, the BS10 should offer a very good foothold into another part. Again though I haven’t yet tried this, it also appears to be a very versatile data acquision system for recording signals. This can be done from within the DSO app or programmatically (with hooks from Python, I believe). The latter part I’m rather looking forward to, a hackable signal capture unit is very nice to have. I don’t yet know how sophisticated I need this side of my project to be, but the BS10 certainly is an option. Alternately I may develop with this interface, then flip to the cheaper BitScope Micro for production.
All in all then, the BitScope BS10 scratches a lot of itches.

## Notch Filter Issues

The natural ELF/VLF radio signals I want to receive are essentially those of the audio frequency range (perhaps going a little lower, so call it 1-20kHz). If you act as an antenna yourself and plug yourself into an audio amplifier by putting your thumb on the input lead, the signal you will hear above anything else is mains hum (50Hz Europe & Australia, 60Hz US). The natural signals are way weaker than this, so if I want to use the receiver even remotely near power lines, I need to get rid of that hum.

While it would be straightforward to cut 50Hz using a digital filter, the level is so relatively high that it will swamp the desired signal going through an A/D filter leaving little useful resolution. There’s also a good chance of it saturating any analog pre-amplification.

It’s worth noting here that the mains hum tends to be pretty dirty, with lots of harmonics (2x50Hz, 3x50Hz etc.). According to Radio Nature the big ones are the odd harmonics. But for now I’ll just try cutting the fundamental, see if that’s enough.

A related issue is that the natural radio signals are of such a low amplitude that noise generated by the receiver circuit components may also be an issue.

So I’m thinking, whether I use a coil (for the magnetic component of the natural signals) or a free antenna (electrical component), I should first have a little fairly wideband but low noise pre-amp, maybe x10 or x100 to minimise noise addition later. Have this followed by a notch filter and then further amplification to get the signal up to line levels.

The standard simple filter is the twin-t notch, more or less a low pass and a high pass filter bang up against each other. But the notch with this isn’t very sharp. This can be improved by throwing in a couple of op-amps, as in this circuit :

So I tried this on the breadboard, only with approximate values (33k rather than 31.8, 5% capacitors).

This didn’t appear to be working, with white noise as input, the scope showing freq domain trace (top, marker line is 50Hz) :

So then I just tried the passive twin-t, and got a similar result 😦 I guess the noise input/freq domain on scope is a losing combination.

The BitScope has a basic signal genenerator built in, so I tried that on the passive circuit:

Here there is a distinct difference between the input (green) and output (yellow) at 50Hz compared to other peaks.

Reassembling, I tried the active circuit with the sig gen :

Boo, no significant difference. But I strongly suspect this is down to measurement fail again. The sig gen is very limited, only offers 50Hz, 100Hz etc, and even if the components in the filter were perfect, the notch would be at 48Hz. Allowing for tolerances, it could be way out. But assuming the active circuit is working, there could be a sharp notch at say 45Hz, relatively flat at 50Hz.

So next step, I reckon I’ll knock together an analog sig gen, hopefully get a clearer view.

## Getting Started

Hello World from new blog; dipping my thongs into analog water

I have been thinking about and casually researching for this project a few months now. But today I started fiddling with some hardware, so it seemed a good point to start a blog on it.

I’m currently in St.Arnaud near Melbourne, a long way from my base in Italy. A couple of months ago I ordered a bunch of electronic components to get started playing with the analog parts of the system, starting with an ELF/VLF receiver. Of those the only thing that arrived before I set off over here was a Bitscope gadget to allow a computer to be used as an oscilloscope and/or data capture. Coincidentally that shipped from Australia, arrived in good time, unlike the stuff from Farnell in Europe.

I didn’t bring any other kit with me, but my darling Raven took me to a component shop the other day (Jaycar) where I picked up some bits & pieces.

I had planned to try some of the VLF receiver circuits in Radio Nature, which seems like the bible on this stuff. The ones I was looking at have a 2N3819 FET at the front end (the circuits can be found around vlf.it, the site of the book’s author). Unfortunately Jaycar didn’t have these, but gave me what they said was an equivalent. It wasn’t – just a regular bipolar. But I’d also bought a few TL084 quad jfet op-amps, so I should be able to get something together that’s functionally equivalent, if perhaps a bit noisier.

Here’s my prototyping setup:

Bottom right is a bit of scrap wood with hot-glued to it: 2xPP3 batteries; a speaker; breadboard; Bitscope.

The Bitscope’s hooked up to an old laptop of Raven, running Ubuntu. My first try with this, doesn’t seem like the signal’s getting through and their site just happens to be down today. Grr!

Still got things to play with though. I want to get the sound of VLF coming out of the speaker, and I want it to be portable to get away from power lines at first. So I got an LM386 250mW amp chip, as used in some Radio Nature circuits. Haven’t played with one of these before – I’d have remembered, it’s atrociously unstable. The basic (inverting) configuration from the data sheet oscillates happily. But I was able to get something more stable by tweaking the non-inverting config (in data sheet as “AM Radio Amplifier”).

Hopping ahead a little on the breadboard I’ve also got a white noise generator. I’m going to make a 50 Hz active (bootstrapped) notch filter to rid the signal of the worst of mains hum, hopefully allowing the receiver to be used in (or near) the house. I should be able to tweak the notch when the Bitscope’s working, with noise as input.

PS. Not long after posting this I remembered archive.org and found the BitScope troubleshooting tips. My problem was just permissions on /dev/tt1USB (?). So I had a crack at the notch filter. No joy with that yet, but my problem could well be inexperience with the ‘scope, there are a lot of controls.