Emitter-Coupled LC Oscillator

tl;dr : the circuit seems good for high frequencies (low inductance) but for low frequencies is very dependent on the emitter current. Probably suitable for use in an inductance/capacitance meter for radio work (when coupled with a freq counter).

I did a little video.

Here’s the version I breadboarded :

DSCN1746

Here’s some analysis.

For the resonant tank I tried both the primary of a little audio transformer + 10nF and a hand-wound coil + 1nF.

DSCN1769

For the transformer + 10n, the frequency was around 850Hz, but varied a lot dependent on the current to the emitters. With about 0.7v from the pot, 30uA at the emitters, it produced a reasonable-looking sine wave (if you ignore the noise, that’s presumably just from my test setup):

Screenshot from 2018-07-27 11-39-35

Upping the voltage, and hence emitter current, distortion of the shape soon became evident (along with a significant increase in amplitude and change in pitch), until at around 3v  – er, and a lot more current, I forgot to write it down, the wave looked like this, more like wonky relaxation behaviour:

Screenshot from 2018-07-27 11-44-55

For the coil + 1n, around 0.7V at the pot, 30uA at the emitters, it produced what looks like a pretty good sine wave  at around 110kHz :

Screenshot from 2018-07-27 11-49-01

Upping the voltage again, there was still a big difference in the amplitude, but nowhere near as much in frequency. Also there looks to be considerably less distortion:

Screenshot from 2018-07-27 11-47-24

Now by my reckoning, given that the resonant frequency is 1/2*pi*sqrt(LC), this should make the inductor 2mH. In theory it should be possible to estimate the the inductance by the coil’s physical characteristics:

turns : 45 (or thereabouts)
wire diameter : 0.4mm (ditto)
coil diameter : 20cm (ditto)

But when I tried the formula here (estimating the coil length as 1.8cm), I got 55mH. Not even ballpark. I’ve tried a few online calculators but alas they seem about as reliable as my arithmetic, getting values that differ by orders of magnitude.

So I double-checked my algebra, rearranging the formula step by step, producing :

L = 1/C*(2*pi*f)^2

This again gave me a result of 2mH.

Googling a bit more, I found this page with some practical examples, including :

  L uH  Litz Size Turns Coil Width  Q-1.6MHz  Outside Wire Holes
  238    165/46    47    1-7/16       770     15/16 inch from each end

The inductance formulae on Wikipedia suggest that the induction is proportional to the square of the diameter of the coil. Which (flipping the above into cm and squaring) gives a ratio of 13:400. Leading to an inductance of 238*400/13 = 7323uH = 7mH. That’s getting more ballpark.

But it gets better – the inductance calculator linked from the page with that formula uses a completely different formula, with factors more like those I’m looking at:

latex!encoded:base64,TF97bG9vcH1cYXBwcm94IE5eezJ9XG11IF97b31cbXUgX3tyfVxsZWZ0ICggXGZyYWN7RH17Mn0gXHJpZ2h0IClcY2RvdCBcbGVmdCAoIFxsblxsZWZ0ICggICBcZnJhY3s4XGNkb3QgRH17ZH0gIFxyaWdodCApLTIgXHJpZ2h0ICk=

Screenshot from 2018-07-27 13-34-58

Yay! Near as damnit 2mH!

PS. Hmm, one thing I’d forgotten with the above calculations is the self-capacitance of the coil. Turns out that without any parallel capacitor the circuit oscillates at around 190kHz.

Frequency is proportional to the square root of the capacitance, so doubling the frequency is like quartering the capacitance…so if my head isn’t overly scrambled by now, that would give give a self-capacitance very roughly in the region of 250pF.  That feels about right, picturing the total area of those 365pF variable caps.

I’m tempted to try out a better-known LC oscillator like the Colpitts, and draw some graphs of results, buy some precision capacitors and inductors, design an Arduino-based LC meter… But this has already taken loads of time and is veering well away from what I should be doing (ELFQuake proper, something towards work-work, or even tidying the kitchen).

Fun though.

 

 

 

 

 

 

 

 

 

 

Advertisement

Test Gear Triumph! (Arduino to the Rescue)

Tidying up my desk a bit yesterday, I found a circuit on a breadboard I’d left hanging. Months ago I was looking into notch filters for removing mains hum, to clean up a ELF/VLF signal a wee bit. I’d put together a bootstrapped twin-T notch filter, but had got rather frustrated when testing it. I wanted to get a general idea of its response and (assuming it looked ok) tune it to 50Hz.

But I’ve only got a USB port Bitscope oscilloscope (the BS10 mixed-signal model) which does do basic frequency analysis and even has a signal generator built in. Unfortunately there’s no sweep for the sig gen, and the UI is so clunky I wound up making a little generator with an easily-twiddled knob. That still didn’t really give me what I was after in being able to clearly see what was going on.

Anyhow, today I thought I’d take another look. Got everything set up, did some manual sweeping which showed that the component values I’d used were quite a way out (more like 70Hz). But still no clear visualisation of the overall response.

Staring at the desk, pondering what to do next…there’s an Arduino Uno right in front of me. I’ve spent a fair while getting to know the things over the past few weeks. I’d noticed in passing that it had a tone() method, but hadn’t actually played with it. Ok, about 15 minutes later I had this loaded:

void setup (){
}

void loop() {
  int i;

  for (i = 35; i <= 100; i++) {
    tone(11, i);
    delay(10);
  }
}

A sweep generator!

Ok,  its frequency range is limited and it gives a square wave out. So I took the output from pin 11 and fed that to a simple RC filter (15k, 220nF) which took the buzziness down a bit. Stray harmonics aren’t that much of an issue for the current problem, and 35-100 Hz cover the range I’m looking at.

One thing the Bitscope’s waveform generator allows is the fairly accurate setting of frequency. So I set that at 50Hz and put it in one scope input, the output of my notch filter into the other. After a bit of fiddling to get levels reasonably stable, I got this:

notch

