Precision current control with Digital Potentiometers

[Taylor]

lol. do you have any clips of this?

i tried to start making some less weird thngs, i never got into teh FV-1 yet but i am still farting around with dsPiC. i started to make a sort of tremelo ring mod combo here http://www.youtube.com/watch?v=eHDSSkvuBDM.

Looks cool! I'm not a super-smart person and have no college math or programming training, but got into the FV1 fairly easy, so I think you could get into it if you were interested. I don't know if it really has anything that the dsPIC doesn't though, so I'm not sure if there's much reason to try it from your perspective.

but not to hijack the thread....

I know pt2399 is dirt dirt cheap but i often wonder, if you think about all the effort you put into making a pedal, is the difference between a 50 cent or 5 dollar IC really that meaningful? obviously from mass production standpoint yes but interms of elbow grease etc to do one or two it really seems a bit silly to me.


edit: sorry i didnt mean using the pt2399 in general seems silly, actually its super awesome. but i meant to go through all teh troubl of developing trap tempo, whenits not that great a delay to begin with.

Well, I think for an individual who just wants to build a DIY tap tempo delay, the PT2399 isn't really worth it. But for someone who wants to develop this as a chip for the DIY community, it makes sense because a lot of people just absolutely will not mess with SMT (FV1). So a tap tempo chip in a DIP package makes sense as a product for DIYers. I guess "decc" (Thought PRocess, Inc.) has gotten out of the game, but I'm not sure what the problem is with the Taptation that needs solving.

[slotbot]

Yes your points are all very good. Actually re dsPIC vs FV-1, to me learning about fv-1 would not even be about capability but more so to broaden familiarity with devices/languages and also a lot of people use it so i can see what people are talking about (like yourself sampling at 260 hz)

There are DIP dspics with built in ADC and DAC (not 24 bit like fv-1 but still comparable or better than pt2399 quality im sure). If your just looking for a delay it would be super easy to incorporate the SRAMS that microchip makes. I was doing this before but switched to a TQFP package so i had enough pins for using normal ram (its much faster and way cheaper per meg sort of thing).

But if you want to make something friendly and all dip you could probably get away with a quad opa the pic and as much srams as you want. And then easily make an extremely accurate tap tempo among any other number of features. Costs more, more ics etc but not prohibitively so. If you use the 12 bit AD and the 256 kbit srams and sample at say 32kHz  you get about .7 seconds per sram. Thats not that bad since they are ~ a buck a piece.

[JKowalski]

The more obvious use is just insane weirdness, though, which I know from your products is something with which you're familiar.

lol. do you have any clips of this?

i tried to start making some less weird thngs, i never got into teh FV-1 yet but i am still farting around with dsPiC. i started to make a sort of tremelo ring mod combo here http://www.youtube.com/watch?v=eHDSSkvuBDM.

but not to hijack the thread....

I know pt2399 is dirt dirt cheap but i often wonder, if you think about all the effort you put into making a pedal, is the difference between a 50 cent or 5 dollar IC really that meaningful? obviously from mass production standpoint yes but interms of elbow grease etc to do one or two it really seems a bit silly to me.


edit: sorry i didnt mean using the pt2399 in general seems silly, actually its super awesome. but i meant to go through all teh troubl of developing trap tempo, whenits not that great a delay to begin with.

Yeah, it is silly, if you have the means and knowledge to program the chips.

But many of the people here have no idea how to write code & don't want to get into it, so they focus on the PT2399 which is a godsend to a largely analog community.


If someone codes a dsPIC for tap delay I think they could easily sell them--probably the best solution, but then you got to have someone willing to do the work and sell in a not-so-hot market. You'd want something to replace the PT2399 directly, since the major appeal of the chip is that it is plug n' play with pretty much no need for digital knowledge.

Wish I could get into dsPICs but so little time! It's funny how hitting the university for an electrical degree caused my electronics knowledge intake to basically halve.

[MoltenVoltage]

I started working on a PT2399 chip over a year ago then kind of put it on the back burner when decc beat me to the punch.

The problem with the taptation is that it assumes that digipots are accurate when in fact they are ridiculously inaccurate (+/- 30% tolerance).  As such, you can't simply create a table and expect the tap timing to line up with the delay time with any reasonable amount of accuracy and/or consistency.

