Precision current control with Digital Potentiometers

[slacker]

Interesting stuff Paul thanks for taking the time to do that.

You might be interested in this thread http://www.diystompboxes.com/smfforum/index.php?topic=68741.0 where stm proposes pretty much the same thing regarding the internal resistance.

Your schematic of the internal connections to the VCO nicely explain how Rick's recent discovery that you can modulate the delay time using the vref actually works.
http://www.diystompboxes.com/smfforum/index.php?topic=86297.0

[PRR]

> stm proposes pretty much the same thing

Ah, "Hypothesis: The PT2399 has an internal 2.8k resistor that adds to the external resistor, and delay time is set linearly according to the sum of the internal+external resistors." --stm, June 17, 2008

Yes, "exactly" the same but I am 2 years behind stm.

The delay "IS" (inverse) linear with resistance, IF you include the internal resistor.

We won't argue the 2.5K/2.8K difference because it is all within 30% Silicon resistor absolute tolerance.

Using a series resistor we are at the mercy of the uncertain internal resistor. At the shortest delays this is about 10 foot air-path slop. If emulating stadium-size acoustics, NBD. If emulating the Rt3 Blues Wagon (13 feet from guitarist to furthest customer!) then different PT2399s will sound like the Blues Cart or the Blues Hall.

_IF_ we have deciphered the internal topology, then we can avoid the internal tolerance with a buffered approach such as I just drew.

The digipot can just as well be a plain pot for hands-on operation; or a switch-tapped resistor string for repeatable fixed settings.

There's (many!!) other ways to do this. Waving Vref, fer example. My way just seemed clear and clean.

[PRR]

The requirement to pull pin 6 VERY low, with ~~1mA current, for shortest time, is tough. Many "rail to rail" amps exist. None will actually pull to 0.000V from the negative rail, many come close only for very small current. LM324 actually does well IF you only need 50uA; else it won't go below 0.6V.

I found the one chip, in DIP pack, but the world supply may only be a few thousand. And it aint cheap, especially if you are not ordering anything else from the few suppliers who have stock.

It would be useful to have a jelly-bean buffer, one using only COMMON 2-bit parts. From 20 feet away, it is 1/4 the cost for 4 times the labor, a wash. For a DIY-er, the labor may be preferable to paying small-order handling charges.



Stuff inside dotty lines is (digi-)pot or PT2399.

Transistors are two PNP and one NPN. Types and specs are not very important; use what you got. For best performance, Q1 Q2 should be high-gain. If Q3 is a "larger die" (higher current rating) type, the minimum voltage is a bit better. Two 2N5087 with one 2N4401 or Aron's 2N2222 would be dandy. But the widely-used 2N3906 2N3904 set will be fine.

Resistor values R1 R2 are moderately fussy. Try to get within 10%. If you must deviate, keep a similar R1/R2 ratio.

Resistor R3 is not fussy and not essential when connected to the PT2399; it's there mainly for testing.

Minimum output should be under 100mV but won't be much under 50mV.

Designers: don't reduce Q1 Q2 current, we need good current in Q1 so its base-emitter voltage is high enough to sock Q3's base-emitter. A discrete Darlington would lift this limit, but Q3 also has a collector-emitter drop, so little is gained.

[MoltenVoltage]

Here's how we solved the problem of the digipot variations:

