AINSER deadband configuration?

[FantomXR]

Hey people,

I searched the NG-firmware for the parameter, which set's the deadband of the AINSER-inputs. I found this:

#define MIOS32_AIN_DEADBAND 31

But if I change that to f.e. 100 or more it doesn't change anything. My problem is, that my slide potentiometer have some jittering (even when the pinrange is set) when they are not at 0 or 127. 
I also found the parameter

#define MIOS32_AIN_IDLE_CTR 3000

But changing this value also doesn't make any difference.

Does anybody know where to set this value?

Thanks,
Chris

[Zam]

Hello Chris

The pinrange= is the deadband setting it has noting to do with jitter.

At what bit depth did you configure your AINSER module ?

Only 7 bit for CC ?

If you have jitter at 7bit you may have a hardware problem... double check wire, strong 0V ref as 5V ref

jitter at 7bit is more than 50mV moving somewhere

 

Proper design/wiring should allow 11bit without jitter, even with 50cm cable from pot to AD input

 

Best

Zam

 

[FantomXR]

Hello Zam,

thanks for your reply.
It's not jittering like a lot of values are send by the slide pot. It's just like every now and then (like every 2-3 seconds but sometimes it stays stable for ever) it sends a value. So maybe I want to have it too perfect ;-) What I'd like to have is a kind of "IDLE" function, which I found in the mios32_ain.h in /svn/mios32/trunk/include/mios32/

It's description reads:

// define the deadband which is used when an AIN pin is in "idle" state
// this helps to avoid sporadical jittering values
// Set this value to 0 to disable the feature (it's enabled by default)
#ifndef MIOS32_AIN_DEADBAND_IDLE
#define MIOS32_AIN_DEADBAND_IDLE 230
#endif

// define after how many conversions the AIN pin should go into "idle" state
// - "idle" state is left once MIOS32_AIN_DEADBAND_IDLE is exceeded.
// - "idle" state is entered once MIOS32_AIN_DEADBAND hasn't been exceeded for 
//   MIOS32_AIN_IDLE_CTR conversions
// 3000 conversions are done in ca. 3 seconds (depends on number of pins!)
// allowed range: 1..65535
#ifndef MIOS32_AIN_IDLE_CTR
#define MIOS32_AIN_IDLE_CTR 3000
#endif

I thought it may be possible to move the slider into the desired position f.e. to value 64 and "lock" it so it only sends any further CCs if the slide pot changes significantly. 

Regarding my wiring: The slide pots are mounted on a PCB which I designed. 5V track is at 0,8mm and GND is designed as plane. The faders are scanned through an AINSER64 module. But this I also designed by myself. The 74HC595 and the MCP3208 are sitting on the mainboard, while the 4051 are directly mounted on the fader-PCB. The cable to the fader PCB is about 30cm. The faders are running at 7bit. 11bit leads to a lot of jitter. Power through USB at the moment, but I'll change that too a MeanWell 5V powersupply.

[Zam]

Hello

I will say you have a design/layout/PSU problem that cause unexpected jitter

I don't now about mux with distant wire, maybe buffer is requested for strong data over long trace, is your "jitter" random regarding value or "around" the actual pot position ?

Also, how is the layout of your 5V trace used for 3208 analogue Vref and slider servo track ?

The expectation is to have a separated trace for this, without power distribution for anything else from Vref at 3208 to sliders

You can check with DMM at lower mV setting what you get between 3208 0V and slider 0v, you can then monitor how "stong" is you 0V ref as consistency over the plane/wire, change the load by on/off led and button state if you have some.

Do the same between 3208 Vref and slider 5V.

 

Another idea is maybe to check how reliable are your slider ? replace one with two resistor in series (equivalent serial value as slider) use the middle as wiper and check if jitter is better ?

By the way what is the ref and stroke length of you fader/slider ?

 

For "critical" operation, like 11bit low or no jitter, and in some circumstance, local precision regulation is a good option...

 

I don't think being concerned about jitter at 7bit is too perfect , you can for sure improve your result !!!

we will find out where we can do it better.

 

Best

Zam

[Zam]

Just to add that in my design the safe "don't send when not used" function is handled at .NGC with a if_equal linked to touch sensor of the respective fader/slider EVENT_AINSER. I suspect you don't have touch detection at your slider, but you can use button for this.

[FantomXR]

5 hours ago, Zam said:

I don't now about mux with distant wire, maybe buffer is requested for strong data over long trace, is your "jitter" random regarding value or "around" the actual pot position ?

it's around the actual position. If the fader is at 105, it sometimes jitters on 106 / 107 f.e.

Of course VREF and standard V+ (5V) do not share the same trace. I attached a screenshot of the PCB:
https://www.dropbox.com/s/ibrunxjkxhdqs5z/BournsPTA.png?dl=0

VREF is the big trace on the very top of the PCB. J1 is the input, J2 forwards the unused analog inputs of IC2, which I need for nine faders on this PCB. 

I'll do what you suggested! Thank you for your help! 

I use Bourns PTA slide-pots with 10k.

 

