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

' "Not that I'm anywhere near the artisan he was, but I wonder if Stradivarius had people hectoring him to "just slap some varnish on that hunk of carved wood and get it out the door!" ' - dewster

dewster, I'm sure you are a bit of an artisan in your own way :-)

With regard to Stradivarius: his workshop produced A LOT of fiddles and as such he would have worked on a production line kind of system. With this in mind, yes, he would be under pressure to get them out as soon as he could.
Unlikely that he would have used bespoke varnish, more likely that he would have used something from the high end painters' drawer of the time, possibly modified a little.
There is a tempting taster of a varnish recipie which he left and people use it but as with many things, a good varnish job is all in the application...get 5 fiddle makers in a room and you'll get at least a dozen different ways to varnish a fiddle from them :-)

Roy

NB-I read this comment of yours dewster late in the thread but I couldn't resist...

"dewster, I'm sure you are a bit of an artisan in your own way :-)"  - RoyP

I am a bit of a stickler when it comes to coding practice and style.  Pretty is as pretty does, and IMO code can never be pretty enough.

"With regard to Stradivarius..."

In that vein, there was a PBS Nova titled "The Great Violin Mystery" featuring high-energy physicist Jack Fry that was pretty awesome when I watched it as a young adult.  I remember he bought a bunch of inexpensive unfinished factory instruments and transformed them with his scientific analysis and techniques.  He died in 2011 at age 90, but did this video a couple of years before that (skip ahead ~20 minutes):

I think the violin field has more hocus-pocus and voodoo than the Theremin field (if that's indeed possible).

Looking at PLL conversion from one frequency to another in order to generate the 128 * Fs needed for SPDIF.  The Altera Cyclone 4 board I have has a 50MHz XTAL osc on board, and the PLLs internally will do [1:512] multiplication and division of this.  It turns out the PLL config wizard in Quartus will pick the optimal mul/div numbers for you, but I only discovered this after writing a spreadsheet to do it.  Ah well, one of the secrets to life is to learn something new each day, even if it is just new to you.  Here's the spreadsheet:

http://www.mediafire.com/download/6bl8n7q7j9kiz78/nearest_rational_number.xls

The upshot is that you can generate 128*48kHz +11ppm, and 128*44.1kH +64ppm from the 50MHz XTAL & PLL, and both of these errors are probably small enough to feed external digital equipment without too much worry.  I'm thinking of going with Fs=48kHz mainly to give a bit more cushion between the audio and nyquist.

Been working on testing the SPDIF DAC box I got from China.  I made an FPGA-based tester that exercises it:

http://www.mediafire.com/download/ktx2vw3x38o9f4a/spdif_tester_2014-09-13.zip

It works.  The tester sends a sine wave and a triangle wave, both around 1kHz but not quite the same frequencies, to the left and right channels.  The analog looks fine on my scope but I don't have the equipment to do much in the way of distortion or noise floor analysis.

One mystery I can't figure out is why this box has less digital headroom than I would expect.  If I send it ~0dB there is severe clipping, and moreso on the negative swing.  I have to cut the digital signal back to -12dB or so (signed right shift by two bits) before the clipping goes away.  This gives a fairly healthy 1Vp-p analog output, but the resolution is obviously limited to 14 bits if one is using 16 bit samples.  I suspect the box will do more than 16 bits as the interface and DAC support it, but I haven't messed with that yet.  I don't want to design my stuff around the limitations of this box though.

The electrical SPDIF interface ground requires a good connection to the FPGA ground otherwise there will be huge amounts of digital noise (~1V) on the analog side.  I've seen single ended serial ports really mess with audio, IMO they should be balanced current loops or optical for musical use, particularly if there are frequencies on the serial line that reach down into audio.

The SPDIF interface is (as these things go) typically overly complex.  The framing and encoding are OK I guess, but they implemented superframes for data subchannels which idiotically contain completely different data sets for the pro and consumer versions of the interface.  It's hard to tell exactly how and for what reasons the vaguely defined and sometimes conflicting data will be employed by the end equipment (from a SPDIF implementation guide which is normally meant to clarify things):

"A scheme for providing copy protection is also currently being developed. It includes knowing the category code and then utilizing the Copy and L bits to determine if a copy should be allowed.  Digital processing of data should pass through the copy and L bits as defined by their particular category code. If mixing inputs, the highest level of protection of any one of the sources should be passed through. If the copy bit indicates no copy protection (copy = 1), then multiple copies can be made.  If recording audio data to tape or disk, and any source has copy protection asserted, then the L bit must be used to determine whether the data can be recorded. 

"The L bit determines whether the source is an original (or prerecorded) work, or is a copy of an original work (first generation or higher). The actual meaning of the L bit can only be determined by looking at the category code since certain category codes reverse the meaning.

"If the category code is CD (1000000) and the copy bit alternates at a 4 to 10Hz rate, the CD is a copy of an original work that has copy protection asserted and no recording is permitted." 

Much of the needless complexity is clearly due to copyright issues, which is always a can of worms for everyone involved.  The above reads like the SPDIF protocol was designed by the three stooges.

"Much of the needless complexity is clearly due to copyright issues, which is always a can of worms for everyone involved.  The above reads like the three stooges designed the SPDIF protocol." - Dewster

I admire your tenacity ! - I think one of the reasons I prefer analogue comes down to the complexity (and boredom factor) involved with communication protocols - you have a simple requirement, and all you want is to get data quickly from your MCU to a component.. In order to do this, you need to read through a bloody manual and implement a whole API in your firmware just to talk to this one component...

Yeah, once you've mastered it and developed some firmware modules you can re-use, its fine - until 5 years later when (if like me) you need to implement it again and youve forgotten it all any your modules make no sense...

And as for copy protection - As all the data is there (no matter how obtuse) its a simple matter for some genuine pirate organization to crack the protection and mass produce copies - it doesn't stop piracy, all it does is makes life harder for someone to copy content they have bought to some other device they own.

Fred.

"...you have a simple requirement, and all you want is to get data quickly from your MCU to a component.. In order to do this, you need to read through a bloody manual and implement a whole API in your firmware just to talk to this one component..."  - FredM

Updating Sartre to this modern world (and present company entirely excepted): hell is other engineers (and the standards bodies that rode in on them).

"it doesn't stop piracy..."

I'm sure they'd love a total chokehold on everything we consume, but I suppose there is some value in throwing stumbling blocks out there for pirates.  Most of the money to be made on media is initially, later on not so much, so you don't want any competition in the early phase.  Still, that doesn't justify making a mess of all of our interfaces.

dewster, thanks for posting that video of Jack Fry-most interesting.

You are right by the way, that the fiddle making world if full of hocus-pocus, or at the very least, the potential for the bedragled guy in the dirty mac to sell you an instrument which he claims is made in the truely authentic Cremona way with wood specially treated, made with special tools and the original varnish which Strad used.

Better stick with theremins!

:-)

