Higher poti/encoder resolution

[Guest the_Swede]

Since the pic has 10bit ADCs, I was thinking what a waste of 3 precious bits... by using other MIDI messages that CCs you can use up to 14bit (pitchbend for instance). My question is - is this electronically feasible? I have heard of people having pot flickering at 7bit already - surely a higher resolution than this must be realisable?

On the encoders - these have 72 discrete steps per revolution I gather (thanks to the interpolation). This however is rather low, almost 6bit resolution. Does anyone know of other (not too expensive) encoders that transmit more than 36 pulses/rev?

[TK.]

Hi Swede,

the pot jitter issue is solved since the MIDIbox converts the pot values with 8 bits and uses the LSB to eleminate the 0.5 bit error of the ADC. A 10 bit conversion could also be possible, but it requires a very clean design on the analog site -> seperate power supply & no external multiplexers! You can try it with the AINX4 example under http://www.ucapps.de/prg.html - just bypass the multiplexer control routine in adc.inc, reduce the number of pots to 8 and get the 10-bit result from the ADRES/ADRESH registers.

Encoders: the MIDIbox16E already sends 72 ticks per revolution with a 36 step encoder, because of the built-in interpolator, which handles not only the rising edge, but also the falling edge of every pulse. It's a tricky approach, but it works very stable! :) Btw.: the required CPU performance for this method is the reason, why only 16 encoders can be handled by every core module.

Best Regards, Thorsten.

[Guest the_Swede]

Hooo hmmm... the revised motorfader extension will be directly connected to the ADCs I gather. Does this mean it is possible to achieve 10bit resolution on these faders? Can the processor cope (it ought to be able to just slow down the faders further when it is in the area of these extra 3bits' value)? This would be great, since we are then on par with the resolution of the Logic Control - a truly professional level!

A 7bit precision amounts to about 1mm per bit, which in my experience leads no a noticeable "stepping", especially with lower volumes.

The interpolation for the encoders is great, but 72 steps is still a rather meagre 6bit resolution. That's why I'm looking for (not humonguosly expensive) encoders with more steps than 36.

But perhaps 72 steps is enough for something like EQ? I have never experimented with this. What is your opinion?

Also, on processing power, isn't possible to decode the encoders in hardware? Although this of course leads to mucho components and soldering.

[TK.]

I will try it with 9bit - this will increase the resolution by 8 times compared to standard midi CC; the LSB is always required to eliminate the 1/2 bit error, I don't want to do it without.

Encoders: 72 steps are really ok for the daily work; if you want to turn a parameter from min to max value with one twist of your fingers, you can enable the "fast" mode which works progressively - that means: than faster you turn, than higher increment/decrement values will be send.

Hardware solution: well, see http://www.ucapps.de/howtoenc.html - but why do you want to replace the software handler by hardware? The software works very stable, the 16 encoders are sampled every 800 uS, the sample routine requires about 200 uS, which means 25% CPU load. Maybe it works also with higher resolutions, but I never tried it... if not, just only the sample rate has to be increased.

To ensure the realtime behaviour (no encoder Tick and no incoming MIDI byte should get lost) and to minimize my support effort if something should not work as expected with an exotic encoder, I limited the routines to 16 encoders. If you need more, just link multiple core modules --- or modify the din_enc program under http://www.ucapps.de/mbhp_prg.html for your needs :)

Best Regards, Thorsten.

[ilmenator]

Encoders: the MIDIbox16E already sends 72 ticks per revolution with a 36 step encoder, because of the built-in interpolator, which handles not only the rising edge, but also the falling edge of every pulse.

Is that the reason why the encoders must not be "mechanically detented" as you write on the 16E-page? Otherwise you would always increase the values in steps of two (from e.g. 72 to 74 to 76 etc.) when turning the encoder one step?

[Guest the_Swede]

Oh, thats GREAT! 9bit resolution is 0,2mm per step (approx), surely good enough. Although it only corresponds to a resolution 4x increase, not 8x.

All this adds up to a really easy-to-build (with minimal firmware changes = minimum debug time) Logic Control / Steinberg Houston etc - only this one will cost MAX 500 Euro (where the motor faders cost 300 of these 500 Euros), and have 16 faders/encoders instead of 8.

A cheaper possibility is to use Panasonic faders instead of ALPS, although these have no touch sensors. But these cost 150 Euro (approx) instead of 300.

The drawback of course is that Houston can control VST Instruments/effects and get parameter feedback, something that is impossible within the Generic Remote Steinberg currently provide.

I'll send my results to Thorsten along with a small construction guide when I'm finished - don't expect me to be before at earliest Christmas, though!

[TK.]

Is that the reason why the encoders must not be "mechanically detented" as you write on the 16E-page? Otherwise you would always increase the values in steps of two (from e.g. 72 to 74 to 76 etc.) when turning the encoder one step?

yes, thats exactly the reason! :)

Best Regards, Thorsten.