14 or 16 bit ADC for ribbon controller?

[Arjan]

Hi,

Well I’m still gathering information on available Hall Sensors (http://www.midibox.org/forum/index.php/topic,13136.0.html) but in the mean time I’m thinking of taking on another, hopefully simpler, project.

This new project is meant to be a drop-in replacement for the Doepfer R2M ribbon controller module (so not the ribbon itself but the analog to midi box) which I want to add functions to such as pitch-rounding. I have implemented this as a Windows app but I want to be able to take it with me on stage without needing a notebook (although a really small and cheap netbook or tablet PC with USB may be an option).

Anyway, for this to work properly I need at least a 12 bit ADC but a 14 or 16 bit ADC would be preferred. I actually need a second one to read the pressure as well but that doesn’t have to be so accurate.

The PIC18F4520 only has 10bit ADC so if I want to use that I’d need an external ADC. Are there any existings designs for that and/or any pre-made PCB’s that I could order?

Alternatively I could use the STM32 which has built-in 12 bit ADC but as stated I’d prefer at least 14bit or better. How noisy are those ADC’s ie how accurate is the lowest bit?

I’m thinking that it might be a good idea to go with the STM32 but I’d like to limit myself to pre-made PCB’s and modules as much as I can and I don’t believe those are available for the STM32 yet right? On the other hand this group has more experience with the PIC so I might be better off sticking to that. But then I will definitely need a better ADC.

Regarding speed, my PC app reads the MIDI output from the original R2M box continuously as MIDI messages come in but it only outputs (corrected) pitchbend messages once every 5ms which appears to provide smooth response. The pitch rounding algorithm is extremely simple and could be implemented completely in integer arithmetic and probably with just additions and some bit shifts. I’m kinda guessing that the PIC would be powerful enough for that but I don’t really have a clue. The original R2M box uses an 8052 derivative (ADuC814) but it doesn’t do this kind of pitch rounding.

Interface wise a few buttons and a 16x2 LCD would be plenty.

Any advice?

P.S. Here’s a screenshot of my R2M PitchRounder windows app:

[stryd_one]

Can,t help asking… what do you need 14bit for? You’re still sending 7 bit values right?

[Arjan]

Can,t help asking… what do you need 14bit for? You’re still sending 7 bit values right?

No, the pitch bend messages have 14 bits of usable pitch bend data (0 to 4000 hex) and both my JP-8000 and Fantom X7 process all of those or at least more than just the upper 7. Otherwise I wouldn’t be getting totally smooth pitch response from them when controlled from the ribbon (either directly or through my app) with the bend range set to + 2 octaves (ie 4 octaves total).

Actually the R2M from Doepfer uses a 12bit ADC so there are jumps in the values I’m getting but the pitch changes are smooth and continuous. I haven’t checked but it should be that the bottom two bits that it’s sending out are probably always zero (ie their 12 bit ADC reading is left-shifted two bits).

[stryd_one]

pitch bend messages

Sorry I missed that part  :-[ I had note messages in my brain for some reason heh.

What you might want to look into is an external I2C or SPI ADC. MIOS has functions to simplify usage of IIC so that would be the way I’d go personally, it makes the driver writing just a bit easier. I’m no expert on ADCs but I have heard that many of these have pretty ordinary SNR so those lower bits will be of dubious value. Maybe you’d want to go with 16. All the datasheets will have distortion and SNR specs you should check out when you select the device you want, they’ll tell you how many of the specified bits are really useful. The trick you refer to with the jumps from the zeroed bits is usually an effect of masking out those lower bits. You can also average it out and other stuff but I’m inclined towards masking out the useless data, and if you have some overhead (16bit > 14bit) then you can use the full depth available.

Obviously you’re going to need a decent PSU for this too, and you might need to take digital noise into account when you design the board. From the MIOS perspective, you’ll want to write a driver module, which you can do in C or ASM if you can (performance will be better). The MIOS32 driver would be in C, no need for ASM there in most cases. If you’re writing that windows app in C, the code should port to MIOS 8 or 32 easily, otherwise you’d probably want to write it in C anyway. If your algorithm is free of division, the PIC should handle it fine, otherwise you might have issues… but as you know, a clever bitshift can go a long way

So yeh, I think the currently available core will do the job, but if you want to wait til it’s ready, core32 probably won’t hurt. Just last week there was some experimentation going on with the AINs, so although I’m sure they’ll be functional, it might be too soon say anything definite about bit depth yet. It’s not that there’s any concern, just that it’s just ‘not ready yet’ And anyway, the 12bit ADC probably won’t be much help for your needs.

[skrasms]

Hi,

Anyway, for this to work properly I need at least a 12 bit ADC but a 14 or 16 bit ADC would be preferred. I actually need a second one to read the pressure as well but that doesn’t have to be so accurate.

The PIC18F4520 only has 10bit ADC so if I want to use that I’d need an external ADC. Are there any existings designs for that and/or any pre-made PCB’s that I could order?

Alternatively I could use the STM32 which has built-in 12 bit ADC but as stated I’d prefer at least 14bit or better. How noisy are those ADC’s ie how accurate is the lowest bit?

Why do you prefer 14 bits to 12? Obviously 16384 is more than 4096, but what do you gain from that? 12 bits gives almost a bit for each cent over a 4-octave range. If Wikipedia’s references are to be believed, the smallest perceivable pitch difference is around 5 cents. That gives what, at least 15 imperceptibly smooth octaves of range?

To go up to true 16 bits, you’ll need to keep the noise floor of the board itself under about 76 microvolts assuming a 5V reference. Anything digital in the circuit will probably give enough ground bounce to mask the lower bits without proper care in the circuit board layout.

The 12 bit A/D converters built into microprocessors generally end up around 10-bit performance or worse. This is obfuscated as much as it can be inside datasheets. For example, I checked out a spec sheet for an STM:

“Typical ADC accuracy values are determined by characterization of a batch of samples from a standard diffusion lot over the full temperature range, where 95% of the devices have an error less than or equal to the value indicated (mean +/- 2*sigma)”

So… most of the chips will fit into the specs given in the datasheet, but 1 in 20 won’t.

Gain error and offset error can be tweaked in software, but linearity errors are more complicated. The STM datasheet lists the max differential linearity error (change between consecutive bits) as +/- 2 LSBs. That essentially eats 2 bits out of the total of 12, and the result is 10-bit accuracy. They also add the disclaimer “Based on characterization, not tested in production” to cover themselves when it turns out to actually be even worse.

[Arjan]

Sorry I missed that part :-[ I had note messages in my brain for some reason heh.

That’s ok, appreciate the response

What you might want to look into is an external I2C or SPI ADC.

I2C crossed my mind but basically I wanted to check if someone had already done something similar with higher resolution ADCs. I get the impression that is not the case.

Obviously you’re going to need a decent PSU for this too, and you might need to take digital noise into account when you design the board.

I think for my first attempt I’ll keep things very simple: an 7805, some capacitors, somewhat careful grounding and see where that leads me.

The MIOS32 driver would be in C, no need for ASM there in most cases. If you’re writing that windows app in C, the code should port to MIOS 8 or 32 easily, otherwise you’d probably want to write it in C anyway.

I’ve done some assembly in my time but I definitely prefer C and C++. The Windows app was actually written in C# because I happened to find a MIDI library for that which makes it very easy to deal with MIDI messages.

If your algorithm is free of division, the PIC should handle it fine, otherwise you might have issues… but as you know, a clever bitshift can go a long way

There are some divisions but I already checked that they can all be either implemented with some bitshifts and additions or with some table lookups.

So yeh, I think the currently available core will do the job, but if you want to wait til it’s ready, core32 probably won’t hurt.

All considered I think I will wait for the core32. Like with the poly aftertouch project I think it would be the better choice, especially as it will allow me to do everything in C.

Just last week there was some experimentation going on with the AINs, so although I’m sure they’ll be functional, it might be too soon say anything definite about bit depth yet. It’s not that there’s any concern, just that it’s just ‘not ready yet’ And anyway, the 12bit ADC probably won’t be much help for your needs.

Well, the original R2M from Doepfer also uses a 12bit ADC and it works well enough. The main reason that I want to try a higher resolution is that I think it may simplify distinguishing between movement and non-movement but of course that very much depends on how noisy the ADC output is. But I could first try with the built-in 12bit ADC of the core32. That way all I’d need is a core module and nothing more (unless the AIN module is always required even if you only need one or two channels of ADC).

I actually have a third project in my mind but for that I might just get an Asus EEE or something because I could use the large display. Install XP embedded on it, add a USB MIDI interface and it should make a very nice dedicated user interface to my Fantom for certain tasks. I’d prefer a very small tablet PC actually with touch screen but I haven’t seen any that are as affordable as an EEE.

[Arjan]

Why do you prefer 14 bits to 12?

You are correct about everything you say but like I said the reason for wanting more resolution is in order to be able to detect movement/non-movement and (slow) speed very accurately. To get rid of the digital noise I could try averaging multiple ADC readings: as long as the finger is in the same position on the ribbon the induced noise should more or less average out just like the thermal noise from the ribbon itself.

But as may be obvious I haven’t really engineered anything yet about this project, no calculations whatsoever. I may be over-specifying my design criteria but this is not a commercial project so I can afford to spend a few $$$ too much and I’d rather do it right once than wrong twice. 

Gain error and offset error can be tweaked in software, but linearity errors are more complicated. The STM datasheet lists the max differential linearity error (change between consecutive bits) as +/- 2 LSBs. That essentially eats 2 bits out of the total of 12, and the result is 10-bit accuracy. They also add the disclaimer “Based on characterization, not tested in production” to cover themselves when it turns out to actually be even worse.

What I think is needed most is local or regional resolution. Non-linearity in itself is not a problem and 10 bits will be enough to accurately place the notes along the ribbons path. Extra resolution would only be desirable to accurately measure the deviation from the previous position as you want accurate response to small finger movements. But I’m sure a, say, 1 mm offset of the actual note positions from their theoretical position won’t be a big problem as these ribbons are largely played by feel and based upon acoustic feedback to the brain.