The yellow is my 50Hz reference, green the notch filter response. The harmonics on the ref are pretty dire – dunno, I guess it must be clipping. But look at that lovely notch in the green! Around 70 or so Hz, as measured before.

So this setup can help me quickly tune the notch down to where it’s needed. But that isn’t the real triumph here. What I wasn’t sure about is the rest of the response of the active notch. Where the passive notch goes from flat into a 6dB (I think) / octave drop into the notch, this version has noticeable mounds either side. Those are potentially very undesirable. If you look at the 50Hz marker here, my filter as it stands would boost that frequency. While I’m sure I can get the notch in a much better position than this, any drift (maybe due to environmental factors) could be very bad. So at the cost of less sharp notch, I reckon on balance the passive version is probably the one to go for.

PS.

A few hours on, and a bit more progress. I pulled out the active notch circuit, did calculations again and plugged in a passive one. Well, I say passive, am using a TL074 to buffer the signal.

The basic filter circuit is this:

rc_twin_t

Fc = 1/(2 pi R C)

Using C = 100nF (2C just two of them in parallel) and 33k for each of the two Rs on top, a single 15k for the R/2 I got something looking like a cleanish notch, centred on 47.8Hz. It took a little trial & error. The capacitors are just off-the shelf, ceramic I think, probably 10% tolerance but came from the same batch so should be reasonable well matched. 1% resistors, again off-the shelf, same batch.

I forgot to take a screenshot…

But as I measured previously, the ambient mains hum here also contains a significant amount of 3rd harmonic, ie. 150Hz. So I did the sums again for this.

Ran into a slight snag with my setup though – when sweeping up through a reasonable range for it to go over the 150Hz target, the spectrogram display was all over the place.

But, as an alternative to sweep, you can also test freq response with white noise (or an impulse, but that’s another story). Coincidentally I was playing with a pseudorandom number generator just yesterday (for DOG-1), so knew what to look for. I found one, to which I’ve made minor tweaks –

#define speakerPin 11

unsigned long lastClick;

void setup() {
  // put your setup code here, to run once:
   pinMode(speakerPin,OUTPUT);
   lastClick = micros();   
}


/* initialize with any 32 bit non-zero  unsigned long value. */
#define LFSR_INIT  0xfeedfaceUL
/* Choose bits 32, 30, 26, 24 from  http://arduino.stackexchange.com/a/6725/6628
 *  or 32, 22, 2, 1 from 
 *  http://www.xilinx.com/support/documentation/application_notes/xapp052.pdf
 *  or bits 32, 16, 3,2  or 0x80010006UL per http://users.ece.cmu.edu/~koopman/lfsr/index.html 
 *  and http://users.ece.cmu.edu/~koopman/lfsr/32.dat.gz
 */  
#define LFSR_MASK  ((unsigned long)( 1UL<<31 | 1UL <<15 | 1UL <<2 | 1UL <<1  )) unsigned int generateNoise(){    // See https://en.wikipedia.org/wiki/Linear_feedback_shift_register#Galois_LFSRs    static unsigned long int lfsr = LFSR_INIT;  /* 32 bit init, nonzero */    /* If the output bit is 1, apply toggle mask.                                     * The value has 1 at bits corresponding                                     * to taps, 0 elsewhere. */    if(lfsr & 1) { lfsr =  (lfsr >>1) ^ LFSR_MASK ; return(1);}
   else         { lfsr >>= 1;                      return(0);}
}


void loop() {
      /* ... */
      if ((micros() - lastClick) > 500 ) { // Changing this value changes the frequency.
        lastClick = micros();
        digitalWrite (speakerPin, generateNoise());
      }

}

One tweak to use pin 11 as I’d already got that wired up. The other is rather sweet. The original code had a loop delay of 50 micros, related to the bandwidth. But that again wasn’t very clear on the spectrogram. Was nice white noise, but I’m only interested in the low end here. Making the micros 500, and letting the display accumulate for a minute, produced this:

notch-2

There’s a nice notch pretty close to 50Hz, plus my new one, near enough at 150Hz (measured at 145Hz). The peak on the left is probably just an artifact of the setup – FFT does that sort of thing. Also the relative shallowness of the second notch I reckon is at least in part to the fact that it uses a linear scale on the spectrogram.

The values I used here were C = 47n, R = 22k, pleasingly standard values (the resistors gived those capacitors calculated at 22.57k, which was handy).

I’ve just got this set up on the breadboard around a TL074 quad op amp, using 3 op amps for unity gain buffers (each with a 1M to ground). Those things have input resistance of 10^12 ohms. So I’m now thinking I might just use one of them as the input stage for an ELV/VLF receiver. The 2N3819 input stage of the BBB-4 receiver I was going to try has a 10M resistor to ground, seems like plenty of leeway for that here. Input buffer, maybe give it variable gain of something like 1-100, to these filters (perhaps adding a little more gain along the way), then use the spare op amp to drive a couple of transistors for a small speaker/headphone level output.

Just trying it with a longish wire at the input, computer speakers at out, still way too much mains-derived noise to hear any natural signals, but the difference between the different stages of the circuit is really noticeable. I’ll have to get it soldered up, battery power, take it up the fields.

And try it when there’s a thunderstorm around 🙂

 

Electronics World and Wireless World Articles

Last night I was looking at some possible analog circuitry again, on the Natural Radio side, specifically filters to track Schumann Resonances. The frequencies involved are around 7-30Hz. To check the response of these and other filters, I could do with a good sweep generator and a true RMS voltmeter. After sleeping on it I remembered that I worked on exactly these (and various other) mostly audio-oriented circuits in articles I wrote for this magazine, way back in 1993. Unlike digital circuits, for the everyday hacker the analog circuit state of the art hasn’t really changed from then.

These were my first published works, helped to pay for my first IBM compatible PC. I was so chuffed that I got the cover feature with The Twisted World of Non-Linear Electronics (PDF). And what a cover!

Circuits in there include exp/log converters, an RMS converter, an (audio) dynamic range processor (compressor/expander) and a couple of chaotic circuits – that make a horrible noise!

