Everyone familiar with the PT2399 knows that you vary the delay time with a resistance. There are a couple chips floating around that perform this function using a digital potentiometer whose resistance is set based on a tap tempo input.
The problem is that digital potentiometers have even worse tolerances than mechanical ones, sometimes +/- 30%.
Suddenly your calculated delay time can sound like triplets instead of 1/8th notes.
There are some brute force methods of minimizing these errors, none of which are very practical (e.g. hand-sorting large batches of digipots).
I thought that maybe putting 2 100K pots (which read 70K each for a total of 140K) with a resistor in parallel would solve the problem until I made a spreadsheet and found that the errors don't exist at 0 and 100, but they get larger and larger until you get to 50% where they peak. With a 140K resistance scaled down the error is over 8%, so the problem is slightly less, but not much. Of course the further off your initial resistance, the greater the error.
I've read all the microchip app notes but can't find anything that solves the problem of precision programmed current control.
Being a programmer primarily, I assumed that a "digital potentiometer" would have "digital precision", until I had them on the breadboard and read the nominal resistance of a batch of 100K pots at 70-80K average. This makes consistent precision control of the PT2399 a challenge.
The other thing I've noticed is that I can never get precise reads on the nominal resistance. It changes from multimeter to multimeter, and when I perform current tests using the nominal resistance and a known voltage, it can be 5% off from the calculated value.
So, the questions remaining are:
1) How to achieve precision resistance values using digital potentiometers
2) How to get consistent readings of the resistance of digital potentiometers
Hopefully 19,000 heads are better than one! Thanks!
Quote from: MoltenVoltage on October 25, 2010, 11:58:53 PM
I've read all the microchip app notes but can't find anything that solves the problem of precision programmed current control.
Why don't you just use a precision DAC with the required analog components to use the output to control the PT2399 pin?
It doesn't have to be a resistance change.
I think digital pots are mainly used for controlling volumes of audio signals & similar where total resistance isn't that important...
I second the precision DAC idea. 12 bit is probably enough for something that's foot-tapped. DACs won't give you the three-lug pot digital pots will, but I don't think that's needed with the 2399, if I recall.
Thanks for the responses.
I don't think you can just apply a varying voltage to Pin 6, but I may be wrong.
I looked at the datasheet and it does say that Pin 6 is a VCO frequency adjustment:
"Overall delay time is determined by internal VCO clock frequency, and user can easy to change the VCO frequency by changing the external resistance."
However, Pin 6 is a current drain to ground, and I don't think can just put a voltage onto a pin that is expecting a current drain to ground.
The only other way that I know of to control current using a voltage is with an FET, but then you are just trading one problem for another since they are at least as variable as the digipots.
Chris, were you thinking of an FET when you said "required analog components"?
I'll offer a third vote for a DAC. Even an 8-bit DAC would probably be good enough. You could use a current-output DAC, but a voltage-output DAC with a resistor in series with the output would probably work as well.
Looking at the data sheet for that delay chip, it appears that the delay time is not related linearly to the control resistance. I also doubt that the numbers given in the data sheet for delay vs resistance are very accurate or consistent from one device to the next. The VCO must use one of the external capacitors in the oscillator circuit, and the frequency accuracy would be directly tied to the tolerance of this cap.
If you're looking to get precise control of the delay time, I would say that you should find a pin on the PT2399 where you can pick up the VCO frequency output and measure it against a crystal controlled reference. Then, using successive approximation, adjust the VCO control DAC until you get the exact frequency you want.
I don't think there's any way that blindly setting a resistance value on the VCO control pin will ever give you an exact 100.00ms delay.
I would vote against a DAC here, given the VCO uses a single resistor to set speed and the speed increases as the resistance decreases I would guess it is some form of current starved VCO in which case the speed is controlled by the current allowed to flow through pin 6. Pin 5 says it is a clock out so monitoring that and adjusting the current allowed to flow through pin 6 would probably be the best solution.
I did it once by driving an NPN with an AVR's PWM (like a DAC) which in turn starved the 2399's VCO. worked like a charm, though a lot of biasing was needed. and I wasn't doing tap so wasn't interested in acuracy.
Monitoring the pin 5 output is a great idea, as I checked that it varies proportionally to the Pin 6 resistance BUT the clock is between 1 and 17Mhz. Calculating those speeds is beyond the reach of my 40MIPS chip.
Maybe some sort of high speed phase lock loop system could resolve those speeds - in a manner similar to the FM tuner auto-tune function? Just thinking out loud with very little practical knowledge of how those systems work.
Quote from: MoltenVoltage on October 28, 2010, 01:42:47 AM
Monitoring the pin 5 output is a great idea, as I checked that it varies proportionally to the Pin 6 resistance BUT the clock is between 1 and 17Mhz. Calculating those speeds is beyond the reach of my 40MIPS chip.
Maybe some sort of high speed phase lock loop system could resolve those speeds - in a manner similar to the FM tuner auto-tune function? Just thinking out loud with very little practical knowledge of how those systems work.
Yeah, a phase locked loop would work. That would basically give you the ability to clock the PT2399 externally.
PLL's are pretty finicky circuits to design. But it is doable. Another plus with PLLs is that you can stick a frequency divider chip in the loop to multiply the frequency input - enabling you to input much lower speeds to get the right high speed clock output on the PT2399. So you can probably use your aforementioned 'chip'.
I already tried using a 4017 to divide the clock frequency (I was going to cascade 2 to divide by 100), but the clock output of the PT2399 gets really lousy below about 10MHz - very non-sinusoidal with extra peaks, and it just gets worse from there down to 1MHz. As a result, the 4017 gets the count wrong. I assume a PLL circuit would have the same problem. I doubt a schmitt trigger could even clean it up, as the clock's waveform distortion gets really severe at the lower speeds. I suppose I could chart the count errors and make a table for the dsPIC to read, but that seems like a very in-elegant answer.
I also tried putting a voltage into pin 6 (with and without a series resistor) and it wouldn't delay at all until the voltage got near zero, then it was just acting as a current drain again.
Interesting problem.
The 'Use a DAC' approach is definitely viable. Here's a couple that'd do the job:
http://www.maxim-ic.com/datasheet/index.mvp/id/4806 (http://www.maxim-ic.com/datasheet/index.mvp/id/4806)
http://www.analog.com/en/digital-to-analog-converters/da-converters/ad5398a/products/product.html (http://www.analog.com/en/digital-to-analog-converters/da-converters/ad5398a/products/product.html)
These are both 'current sink' DACs, so could be connected directly to the PT2399.
Alternatively, the datasheet for the Microchip MCP4821/4822 series DACs has details on building a programmable current source:
http://ww1.microchip.com/downloads/en/devicedoc/21953a.pdf (http://ww1.microchip.com/downloads/en/devicedoc/21953a.pdf) (page 25)
This would work with a lot of other DACs too.
Hope this gives you a few ideas!
Regards,
Tom
According to Merlinb you can control it with voltage in the range 0 - 2.5 volts, have a look here http://www.diystompboxes.com/smfforum/index.php?topic=87543.0 (http://www.diystompboxes.com/smfforum/index.php?topic=87543.0) never tried it myself.
Not that I have any programming skills, but my thought was to use the clock out for error correction, but it seems like that's probably not doable.
Here's another idea that will probably work, very brute force though. Use a digipot, or whatever to control pin 6, then have another output from you uC that sends a pulse to the input of the PT2399, and another to read from the output. Set the digipot to some resistance say 1k, fire a pulse through the PT2399, calculate how long it took. Repeat over a range of resistances. Don't know what you'd do with data after you'd collected it, presumably you could use it to do some sort of lookup table or for error correction. I guess you could do this each time the pedal was turned on or store it somehow.
Probably be easier if we all just stopped trying to make the old PT2399 do stuff it's not designed to do and embraced something like the FV-1.
Quote from: slacker on October 28, 2010, 02:42:47 PM
Probably be easier if we all just stopped trying to make the old PT2399 do stuff it's not designed to do and embraced something like the FV-1.
This! +/- 1 clock-pulse... :icon_smile:
I went back and did some more tests (since I don't always get the best results at 3 a.m.), and found that the 4017 actually does a decent job of dividing the clock output across the range that matters for a tap input. I calculated an error of between 1 and 3 percent, but some of that could very well be due to my frequency counter.
It's worth noting that the 4017 hits a very definite ceiling at 10MHz, at which point it just stops counting.
I was hoping the FV-1 would work, but I really want something that can do at least 1 second of delay, and the PT2399 is the only practical solution I can find.
Also, since tayda sells the PT2399 for $.54 each (thanks frequency central!), it makes it a very attractive component.
Now I just hope the relationship between delay time and clock frequency is linear. :icon_eek:
Sincerest thanks for all the feedback!
Quote from: MoltenVoltage on October 28, 2010, 05:52:22 PM
I was hoping the FV-1 would work, but I really want something that can do at least 1 second of delay, and the PT2399 is the only practical solution I can find.
...makes 2 seconds if using the Mark Hammer/Bill Rupert/puretube - trick... (http://www.diystompboxes.com/smfforum/index.php?topic=87267.msg738952#msg738952) (=1st channel out to 2nd channel in)
[edit]: insert: :icon_rolleyes:
Since the FV-1 has 32K ram, doesn't that limit the total time @ 44.1kHz to about .72 seconds, whether you are using one channel or two, or does each channel have its own 32K ram bank?
I just hacked my second Fab Echo with the Taptation kit from the store. The first one is spot on - perfect sync, but the layout and footswitch I used are not really road-worthy.
Which inspired me to do another, nicer one, which of course is out of sync to the point that is neither fish nor foul - tap doesn't work but it's not quite as good as a DMM, soo....
I'm wondering - the delay times on mine are a little short of what they are supposed to be; would it work to just put a trimpot inline with the wire that goes to pin 6 of the pt2399? Or is it off by a different amount at every time.
It will be out by different times for different speeds. Adding a trim will just let you add a fixed amount of time, you might find a setting of the trim that is good enough for a range of times, but it will never be exact.
Quote from: puretube on October 28, 2010, 06:11:43 PM
Quote from: MoltenVoltage on October 28, 2010, 05:52:22 PM
I was hoping the FV-1 would work, but I really want something that can do at least 1 second of delay, and the PT2399 is the only practical solution I can find.
...makes 2 seconds if using the Mark Hammer/Bill Rupert/puretube - trick... (http://www.diystompboxes.com/smfforum/index.php?topic=87267.msg738952#msg738952) (=1st channel out to 2nd channel in)
Don't see the explanation of your trick other than the parenthetical statement there, but that's
not the way to get 2 seconds. Converting a-d-a twice doesn't make any sense when you can just lower the sampling rate to 16k, which is what you're doing with the stereo trick anyway, except with higher fidelity.
Quote from: MoltenVoltage on October 29, 2010, 02:03:23 PM
Since the FV-1 has 32K ram, doesn't that limit the total time @ 44.1kHz to about .72 seconds, whether you are using one channel or two, or does each channel have its own 32K ram bank?
Yes, but you don't need to sample that high. The FV1 is
way nicer sounding at 1 second(32k sample rate) than the PT2399 is at the same length. With a little filtering you can get a nice clean 2-second delay, as noted above, by using a 16k xtal. I have actually played around with getting much more time out of the chip than that even - with software sample rate reduction you can get a usable 8 seconds out of it, or if you're nasty, a whole minute. :)
You might say you want more fidelity than 32k sample rate will give you, but the PT2399 just plain does
not give more fidelity than the FV1 at 1 second. And no guitar speaker goes to 16k anyway.
BTW, Karl, I have no problem with you and don't want to stir anything up - just curious if this is homework for a commercial device?
You're right about the long delay times on the PT2399, they do sound pretty lousy (at least in the rebote), but the short delay times sound really good, the chip is very inexpensive, and there already exist multiple layouts and projects.
Maybe I'm wrong, but I don't think a 16K sampling rate translates directly into a max audio frequency of 16 kHz. You also have to look at the bitrate which, if I understand Frank right, is limited to 14 bits on the FV-1.
The other reason I hesitate to develop a controller for the FV-1 is that I think most people are intimidated by having to code the FV-1 themselves (I'm not in any hurry to learn another device). If there were out-of-the-box presets that were long pure delays, I would be much more motivated to come up with something. hint hint Frank!
2 seconds = 16khz sample rate = 8khz max frequency without aliasing (see Nyquist).
1 second = 32k sample rate = 16k max frequency
Steep filters are easy in the FV-1, so you can filter aliasing without losing as much of the instrument signal's bandwidth. Not so with the PT2399, so longer delays will always mean more grunginess and/or more loss of high frequencies.
You're right that DIYers are scared of SMT.
BTW, if 14 bit is too low bit depth for you, run fast from the PT2399, which AFAICT is 10 bits.
I thought the 2399 was 1bit, but at several magnitudes of the speed of conventional sampling?
Well, I did see something about that while googling, but I also saw something from Princeton saying it was 10 bits. They don't say anything about it, even in the more detailed datasheet. In any case I think it's fair to say that the PT2399 sounds much lower fidelity than the FV1. That's neither bad nor good necessarily, of course.
Quote from: Taylor on October 29, 2010, 06:19:44 PM
the FV1 doesn't leave a platform for a microcontroller product.
:icon_rolleyes:
_______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ :)
On the 14-bit issue: Keep in mind we are talking a floating point format so on real loud sounds a few bits will be truncated (but you aren't gonna hear it because, well, it's loud) and on soft sounds you get the full 24-bits of the MAC/converters.
As far as adding a pure delay as a default program, not going to happen. The programs are in a ROM in the FV-1 so changing them requires at least 2 new masks for production and if you have done custom chips you know what a mask set costs!
_______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ :)
For those interested, the relationship between frequency and delay time on the PT2399 is inversely proportional +/- < 1% from my readings.
Quote from: MoltenVoltage on October 30, 2010, 01:58:50 PM
For those interested, the relationship between frequency and delay time on the PT2399 is inversely proportional +/- < 1% from my readings.
Q.E.D. ...
At a slight tangent, has anyone ever tried running a suitable speed clock signal into pin 5? Depending on where this is tapped from and whether or not it's buffered you might be able to completely swamp the internal clock signal and control the speed that way. I believe circuit benders do a similar thing with crystal driven circuits.
Quote from: slacker on October 31, 2010, 06:29:22 AM
At a slight tangent, has anyone ever tried running a suitable speed clock signal into pin 5? Depending on where this is tapped from and whether or not it's buffered you might be able to completely swamp the internal clock signal and control the speed that way. I believe circuit benders do a similar thing with crystal driven circuits.
I feel like this forum has come around to this question (PT2399 tap tempo) a hundred times or more... :icon_neutral:
The answer was a definite no I believe, it is not like a conventional clock - the adjustment terminal is a completely different beast.
Quote from: JKowalski on November 01, 2010, 12:00:49 PM
I feel like this forum has come around to this question (PT2399 tap tempo) a hundred times or more... :icon_neutral:
The answer was a definite no I believe, it is not like a conventional clock - the adjustment terminal is a completely different beast.
It *does* alway seem to come back to this...at least, it will until someone comes up with the killer solution!
Part of the problem is the poor documentation. Even the better version of the PT2399 datasheet (the one with the block diagram) doesn't include everything.
http://www.synthdiy.com/files/2007/PT2399.pdf (http://www.synthdiy.com/files/2007/PT2399.pdf)
I think Slacker might be onto something. The datasheet shows the clock output pin 5 as unconnected. But presumably it is connected to the VCO output, which is also the clock *input* for the main delay block (whatever it really is - they're not saying). So perhaps you could feed a clock *into* the clock output, whilst tying something to pin 6 to ensure the VCO is disabled. Or alternatively feed 240V into pin 6 - that'd disable the VCO...;)
The datasheet also gives no clue at all as to why the Little Angel Chorus trick of feeding modulation voltages into the pin 2 ref works. It's frustrating, really.
T.
I always wonder why people don't link to the datasheet at the manufacturer's site which is usually more recent, like:
http://www.princeton.com.tw/downloadprocess/downloadfile.asp?mydownload=PT2399_1.pdf (http://www.princeton.com.tw/downloadprocess/downloadfile.asp?mydownload=PT2399_1.pdf)
Which does show more info.
Quote from: Taylor on October 29, 2010, 05:45:19 PM
2 seconds = 16khz sample rate = 8khz max frequency without aliasing (see Nyquist).
1 second = 32k sample rate = 16k max frequency
Steep filters are easy in the FV-1, so you can filter aliasing without losing as much of the instrument signal's bandwidth. Not so with the PT2399, so longer delays will always mean more grunginess and/or more loss of high frequencies.
AFAIK You cant filter aliasing once it has occurred. Aliasing = a higher frequency appearing as a lower one after sampling (ie getting a new Alias). For example if you sample at 16 KHz then play in a signal at 10 kHz, wihtout external filtering that will show up as 6 kHz when you play the captured sound back at the same rate. Internally you cant filter out the 10Khz because it never even gets captured as such.
Quote from: cloudscapes on October 29, 2010, 06:09:45 PM
I thought the 2399 was 1bit, but at several magnitudes of the speed of conventional sampling?
i am also pretty sure this is how the pt2399 works. This is why you get huge volume changes when you rapidly increase or decrease the sampling time etc. Sony was actually working on a standard based on this principle. http://en.wikipedia.org/wiki/Super_Audio_CD and many other devices work the same way.
What I was talking about is software sample rate reduction for longer delays. So I have a program (most of the clever stuff was done by another guy named Don Stavely) where only every n sample actually goes to the output. By doing a 1-second delay but using this software SRR, we can have any delay length we want, with the proportional loss in sample rate (whereas in the FV1 you can't clock it below 16khz externally). So even a 2-minute long delay is possible with ridiculously unusable amounts of aliasing.
But the slick part is that since this SRR happens in the code, we can digitally filter the signal before the reduction, so it is actually possible to stop the aliasing from happening. I still like some filtering on the end as well for the longer delays (16 seconds...) and this ends up sounding "analogish" I guess.
Ah ok i get what your saying. For this it makes sense. What is your effective sampling rate at 2 minits delay? about 260 hz? ;)
Quote from: ElectricDruid on November 01, 2010, 02:15:45 PM
Quote from: JKowalski on November 01, 2010, 12:00:49 PM
I feel like this forum has come around to this question (PT2399 tap tempo) a hundred times or more... :icon_neutral:
The answer was a definite no I believe, it is not like a conventional clock - the adjustment terminal is a completely different beast.
It *does* alway seem to come back to this...at least, it will until someone comes up with the killer solution!
Part of the problem is the poor documentation. Even the better version of the PT2399 datasheet (the one with the block diagram) doesn't include everything.
http://www.synthdiy.com/files/2007/PT2399.pdf (http://www.synthdiy.com/files/2007/PT2399.pdf)
I think Slacker might be onto something. The datasheet shows the clock output pin 5 as unconnected. But presumably it is connected to the VCO output, which is also the clock *input* for the main delay block (whatever it really is - they're not saying). So perhaps you could feed a clock *into* the clock output, whilst tying something to pin 6 to ensure the VCO is disabled. Or alternatively feed 240V into pin 6 - that'd disable the VCO...;)
I definitely remember reading about someone trying this and failing. It's probably a buffered output.
Quote from: ElectricDruid on November 01, 2010, 02:15:45 PM
The datasheet also gives no clue at all as to why the Little Angel Chorus trick of feeding modulation voltages into the pin 2 ref works. It's frustrating, really.
T.
I know! Totally wierd.
Maybe we could somehow contact princeton and clarify things, though I doubt they would care to indulge us. Unless we pose as a buyer thinking about a 2,000,000 unit order... :icon_rolleyes:
what about using a frequency counter as feedback device? measure the clock out pin frequency and have the mcu adjust the R accordingly.
Quote from: slotbot on November 02, 2010, 05:36:33 PM
Ah ok i get what your saying. For this it makes sense. What is your effective sampling rate at 2 minits delay? about 260 hz? ;)
Yep! ;D Which means max 130hz representable without aliasing. I only have a 4-pole lowpass at the beginning and end, but with something more aggressive at the front end this could actually be usable as a bass looper. The more obvious use is just insane weirdness, though, which I know from your products is something with which you're familiar.
Quote from: Taylor on November 02, 2010, 06:41:10 PM
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 (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.
Quote from: slotbot on November 02, 2010, 06:54:56 PM
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 (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.
Quotebut 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.
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.
Quote from: slotbot on November 02, 2010, 06:54:56 PM
Quote from: Taylor on November 02, 2010, 06:41:10 PM
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 (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.
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!
@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.
QuoteThe 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!
Quote from: slotbot on November 03, 2010, 02:49:56 AM
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.
Quote from: slotbot on November 03, 2010, 02:49:56 AM
@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?
QuoteFrank 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.
QuoteOn 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.
heres a crude demo of said dip delay line:
http://www.youtube.com/watch?v=eKgtkvLeNCE (http://www.youtube.com/watch?v=eKgtkvLeNCE)
no frills atm.
Quote from: slotbot on November 08, 2010, 07:00:23 PM
heres a crude demo of said dip delay line:
http://www.youtube.com/watch?v=eKgtkvLeNCE (http://www.youtube.com/watch?v=eKgtkvLeNCE)
no frills atm.
we gotta get you a new camera ;D
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?
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 :( )
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 ( :D )....
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.
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.
Well, to a certain extent I agree with you in a general sense.
But I agree with Karl that 30% is pretty far off.
Quote from: Taylor on November 10, 2010, 06:26:33 PM
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? :D
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.
Quote from: Galego on November 10, 2010, 06:37:18 PM
Well i'm just a bit surprised because i didn't encounter this issue at all. Was i blessed with better digital pots? :D
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.
Has anyone seen this:
http://www.woosteraudio.com/space-baby.html (http://www.woosteraudio.com/space-baby.html)
This one seems good.
RonaldB
> 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 (http://www.princeton.com.tw/downloadprocess/downloadfile.asp?mydownload=PT2399_1.pdf), plotted T/R, then T/(R+2500). Then times 1000 just to get numbers near ten.
1000*(T/(R+2500))
(http://i56.tinypic.com/2d6ny4w.jpg)
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.
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.
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:
(http://i55.tinypic.com/iejb7a.jpg)
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.
(http://i55.tinypic.com/27zzwx1.jpg)
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
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 (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 (http://www.diystompboxes.com/smfforum/index.php?topic=86297.0)
> 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.
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.
(http://i56.tinypic.com/n5h1dg.jpg)
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 (http://diystompboxes.com/zencart/index.php?main_page=index&cPath=12&zenid=3fbe4f78cf6461b30f383835c7a3f785) 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.
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.
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?
Quote from: slotbot on November 15, 2010, 04:09:17 AM
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?
Quote from: Taylor on November 15, 2010, 04:11:08 AM
Quote from: slotbot on November 15, 2010, 04:09:17 AM
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? 8)
edit:
also above i said GHz but i meant MHz. Most around ~50Mhz which is consistent with the physical pin properties of a pic.
Oh, right. D'oh. Need to stop posting at 3 in the morning.
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.
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. 8)
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.
> 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.
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 (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
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.
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? ::)
That should work fine, I've used a transistor driven by an LFO to modulate the delay time which is basically the same thing.
Quote from: MoltenVoltage on November 21, 2010, 03:34:09 AM
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?
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.
Quote from: MoltenVoltage on November 22, 2010, 12:00:37 PM
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.