"dewster, thanks for posting that video of Jack Fry-most interesting."  - RoyP

Glad you found it worth watching Roy!  The Nova that he was on years before totally mesmerized this young luthier wannabe.  The way he explained everything as masses, springs, and dampeners - including the bridge carving filigree - just about made my hair catch fire.

Had a couple of spare minutes to rub together and used them to examine the SPDIF tester output.  Hooked up a 1k resistor and red LED to the FPGA pin and ground, stuck the LED into the Toslink connector on the DAC box and voila!  Noise free (from the serial connection anyway) analog:

The sine spectra:

I'm impressed with the 14 bit performance of the DAC and the simple sine generator.  Optical SPDIF (Toslink) out of a Theremin into an external DAC box seems like a marriage made in heaven.

Tried increasing the effective PCM width in the verilog tester to 16 bits but the results weren't noticeably different from the above - not sure what's going on in the DAC box.

That looks real good, Dewster!

"Tried increasing the effective PCM width in the verilog tester to 16 bits but the results weren't noticeably different from the above - not sure what's going on in the DAC box."

I kind of wonder about your "Hooked up a 1k resistor and red LED.." - If this LED wasn't a fast response part*, could this be the cause of the problem?

*Actually, more a function of capacitance than the emitter physics probably - and I may be talking complete BS anyway.. problems are probably more likely on the RX side.. Its just that 1k seems a bit high - at 5V I would probably go for 220R or less - Whatever is needed to get ~10mA

But I have never played directly with LED's in this kind of application so everything I say relates to other stuff and may not apply.

Fred.