The other article I have a scan of is The Versatile World of OTAs (PDF) – I think I wrote others, but don’t appear to have scanned copies. That’s operational transconductance amplifiers.  They are closely related to regular op amps, but instead of producing an output voltage, they produce an output current. What makes them really useful is that they usually feature an additional input that controls the level of the output current. These things are found pretty much everywhere you might want something voltage-controlled, such as voltage controlled oscillators (VCOs) etc. in analog music synthesizers.

Circuits in there include a tunable active loudspeaker crossover, a couple of voltage controlled filters and a VCO. And…a bat detector. That worked a treat – made one, I with an LM380 or similar amplifier, out on a summer night, chirp, chirp!

Arduino ESP8266 ‘Shiald’, step by step

A little while ago I ordered a couple of Arduino Uno cards along with a couple of ESP8266 WiFi shields. It being my first hands-on with Arduinos, I was rather naive in my choice of shields. I got mine from banggood.com when they were listed as “ESP8266 ESP-12E UART WIFI Wireless Shield TTL Converter For Arduino UNO R3 Mega“, but while figuring out how to use them I found that various other budget tech vendors sell them. Their identifying feature is a charming little typo printed on the PCB :

Arduino ESP8266 WiFi Shiald Version 1.0 by WangTongze

DSCN0002

The major problem is that the only official documentation is in Chinese (Mandarin?), something I haven’t a clue about. But by trawling the web and with a lot of trial and error I was eventually able to get code running on the card. I’ve written the process up spread across previous posts here, but it is rather convoluted, so for future ref. I’m pulling it together here. If you haven’t already bought one of these shields, you may well be better off getting something like a Wemos card.

Requirements

  • Arduino ESP8266 WiFi Shiald Version 1.0 by WangTongze
  • Computer with Arduino IDE loaded (I’m using a regular laptop with Ubuntu OS)
  • USB-TTL level serial converter – NB. I didn’t have one of these, but it turns out to be straightforward to use an Arduino Uno as a pass-through converter
  • USB cable, jumper leads (4 with a socket on one end)

Flashing Firmware

I must admit I don’t know if this step is entirely necessary, there may well be a quicker approach. But it worked for me, and is useful for resetting the card.

Using Arduino as USB-Serial Converter for the ‘Shiald’

The wiring is as follows :

Shiald Debug TX  => Uno Pin 1 (TX)
Shiald Debug RX  => Uno Pin 0 (RX)
Shiald Debug 5V  => Uno 5V
Shiald Debug GND => Uno GND
Uno Reset        => Uno GND

(Uno USB => Computer USB)

Flashing

Before connecting the Arduino to the computer, set the DIP switches on the Shiald as follows:

1 Off
2 Off
3 On
4 On

The following I got from the Wemos page Tutorial – Returning a Wemos D1 Mini to Factory Firmware (AT) :

I had to tweak my paths a little bit, I forget the details, but whatever it took to get esptool.py running from the shell.

The script needed tweaking for the appropriate paths. Run:

ls /dev/tty*

–  and the appropriate port should be obvious on the resulting list. My version of the script looks like this:

#!/bin/sh
# ESPToolDir="$HOME/Downloads/esptool"
FirmwareDir="$HOME/Arduino/ESP8266_NONOS_SDK"
cd "$FirmwareDir" 
port=/dev/ttyACM0
if [ ! -c $port ]; then
 port=/dev/ttyACM1
fi
if [ ! -c $port ]; then
 echo "No device appears to be plugged in. Stopping."
fi
printf "Writing AT firmware in 3..."
sleep 1; printf "2..."
sleep 1; printf "1..."
sleep 1; echo "done."
echo "Erasing the flash first"
"esptool.py" --port $port erase_flash

"esptool.py" --chip esp8266 --port $port \
 write_flash -fm dio -ff 20m -fs detect \
 0x0000 "$FirmwareDir/bin/boot_v1.7.bin" \
 0x01000 "$FirmwareDir/bin/at/512+512/user1.1024.new.2.bin" \
 0x3fc000 "$FirmwareDir/bin/esp_init_data_default_v08.bin" \
 0x7e000 "$FirmwareDir/bin/blank.bin" \
 0x3fe000 "$FirmwareDir/bin/blank.bin"

echo "Done."

The messages given by esptool.py are pleasingly informative, but I found I have to press the reset button on the Shiald when the message got to:

...
Hard resetting...
esptool.py v2.2.1
Connecting...

The original script suggested using miniterm to check this had worked. I used the Arduino IDE. First unplug the USB and set the DIP switchesto all Off.

After plugging back in again & launching the IDE, go to Tools -> Port and choose whatever looks right. Under Tools -> Board choose NodeMCU 1.0 (ESP 12E module). Then go to Tools -> Serial Monitor.

In the serial monitor, set the baud rate to 112500 and then click reset on the Shiald.

You should get a message that ends in ‘ok‘.

At this point you should be able to communicate with the Shiald using AT commands. Two useful things:

AT+UART_DEF=9600,8,1,0,0

This will flip the baud rate down to 9600.

AT+GMR

Gives the versions of various things.

At this point it should be possible to upload software to the Shiald (with the DIP switches Off, Off, On, On) from the Arduino IDE.

Tools -> Board NodeMCU 1.0 (ESP12)

 

I’ve found that it often takes several attempts (and hits of the reset switch) to get a successful upload, no matter what the baud rate.

e.g. this minimal web server:

#include <ESP8266WiFi.h>
#include <WiFiClient.h>
#include <ESP8266WebServer.h>
const char* ssid = "AllPay Danny";
const char* password = "not this";
ESP8266WebServer server(80); // HTTP server on port 80

IPAddress ip(192, 168, 0, 14); // where xx is the desired IP Address
IPAddress gateway(192, 168, 0, 1); // set gateway to match your network
IPAddress subnet(255, 255, 255, 0); // set subnet mask to match your network