[Zam]

Hello Chris

 

I have a quick look at your pcb

few things in mind:

-J1 and J2 only use one wire (ribbon) for 5v and 0v, ribbon is very thin wire... you can expect voltage drop/change/instability anytime you have small load change.

Try cut the ribbon at 0 and 5v and replace with 0.25 or 0.5 mm2 wire (direct soldering at connector pin for test)

-what side is your ground plane ?

-Did all fader have same jitter or position in the PCB have impact ?

-IIRC unused 4051 pin are better clamped to ground !

 

Best

Zam

[FantomXR]

Thanks for your suggestions! I'll try that, but time is very limited at the moment! Will give you a feedback asap!

Regarding your questions:

- GND-Plane is on both sides.
- I have the impression that the first faders are not jittering... but will need to do some more testing here
- will do! Thanks!

[FantomXR]

@Zam: I had no time yet to follow up on your suggestions. But I'll do as soon as possible.

Maybe you can answer another question: Is it possible (f.e. by modifying the source code) to set the resolution on a per-pin-base and not on a per-chip base? I ask because if I connect pedals as well as pitch to my board, than I don't need 11bit on the pedals, but I need them on the pitchwheel. I don't want to waste an IC just for one analog input ;)

Thanks,
Chris

[Zam]

Hey Chris

22 hours ago, FantomXR said:

Is it possible (f.e. by modifying the source code) to set the resolution on a per-pin-base and not on a per-chip base?

I have no idea about this.

But at MB_NG if your event definition is à 7bit one (note or cc) the Ain data is scaled accordingly.

If that's the question you ask ?

Best

Zam

[FantomXR]

7 hours ago, Zam said:

If that's the question you ask ?

No. What I was asking is: If you configure your analog inputs via the AINSER command (AINSER n=1 enabled=1 cs=0, etc. pp.) the resolution of the EVENT_AINSERs that belong to this configuration of course use the resolution you entered in the AINSER configuration. 

I basically use the AINSER64. And using the standard method for the configuration allows me to set ONE resolution for the whole AINSER64 module. But what if I need a resolution of 7bit for the first 8 inputs and 11bit on the second 8 inputs? Hmmmm :-)

[Zam]

Hello

As AINSER64 is a multiplexed solution to one AIN mcp3208 I don't think it is possible.

Just set the device at 11bit (max if possible regarding jitter), then your event_ainser definition will take care of the effective bit depth you specify here.

I don't see the reason/use case you need to scale this at chips ?

Best

Zam

[FantomXR]

Dear @Zam

You are totally right. That doesn't make any sense ;-)

Today I checked what you suggested. In the end it were the WS2812 LEDs that caused the potentiometers to jitter.... if I don't connect them, everything works great.... so I need to find another way to implement them into my setup....

[Zam]

Hey Chris

Ok, that make sense, good you find the issue

I just have a look at this led ribbon.

288 leds... 20mA/led it's close to 6A all ON and 300mA idle. Your 7bit jitter represent more than 50mV which is not a surprise then

To handle this without voltage drop you need a very strong PSU at 5V rail, with sens detection...

Keep in mind that 11bit with 5V ref represent 2.5mV per step, if you have ripple/Vdrop bigger than that you will have problems

Try to use (if your design can handle it) two separate rail/psu, one for "power" and one for "precision" circuit.

Also local regulation can be an option.

Best

Zam

[FantomXR]

@Zam: Thanks for your suggestions. If you take a look at my screenshot above you will notice 9 4pin-pinheaders right next to the faders. This where the WS2812-PCB sits on. Do you think it makes sense to remove those headers and connect the LEDs directly? Maybe it's a problem that both (faders & LEDs) share the same PCB?

BTW: I use a MeanWell RS15-5 Powersupply and I have 6 LEDs next to each fader => 6*9 = 54 LEDs. And none of them running at full power. They are at about 20%...
I need to measure the current of the whole circuit. Maybe I should upgrade the PSU to MeanWell EPS-35-5?

//edit: While my current PSU RS15-5 has a load regulation of  +-1,5% which means 75mV the EPS-35-5 has a load regulation of 1% => 50mV.
So you would suggest to add another power supply that is just connected to the LEDs? What is sense detection? I'd be happy to NOT add another power supply because I already have two supplys in the housing... 19V and 5V.

Thanks for your help!

Edited July 7, 2017 by FantomXR

[Zam]

Hello Chris

Ok it's not the 2m ribbon I see with 288 leds !

I think you already spot the problem so yes the answer is your led and AIN don't like to be close together.

I'm not used to this color LEDs but they use PWM to acheave 20% power and color change right ?

PWM can introduce noise which can also be the reason you notice jitter, in conjunction with voltage drop if there is any ?

Can't say about PSU choice, you have to measure current and pick one accordingly

By the way, what for the 19V rail is? because you can maybe use this on to add a small regulator (like LM317L) for the critical AIN and slider Vref

My first test will be to locally separate AINSER circuit and LED circuit, not sharing VDD/VSS locally, but only at PSU terminal in the manner of star power distribution, if your design allow it.

