Let's Design and Build a (mostly) Digital Theremin!

I believe that the digital conversion, should take place as soon as possible and with the minimum amount of components, to maximize reliability, minimize thermal and electrical instability and reduce costs and environmental impact. And since our micro are not "asthmatic" (funny and appropriate adjective used by you in a few posts), and that we also have the enormous power of the PC, we can use simple strategies and convert directly into digital, the same oscillator.

Our simple technique eliminates the second oscillator, the hetherodyning mixer, the low pass filter, the audio signal, the DC amplifiers and the ADC.

For me a true Digital Theremin should't use hetherodyning and audio signal.

--------------------

On this link: www.thereminworld.com/Forums/T/29160/tell-us-about-your-experience-with-opentheremin

You posted: "They are heterodyning because the asthmatic Arduino can't handle fast precision timing, nor does it handle audio generation very well." So why still thinking using heterodyning, low pass filter and ADC?

I can not simulate your circuit, but I'm simulating the Open Theremin. I will tell you in more details later, but I have already identified some serious limitations:

1) The oscillators using the 4069 are extremely noisy, we used them before moving on to FET and we were never able to achieve a stable useful distance (over 30cm the noise becomes disproportionate and the note flutters)

2) The heterodyning and the Low Pass filter introduce delays and jitters.

3) Since, after all that transformations, the final measuring is a period, why not simply measuring the oscillator's period, as we do?

The schematic I'm referring to is: "Open Theremin ONE V1.2".

Livio, there is a big mistake in your interpretation. :-)

You should not only look at the schematic but also at the code. The LPF output signals after mixing go NOT through 10bit ADCs, they are used on the digital inputs D2 and D8 where they trigger timer interrupts. Thus your points 3 to 6 don't play a role.

And I'm actually not yet sure if the fact that these pseudo-analogue signals are used to trigger interrupts on the falling edge only will not (at least partly) reduce the noise and delay problems which you mentioned in points 1 and 2.

I have everything here to build an open.theremin.uno but my rare free time is actually more than eaten up with Moog Etherwave Theremins waiting for upgrading or repair in my atelier. Thus it will still take a few time until I can see in practice how it behaves. I had the occasion to play one for a few minutes two weeks ago and I was surprised how well it was playable (from the player's or musician's point of view only). During the many years of fiddling around with all kinds of analogue theremins I discovered that there are big discrepancies between theory and practice and I expect the same when I start exploring partly or fully digital approaches. 

Thanks for the explanation, I corrected my post already.

You're probably right that we should try the hardware instead of the simulations, but I'm already sure that the oscillators with 4069 are too noisy, as we used them for a long time.

To check this you should try to keep your hand steady at about one meter, to see if the note remains steady without fluttering. I am sure that with the 4069 this is not possible.

Instead our CapSensor can arrive at these distances and far beyond, with great stability (thanks to Colpitts oscillator, the low noise BF862 FET and a very hard decoupling through low value capacitors, that allow to work with an oscillating circuit with a high Q-Factor).
Schematics here: www.theremino.com/en/technical/schematics/#capsensor
And data sheet here: www.theremino.com/wp-content/uploads/2012/02/Slave_CapSensor_Datasheet_ENG.pdf

 

Hi Livio,

it's a sign of very stable technology if you can get stable pitch values at 1m or more from the antenna, but from the classical precision theremin player's point of view, this might be outside his comfort zone...

BTW: There is a kind of simple mathematical low pass filter in the code of the open.theremin.uno which averages partly consecutive pitch values, using always pitch=(0.75last_pitch+0.25actual_pitch). This might contribute to the stable feeling which I had when playing the prototype exposed in Switzerland (I deleted the part of the code which does the null and linearity correction, so that the principle is better visible):

if (TIFR1&(1<<ICF1)){                      // If capture event

    pitch_counter=ICR1;                      // Get Timer-Counter 1 value

    pitch=(pitch_counter-pitch_counter_l);   // Counter change since last interrupt -> pitch value

    pitch_counter_l=pitch_counter;           // Set actual value as new last value

    pitch_v=pitch;                  // Averaging pitch values

    pitch_v=pitch_l+((pitch_v-pitch_l)>>2); 

    pitch_l=pitch_v;    

 

    TIFR1 = (1<<ICF1);                          // Clear pitch capture flag

  }

"I believe that the digital conversion, should take place as soon as possible and with the minimum amount of components, to maximize reliability, minimize thermal and electrical instability and reduce costs and environmental impact." - livio