void setup() {
 Serial.begin(9600); 
 WiFi.disconnect(); // Disconnect AP

 WiFi.config(ip, gateway, subnet);

 WiFi.mode(WIFI_STA); 
 WiFi.begin(ssid, password); // Connect to WIFI network
// Wait for connection
 while (WiFi.status() != WL_CONNECTED) {
 delay(500);
 Serial.println(".");
 }
 Serial.print("Connected to ");
 Serial.println(ssid);
 Serial.print("IP address: ");
 Serial.println(WiFi.localIP());
server.on("/", [](){
 server.send(200, "text/plain", "Hello World");
 });
server.begin(); // Start HTTP server
 Serial.println("HTTP server started.");
}
void loop() {
 server.handleClient();
}

Pointing a browser at the chosen IP address should now work.

There’s a complication to comms between the Arduino and the Shiald. It seems the serial Tx/Rx lines of the ESP8266 connect to ports 1 & 2 on the Shiald – the Arduino’s Tx/Rx.

Again, I’m not really sure how essential this is, but it certainly works to wire other ports on the Arduino to the serial on the Shiald and use the SoftwareSerial lib. For reliability a baud rate of 9600 seems advisible.

Here’s a little example that worked for me:

#include <SoftwareSerial.h>
SoftwareSerial mySerial(2, 3); // RX, TX on Arduino
void setup() {
 Serial.begin(9600);
 mySerial.begin(9600);
}
void loop() {
 if (mySerial.available()) {
 String msg = mySerial.readString();
 Serial.print("Data received: ");
 Serial.println(msg);
 }
}

Remember before uploading to remove the jumpers and change the board settings in the Arduino IDE.

At runtime, the following wiring worked for me:

Arduino   | Shiald

GND       - Debug GND
+5v       - Debug 5v
Digital 2 - Digital 0
Digital 3 - Digital 1

For my own application I want to be able to read values from the Analog Ins of the Arduino (6) and ESP8266 (1) and expose these (and one or two other little things) on a web server over Wifi. I’ve made a bit more progress towards this, will upload code to this project’s GitHub repo once I’ve tweaked to hide passwords.

So…this is my current setup:

DSCN0004

The lower part is a Shiald piggybacking an Arduino Uno, the upper another Arduino acting as a serial interface direct to the Shiald. Each Arduino is going to a USB port on the laptop.

The wiring – the Shiald has its pins 1 & 2 bent out of line and connected instead via jumpers to pins 2 & 3 on the host Arduino. The Arduino acting as a serial interface has is as above, less the power lines.

For writing code to the Shiald, the DIP switches are at Off, Off, On, On. At runtime they’re at On, On, Off, Off.

I’m still using the Arduino IDE, flipping between USB port and board (Arduino Uno/NodeMCU 1.0).

It’s a bit of a pain flipping between the configs, but takes less time than uploading a reasonably long program to the Shiald, so I can’t really complain.

 

 

Arduino front end ideas

So, as mentioned in previous posts, I reckon it’s worth trying to use Arduinos as front-end microcontrollers for this project, as shown in the block diagram here. An Arduino Uno has 6 analog inputs, and the ESP8266 WiFi card which I plan to use has one. These are quite limited – 10 bit ADCs with bandwidth that at best may go up into a few kHz. As such, while they should be ok for picking up seismic data, they fall far short for the ELF/VLF radio capture which should really go up to the region of 20kHz.

On the seismic side, I think a first pass worth trying is a home-hacked sensitive, one axis sensor, plus a 3 axis gyro and a 3 axis accelerometer. I’ll come back to this is a while – I need to research & buy the gyro & accelerometers. But I have all the components for an attempt at a useful radio subsystem, provisional design as follows…

vlf-filter-based

Starting at top left, the blue circle represents the actual ELF/VLF radio receiver. This will be some kind of antenna, picking up the electric field with a frequency range from somewhere probably in the 100s of mHz up to around say 200kHz. A good starting point for this seems to be the BBB-4 VLF Receiver. It’s a relatively simple 2-transistor design, with a high impedance FET input followed by a bit of further amplification provided by a regular BJT.

A major problem, as mentioned here before is mains hum interference. It seems that as well as the 50Hz fundamental, there’s also a significant amount of the 3rd harmonic at 150Hz. So I propose using notch filters at these frequencies (also in that earlier post). Given what will follow in the circuit, I don’t think these need to be very high Q/narrow, just enough to prevent these parts of the input swamping everything else, saturating what comes next. These filters are shown as the yellow block in the diagram.

Next comes a bank of bandpass filters. The Arduino+ESP8266 offer 7 channels, so I propose having the first being relatively broadband, pretty much just a buffer for everything coming from the receiver (post notches). After each of these will be a simple peak level detector, shown above as a diode & capacitor. The level on these will be passed onto the Arduino/ESP8266 analogue inputs.

(The diagram is simplified a bit. The gain of the different stages will need to be figured out, additional gain/buffering/level-shifting/limiting stages will be needed).

The key references on ELF/VLF radio precursors to earthquakes are vlf.it (note especially the OPERA project) and a chapter in Roberto Romero’s Radio Nature book. Alas, it seems that research is fairly inconclusive (and in places contradictory). Radio frequencies from the milliHertz right up to microwave are mentioned, may contain useful information. But keeping things simple is a major consideration here, so I’ll stick to somewhere a bit below audio up to a bit above. Yes, this project is experimental…

I intend to do a bit more examination of the signals that appear in VLF before going further, though whatever, the choice of frequency bands at this point has to be fairly arbitrary. Pretty much decades in the audio range seem a reasonable starting point. So on top of 0. broadband, here goes:

  1. 0.01 … 10Hz
  2. 20Hz
  3. 200Hz
  4. 2kHz
  5. 20kHz
  6. 40kHz … 200kHz

The question of how narrow/broad to make the filters for best results is another question that I reckon can only be answered with the help of experimentation. But it is possible to make pragmatic educated guesses. I intend using general-purpose op amps for implementation.

