Modular Synth Reconfigured

Mostly pics for now, it took me ages to fit the new power supply & test, did have other things to do today…

A 1 minute video of the testing

This is what the (mostly) analog (moderately) modular desk looks like now. Loads of lovely rack space!

These two are modules I put together myself. First was the one on the right, two attenuators (a pot, I probably DC blocked so a couple of caps too) and two amplifiers (a couple of op amps each. I believe I used kcad for the schematic, should be around somewhere, but was pretty much datasheet stuff.

The one on the left, dual low pass gate, was very experimental. Vactrol-based, entirely passive. Surprisingly useful for very few components. The front panel was also a (failed) experiment.

This is just a passive switch box I made to quickly change monitoring setup. Included here because the front panel technique is the one that has worked the best. Design on computer (I used LibreOffice Draw, it’s good for block diagrams etc). Do a rough printout to use as a template, cut/drill 3mm aluminium to match. Do a high quality printout on glossy paper. Laminate. Cut out and glue to the aluminium, cut out the holes with a scalpel.

This is the Chatterbox, something I put together just before I started looking into modular. ESP32-based with decent 2-channel DAC, has MIDI in, and I even got WebSockets over Wifi going so it could be controlled from a web page. The ESP32 also has Bluetooth support, but I haven’t played with that yet).

Although I love the look, the case took way longer than I’d have liked to get together. Eurorack time!

It also revealed loads of little issues, eg. those push switches are hard work.

A bigger issue was that my code got messy. I’m not very experienced with C++ and the dual cores of the ESP32 did my head in a bit.

So next I made a version of another old idea, the Dreamachine. Like the Chatterbox this needed some controls and some DSP (for modulating the lights and generating white/pink noise for audio). My main aim was making a reasonably solid code framework. Instead of analogue pots I used rotary encoders and added a little display, only used the internal DACs.

I’ve got most of the coding done. The main frameworky idea was to have ESP32’s core 0 running all the UI code, core 1 doing the DSP. This seems to be working nicely, should be a good basis for other synthesis on the ESP32.

(The cable connects the device to an battery pack attached underneath).

I’ve got a bunch of analog and digital modules at various stages of design. More on those another day.

Happy New Year!

A good time to take stock, huddled in front of the fire.

Boo!

As is often the case, I’ve been moving more slowly on this project than I’d have liked. Lack of resources is a continuing problem, but my own tendency to procrastinate has been by far the biggest obstacle to progress. On top of this, my main dev computer packed up recently, so until I can get that fixed or replaced I’m getting things set up again on an old laptop. Frustrating.

Three Steps Forward…

My strategy of taking a multi-pronged approach has had its pros and cons. I’ve got a prototype VLF receiver mostly built and have spent quite a lot of time playing around with Arduinos and related devices. On the software side – which is really the novel aspect of this project – I did make reasonable progress, getting together a provisional system design and some of the implementation. But then stalled. My desire to build hardware to allow local data collection has been something of a distraction, when there’s nothing stopping me from working with data from INGV and VLF.it.

Plans.

Looking ahead, I really need to reboot myself on the software dev. The ultimate target for running code will be nothing more sophisticated than this laptop. But for exploring algorithms and probably NN training, pre-optimisation, I reckon using cloud services will be my best bet. Concurrently I can look at some of the side prongs that I want to include in the system as a whole – notably web publication of data and automatic generation of Twitter notifications.

As everyone that’s worked on a solo project knows, I’ve also got a lot more material in my head or at best sketched in notebooks that needs writing up. How often has the New Year Resolution been : “Write more docs.”.

Mini-Seismograph

On the hardware side, until I’ve got my income a bit better sorted out I am pretty much limited to rather a scattergun approach using what ever components I have at hand. As well as finishing off the mostly-built VLF receiver, I’ve also got the bits for a basic seismograph. It’ll essentially be :

•  ESP32 – microcontroller + comms :  core of the subsystem, handling the acquisition and preprocessing of data, which it will expose using a basic web server, accessible from the local network (the ESP32 includes WiFi connectivity).
• MPU6050 – sensors : accelerometer +gyroscope : a tiny MEMS device, connected over I2C.
• MicroSD card – data logging : experience shows that 100% connectivity is implausible, so some local history is very desirable
• Tiny RTC card – realtime clock :  the comms will be async, so accurate local timestamps are a must.