The dsPIC is limited to 12 bits but can output an extremely fast sample rate.  I've thought about making a dedicated delay chip with it, but just don't see the point in making a 12 bit delay chip when, with a few(?) months of work, I could learn a more powerful chip and make something 24 bit with 96kHz sample rate, like the Empress delay:
http://www.empresseffects.com/?page=superdelay#

IMO, that's the gold standard for boutique delays at this point.

Slotbot, seems to me I've read about using SD cards as external memory for the dspic.  Might be a lot more cost effective than $1 for 256K SRAM since you can get 2 gigs for $3!

[slotbot]

@MV

Yes 12 bits is not great but more than good enough and the DAC interpolate 10x sampling rate at 16 bits resolution so its pretty smooth, i was simply suggesting since you can go all dip that way easily and less chip count than making full audio system.  The best option to me is to use an external Audio CODEC IC but i dont think there are many available in DIP.

And yes SD is excellent bang for the buck in terms of memory. Do you know what the access times are like? (real question) I think you have to read/write to them in pages as well but im not an expert on SD. Maybe with some DMA buffering it would be fast enough for a delay but im not sure.

I think you have to decide whether we are talking about making something that anyone could assemble or a cut throat state of the art digital delay using smt etc. My suggestion was more for the former. But i agree the empress products are very very nice.

The problem with the taptation is that it assumes that digipots are accurate when in fact they are ridiculously inaccurate (+/- 30% tolerance).  As such, you can't simply create a table and expect the tap timing to line up with the delay time with any reasonable amount of accuracy and/or consistency.

I seriously think that you could read the frequency of fck pin and adjust a digital pot with the same MCU. Like a feedback controller. The Fck/ delay time relation should be very accurate since the number of steps in the delay line is fixed. This way you can check if the pot is really at the value you wanted and adjust accordingly. Its certainly less straightforward but could give better results

@JKowolski

Im just making some suggestions and hopefully not coming off as belittling anyones level of knowledge or taking a crap on anyones attempts to enhance the pt2399. I am certainly far from a dsp expert myself (but could probably code this for you without much effort) . Good luck with your schooling!

[MoltenVoltage]

I seriously think that you could read the frequency of fck pin and adjust a digital pot with the same MCU. Like a feedback controller. The Fck/ delay time relation should be very accurate since the number of steps in the delay line is fixed. This way you can check if the pot is really at the value you wanted and adjust accordingly. Its certainly less straightforward but could give better results

Frank actually suggested this on page 1 and I'm pretty close to having it working but there are some technical hurdles involved that have to do with the messy output of the PT2399 at long delay times and the physical limits of frequency dividers.

...

I wasn't thinking about the read and write times or page write requirements of SD, both good points that need to be considered.

[JKowalski]

@JKowolski

Im just making some suggestions and hopefully not coming off as belittling anyones level of knowledge or taking a crap on anyones attempts to enhance the pt2399. I am certainly far from a dsp expert myself (but could probably code this for you without much effort) . Good luck with your schooling!

No, don't get me wrong, I was totally agreeing with you. Just pointing out why exactly the PT2399 is popular.

On another note, if I was to get into DSP, any tips? Are dsPICs a good start, since I am pretty familiar with coding PICs in assembly and c? Or should I look to a more formidable product?

[slotbot]

Frank actually suggested this on page 1 and I'm pretty close to having it working but there are some technical hurdles involved that have to do with the messy output of the PT2399 at long delay times and the physical limits of frequency dividers.

Ah ok. I have some pt2399 maybe i will look into it as well. I was thinking something like feeding the clock into a counter pin of an mcu and jsut taking snapshots of the counter register at fixed intervals. IE if the counter reads X in Y seconds (or fractions of seconds ) then f = Z and that is either less than or more than i wanted from my tappa tap.

On another note, if I was to get into DSP, any tips? Are dsPICs a good start, since I am pretty familiar with coding PICs in assembly and c? Or should I look to a more formidable product?