At the bottom end of (1.), I suspect it’ll be more effort that it’s worth to worry too much about LF roll off, a simple buffered CR filter, should be adequate. Effectively just DC blocking. For the top end of (1.), a straightforward two op amp LP filter should be fine. For 2. – 5. bandpass filters made from 2 op amps should make a fair starting point. Regarding the steepness of their curves, Butterworth configurations (maximally flat in passband) keep design straightforward.

You may notice that 3. + are at multiples of 50Hz. But I’m hoping that using standard value/tolerance components will make enough offset to alleviate the hum harmonics. E.g. using the Sallen-Key circuit (this is a low pass, but shows what I’m talking about):

Sallen-Key_Lowpass_Example.svg

This gives fc = 15.9 kHz and Q = 0.5, subject to component tolerances (typical inexpensive capacitors are +/-10%). The kind of values that are probably close enough to the decades above to usefully split ranges, but (hopefully) offcentre for the 50Hz harmonics.

I don’t know if I’ve mentioned it before, but as the radio receiver needs to be as far away as possible from power lines (which will likely be determined by my WiFi range), I’m intending using little solar panels feeding rechargeable batteries for power.

While on the subject, I reckon it’ll also be worthwhile adding data from other environmental sensors, notably for temperature and acoustic noise (a mic). Pretty straightforward for Arduinos. Variations in this data may be unlikely to be useful as earthquake precursors, but they will almost certainly play a part in environmental noise picked up by the radio & seismic sensors. My hope is to get a Deep Learning configuration together that will in effect subtract this from the signals of interest.

ESP8266 Shiald Progress!

I’m really tired, but while trying to watch TV got to thinking about the Wifi board I’ve been playing with (described in previous post). I’d got as far as loading firmware that allowed it to speak AT codes. Couldn’t resist having a quick look at what could be done next. Luckily I went to my bookmarks first rather than looking at my notes here, because there was a page I must have bookmarked early on and forgotten about : Arduino UNO + ESP8266 ESP-12E UART WIFI Shield. It contains code for a minimal web server.

Looking at an image in this post reveals that the Shield there is there very same Shiald [sic] I have. Only problem, the author uses a USB-serial adapter to talk to it, something I don’t have. But wait – I found a way of rigging the Arduino to act as such an adapter (previous post).

I saw somewhere, and confirmed (by using a tablet to scan for WiFi networks) that the default IP address for the Shiald is rather an obscure one, off my local subnet anyway. But a bit of googling gave me the info necessary to set the IP to something else.

After fiddling a bit with the baud rate, a little blue light started flashing next to the ESP8266 chip, and it worked!

In the IDE:

Screenshot from 2018-02-07 23-07-57

In the Serial console:

Screenshot from 2018-02-07 23-11-12

Screenshot from 2018-02-07 23-11-35

And in a browser! Woo-hoo!

Screenshot from 2018-02-07 22-45-33

Here’s my tweaked version of the script:

#include <ESP8266WiFi.h>
#include <WiFiClient.h>
#include <ESP8266WebServer.h>
const char* ssid = "AllPay Danny";
const char* password = "not this";
ESP8266WebServer server(80); // HTTP server on port 80

IPAddress ip(192, 168, 0, 14); // where xx is the desired IP Address
IPAddress gateway(192, 168, 0, 1); // set gateway to match your network
IPAddress subnet(255, 255, 255, 0); // set subnet mask to match your network

void setup() {
 Serial.begin(115200); 
 WiFi.disconnect(); // Disconnect AP
 
 WiFi.config(ip, gateway, subnet);
 
 WiFi.mode(WIFI_STA); 
 WiFi.begin(ssid, password); // Connect to WIFI network
// Wait for connection
 while (WiFi.status() != WL_CONNECTED) {
 delay(500);
 Serial.println(".");
 }
 Serial.print("Connected to ");
 Serial.println(ssid);
 Serial.print("IP address: ");
 Serial.println(WiFi.localIP());
server.on("/", [](){
 server.send(200, "text/plain", "Hello World");
 });
server.begin(); // Start HTTP server
 Serial.println("HTTP server started.");
}
void loop() {
 server.handleClient();
}

The blog post goes on to Part 2 Upload code to Arduino, which I’ll try next – when I’m properly rested 🙂

PS.

Just tried this Part 2 bit, essentially comms between Shiald & Arduino. It nearly worked :

Data received: . .
Conoected to AllPay Danoy
IP address: 092.168.0.04C!⸮⸮⸮⸮ٕɁ⸮⸮

I’ve read somewhere that the Software Serial struggles at high baud rates, and this example is using 115200 so presumably that’s the problem. Bit of tweaking required.

PPS.

I flipped the baud rate in the code based on that in the blog post to 9600, and with the Arduino as serial converter uploaded the new code to the Shiald (at 115200 baud), set as NodeMCU 1.0. Uploading took a good few attempts, but finally it worked.

I also changed the Arduino part of the code to use different ports :

#include <SoftwareSerial.h>
SoftwareSerial mySerial(2, 3); // RX, TX on Arduino
void setup() {
 Serial.begin(9600);
 mySerial.begin(9600);
}
void loop() {
 if (mySerial.available()) {
 String msg = mySerial.readString();
 Serial.print("Data received: ");
 Serial.println(msg);
 }
}

The wiring I now have as :

Arduino   | Shiald

GND       - Debug GND
+5v       - Debug 5v
Digital 2 - Digital 0
Digital 3 - Digital 1

The switches on the Shiald are at (1,2,3,4) On, On, Off, Off.

And finally, the Hello World is still visible on the IP address I set. And what’s more, in the serial monitor (now set to 9600 baud) I see:

Connected to AllPay Danny
IP address: 192.168.0.14
HTTP server started.

Yay! It all works.

So…

Next

First thing I should do is pull together all the various bits from the last post and this, with relevant material from linked pages, and write it up as a from scratch to here procedure. I won’t remember, and also anyone that buys the same boards will stand a chance of getting things going.

Then I need to think about what I’m going to do on the analog/sensor side. What I can do with the hardware I’ve got is fairly limited – a key factor being the speed of the data acquisition on the Arduino. But I should have the necessary for me to build something that operates end-to-end with essentially the same topology as my target design.