I wholeheartedly agree, and try to live by this as well.

"You posted: "They are heterodyning because the asthmatic Arduino can't handle fast precision timing, nor does it handle audio generation very well." So why still thinking using heterodyning, low pass filter and ADC?"

I don't plan on doing this in the analog domain like the Open.Theremin, but in the digital domain within the FPGA.  The FPGA I/O is simply logic level, not ADC.  The NCO, XOR, and 2nd order LPF are digital constructs inside the FPGA.

"1) The oscillators using the 4069 are extremely noisy, we used them before moving on to FET and we were never able to achieve a stable useful distance (over 30cm the noise becomes disproportionate and the note flutters)"

I'm using a different oscillator topology than the Open.Theremin.  Half of it uses faster logic with feedback to make it linear, the rest is inside the FPGA.  I had an earlier version (capacitive feedback rather than inductive) running and it was definitely sufficiently stable (no fluttering).

"2) The heterodyning and the Low Pass filter introduce delays and jitters."

The delay is not an issue if kept below ~1 ms.  Jitter remains to be seen.

"3) Since, after all that transformations, the final measuring is a period, why not simply measuring the oscillator's period, as we do?"

That's what I was doing (frequency actually) but heterodyning seems to dramatically increase the precision.  Linearization / sensitivity / offset is much easier in the log2 domain, and I need log2 for the tuner anyway.  Exp2 is for the final exponential pitch number.  Period measurement seems inherently more linear in simulation, and gives more information in the far field where the noise is perhaps more pronounced due to processing.

livio, if you look back a few pages in this thread you'll see graphs I that posted where I was investigating the information increase that heterodyning gives over direct measurement (page 45) and linearization and sensitivity (page 46).  You might also be interested in the hand capacitance model I've developed, as it removes a lot of conjecture from this type of endeavor.

(responding to Thierry)

We use exactly this average formula in many of our applications, it is a Infinite pulse response filter, called "Moving Average".

A more generalized version is: value = value + (newvalue - value) / n

In our application HAL (Hardware Abstraction Layer - the hearth of the Theremino System) the value "n" can be changed continuously by the user, to get more or less average, with a great average, values are more stable but the reaction speed is low.

--------------

Very interesting your words about the player's "comfort zone" !!!

Can you please write what is the normal range of this area?

That's what I was doing (frequency actually) but heterodyning seems to dramatically increase the precision.  Linearization / sensitivity / offset is much easier in the log2 domain, and I need log2 for the tuner anyway.  Exp2 is for the final exponential pitch number.  Period measurement seems inherently more linear in simulation, and gives more information in the far field where the noise is perhaps more pronounced due to processing.

I think what you say is true, mainly with regard to linearity.
Perhaps your method can achieve very good results and what you say about the exponential pitch, is absolutely right. 

But I think you can get very similar results, linearizing with a mathematical formula, like we do.

------------------

For those interested, this is the method we use to calculate the hand position:

    Private Sub CapSensor_CalculatePosition()

        ' ----------------------------------------------------------- input capacitance ( after serial capacitor )

        Cap_input = CSng(ELEC_C2_FromSerial(Cap_total - Cap_zero, Cap_serial))

        ' ----------------------------------------------------------- K area 

        ' Teoric K_Area is: 88 * 100 * Area_cmq

        ' from: 0.885F(cap. to dist. coeff.) * 100(cmq to mmq) * Area_cmq

        ' ---------

        ' A High coefficient ( 80 .. 160 ) expands the "Near" zone

        ' A Low coefficient  ( 40 .. 80 ) expands the "Far" zone

        ' ---------

        ' The user can change this Near-Far linearity 

        ' increasing or decreasing the parameter "Area_cmq" 

        ' ---------

        Dim K_Area As Single = 88 * Area_cmq

        ' ----------------------------------------------------------- MaxDist and MinDist correction for area

        Dim K2 As Single = Area_cmq / 100.0F

        Dim MinD As Single = MinDist_mm * K2

        Dim MaxD As Single = MaxDist_mm * K2

        ' ----------------------------------------------------------- distance in mm 

        Dist_mm = K_Area * MaxD / (K_Area + Cap_input * MaxD * MaxD)

        ' ----------------------------------------------------------- distance limits

        If Dist_mm < 0 Then Dist_mm = 0

        If Dist_mm > MaxD Then Dist_mm = MaxD

        ' ----------------------------------------------------------- range

        Dim range As Double = MaxD - MinD

        If range < 0.1 Then range = 0.1

        Value_Normalized_New = 1 - CSng((Dist_mm - MinD) / range)

    End Sub

    Private Sub CapSensor_CalculateTotalCap()

        ' ----------------------------------------------------------- total capacitance ( in parallel to inductor )

        Cap_total = CSng(2.53302955E+16 / (Inductor_uh * Freq ^ 2))

    End Sub

 

