Scaling pot values (deadbands). (was Some trouble with pots' Min and Max values)

MIDIbox HUIs
1

Hello,

I’m having this problem, sometimes the pots only reach to 126 (or even 125) as the max value, and 1 as the min value. It is an intermittent problem, I mean, maybe you use it one day and everything’s fine, and next day the problem appears. It affects several pots, and I didn’t find a pattern. Sometimes some of the pots are affected, sometimes others.

One thought is that maybe it has a relationship with the AC supply (I don’t mean the PSU, but the 220v I get from the wall outlet), since in the neighborhood we have lower voltages at times, I mean, lights go dimmer.

I don’t know, anyway if this could be correct, since I understand we are using a stabilizer in the core’s circuitry…

My question is whether there is a software solution to this, scaling the readings, not the way mb64 already is able to do (limit the same voltage reading between a reduced range), but exactly the opposite.

I’ve been searching in the forums, and found some info that relates to this sort of scaling, but in general it’s coded in C, and I would need to modify MB64 software, which is written in Assembler.

I also read that this kind of calculations which involve division could slow things down more than acceptable…

Any clues will be greatly appreciated.

Regards,

Pablo

2

hola Pablo

no need for scaling!! you are having some kind of AIN issue, fight the problem at the root.

To start with, measure the voltage at the right and left pin of the affected pot, check that the pots are OK ranging from 0 to 10KR, check the solder joints on the pots and use good cables to connect them (sometime shielded cables may be a better choice)

Simone

3

Hey dude

Cimo is totally right. Anyway just for info:

It is an intermittent problem, I mean, maybe you use it one day and everything’s fine, and next day the problem appears. It affects several pots, and I didn’t find a pattern. Sometimes some of the pots are affected, sometimes others.

El bizarro. Does anything change, or get moved, or anything? Does the temperature in the room change a lot? Think of anything you can that changes… If there is anything. “Intermittent bugs suck” was my ‘thought for the day’ in the chat two days ago. And they do. They’re the hardest thing to fix.

I don’t know, anyway if this could be correct, since I understand we are using a stabilizer in the core’s circuitry…

You’re correct, it’s regulated… however, if the external voltage were low enough, and it was rated to 9V from 220…lets see..(lazy man breaks out calculator… Calcutta rules.)

220/9

        out = 24.4444444444444444

out*8.6

        out = 210.2222222222222222

8.6V is stryd’s magic voltage. I have problems every time I drop below that, even though it should BOR before it acts strangely. (Offtopic: My lucky number is 86. Coincidence? Probably!). So if your mains drops below 210.2’ volts, you *could* see problems, if you’re using a 220:9V transformer. If the lights are constantly dim (not dimming and then coming back, but staying dim for long periods) it’s possible…But this is *very* unlikely. Chances are, it’s along the lines of what cimo said.

scaling the readings, not the way mb64 already is able to do (limit the same voltage reading between a reduced range), but exactly the opposite.

There’s not much scaling to do here really… just add a step in somewhere, like ‘if val=126, val=127’

I’ve been searching in the forums, and found some info that relates to this sort of scaling, but in general it’s coded in C, and I would need to modify MB64 software, which is written in Assembler.

Err, I think you’re referring the TK’s magical scale7bit function, and it is asm optimised. You probably sow it wrapped up in C :slight_smile:

I also read that this kind of calculations which involve division could slow things down more than acceptable…

It’s magical because it uses multiplication and not division, and does so using the PIC’s hardware multiplier, so it happens in just a few cycles. TK is boss :slight_smile:

4

Quote from: Pablop on Yesterday at 21:26

I don’t know, anyway if this could be correct, since I understand we are using a stabilizer in the core’s circuitry…

You’re correct, it’s regulated… however, if the external voltage were low enough, and it was rated to 9V from 220…lets see..(lazy man breaks out calculator… Calcutta rules.)

220/9

        out = 24.4444444444444444

out*8.6

        out = 210.2222222222222222

8.6V is stryd’s magic voltage. I have problems every time I drop below that, even though it should BOR before it acts strangely. (Offtopic: My lucky number is 86. Coincidence? Probably!). So if your mains drops below 210.2’ volts, you *could* see problems, if you’re using a 220:9V transformer. If the lights are constantly dim (not dimming and then coming back, but staying dim for long periods) it’s possible…But this is *very* unlikely. Chances are, it’s along the lines of what cimo said.

i had the same thought but if there is a voltage drop that would affect the whole box, wouldn it ?

and, now that we get to this point: are you suppplying the pots with the same rail as you use for the CORE and AINs? if you would use different supplies for pots/AINs/CORE and having random voltage drops that could explain your issues.

Suerte!

Simone

5

i had the same thought but if there is a voltage drop that would affect the whole box, wouldn it ?

Well, the vregs are intended to be ‘all or nothing’, but that’s only in theory. In practice they have a drop off slope which is very steep. If you give them enough input, they output 5V (+/- a tiny bit) all the way, and then suddenly nothing, and the core switches off. At this point, the amount of power required to run the regulator drops (because your core is not doing anything) and it powers back up. MIOS studio will tell you that you have an unexpected upload request, rinse, repeat…

If you’re really unusual, the power will be just enough, then you’ll light a few leds, and it’ll drop, and the core will BOR (Brown-Out Reset) and restart before it powers right off. BOR happens but not often (and much less often these days since a mod to the threshold a while back)

If you’re a total freak and have the luck of a one leafed clover (me), then it’ll sit in the sweet spot inbetween working properly and a BOR, where it’s not enough power to make it work cleanly and not low enough to cause a reset or a power off. In the history of midibox as far as I know, that’s happened to two people, and I’m one of them. It’s rare.

So yeh I still think you were right the first time cimo.

Pablop: you mentioned that which pots are too low, changes from time to time… is it a random spread, or are they groups of ‘neighbouring’ knobs?

6

Thank you people for your fast and thorough replies. I have been working on it, and found some issues, resoldered some joints, etc. Still have some minor problems in one or two pots, but I think it´s the pots themselves.

I’ll post any good news. See you around,

Pablo

7

You could be onto something there with dodgy pots.

If they are really bad, you might not get the full range available, say if the wiper doesn’t reach the extremes of travel due to a manufacturing flaw.

I’d say the lesson if that is the case, would be to get the best pots you can get

(mind you, don’t go too far. You don’t need linearised conductive plastic or anything… unless you have a mysterious benefactor to pay for such things.)

8

Hello people, I have finally solved the pot trouble. The fact that some pots didn’t reach 127 was a hardware problem, but what really was awkward was why they didn’t reach zero, sometimes.

That happened with ALL of them, and it did happen when I moved the pots SLOWLY down. It never happened in any pot when moved quickly down. Many other tests done, I concluded that it was not a soldering problem.

So, having no clues for something that puzzled me, I opted for the software solution.

I modified the MIOS_AIN_NotifyChange in main.asm (mb64) in order to have a small dead band up and down the pot and sliders way. The deadband is really small (32 of all 1024 steps in a 10bit ADC conversion), but was enough to fix the issue. Nonetheless, the code is adaptable to greater deadbands.

I’ll paste it here. It’s full of comments, heh, I think it’s more comments than code, actually. I wrote most of them to help myself in tracking what I was doing, it may be useful to someone, or maybe it’s useful for me that someone takes a look at it.

I’m really happy because it works, and because I learnt a lot while doing it. I did various versions, and this is the best of them, because it does the scaling from the whole 10bits the Pic delivers. That means that MB64 still doesn’t skip any value from 0 to 127, and that there are not “difficult” values to be output.

Here, the code:

;; --------------------------------------------------------------------------

;;  This function is called by MIOS when a pot has been moved

;;  Input:

;;     o Pot number in WREG and MIOS_PARAMETER1

;;     o lower byte value in MIOS_PARAMETER2

;;     o upper byte value in MIOS_PARAMETER3

;; --------------------------------------------------------------------------

USER_AIN_NotifyChange

;;Reading= 1023 (max)

;;Scaled = ( Reading - 31 ) * (33 /32).   I’m dividing by powers of two, to use bit shifts, so the next smaller ratio would be (65/64).

;; That would permit a smaller deadband, but  maxreading (1023)*65 goes beyond the 2^16 (two byte) limit.

;;I will split the 31 values deadband in 16 low and 15 high.

;;Easier just to take into account the low deadband here, and limit higher than 127 values at the end of the process

; * if reading < (16) then reading = 16

; * for reading to be < 16, MIOS_PARAMETER3 must be 0, and MIOS_PARAMETER2 <=16

; *if MIOS_PARAMETER3 not zero, goto CONTINUE1

movlw 1;; w==127

IFGEQ MIOS_PARAMETER3, ACCESS, rgoto CONTINUE1

;*if MIOS_PARAMETER2 <=16 then MIOS_PARAMETER2 =16

movlw 16 ;

IFGEQ MIOS_PARAMETER2, ACCESS, rgoto CONTINUE1

movlw 16 ;

movwf MIOS_PARAMETER2

CONTINUE1

;----------------------------substract 16

;I substract 16 to put values on the range 0 - 1007. (That’s an 8 bit substraction from a 16 bit value. I took a model of a 16bit substraction and optimized it a little bit)

; movf    SourceL,W ; ;;;;;;;THIS IS THE MODEL 16 bits---------------------

        ; subwf   DestL;           ;;;;;;of 16 bit substraction

        ; movf    SourceH,W;

        ; btfss   STATUS,C

        ; incfsz  SourceH,W

        ; subwf   DestH   ; --------------------------------------------------------------------

movlw 16 ; ---------------------------------------------

subwf MIOS_PARAMETER2, F;substracts 16 from MIOS_PARAMETER2

movlw 0

btfss   STATUS,C ; if result was positive or zero, SKIPs next instruction

decf MIOS_PARAMETER3, F; if negative, we need to substract 1 to the upper byte.

;; NOT NECESSARY________________ I’ll limit output to 127 after calculation is done

;;* if reading > (1023-15) then reading = 15

;; ______________________________

; * ---------------------multiply reading by 33.

; Result = upper byte*33+lower byte*33 (upper byte in MIOS_PARAMETER3 and lower byte in MIOS_PARAMETER2)

; *  I know MIOS_PARAMETER3 will never be > 3 so, 3*33 = 99, I don’t need to care about PRODH

movf MIOS_PARAMETER3, W

mullw 33

;;movff PRODH, TMP1  -----------> Don’t care about PRODH

movff PRODL, TMP2; So, I have MIOS_PARAMETER3 * 33 in TMP2

movf MIOS_PARAMETER2, W ; Now, I multiply lower byte *33

mullw 33 ; Result in PRODH:L

; -------------------------------But I will have to divide by 256 (see below) so, I don’t care about PRODL, now.

;movf PRODL, W;----------PRODL would hold a resolution I won’t use

;addwf TMP2, F ;

movf PRODH, W; So, let’s add Original upper byte * 33 + the upper byte of the product of (ORIGINAL lower byte*33)

addwf TMP2, F;

; ----------------------* divide by 32.

;I should immediately divide by 8, so that’s a 256 divide, I can Just keep my upper byte.

; Keeping just the upper byte of my multiplication implies dividing by 32 and then by 8. That’s just what I needed

movff TMP2, MIOS_PARAMETER2 ;

;------------------------Now, let’s limit output to 127

; * if MIOS_PARAMETER2 > 127 then MIOS_PARAMETER2 =127

; If MIOS_PARAMETER2<=127 then goto CONTINUE 3

movlw 127;; w=127

IFLEQ MIOS_PARAMETER2, ACCESS, rgoto CONTINUE2

movlw 127

movwf MIOS_PARAMETER2 ;MIOS_PARAMETER2=127

CONTINUE2

;; FIN PABLO, end of my code

;; now: pot number in MIOS_PARAMETER1

;; 7-bit value in MIOS_PARAMETER2

#if DEFAULT_ENABLE_DRUMS

;; if drum trigger (MIOS_PARAMETER1 < 8) :

;; branch to the DRUMS module

movlw 8-1

IFLEQ MIOS_PARAMETER1, ACCESS, goto DRUMS_AIN_NotifyChange

#endif

;; else continue with MB64 pot handler

;; (expects number of pot in WREG)

movf MIOS_PARAMETER1, W

goto MB64_POT_Handler

9

Howdy!

I’m glad to see you’ve solved the problem. But after reading this post I just had to add my .02;

I can’t speak to the software side of the issue, but anytime I have this type of problem, the first thing I do is clean and lube the pots. ( CAIG works well ).  Also the low line voltage, perhaps, but I was thinking more along the lines of not enough current rating on the transformer.  When I test my projects, I am lucky enough to have a 12 volt 36 amp power supply ( I used to do a lot of car audio repair) Before finalizing my design I measure the current load of my new project, and then design the power supply ( transformer and DC supply ) with a little overhead.

Scam