Regarding code on the Arduino & Shiald, the next steps will be to :

  1. Get the data from the single Analog Input on the Shiald, buffer/filter it and expose it on a local web server. With a little analog pre-amp & filter this should be enough for a single-channel seismometer.
  2. Do the code necessary on a regular computer to access and do something with the data from the web server on the Shiald.
  3. Get the data from the 6 Analog Inputs on the Arduino, buffer/filter it, transfer it to the Shiald and again expose on a local web server. I might well try the analog bandpass filter idea mentioned in my previous post.
  4. As 2. but for the 6 channels.

A global job to put together in parallel with the above is the code necessary for self-description of the units to provide status information alongside the data. RDF and Web of Things time!

So now I’ve got fairly fun jobs to get on with on every side of this project :

  1. Sensor hardware
  2. Arduino/Shiald software
  3. Comms/post-processing software – I can get on with the Deep Learning bits using online sources, haven’t looked at that for weeks
  4. Notification system – hook the Deep Learning bit output to Twitter

I may have to get the dice out…

//// note to self

danny@lappie:/dev$ esptool.py --port ttyACM0 --baud 9600 flash_id
esptool.py v2.2.1
Connecting........_____....._____
Detecting chip type... ESP8266
Chip is ESP8266EX
Uploading stub...
Running stub...
Stub running...
Manufacturer: c8
Device: 4016
Detected flash size: 4MB
Hard resetting...

Arduino – initial experiences

skip to Arduino/WiFi bit, also Issues Raised and a Cunning Plan

Requirements & Constraints

On the hardware side of this project, I want to capture local seismic and ELF/VLF radio data. I’ve given myself two major constraints: it should be simple; it should be low cost. These constraints are somewhat conflicting. For example, on the seismic side, a simple approach would be to purchase a Raspberry Shake, an off-the-shelf device based on a Raspberry Pi and an (off-the-shelf) geophone. Unfortunately, these gadgets start at $375 USD, and that’s only for one dimension (and there may be software licensing issues). I want to capture 3D data, and want to keep the price comfortably under $100. Note that project non-constraints are absolute measurement, calibration etc. So the plan is to hack something. I’m taking rather a scattergun approach to the hardware – find as many approaches as are feasible and try them out.

Both the seismic and radio sensor subsystems have particular requirements when it comes to physical location. The seismic part should ideally be firmly attached to local bedrock; the radio part should be as far away as possible from interference – mains hum being the elephantine wasp in the room. For my own installation this will probably mean bolting the seismic part to my basement floor (which is largely on bedrock) and having the radio part as far up the fields as I can get it.

What seems the most straightforward starting point is to feed data from the sensors into a local ADC, pass this through a microcontroller into a WiFi transceiver, then pick this up on the home network. (WiFi range may well be an issue – but I’ll cross that bridge when I come to it).

The two microcontroller systems that seem most in the frame due to their relatively low cost are the aforementioned Raspberry Pi and the Arduino family. For a first pass, something Arduino-based seems the best bet – they are a lot cheaper than the Pis, and have the advantage of having multiple ADCs built in (compared to the Pi’s none – though there are straightforward add-ons).

Arduino Fun

Quite a while ago I ordered a couple of Arduino Unos and WiFi shields from Banggood, a China-based retailer of low cost stuff. My only prior experience with Arduinos was when my brother was building something MIDI-related and hit a code problem. He mailed me on the offchance and amusingly I was able to solve the problem in my reply – it was a fairly easy bit of C (I hadn’t done any other C for years, but coding is coding).

I instantly fell in love with the Arduino boards (actually a clone by GeekCreit). After very little time at all I was able to use the Arduino IDE to get some of the example code running on one of the devices. Light goes on, light goes off, light goes on… Very user friendly.

ESP8266 Nightmares

In my naivety, I assumed the WiFi shields would be as straightforward. Most probably are, but the ones I ordered have been distinctly painful so far. But I can at least put slow progress so far down as a learning experience. Essentially the ones I got have several issues. The story so far:

The boards I got are labeled “Arduino ESP8266 WiFi Shiald Version 1.0 by WangTongze”. Yup, that’s ‘Shiald’, not auspicious. The first major issue was that the only official documentation was in Chinese (mandarin?). I wasted a lot of time trying to treat them as more standard boards. But then found two extremely helpful blog posts by Claus : Using ESP8266 Shield ESP-12E (elecshop.ml) by WangTongze with an Arduino Uno and Arduino ESP8266 WiFi Shield (elecshop.ml) by WangTongze Comparison.

The first of these posts describes a nifty little setup, using an Arduino board as a converter from USB to TTL level RS232 that the Shiald can understand (I didn’t think to order such an adapter). It looks like this:

arduino1

By default the Shiald plugs its serial TX/RX pins to the Arduino’s, which does seem a design flaw. But this can (apparently) be flipped to using software serial via regular digital I/O pins on the Uno. A key thing needed is to tell the Shiald to use 9600 baud rather than its default 115200. The setup above allows this. This part worked for me.

However, at this point, after bending the TX/RX pins out of the way on the Shiald and plugging it in on top of the Uno (with jumpers to GPIO for TX/RX), I couldn’t talk to it. So going back to Claus’s post, he suggests updating the Shiald’s firmware. Following his links, I tried a couple, ended up with the setup spewing gibberish (at any baud rate).

At this point – after a good few hours yesterday, I was ready to cut my losses with the WiFi Shialds. I’d mentioned to danbri that I was struggling with these cards and he mentioned that he’d had the recommendation (from Libby) of Wemos cards. So I started having a look around at what they were. As it happens, they have a page on their wiki Tutorial – Returning a Wemos D1 Mini to Factory Firmware (AT). The D1 uses the same ESP8266 chips as my Shiald, so this morning, nothing to lose, adjusted the script and gave it a shot. Going back to the setup in the pic (with DIP switches tweaked as Claus suggests) it worked! (Tip – along the way of flashing, I had to press the Shiald’s reset button a couple of times).

