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

Tuner Interference Test

Here I am advocating a much closer pitch antenna without doing my due diligence (oh, doo-dah day)!  It dawned on me that my control unit and pitch axis plate are both on double ball joints, so I just loosened things up, repositioned them, and retightened, which produced the following configuration, and which is just asking for unwanted interference:

I then did an auto calibration, followed by some tweaking of Pcal to make it react to my body out past 1 meter.  A bit of dancing around and (literal) hand waving demonstrated that, for this particular configuration of coils and whatnot at least, the tuner doesn't seem to have any influence over the pitch axis stability when both are co-located within a couple of inches.  Which is pretty amazing!  Though I'm pseudo randomly jittering the holy hell out of the LED tuner interface signal timing, and hence the LED display timing, so on some level perhaps not entirely surprising.  But this arrangement works unexpectedly well, it's almost like the tuner isn't even there.

D-Lev Antenna Geometries

A digital Theremin like the D-Lev has somewhat different requirements for the antennas, particularly on the pitch side, than your typical analog Theremin.  Analog Theremins "like" to have a long thin rod on the pitch side as this marginally improves field linearity.  The D-Lev has an adjustable linearizing process in the code, which makes it largely agnostic to antenna geometry (at least in terms of linearity).  Let's look at some options here:

Above left is a rod antenna.  It has low intrinsic capacitance, low mutual capacitance with the hand, and the highest possible RF emission for a given surface area as it is practically one dimensional.  The low intrinsic capacitance gives the tank inductance a smaller energy reservoir to work with, so it oscillates at a higher frequency, which can tax the coil in terms of frequency dependent parasitics.  And the low mutual capacitance lowers the overall sensitivity.  These are a problem for the D-Lev as they lower the SNR and cause it to rely more on dithering and filtering to extract and stabilize the pitch axis value.  RF emission is an energy loss so it can lower the overall Q of the LC resonance, and it can also be a compliance / interference problem, though I haven't really made any attempt to quantify either.

Above right is a plate antenna.  It is the exact opposite of the rod antenna with regards to the three criteria listed, and so makes a much more ideal geometry for use with the D-Lev.  The surface area is maximized, as is the way it interacts with the environment and hand, and RF emission / reception is minimized due to the minimal "longest" dimension.

Above center is a center mounted 'T' pipe antenna.  The larger diameter gives it higher capacitance and response than the rod, and the feed point in the middle gives it roughly 1/2 the RF emission of the rod antenna.  So the T-pipe is a sort of middle ground / compromise technically speaking.

But what are these like to play?  Above we see a top view of equal capacitance response contour lines rather crudely drawn.  Except for at very close range, the rod and the T-pipe should "feel" the same to the player.  The rod and T-pipe provide a non-critical vertical target for the hand, but horizontally they are quite specific as to location, particularly in the near-field.  Being symmetrical in both axes, the plate provides the same response vertically and horizontally.  All geometries in the very-far-field will behave mostly like point sources, any major differences the user may experience will be in the mid-field and especially the near-field.

Above is another top view which shows the sensitivity variation in the near-field with horizontal hand location for the rod and plate (and for the plate this is also the vertical hand location response).  The plate presents a "softer target" for the hand, in that absolute horizontal location of the hand isn't as critical as it is for the rod antenna.  Depending on your learned playing style this may be a feature or a bug for you.

In conclusion, plates are the bee's knees on the D-Lev if you like them / are indifferent to them / can tolerate them.  If you can't, I'd highly recommend a T-pipe type of arrangement.  Bringing up the rear, rods seem to work OK, but they tax what the D-Lev can do, and so if any issues of interference or sticky points crop up, I imagine that you'll likely experience them with a rod worse / sooner than you would with a T-pipe or plate.  These kinds of issues can make the D-Lev look bad and would give me support headaches, so if / when any D-Levs are built for others (by me anyway) I'll probably only offer plate or T-pipe options on the pitch side.  For the volume side you're probably only going to be offered a plate (players seem to be more flexible on this, perhaps due the historic variability of volume antenna geometry).

And the plate and T-pipe work equally well with the proposed D-Lev tour overall ergonomics, whereas the end mounted rod would be problematic (unless you like to raise your pitch arm or address the bottom of the rod when playing).

D-Lib

Still grinding away in the code mines, working on the D-Lev preset librarian.  Had a minor breakthrough yesterday implementing a bank view:

Above is a view of the actual presets in the EEPROM of my prototype.  It's a little involved producing this screen: the program downloads the preset EEPROM data for the desired preset slots on the D-lev (for the view above this is slots -40 thru +39) via the serial port, and then stores that data in a string vector (one string per preset slot).  It then performs a directory listing, filters out the non-preset file names, opens each of the remaining files, and stores the contents to a string vector (again one string per preset file).  Then it compares each preset slot string to all of the file content strings, and if there is a match it assigns the file name to the displayed slot.  If there is no match the displayed slot name is "-?-".  For 80 slots this takes a couple of seconds, most of which is spent on the serial port data transfer.