Hook the clock output (pin 5) of the PT2399 to a 4017 and divide by 10 (the 4017's frequency limitation just squeaks by for the tap-based frequency range of the PT2399)

Then take the /10 output and run it into the uC

Then the uC sets the digipot to 255, samples the 4017 output for a fraction of a second, calculates the corresponding tap timer value and stores that value in a table

Then the uC sets the digipot to 254 and does the same, repeating this all the way down to the shortest time needed to deal with tap inputs

Then when the user taps, the uC calculates the tap interval then starts in the middle of the calibration-generated table and looks up or down until it hits the closest value, at which point the associated digipot value is sent to the digipot.

What makes this technique cool is that you can use any digipot or even run two in series (since the 100k pots are often below 75k), then have the device self-calibrate each time it powers on.

[slotbot]

now why not take it a step further and get rid of the digipot. use fast pwm out to blast an led/ldr combo. probably the cheapest way.

also i am really surprised you need to divide by 10. i googled pic frequency counter and people have them working in the GHz range. what type of algo are you using?

[Taylor]

now why not take it a step further and get rid of the digipot. use fast pwm out to blast an led/ldr combo. probably the cheapest way./

But isn't the tolerance on LDRs bad enough that you'd end up where you started?

[slotbot]

now why not take it a step further and get rid of the digipot. use fast pwm out to blast an led/ldr combo. probably the cheapest way./

But isn't the tolerance on LDRs bad enough that you'd end up where you started?

true, but the fact is that by measuring the rate of the pt2399 this way you dont have to worry about any tolerance (of any device, digipot/ldr or otherwise). just making a suggestion for the cheapest way to do this/with least specialized parts. Also the digipots have what, 256 presets? 16 bit pwm => ~65000?  

edit:

also above i said GHz but i meant MHz. Most around ~50Mhz which is consistent with the physical pin properties of a pic.

[Taylor]

Oh, right. D'oh. Need to stop posting at 3 in the morning.

[MoltenVoltage]

As far as /10, you'd have to count at almost 11 MHz which might be possible running at 40 MIPS, didn't test that.  But the 4017 also cleans up the signal which is really bad when you get to the longer delay times, so since you need a buffer, why not divide down.

Re the PWM suggestion, the rise/fall times on an LDR are something to consider.  Here's a datasheet I found with a quick search that identifies a 2.8 mS rise time and a 48 mS fall time at 1000 lux:
http://www.biltek.tubitak.gov.tr/gelisim/elektronik/dosyalar/40/LDR_NSL19_M51.pdf

Assuming you have 1000 lux LED, that's at least 50 mS per test.  If you have 10 lux, you need 125 mS per test.  For 200 tests, you are looking at 25 seconds for calibration.  The way I have it configured the whole calibration takes less than 2 seconds.  Not that speed is that important on power up.

Overall a good suggestion, but vactrols are pricey (>$4) while the digipots are under $1, and rolling your own vactrol or making a light-proof enclosure is a pain and almost as costly as the digipot for parts alone.

If the higher resolution of the PWM were important (which for tap tempo it probably isn't), then it would make sense to consider PWM.

[slotbot]

well i would use an RC filter in front of the LED to have a DC voltage instead ( LED not turning on and off, but having a constant DC current proportional to the PWM value) but ya if digipots are so cheap... I was not insinuating this is not an excellent solution, just to me less specialty parts = better. Also you could get fancy implement it more as a PID style controller and not even use a LUT to say xyz tap time means abc pwm.

Also ya the 65000 comment was more of a joke.

But really how are you measuring frequency? You dont have to post your code im just interested in the theory of the algorithm you are using. If you hook the clock up to a timer/counter the MIPS of the processor becomes completely irrelevant if you are driving it with an external clock (the clock out of the pt2399) . What becomes relevant is the capacitance of the pin (ie how fast can you charge/discharge this capacitor => how fast a clock you can drive it with).  This is very standard feature on all MCU from all major manufacturers. From what i have read on the net of peoples success it seems ~ 50 MHz is the upper limit (with PIC, which im assuming your using)  of this technique although having not tried it myself i cannot vouch for these results, just thought it might help you drop the parts count.

[PRR]

> that's at least 50 mS per test.

You wrote mostly what I was too lazy to write.

LDRs are worse than the sheets really say. They have "history" and light/dark several minutes ago will affect the present resistance.

And it isn't that bad. The rise/fall times are specced dark-light and light-dark. They go low pretty fast for small increments. Bring the LED up to half-bright for a second, full dark for a second. Then ramp until you hit your largest target, say 30K. Hold for 50mS to be sure, store. Ramp to 29K, hold 5mS, store. 200 tests is not much over 3 seconds total (including preconditioning).

They will still drift for no known reason. If you are very-very fussy, just use the stored values to get an initial setting, so the song starts on-tempo near-enough. Then monitor the clock and fine-trim the rate to the set tempo, simple math.

You could probably just do 10 or 20 startup calibrations and interpolate; the curve is curved but smooth. That would only get you from 3 seconds to 2.1 seconds, maybe easier to read 200 values than to interpolate and maybe start 0.5% off-tempo.

[potul]

I share most of the thoughts of slotbot.... According to the datasheet, most PICs (even simplest ones) can count up to 50Mhz using TMR0 in async mode and the 1:256 prescaler. And there is an interesting technique to avoid any additional hardware to gate the signal. See this interesting post with some information:
http://www.electro-tech-online.com/microcontrollers/99153-100mhz-frequency-counter.html

Regarding the pwm vs digipot discussion: In fact with the measuring of the clock freq, we have a closed loop system where we can get realtime feedback of the delay time we set the PT2399. Why using the calibration procedure instead of continuously reading the freq and correct on the fly? This would make the variations in digipots or ldr almost irrelevant...
You would still need a table to target the nearest possible value in order to minimize the stabilization time, though.

Potul

[MoltenVoltage]

That's how I did it, just resetting the TMR0 async counter and changing the pin to an input for x instruction cycles.  TMR0 is pre-scaled accordingly.

I wanted to calibrate up front to make the run-time code as efficient as possible.

[slotbot]

At this point i think its splitting hairs as to what type of 'R' you use. The big step is getting the closed loop feedback to work which, in combination with whatever R, is going to be much more accurate than the previous solution offered. nice work mv

Back to splitting hairs: what about filtering the PWM to DC then driving a transistor similarly to the 3904 in PRR's nice schem? 1 transistor plus 2 or 3 passive components  is cheaper than 1 digipot? will it work? 

[slacker]

That should work fine, I've used a transistor driven by an LFO to modulate the delay time which is basically the same thing.

[potul]

That's how I did it, just resetting the TMR0 async counter and changing the pin to an input for x instruction cycles.  TMR0 is pre-scaled accordingly.

I wanted to calibrate up front to make the run-time code as efficient as possible.

And, is  the divider needed because of processing power of the PIC not enough?

[MoltenVoltage]

Like I said, I didn't test without the divider but assume that the signal needs some type of buffer since it gets really ugly at long delay times.  Put it on a scope and see for yourself.

It might work without the divider - it's worth testing.  The async clock counter should be able to handle up to 50 MHz per the datasheet.

You'd also need to take a smaller sample if its 10x as fast due to the 16 bit counter, so maybe more like 1/1000th of a second per sample.

[potul]

Like I said, I didn't test without the divider but assume that the signal needs some type of buffer since it gets really ugly at long delay times.

Oh, ok. Sorry I missed this point.