arduino-at

So far so pleasing – I thought I might have bricked the board.

(See also ESP8266 Wifi With Arduino Uno and Nano)

After this I’d tried with the Shiald mounted on top of the Arduino in a good few configurations with various different software utilities, haven’t yet got everything talking to everything else, but this does feel like progress.

Issues Raised and a Cunning Plan

Sooo… these Shialds have been rather thieves of time, but it’s all learning, innit.

These bits of play have forced me into reading up on the Arduinos a bit more. For this project, a key factor is the ADC sample rate. It seems that the maximum achievable for a single ADC is around 9kHz (with 10 bit precision). That should be plenty for the seismic sensor. The radio sensor is another matter. I’d like to be able to cover up to say 20kHz, which means a sampling rate of at least 40kHz. I’m still thinking about this one, but one option would be to use an ADC shield – these ones from Mayhew Labs look plenty – though getting the fast data along to WiFi could well be an issue (intermediate baud rates). If necessary, some local processing could be a workaround. I have been intending to present the radio data to the neural network(s) as spectrograms so maybe eg. running an FFT on the Arduino may be feasible.

Along similar lines, I may have a Cunning Plan, that is to shift some of the processing from digital to analog. This is likely to need a fair amount of research & experimentation, but the practical circuitry could be very straightforward. It seems at least plausible that the earthquake precursors are going to occur largely in particular frequency regions. The Arduino has 6 analog inputs. So imagine the radio receiver being followed by 6 bandpass filters, each tuned around where precursors may be expected. A simple diode & (leaky) capacitor peak level detector for each of these could provide a very crude spectrogram, at a rate the Arduino could easily handle. Op amp BP filters are straightforward and cheap, so an extra $5 on the analog side might save $40 and a oad more work afterward.

Regarding the research – a key source is (of course) Renato Romero’s vlf.it, notably the OPERA project – although that does seem to focus at the low end of potential frequencies.

Revisiting Hum Filters

Skip to filter circuits:

I’m in a relatively noisy environment when it comes to mains hum having overhead power lines nearby. So any ELF/VLF receiver I put together will have to deal with this.

To get an idea of what kind of filtering I might need I simply put a jack plug with bare terminals into the mic in of a laptop, held on to it to make myself an antenna, and recorded for half a minute using Audacity. Here’s a snippet of the resulting waveform:

hum

Yup, that is one well-distorted sine wave. Reminds me of the waveform going to bulbs from triac-based dimmers, though haven’t any in the house.

More usefully, here’s the spectrum plot (Audacity rocks!) :

hum-spectrum

There’s a clear peak at 50Hz. Next highest is at 150Hz, the 3rd harmonic. It’s around 12dB down, which (assuming it’s the voltage ratio being shown, ie. 20*log10(V2/V1)) is 1/4 of the voltage. Next comes 100Hz, the 2nd harmonic, about 30dB down, about 1/32 of the voltage (from ratio = 10^(dB/20)).

(I’m in Italy where like most of the world the mains AC frequency is 50Hz. In the Americas it tends to be 60Hz).

So I reckon I definitely need to cut the 50Hz as much as possible, probably 150Hz too.

Digital filters are relatively straightforward to implement in software, but here there’s a snag. The incoming signal is analog, so will need to go through an ADC. The ELF/VLF signal of interest is likely to be of very small amplitude compared to the mains hum. So using say a 16-bit ADC, capturing the whole signal at maximum resolution, it’s conceivable that the interesting signal only occupies a couple of bits, or maybe even be below a single bit. So really the filtering has to happen in the analog chain, before the ADC. Experimentation will be needed, but I imagine a setup like this will be required:

vlf-in-block

There are a few options for the kind of receiver to use, essentially coil-based (magnetic component of the radio wave) or antenna (electrical component), the nature of the early circuitry and pre-amp will be dependent on this. But the main role of the pre-amp is to boost the signal well above the noise floor of subsequent stages (using low-noise components). At a first guess, something in the region of x10 – x100 should be adequate.

Next comes the filter(s). Now the fortunate thing here is that the ELF/VLF frequency ranges I’m considering, say 5Hz-20kHz are pretty much the audio frequency ranges and are thus within the scope of standard audio components. Well, 5Hz is below the nominal 20Hz-20kHz figures given for audio, but the key thing is that at the high end, it’s nowhere near anything requiring exotic components. Even the humble 741 op-amp (dating from 1968) has a unity-gain bandwidth around 1MHz. For the TL071 family, a reasonable low-cost default these days it’s 3MHz.

One option for filtering the mains hum out would be to use a high pass filter and only look at the higher end of VLF (conversely, a low pass filter and go for ELF). But notch (band stop) filters can be pretty straightforward, so it should be productive to target just the 50Hz (and maybe 150Hz).

(A more exotic approach would be to use something like an analog bucket brigade line device as used in many analog phaser & flanger audio effects boxes, with its delay fixed at the period of the fundamental 50Hz. Mixing this inverted with the input signal non-inverted will cause cancellation at the fundamental and all it’s harmonics, ie. a comb filter. But not only does that seem overkill here, it will in effect degrade the signal of interest).

There are a few alternatives for notch filters. While they can be built from passive components, there are significant benefits to using active components, especially in terms of controlling the parameters. For these reasons and circuit simplicity, op-amps are a good choice over discrete components.

There are three leading candidate circuit topologies, as follows.

Active Twin-T Notch

This classic passive circuit is the starting point.

twin-t00

The notch frequency is given by fc = 1 / (2 pi R C)

This assumes a low impedance source for Vin and a high impedance connected to Vo, which can easily be achieved using op-amp buffers. One drawback of this setup is that its selectivity, the slope of the sides of the notch, is fairly poor. This can be significantly increased by using op-amps to bootstrap the T :

Twin-T-Notchfilter

The notch frequency is determined as for the grounded T above, only this time the Q/selectivity can be varied, according to the values of R4 and R5.