There is also a directory listing screen, and before I came up with the "live slot bank" thing above which incorporates the functionality, it was just a way to view the available preset files.

Above is the preset file list view.  When in edit mode you can select a file with the arrow keys, and pressing the spacebar or return will copy the file name to the command line and exit edit mode.  Then you can type in " rf " to read the preset file data into the editor, or " owf " to overwrite the preset file with the data currently in the editor, etc.

What was fairly tricky was rolling my own "auto-complete" for the command line.  This is where you enter a character or two and then hit the tab key to complete the remaining file name, but only up to the point of uniqueness.  It's funny how aware you get of the inner workings of these mechanisms in the operating system console when you have to re-implement them.

Finally, with all the serial port code and such just laying there, I thought it would be good to implement a way to pump the SW into the EEPROM.  In the past I was doing all of this via TeraTerm and its TTL macro language, and thought for a while I might implement some small subset of the TTL language.  But in the end I made the Hive simulator / assembler just kick out four byte lines of hex text (this is the way preset files are formatted as well) and wrote a C++ routine in the librarian to upload it.  The new file extension is "*.spi" and the upload process seems to work more reliably than the TeraTerm method.  Here's a view of the beginning of the current SW load SPI file:

3dc407cc
81c09
3e08
0
49809
0
57609
0
65d09
0
82f09
0
d80a00b8
80301b04
8b8030c
fd04d80b
2c01d82f
69065c01
5907cc01

Each line is parsed to 4 bytes.  You can see there is no hex prefix like "0x" or "$" as the format is known to be hex always.  And there are no addresses as the format is pure data.  And there are no compression routines, as shorter data and zeros perform this naturally.  IMO virtually all raw data formats are over-thought, over-featured, and overly complicated.

Currently it's all running in Linux; when it's a bit more finished I'll start in on the Win compile (where the real fun starts).  I need to make the file listing be able to display more files than fit on the screen, add error messages, and generally make the serial port communications as robust as possible.  But it's fairly useful even now.  IMO the bank view, which allows you can see the actual contents of the D-Lev preset slots en mass, is a really essential and powerful thing, and once you have that a lot of other features aren't all that necessary.

So there are a total of four screens in the D-Lev librarian: preset editor, directory listing, bank listing, and raw serial port console.

Can't upload of wrong file turn device into a brick?
Or it's only configuration data?

"Can't upload of wrong file turn device into a brick?
Or it's only configuration data?"  - Buggins

Because the SW resides in FPGA block RAM when running, and BRAM contents can be defined at FPGA configuration, a default SW load is actually part of the FPGA configuration bitstream, and this mechanism makes it impossible to totally brick the D-Lev via the serial port.  The boot code is always in the FPGA, and after configuration it goes out and reads the entire SW load in the SPI EEPROM - but just to calculate and check the CRC.  Only if the CRC is good does the boot code copy the EEPROM SW load into the FGPA and run it, otherwise it runs the default SW in the FPGA.  Even if this process somehow got screwed up, or if the new load is buggy, you can hold one of the encoders down at power-up to just run the default FPGA SW.

The librarian can up / download preset data to / from the SPI EEPROM, and it can also upload new SW loads to the SPI EEPROM.

At first glance I read preset 38 as "fresh hell" and somehow that seemed more relevant than the correct name.

I'm looking forward to having this to replace all of the yellow pad sheets and post-it notes listing preset assignments.

"At first glance I read preset 38 as "fresh hell" and somehow that seemed more relevant than the correct name.

I'm looking forward to having this to replace all of the yellow pad sheets and post-it notes listing preset assignments."  - pitts8rh

And so you shall have it!  I'm going to add a "print to text file" option for the bank screen.

"fresh heli" is my helicopter preset.  The pseudo stereo really helps with the realism.

"Fresh hell" is what I go through with C++!   I've learned to haunt http://www.cplusplus.com/reference/ and very closely examine any exception throwing behavior ("no-throw guarantee" == good).  C++ programs do this nasty thing where, when they encounter something going on they don't like, they just freakin' crash.  Two hours of commenting code in/out later you find that the otherwise innocent seeming isspace() is oddly fussy with certain inputs.  And there are like 10 variations of every string / int conversion function, many of which throw exceptions out of the blue, so it's like a minefield. 

Other than that, the play was fine  - Mrs. Lincoln.

Ditties

Always on the lookout for songs that are:

1. easy to play on the Theremin,
2. easily recognizable,
3. already in my head (or so I think!).

Here are a couple I just started playing so I'm kinda rusty on them:

"What'll I Do" in a cello voice dry (no additional processing): [MP3]

"The Shadow of Your Smile" with the "me" voice in two different registers and a skosh of room reverb added: [MP3]

MediaFire shows that many of my MP3's have been downloaded over a hundred times - thanks for the interest folks!

Nice instruments.

Your playing skills are getting better.

Always on the lookout for songs that are:

1. easy to play on the Theremin,
2. easily recognizable,
3. already in my head (or so I think!).

Could you pleas share list of songs you already found?