And this is the exponential formula we use for smoothing vaues:

    Friend Sub SmoothValue_Pow(ByRef value As Single, ByVal new_value As Single, ByVal speed As Single)

        Dim delta As Single = new_value - value

        Dim delta_sgn As Single = Math.Sign(delta)

        Dim delta_abs As Single = Math.Abs(delta)

        Dim delta_pow As Single

        delta_pow = CSng((speed / CommFps * delta_abs) ^ 2)

        If delta_pow >= delta_abs Then

            value = new_value

        Else

            value += delta_sgn * delta_pow

        End If

    End Sub

This code is only partial, the complete implementation is in the class "Pin" of the application HAL, you can download from here: www.theremino.com/en/downloads/foundations/

Our software is Open Source and Free, so anyone interested can download our apps, copy the interesting sections and use them, also without specifying the source.

"But I think you can get very similar results linearizing with a mathematical formula, like we do."  - livio

I do linearize with a mathematical formula, it's a second order polynomial.

I do linearize with a mathematical formula, it's a second order polynomial.

You are doing a very good work!
It is a complex way to do this, but potentially the configuration you propose, could also reach better results than our CapSensorHQ. 

When your "physical interface" is over, it would be nice to connect it to the Theremino system SLOTS (I will help you about this), in order to take advantage of all our software and the infinite possibilities of connection, that can be obtained from our modular system. For example to exchange data with VST plugins, MIDI, OSC (Open Sound Control), UDP (Ethernet) and hardware sensors and actuators. Also with apps like our ThereminSynth or MaxMsp, Processing, PureData etc ... Or writing small musical processing applications with Theremino Script, or complex musical programs with DotNet, C++, Java and Pascal.

To give you an example, you can refer to this video, where gamma rays are converted to music, via our apps ThereminoMCA and ThereminSynth: www.youtube.com/watch?v=aPfE0xtoSZI

For other modularity and interaction examples, visit our YouTube channel: www.youtube.com/user/ThereminoWorld/videos

"If you heterodyne (analog or digital) and measure the period rather than the frequency, you can dramatically increase resolution. Having a high speed clock with which to do that counting helps a lot, and this is where an FPGA really shines in comparison to a processor. - dewster"

This is not true! 
We measure the period, without heterodining stages.
We measure with a High Speed Clock, without using an FPGA.

This is the method used by "ThereminoSystem CapSensorHQ" 
---------------------------------------------------------------------------------------------------------------

1) The FET oscillator spans from 2.7 MHz (no hand) to 2.5 MHz (hand close to the antenna) 

2) The oscillator is immediately squared by a Schmitt trigger and divided by a microcontroller counter.

3) After the (16384:1) divisor we get a frequency of 165 Hz to 150 Hz (period = 6 mS to 6.6 mS)

4) We count a 32 MHz clock for that period, getting a digital count of about 50K to 800K, like a 16 to 20 bit ADC, as summarized in the next table:

- Resolution of 1 part over 800 000 at  40 Hz (24.0 mS) (divisor  65536:1)
- Resolution of 1 part over 400 000 at  80 Hz (12.0 mS) (divisor  32768:1)
- Resolution of 1 part over 200 000 at 160 Hz ( 6.0 mS) (divisor  16384:1)
- Resolution of 1 part over 100 000 at 320 Hz ( 3.0 mS) (divisor   8192:1)
- Resolution of 1 part over  50 000 at 640 Hz ( 1.5 mS) (divisor   4096:1)

Our strategy makes possible, to get a variable tradeoff between resolution and speed!

The final resolution is high, the response fast and the precision absolute (the same of the quartz).

In addition our strategy benefits from:

- Constant resolution and constant speed, on the whole frequency spectrum.
- No user trimming, no factory trimmings, no variable capacitors.
- Calibration done completely in software, with a "Calibrate" button, in some milliseconds (Note 1)
- Complete software knowlege of all the involved physical quantities (Note 2)
- Very simple hardware implementation.