But a troublesome problem remains: all 6 components on which the frequency depends have to have precise values to place the notch where required. Any variation is likely to lead to a sloppy notch, of low Q. While 1% tolerance resistors are the norm these days, capacitors tend to have tolerances more like 5 or 10%.  One option is to use reasonably well-matched capacitors (from the same batch) and vary the resistors. But this still leave 3 variables, with some level of interdependence.

(I’ve actually got this one on a breadboard at the moment. For a one-off circuit it isn’t unreasonable to use resistors a little below the calculated values in series with pots, and once fine tuned replaced with fixed values).

Bainter Notch

This is quite a nifty circuit (and new to me). The main benefits are described in the title of Bainter’s own description : Active filter has stable notch, and response can be regulated. Notch depth depends on gain and not (passive) component values.

Bainter_Notch_Filter

I’ve yet to play with this one, but it certainly shows promise. A downside is that the component values calculation is rather unwieldy. Another ref. is this TI doc: Bandstop filters and the Bainter topology.

State Variable Filter

The State Variable topology is very versatile, offering high- and low-pass outputs as well as bandpass. By mixing the high- and low-pass outputs or the input with the bandpass output, a notch can be achieved. Crucially the gain, center frequency, and Q may be adjusted separately. A bonus compared to the Twin-T is that the frequency is determined by just 2 resistors and 2 capacitors. A few days ago I stumbled on a tweaked version of the standard topology which offers a few advantages. I won’t go into details here, it’s all described in the source of this diagram – Three-op-amp state-variable filter perfects the notch.

new-sv-notch

Once I’ve played with the Twin-T a bit more, I’ll have a go with this one. I have a good feeling about it.

Hall Effect-based Seismometer, Sanity Check Experiments

PS. Oops! I made a silly mistake in the breadboarding, if you look closely at the photo you can see that the 10k ground resistor at the input of the op amp is going to + input, not – as intended. Which kind of messes up all my measurements. Hey ho. I have since made a ball-bearing in a jar (1 axis) sensor and roughed out a signal conditioning circuit (which will now need tweaking…), so will repeat the experiment here and do another post asap.

A fun part of this project is the investigation of hardware possibilities for detecting seismic events and ELF/VLF signals. Even though I’m aiming towards minimum budget hardware, my funds for this have been virtually non-existent so I’ve not got much done (grumble, grumble).

For a seismometer, the requirements as it seems to me, are: simplicity, reasonable sensitivity and low cost. Ideally I want to monitor all 3 dimensions with relatively wide bandwidth. A non-requirement is any kind of absolute accuracy or calibrated measurement.

There are a variety of options for seismic sensors, most that I’ve seen fall down for these requirements in one way or another. I won’t go into them here – try searching for accelerometers (low sensitivity), geophones (expensive), pendulum-based systems (complicated build, 3 dimensions would be very tricky…). To give a ballpark, prices for a ready-made seismometer system based on the Raspberry Pi, the Raspberry Shake, start at $375 USD. That’s for one dimension, using a geophone sensor.

Almost a year ago I sketched out an idea for something that might work.

DSCN7976

At the time I picked up a linear Hall Effect device from Jaycar, a UGN3503UA, costing just $7.75 AUS. It’s in case very like a transistor, just 3 pins : +ve, -ve power and output. An example use in the datasheet uses the same principle as I want to exploit:

gear-sense

A magnet is glued to the back of the sensor. As a (ferrous material) cog approaches the sensor, the magnetic field increases, correspondingly increasing the devices output voltage.

The other day a bag of ball bearings arrived. I just got around to having a play. This is what the setup looked like:

DSCN7974

I’ve got the Hall Effect device soldered to a connector to make breadboarding easier. On the left of it is a blob of Blue Tack attaching a 1cm diameter/3mm deep neodymium magnet. On the right, a 5/8″ steel ball precision mounted between my finger & thumb.

Right now I’ve only got a crude +/- homebrew power supply, so I’m using an op amp to buffer a potential divider to provide a lower voltage to suite the device. Another op amp is used to provide a 10x amplifier from the output of the device.

When I put the magnet in direct contact with the sensor it saturated it at one extreme or the other. I seemed to get best results with around 1cm space in between. With a 5.2v supply to the sensor, this led to a no-magnet output of 2.52v (after the 10x amplification). With the magnet, this changed to 3.07v or 1.76v depending on polarity. With the ball bearing at 1cm away this changed by approx 0.01/0.02v, steadily increasing from there to 3.50/1.22v when the ball bearing touched the sensor.

This sensitivity was less than I’d hoped, but will hopefully be enough to be usable if I tweak a few of the components. I reckon it’s definitely worth going for a prototype, see how it behaves in practice.

I’ll need to find a very small jar 🙂

Here are my full notes:

seismo-experiment

 

 

 

Human Impact on Radio Nature

I’ve stumbled on two pieces of info related to this in the past couple of days so reckon it’s worth making a note.

The first is NASA’s Van Allen Probes Spot Man-Made Barrier Shrouding Earth, actually about high-powered VLF transmitters for ground-submarine comms,  probably affecting the near-space environment. “A number of experiments and observations have figured out that, under the right conditions, radio communications signals in the VLF frequency range can in fact affect the properties of the high-energy radiation environment around the Earth”. The main reference paper is on a pay-for site, so little detail is at hand.

The second is Why I Quit Natural Radio, a post by a Radio Nature enthusiast who’s been monitoring ELV/VLF for decades, noting a massive drop off in the ‘interesting’ natural signals he receives. He suggests the cause may be the rise in the use of mobile phones, associated UHF/microwave emissions (‘Cellular frequencies‘) affecting the magnetosphere and/or ionosphere thus impacting VLF propagation. A term he’s coined is rather disturbing ‘electromagnetic smog’.

He also refers to HAARP, a research system (and favourite of conspiracy theorists) that has historically blasted the ionosphere with high power HF. According to official sources it hasn’t been used for a long time. I have my doubts that relatively brief, localised high-energy signals like these would have any lasting impact – similar events might well occur in nature, and these natural systems tend to be very resilient.