Sense detection, is a sense input that some PSU have to attach at the load, tracking voltage at that point, an maintain it.

Best

Zam

 

 

[FantomXR]

31 minutes ago, Zam said:

I'm not used to this color LEDs but they use PWM to acheave 20% power and color change right ?

Yes! Correct!

31 minutes ago, Zam said:

PWM can introduce noise which can also be the reason you notice jitter, in conjunction with voltage drop if there is any ?

I tried to measure this with my DMM. But I'm afraid my DMM is not the best. I'll use my oscilloscope to check that.

32 minutes ago, Zam said:

By the way, what for the 19V rail is?

This is for a small computer which sits in the housing. It's a great idea to use a small regulator... but like you said: I'll start with separating the PCBs.

Thanks for your help!

[Zam]

You'r welcome Chris

Keep us informed of your progress

Best

Zam

[FantomXR]

@Zam: Some more informations on this. Today I tried to use a separate powersupply for the LEDs. The LEDs are still attached to the fader-pcb... I already created a new PCB, but this needs to be produced first. Anyway: the jitter stays... also I found out that the jitter also occurs if the LEDs are not even switched on! Meanwhile I think it's more a problem wit shielding... I took a piece of copper foil, attached a cable to it and connected it to GND. When I put this piece of foil between the LED-strip and the fader the jitter will slow down but does not disappear.

[FantomXR]

@Zam: I followed up on this today. Meanwhile I received the new PCBs where the LEDs are not sitting on the fader-PCBs. The jitter has improved a lot. Thanks for the suggestion. I also tried, not using the USB-power directly from a computer which also improved the stability and the jitter-issues. Anyway: If both PCBs (and the core of course) are powered from the same power supply, I still get some jittering. Way less than before. But it's still there. The only solution for now is, to use a totally separate power supply for the LEDs, but share GND with the core & fader PCB. This works great... but I'm not totally satisfied with using two power supplies. 

I did some experimenting with direct USB-power. Like I wrote it's not good, to power everything from the same port. But, and that is kind of weird, if I use one USB-port for the core & faders / AIN and another USB-port from the same computer for the LEDs, it works great too. I don't think it has something to do with power consumption because I tested it with 16 LEDs at low brightness. They shouldn't draw too much current. 

I also measured with an oscilloscope. I'm not very experienced with that... but I noticed some voltage drop when switching the colors from the LEDs and it seems that this will influence the AIN. So my question is: Is there a way to power everything from one power supply but add some filtering before the LEDs (or AIN?) ? Do you have any recommendations on this?

Thanks!
Chris

[Zam]

Hey Chris

What is the amount of your voltage drop? one LED on, all LED on, at PSU terminal, PCB power input, somewhere far from PSU, opposite end of 5v trace

How is the jitter threshold now, 8bit 9bit 10bit ?

Also current "call" from LED can momentary "move" your GND

What you have to measure is voltage change between two GND point

-AIN 0V pin across common PSU GND

-AIN 0V pin across fader 0V pin

Also your 5V rail

-AIN Vref across fader Vref

 

More generally, try to look how the same trace/signal move within different place, especially long trace.

It should give you a clue where instability is. Is the 5V dropping, is the 0V momentary loading a little, etc...

 

Another test because, it could be low cost fader limitation, use two 5k series resistor (or any sum around 10k) in place of fader, "wiper" (at two resistance junction) is now hardly fixed, half Vref voltage (if 2x5k), and check if consistency at this AIN pin is better or not

 

If you really need to keep only one PSU, maybe go for a 9 or 12v, and use different onboard regulation for each section, analog and digital, Like LM317 (should run 5V with 9V input) or LM317L for AIN Vref (low current here)

I was tempted to tell you to just add a 317L from 5V to AIN Vref, but you have to check minimum voltage and minimum IO differential at data sheet, If you end over 3V but super stable it can make the trick... it depend of the noise around

 

Hope it help

Best

Zam

 

[FantomXR]

Thanks for your suggestions!

I'll keep an eye on it again tomorrow. I took a look into the LM317 datasheet and it looks like it needs Vin - Vout = 5V, which is with 5V = Vin not possible. 

If I want to use another source for Vref, do I just need to change the source for Vref or also for VDD of the MCP3208? And the 10Ohm resistor than is no longer needed?

Thanks!

[Zam]

Hi

Check also for the LM317L, I don't remember if it have the same spec regarding min Vin against Vout

For local regulation, yes, only Vref (and fader/pot +side), chips supply can stay at +5V logical/digital (VDD).

10ohm no longer needed, but you have to take care that Vref don't exceed VDD, or you won't have full scale definition.

If you expect voltage drop at VDD, set Vref regulator to be little below worst VDD drop case (all LED on).

Best

Zam

[FantomXR]

Sounds like a plan! I'll report! ;-) Thanks!

[FantomXR]

And two side notes:

I'm running at 11bit resolution and the faders I use are Bourns PTA4553 at 10k linear.