Hmm well probably dsPICS are not the most advanced chip. I was facing the same problem before trying anything out. I noticed that there is a lot of actual published books on the TMS320 (dsp's are i think 5400 5500 and 6500 series) and they look impressive but from what i could find out CCS (the TI IDE) is not free for dsp's, only for the mcus. The educational discount brings it to 300 dollars instead of 1000 but i still haven't made the splurge.

Maybe someone like that guy who had posted the tiny dsp pcb a month or so ago would have more to say about the differences between companies and have some suggestions.

I already was using MPLAB for the 8 bit pics. The dsp's are a bit different obviously but if you know C it is not difficult at all to get started . If you have a programmer that can do the dsps already id say order some samples from microchip direct and try it out. In summary, i have no overwhelming reason as to why i am using dsPIC other than it is here on my desk now and the documentation is complete enough to teach yourself, although i would warn it is not quite as explicit as it is for their 8 bit products.

I will try to pump out some sort of 12 bit delay line and see if it is really so easily feasible or not.

[slotbot]

heres a crude demo of said dip delay line:

http://www.youtube.com/watch?v=eKgtkvLeNCE

no frills atm.

[cloudscapes]

heres a crude demo of said dip delay line:

http://www.youtube.com/watch?v=eKgtkvLeNCE

no frills atm.

we gotta get you a new camera 

great stuff! what kind of ram are you using? SPI? I'm using a few 23k256's for my looper at the moment. dsPIC I assume?

[slotbot]

I know I know. My friend has a nice sony camcorder that he said i could borrow to make demos in the future. The built in one on my laptop stopped working so i am using this wonderful 4 dollar rocketfish webcam.

anyways ya this is just dsPIC with 4x spi rams. they are the only real affordable dip ram?  spi becomes the real bottleneck though. right now i cant really get beyond 55 kHz sampling rate and it is simply due to ram access time. it seems most microchip (rams dacs etc) devices are advertised up to 20 MHz spi clock but i *think* the dsPIC can only put out 10 MHz? i set the prescalers to output a 20 MHz clock but it is not stable at all (possibly also due to "breadboards love 20 MHz"). Some of the pics have 2 spi buses so that may be a way to get better results since you can read to one while writing the other etc, potentially hitting the 96kHz sampling grail (still at 12 bits though )

[cloudscapes]

55KHz is really great, though! Probably more than enough for just about anything, in my opinion.

I use the same SPI rams. Only solution I've found that doesn't involve a crapload of pins (something DIP micros don't have). Every now and then I go on a digikey/mouser spree looking at different kinds of RAM. It really is all paralel. I figure one of these days I'm gonna have to tinker with an XMEGA or something else with DMA. it's true SPI eats a lot of clock ( )....

a lot of these projects use paralel RAM and DACs/ADCs so the MCU doesn't even need to sample! The bit lines are shared and the MCU just needs to juggle chip selects, read/write states, etc.

I'm sampling at around 10KHz for my current project. 8bit AVR though, 12MHz (actually overclocked for 3v operation). and there's a lot of sample-manipulation code that doesn't need to be there if I want bare-bones sampling. I've still not made the official jump to dsPIC, even if I've tinkered a bit.

[Galego]

Aren't you guys being a little anal with this "digital pot precision" issue?

I'm a noob and made a delay with a PIC 16F684 controlling both the delay time and PWM output as an LFO for the modulation effect of slightly changing the delay time... and it works just fine. No one is going to check if after 100 blinks the led is matching the delay time perfectly. As long as you look at the led when you are tapping and there isn't an obvious discrepancy, i don't see what the issue is.

If there's any need to fine tune the program on how the digital pot is matching the tempo on the PT2399, either use a variable you can change to make it right, or simply program a mode to change it using the controls you are connecting with the PIC. Initially i was going to do that. Have an internal microswitch, that when pressed would enter a mode where you'd tap to the delay you were hearing at max delay time, and the program would write the variable to the flash memory and it would be calibrated. It would of course be then read at every startup.

[Taylor]

Well, to a certain extent I agree with you in a general sense.

But I agree with Karl that 30% is pretty far off.

[Galego]

Well, to a certain extent I agree with you in a general sense.

But I agree with Karl that 30% is pretty far off.

Well i'm just a bit surprised because i didn't encounter this issue at all. Was i blessed with better digital pots?
Because if i remember correctly, the 41050 i used at first measured between 50 and 51k and the 41100 was something like 105k i think. I still have a bunch of them for other projects, if i do anything with them, i'll try to remember to post the results here.

[Taylor]

Well i'm just a bit surprised because i didn't encounter this issue at all. Was i blessed with better digital pots?

Yes, very possibly - obviously when the tolerance is 30% plus or minus, that doesn't mean it will always be 30% off, it just means that 30% off is possible.

[RonaldB]

Has anyone seen this:
http://www.woosteraudio.com/space-baby.html

This one seems good.

RonaldB

[PRR]

> digital potentiometers have ... tolerances ... sometimes +/- 30%.

It is sold as a POT, not a rheostat. The RATIO is correct. The total value is approximate. That's the great thing about potentiometers: you don't need exact resistors, just exact ratios.

Sadly this PT2399 is specified for a rheostat.

> it appears that the delay time is not related linearly to the control resistance.

It "is". Imagine 2,500 ohms inside the chip.

I extracted the numbers from this datasheet, plotted T/R, then T/(R+2500). Then times 1000 just to get numbers near ten.

1000*(T/(R+2500))



If the relation were exact linear we would get a straight line. The numbers wander  up to 11.7 and down to 11.4, or 2.6% spread, or +/-1.3%. We expect some rounding-spread because the numbers are reported to 2 or 3 significant digits. There may also be some hasty data collection and some temperature/voltage drift over the course of the measurements.

Anyhow, ~~1% slop is typical of simple R/C oscillators. And there's no mass-market demand for <1% precision in delay times.

So for a given delay T in Seconds you need a resistor R in ohms

R = ((86,681*T)-2500)

ex:
342mS is ((86,681*0.342)-2500) = 27,145 (sheet sez 27.6K)
40.6mS is ((86,681*T)-2500) = 1,019 (sheet sez 1.08K)

(EDIT: The average factor over the suggested range 27.6K..1K works out as 86,245.)

JUST like the digi-pot, I assume this "2500" internal resistance has typical chip-resistor +/-30% tolerance. For the longer delays this does not matter: rate and delay is dominated by the external resistor. For delays 100mS and shorter it starts to matter.

There's lots of ways to flow a controlled current. There's a way to emulate a single-ended resistor IF that Pin 6 is not wobbling up and down at MHz rates or sinking real close to V-.

> clock is between 1 and 17Mhz.  Calculating those speeds is beyond the reach of my 40MIPS chip
> 4017 hits a very definite ceiling at 10MHz

Pre-divide. There's much faster dividers than the 4017 CMOS chips.

F/V conversion. Tachometer. Astable monostable generates a fixed-width pulse on each clock. Average the pulses to a DC level. This adds an averaging delay, which may confuse a PLL.

Put a narrow BIG blip in the input. Monitor the output for a big blip, while counting time. This is not performance-friendly, of course. A big + and - zig-zag at input, monitored at pins 10 11, is unlikely to appear in program input and may not be a big audible thump.

> I don't think a 16K sampling rate translates directly into a max audio frequency of 16 kHz.

It's a 3-D concept.

You have a Sample Rate. This must be twice the highest signal frequency. If unwanted frequencies may slip in, they will alias into the signal frequencies, you want filters. There's no brick-wall filter, so your max signal is less than half the sample rate.

You have a Sample Depth. Every bit adds 6dB signal/garbage. 8-bit samples give 48dB and even telephones don't get that bad (they use 8-bit but with a trick). 10 or 12 dB is in the area of LP, tape, or good BBD... not the same because the noise quality is very different. 16-bit is available on CDs, though 99% of the CDs on the market don't really need that much (Rikki Martin tracks are all up in the top 8-12 bits).

So CD quality takes 44,200 samples per second, 16 bits per sample, 707,720 bits per second. (Times 2 for stereo.)

Guitar does not need or want much past 6KHz. 12,000 samples per second would be OK, if we can keep all >6KHz signal out of the system.

Total Delay is the number of sample which will fit in memory divided by the sample rate.

8-bit and 16-bit RAM is common. So we often pick 8 or 16 bits and just quote a sample rate.

RAM is cheap but not free. In custom-chip work, it may make sense to re-layout for 12 or 14 bits in trade for 14% or 33% longer delay time.

Common computer RAM is optimized to deliver any word equally fast. So common that other types have faded. However a "FIFO" is optimized as a pipe: what you put in is not available until it gets to the output. This saves a lot of address connections, though does usually need a connection from each cell to the next, so it aint a lot smaller/cheaper.

The standard ADC is Successive Approximation: to get an 8-bit sample it does 8 steps. It outputs one bit of result each step. An SAR ADC fits naturally with a 1-bit FIFO. For 10,000 samples per second, you clock the SAR at 80,000 steps/second and put them into the FIFO. This is the same number of bits as 10,000 8-bit samples per second, but the hardware is (or was) simpler/cheaper. There's other ways to do 1-bit sampling, and because audio does not swing full-scale at maximum frequency there's ways to save some RAM bits. I think modern cheap RAM has made this moot.

[PRR]

The PT2399 datasheet shows a "44K Bits RAM". The fact is is quoted in bits not Bytes suggests they use a Delta-Mod process. Instead of encoding the absolute value of each sample, they encode the _difference_ of each sample to the one before it. The difference is just "up" or "down". In audio, this works well as long as the bit rate is much higher than the Nyquist Criteria for the desired audio bandwidth. The multiplier is essentially the sample-depth we would use for parallel encoding, 8 (ugh) or 16 (CD) or whatever.

Taking the given "44K Bits RAM" and the given clock-rates we find the equivalent sample-depth:

44Kbits 2MHz 0.342 sec 15.5 bits/sample
44Kbits 16MHz 0.043 sec = 15.6 bits/sample

The theoretical noise is 94dB down. The noise spec is -90dBV and max out is +2dBV, 92dB. The 94/92 difference is analog noise, rounding, or conservative specs.

A flaw in Delta-Mod is that it can not handle a full swing at maximum frequency. Fortunately speech/music never does that: it is not easy with massy mechanical noise-makers (vocal cords, trumpets, guitar strings) and would burn our ears and our tweeters. This is similar to Slew Limiting and Merlin observed such an effect. His chart is steeper than simple slewing. I forget what the math on Delta-Mod implies. The steepness suggests that a PT2399 may "smear" cymbals and the brightest over-drive--top-boost screamin' guitar sounds. The slewing should be less at short delays, unless there is additional slowness in the mod/dem blocks; Merlin does not cite what delay was measured.

This ~~~1KHz roll-off is NOT frequency response. The chip is surely flat to 5KHz or beyond. It just won't make big 5KHz output. Since the ~~90dB range is generous, you can reduce overall level to half-volt and have 5KHz as strong as 1KHz.

Slewing smears complex multi-timbre sounds such as orchestra and choir. It is fairly benign on a single instrument such as guitar.

[PRR]

Control:

Merlin proposes an internal structure not shown on PTC's sheets: an opamp with "+" to 2.5V, a "1K?" NFB resistor, and the "-" input at pin 6. The output of this amp is then 2.5V plus 2.5V times the NFB gain ratio. Extrapolating the resistance-time table, infinite resistance at pin 6 gives low-low clock rate, saying that the VCO is zero-frequency for 2.5V input and rises as external resistance and gain forces the opamp output positive of 2.5V. An obvious limit is the 5.0V supply. The resistance-time table shows clock rate rising even from 288 ohms to 0.5(!) ohms, so apparently the gain is internally limited somewhat short of slamming the opamp to 5V.

Merlin gives "1K?". Elsewhere I found 2K5 missing in the resistance-time table. I'm going to assume Merlin's "?" means "very approximate". Perhaps a retrogress on his graphs would find the value for his specific chip. Since this is probably +/-30%, 1K75 to 3K25 would not disagree with the 2K5 found from factory data.

Putting the clues together, I propose this equivalent "inside" for PT2399:



Since frequency is somewhat ratiometic to Vref we may use a pot against Vref to set frequency.

Because the Pin 6 impedance is only 2K5, and our digipots are 10K or 100K, we can not wire the pot directly or we will have large loading errors, made unpredictable by 30% tolerance on both digipot and PT2399 internal resistors. The PT2399's internal Vref is also a high and uncertain impedance (see Merlin's 5K6 measured versus 4K7 speced). However buffers with hi-Z input and lo-Z output eliminate loading effects. Potentiometric beauty.



There is one killer spec on this buffer. Assuming we don't have a negative rail (and don't want to stand the PT2399 on a diode), the buffer output must pull-down VERY close to zero volts with a 1mA load. (It must also have inputs that work to zero but this is easier to find.) We (some of us) also prefer thru-hole DIP not the teensy-packs.

In some searching, I only turned up one strong buffer which works:
LM6132BIN
http://www.national.com/ds/LM/LM6132.pdf
Both DigiKey and Farnell/Newark have stocks of the DIP-8 package for $3-$4