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

Posted: 7/18/2016 6:37:34 PM

From: Northern NJ, USA

Joined: 2/17/2012

Trying to read that patent but my eyes keep glazing over from all the gobbledygook.  It claims the MSb inverter is part of a high pass filter block, but that's incorrect.  The parallel data coming from a singly clocked LFSR is already ~differentiated if you consider it to be signed.  The inverter merely converts signed to unsigned.  IANAL, but I believe if you want signed and differentiated noise from an LFSR you can just use it directly (and sign extend it if necessary) and not infringe on the patent.  If you want unsigned you would need the inverter, but it's not clear to me as to how this would be infringement either, as inverting the MSb is a well known method of converting signed <=> unsigned.  Ugh, this shit just ties people's hands in nonsense.

One thing the patent mentions is the combination of uncorrelated noise samples leading to a triangular PDF (probability density function).  You get a rectangular PDF when you throw one die, because the probability for each value 1 thru 6 are the same.  You get a triangular PDF when you throw two dice, which is easily seen by listing all possible outcomes:

2 = 1+1
3 = 1+2; 2+1
4 = 1+3; 2+2; 3+1
5 = 1+4; 2+3; 3+2; 4+1
6 = 1+5; 2+4; 3+3; 4+2; 5+1
7 = 1+6; 2+5; 3+4; 4+3; 5+2; 6+1
8 = 2+6; 3+5; 4+4; 5+3; 6+2
9 = 3+6; 4+5; 5+4; 6+3
10= 4+6; 5+5; 6+4
11= 5+6; 6+5
12= 6+6

So you can see 7 is the most likely outcome, and 2 and 12 the least, with a linear slope to the probabilities on either side.  Triangular PDF works well for dithering audio, but applications like video and NCO / NCPD work best with a rectangular PDF.  Also, triangular dither requires an amplitude of 2 LSbs (post truncation), while rectangular dither only requires 1 LSb, so the injected noise with rectangular is lower.  Anyway, one can see how combining two independent noise sources might lead directly to triangular dither.

To get Gaussian PDF noise (not mentioned in the patent) you add together a bunch of (5 or more - more giving a better approximation) independent noise sources.  This gives a nice sinusoid, smoothing out the triangle above.  Gaussian noise is most similar to the noise generated by analog electronics.

The patent also uses the length of the LFSR to generate multiple samples at once, and to store previous values, which is neat but quite obvious - so what is really unique and patentable here?  To me it's exploitation of the otherwise problematic correlation of LFSR parallel samples separated by one clock.

Posted: 7/21/2016 7:48:16 PM

From: Northern NJ, USA

Joined: 2/17/2012

Investigating differentiated noise via spreadsheet, I was surprised to discover that straight 1st order differentiation of independent noise samples produces a triangular PDF.  I suppose I should have been prepared for this, as even though the use of each sample is spread over two successive time slots (first it is used as the main thing which gets the old thing subtracted from it, and then it is used as the old sample which gets subtracted from the new) the noise it gets combined with is itself independent, and independent combinations are like two dice, hence the triangular PDF.  Knowing this, it was not so surprising to find that higher order differentiation tends to Gaussian PDF. 

Things they don't teach you in school (and that don't instantly turn up in Google).  IIRC, my first encounter with the use of a multi-sample combination to produce Gaussian noise was in a physics lab in college - extremely basic and handy information that was nowhere to be found in any of my class texts.

Posted: 7/24/2016 8:49:10 PM

From: Northern NJ, USA

Joined: 2/17/2012

Rotary Encoders

(Mostly a rehash of this post.)

Busy bolting a bunch of System Verilog of stuff onto the processor. Got the NCPD, simple quadrature phase detector, and 4th order LPF tied together with a processor register interface.  Need to do the same with the SPDIF TX component and for some kind of serializer for the LED tuner.

I was planning on doing the rotary encoder debounce and decode in software, but now I'm wondering if throwing a tiny bit of hardware at it in order to conserve processor real time for bigger and better things might be a better approach.  I was thinking SW would be safest if glitching is a problem, as it could perhaps be dealt with more flexibly in SW, but as a first pass I'm going the HW route.  The pushbutton (when the encoder shaft is pressed) debounce is probably best being SW based, as it may need tuning.

The encoder hardware outputs form a 2 bit glitchy inverted Gray code, but only one input is supposed to glitch at a time.  Detent state is 11.  First thing is to synchronize the inputs with the system clock, and we do this with two shift registers, then we invert.  It's much simpler to feed the result to a state machine (SM) if we first convert the Gray code to binary, here the MSb is fed to the SM straight, while the XOR of the MSb and LSb form the LSb fed to the SM.  To see this:

CW rotation (inverted Gray): 11, 10, 00, 01, 11

Inversion (Gray): 00, 01, 11, 10, 00

Binary conversion: 00, 01, 10, 11, 00

A trick here is to use a 3 bit up/down binary counter as the state machine.  Detent position is 000, with CW rotation incrementing by 1 thus going positive, CCW decrementing by 1 thus going negative.  Machine transitions are limited to seeing an increment or decrement value at the input, and detent at the input always resets the state.  So if the machine has transitioned to +3 and detent is seen, we output a CW pulse.  And if the machine is at -3 with detent input, we output a CCW pulse:

CW state transitions: 000, 001, 010, 011, 000

CCW state transitions: 000, 111, 110, 101, 000

Even if doing this with SW we would need resynchronization, which takes at least 4 flops.  Doing it all in hardware (including resync) requires 12 LEs (logic elements), which is just a drop in the ocean even for the smallish FPGA we're targeting.  Each encoder needs a separate SM to track what's going on, and the processor register interface would likely be clear on read.

I suppose the moral here is to use the carry chain logic for state encode / decode if binary is (or can be made) a good fit to the state.


Also finalizing on system timing.  There's a 50MHz oscillator on the demo board.  Running this through one of the 2 configurable PLLs in the FPGA and multiplying/dividing by 29/236 gives 6.144067MHz.  For SPDIF we need 48kHz * 128 = 6.144MHz.  So the reference is 67Hz high, or +11pmm, which is within the 50MHz oscillator manufacturing tolerance limits. 

The SPDIF TX module has a 48kHz frame output which will be resynchronized and used as an interrupt for the one or more processor threads handling the capacitive DLLs, sound generation & filtering, as well as LED tuner output and rotary encoder sampling.

The second FPGA PLL will be used to drive the processor core at whatever maximum speed is fairly easily attainable (hopefully ~190MHz or so for 190 aggregate MIPS).

Posted: 7/28/2016 4:31:44 AM

From: Northern NJ, USA

Joined: 2/17/2012

Trying to figure out the TLC5916 via the datasheet (serializer and constant current driver for the LED tuner) and for the life of me it's all but impossible.  I've seen some lame datasheets in my time and this one is near the bottom in terms of describing what's really going on.  There's a rather odd way to place it in the mode where you can set the brightness and read diagnostic info, which they describe in various vague and vaguely different ways.  They show the latch as an independent clock in some of the diagrams, but then they give setup and hold to it from the serial clock?  The text states the output data is latched on the falling edge of the latch, but the edge to output spec is from the rising edge?  I'm going to have to breadboard it and send it some signals.  Independent clocks and asynchronous enables shouldn't have other modes where they behave as synchronous to some other clock.  Kind of surprisingly coming from TI.  </rant>

It's only slightly better than this joke data sheet.

[EDIT] Someone else crabbing about the TLC5916 datasheet, so it's probably not just me.  What's unsettling is the more time you spend poring over the datasheet the less sense it makes.  This IC should be one of the most straightforward things around but it's loaded with poorly documented cruft.  This seems to be a case of an analog team designing a fundamentally digital IC.  Analog is hard, but digital is deceptively harder than it seems to do right - simplicity, consistency, and adhering to rational interface norms are everything.

The TLC5916 is just a serial string of 8 flops - a simple shift register - driving a second layer of 8 flops in parallel, which drive the constant current outputs.  The serial clock shifts the serial data in and out.  Two other inputs control transfer from the serial flops to the parallel flops, and output enable.  The basic operation of these other two inputs is strange, and their overloaded functions are implemented in weirdly complex ways.  Even the current (brightness) setting is oddly implemented, with a discontinuity in the center and flipped endianness.

[EDIT2] Levenkay over at AVR freaks: "I finally took a look at the spec-sheet for that LED driver IC. Its interface is so totally botched that there must have been some enormous-volume customer who locked in on the unwieldy nightmare early for TI not to have corrected the design. Kind of like those oddball AVRs that have only twelve I/O pins, but are packaged in 294-pin hairbrushes, 'cause that's what General Motors ordered (I know, I exaggerate somewhat...). I would expect TI to offer a similar part, but with a sane interface that you could switch to; do they?"

I wish.  "Hairbrushes" <snerk>.

You must be logged in to post a reply. Please log in or register for a new account.