The ESP32 is a remarkably capable little device and I’m reasonably confident of the viability of interfacing the peripherals. Hopefully just a matter of plodding through example code for each, tweaking as needed.

The MPU6050 sensors are much less sensitive than those of typical seismometers. Only events with significant magnitude are likely to be detectable. It remains to be seen, but I have my suspicions that having 2 different types of sensor in there mean it will, with a bit of wrangling, be possible to get more effective sensitivity than the individual sensor data would yield. Whatever, once the wiring and code is in place for this setup, it should be trivial to extend it to use a more sensitive sensor. (Note the Raspberry Shake 4D configuration.)

Also…

I’ve got a little tangential project on the go. ELFQuake is in essence about trying to model aspects of a physical system : Earth geology and its electronically-detectable artifacts. Creating an analogue in software that captures enough to be able to make useful predictions. Also I’m increasingly convinced that the design of analog circuits between the sensors and standard data acquisition elements (ADCs etc) will have a major impact on the potential success of the system. Putting these points together, it shouldn’t seem that off the wall that I’ve been working on the design of an analog computer. (I must admit I also want to play with chaotic systems, this is something I’ve been messing about with for years).

 

 

Connecting all the World’s Circuits

I’ve been a bit frustrated in recent weeks by electronic circuit design tools. The typical process is to draw out the circuit schematic, run simulations and then generate/draw PCB layouts etc. Many of the tools (especially on *nix) use SPICE format to represent the circuit topology between the different operations.

The tools I’ve looked at so far all appear to have one major flaw or another.

To give just three examples:

• gEDA – rather out-of-date, clunky UI
• KiCad – the netlists it generates aren’t quite compatible with SPICE (circuit emulation) tools
• Fritzing – the netlists it generate are nothing like SPICE format (I believe it uses XML)

So, the go-to representation as far as I’m concerned for pretty much anything is the Resource Description Framework (RDF). So I had a quick search around looking to see if anyone had looked at SPICE in RDF before. D’oh! I found a SPICE vocab I’d roughed out on GitHub around 2011. Jeez, my memory.

So it turns out that most of what I might have put in this post, I’ve already written up in Adding SPICE to the Semantic Web.

Just a couple of things to add here.

Why not use JSON? 

Since I did that post, JSON has become fairly ubiquitous, I’m sure it’s now most coders’ go-to representation of data. But in its basic form it isn’t Web-friendly, in the sense that it doesn’t natively support links.

Links could make things much easier to share and find: circuits, components, datasheets etc (the description of the circuit in RDF would include URLs for the components, which in turn could be associate with their characteristics, with their datasheets, etc etc).

There’s even a commercial angle. Given the list of components, a bill of materials can be generated. But typically nowadays you have to trawl through vendors to find suitable suppliers. But in RDF, the component could be associated with a vendor, with fields like the price etc. A distributed SPARQL query could figure much of this stuff out automatically.

Ok, why not use JSON? – There’s JSON-LD, which is an RDF representation, it’s JSON with links included.

One other idea. In the middle of typing this, I had a brief chat with Reto, told him what I was typing. He wondered whether there might be a role for inference (which is a good question, given the existence of RDF/OWL  reasoners). Hmmm, my immediate response was, yeah, maybe something like consistency-checking a circuit for dangling wires. But Reto made the point that OWL probably wouldn’t be the best reasoning for the job, this might be more of a SHACL use case.

 

VLF Receiver Oddments

I’m doing a little more on a simple handheld VLF receiver I’ve been working on. For an electric field receiver all that’s essentially required is a whip antenna and a high input impedance, high gain, audio frequency amplifier. Some filtering is desirable to limit the bandwidth and cut the noise of mains hum.

I’ve already soldered up the input & filter stages, yesterday breadboarded the output stage – an amplifier to drive a little speaker/headphones. But I’d forgotten a key consideration, how much overall gain the thing should have.

A quick google later, found this rather nice poster on NASA’s site, “Building and Testing a Portable VLF Receiver“.

It doesn’t have the schematic – I expect it’s one of their INSPIRE models. But it does have what I was looking for. Signal is of the order of microvolts, their overall gain is x1500 – rather more than I’ve allowed for so far. There’s a feedback resistor change in my near future.

First though I reckon I’ll draw up the circuit as it stands (in KiCAD). I can figure out the gain bits from there, and simulate. I also need to check roll-off at the frequency extremes (call it 20Hz & 20kHz). Hmm, gain of 1500, that’ll be tempting to stability problems.

When I was looking for the gain requirements yesterday, I opened a bunch of the results in browser tabs. I found what I was looking for in the first, but am pleased I didn’t close the others. While vlf.it is the site for all things Radio Nature, I did stumble on some material I hadn’t seen before.

This page is notable : VLF Natural Radio Reception at techlib.com. It features a variety of simple receiver designs. One piece of utter genius jumped out at me. The major problem with VLF reception is interference noise, so ideally you want to situate the receiver a long way from sources of that – eg. houses, computers… Which is a pain if you want to record/analyze the signal. Here the author bends a baby monitor transmitter, replacing the mic with a VLF preamp. Voila, instant remote receiver.

I love this :

“The antenna was horizontal and near the ground under my truck for this recording. That turned out to be a questionable location, by the way! Not only did several neighbors become alarmed by it, but a couple of police officers also spotted the thing. I must admit, it does have a bomb-like appearance! It spent the rest of the night under an overturned flower pot with the VLF antenna sticking out the little drain hole in the bottom.“.

Another very promising site I ran across, have still to read, is Larry’s Very Low Frequency Site. Looks like there’s some good material.

For now, back to the KiCAD.

 

Matching Transistors for Log/Exp Converters

Slightly off-topic again.

I’ve been looking at analog log/exp converters, primarily with music synth applications in mind. Here’s a typical Voltage Controlled Oscillator circuit, which uses a pair of transistors as part of the exponential conversion sub-circuit.  But there may well be potential for using an analog log converter to effectively improve the resolution of the ADC part of a seismic data acquisition system. Note that earthquake magnitude measurements are usually expressed as log values – e.g. in the Richter Scale, a magnitude 5 event has an amplitude 10x that of a magnitude 4 event.

There’s a useful selection of general-purpose log & exp converters in TI Application Note AN-30. When building such circuits from op amps + transistors, there are two factors that can significantly affect accuracy. The first is the effect of temperature on transistor characteristics. This is usually offset by using a temperature-sensitive (‘tempco‘) resistor. I don’t currently have any of these… The second issue is that the circuits generally involve a pair of transistors in a balanced configuration. Here it’s useful to select transistor with closely matched characteristics.

The classic circuit for testing for matching was given by none other than Dr. Robert Moog:

More sophisticated variations are described at Music from Outer Space. I’ve got a bag of 100 2N3904 transistors (about €2 from China), so I decided to have a go at finding some matched pairs.

My circuit began with a silly mistake. I’d misread Moog’s circuit, thinking that both test points were floating, not noticing that one was ground. I only realised once I’d got the thing breadboarded. No big deal, and buffering both lines did offer a bit more scope for experimentation. This is what I ended up with:

I used KiCAD for the diagram, files are on github.

The left-hand side is the same as Moog’s, just with a better op amp and 1% resistors. The right-hand side is a basic instrumentation amplifier consisting of a couple of unity-gain buffers feeding a differential amplifier with gain of 10. I initially tried a gain of 100 (using 220k rather than 22k around U1C), with a bias voltage (from a pot) on pin 5 of U1B, but this turned out to be over-sensitive, it was too easy to flip the output to one rail of the other.

I didn’t see much point in accurate reference voltages as in the MFOS designs, my 12v is regulated and after I’d left everything connected for a little while, there was too much variation in individual measurements.

To do mass comparisons while avoiding touching the transistors (and warming them up), I stuck 40 of them into a breadboard:

Moog refers to Vbe values of around 0.6V, and a target of matching within 2mV. I got similar values, 0.573 +/- 0.001V with only a couple of exceptions (even then less than 3mV difference). This seemed a little too good to be true, so I played around with things like changing the bias voltage, but still the values did seem surprising closely matched. Then a simple sanity check occurred to me. Putting a BC109 under test, this gave a value of 0.553V. Not matched to the 2N3904s.

So it looks like I got lucky 🙂

 

 

Arduino White Noise Generator

Aiming towards 16 bit.

I’ve done a video to demonstrate.

I’m still learning about what can be done with Arduinos, the main target being data acquisition for the ELFQuake project (the material in this post is all about getting stuff out). But as it involves breadboarding, I’ve got another fun target in mind – a hybrid music synth.

I’ve been reading around what other people have done with the things. For analog output, especially when considering music synthesis, there’s a problem that needs solving.

(Note I’ve been playing with an Arduino Uno – some of the other models have improved features).

The Quality Issue

Unless you’re after bitcrushed, lo-fi, glitch sounds, you need a decent sample rate and resolution. For ballpark, CD audio has a 44.1kHz sample rate, offering something under 22kHz bandwidth, see Nyquist frequency. It’s 16-bit, which means in its basic form, it has a Signal/Noise Ratio of about 96dB – though there are tricks to improve this.

A typical digital synth would use a high sample rate through a dedicated Digital-to-Analog (DAC) chip, with associated circuitry to get things into the analog domain. But as they stand though, Arduinos are very much 8 bit-based. You can get 8 bit analog signals out of a digital output pin using Pulse Wave Modulation (PWM), followed by a very simple analog filter. The easiest way is analogWrite(pin, value). But then you pretty much immediately run into the sample rate problem – I can’t remember offhand, but it’s slow. But the Arduino has 3 built-in PWM timers which can be used to get a much better rate (into the 10s of kHz, so tolerable quality should be possible).

When using the interrupts, the code starts getting obfuscated, but the principle is the same as analogWrite().
(TCCRxx refers to control registers, OC1A (Arduino pin 9) and OC1B (Arduino pin 10). For more info check the ATmega328 Datasheet.)

For the resolution, it’s possible to combine the analog from more than one PWM output. There’s some excellent material on the Open Music Labs site about this, but the basic idea is to scale the (analog) values from the PWM outputs, so eg. one is 256x the other, corresponding to the low and high 8 bits of a 16 bit signal. My basic circuit looks like this:

 
D9 ---- 1k --------------|

D10 --- 200k --- 56k ----|---> OUT
                         |
                    10n ===
                         |
                         |
                        GND

However, it can pretty much be guaranteed it won’t be 16 bits coming out of here.

The Mozzi synth project uses the same kind of configuration, but they, more realistically, only aim for max 14 bits (and kinda amusingly, their example of a 14 bit output actually only receives 8 bit values, left-shifted 6 bits, and their circuit uses a 499k/3.9k ratio, specified at 0.5% tolerance…). More generally, I doubt very much if the actual output using the kind of circuit above will get anywhere close to 14 bits.

However (2), my gut feeling is that by paying a little more attention to the analog side, it will be possible to get something like 14+ bits. I plan to experiment on this, using a few little tricks:

• send the digital outputs through voltage-referenced comparators, so they are as close to each other in ‘raw’ state as possible
• buffer the voltage division
• use considerably more sophisticated integration/filtering of the PWM (perhaps independently for each output)

Noise Generation

I must admit to have been gobsmacked to have seen some folks using wavetables to generate noise. The shift register-based generators only need a handful of very low-level processor operations, they should compile down to very fast machine code. Depending where the table is stored, I wouldn’t be surprised to find out the computation is faster than the lookup. On a memory-limited device like the Arduino, I’d say it’s worth the trade-off whatever.

To be continued…

Here’s the code (I’ve left in lines that refer to the ADC, might want to use a pot to control freq or level):

*snip*

 

oops – I forgot about all the << and >> in there, so rather than figuring out the markup escaping here, I’ve popped it on github.

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 :

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.

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

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:

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 :

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:

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:

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.