PT2399 noise problem. Have you encountered it?

[Hides-His-Eyes]

With things as they are, I think the FV-1 and a breakout board is more the place to start.

Here's a question: is there a "digital BBD" (shift register) type RAM?

is it possible to make a delay without a PIC controlling the read enable/write enable bits and bobs?

Could you make a delay of arbitrary length with a PIC's ADC, a DAC chip and a RAM chip that can read and write simultaneously, if such a thing exists?

[R.G.]

Here's a question: is there a "digital BBD" (shift register) type RAM?

Yes. Or at least there used to be. FIFO/shift register memory existed. Not cheap, but it existed. The problem then becomes how to change the length of the delay. Purely changing the clock speed works if everything is stable at a variety of clock speeds. If you have to change the length of the delay channel by accessing more/fewer locations, then you have to do a fair bit of logic to make the address counters increase/decrease and to make sure that when you increase the delay loop in memory it does not contain grak from previous use.

is it possible to make a delay without a PIC controlling the read enable/write enable bits and bobs?

Yes, but a PIC or other uC is by far simpler to do and get running. There were hard-logic controllers to do the read/write and address loop length stuff, but programming a controller is much, much simpler. It is possible to do field programmable gate arrays to to the job, but anything beyond the simplest FPGA is a job for experts withe experience.

Could you make a delay of arbitrary length with a PIC's ADC, a DAC chip and a RAM chip

Yes, in theory. The PIC has to be fast enough to complete all actions, no matter what the controls tell it to do, in the time between one sample and the next. For CD quality, that's 1/44000 S or about 22.7uS. That probably means at least a 20MHz PIC (or similar). Even then a PIC only gets 113 instructions in that 22.7uS. Maybe another controller would get 400-500 instructions if it gets one instruction per clock. However, you're rapidly getting out of cheap microcontrollers.

that can read and write simultaneously, if such a thing exists?

You don't need one that can read and write simultaneously. Just one that does each so fast that it's an insignificant part of 22.7uS, and a controller fast enough to tell it what to do.

I thrashed all of the above pretty thoroughly over the years; I have the scars to prove it. One thing I did was to approach Princeton Technologies about producing either a bigger-memory PT2399 or a PT2399 with an external memory interface. They pointed out that the PT2395 is an earlier version of the 2399 with an external memory interface, albeit limited, and that they were not interested in making any changes in either one, even for guaranteed quantities in the thousands. I'm pretty sure if you could guarantee millions in sales that would work; as my friend in the contracts-negotiation group put it "There's always a number."

[merlinb]

Any chance of a sound clip? I'm having a hard time figuring out what sort of noise is being talked about, and whether it's just what's normal for the PT2399 or something else.

Here is sound a clip of mine (past into your browser to stop freewebs redirecting). That background hash when there is no signal is also coming from the PT, but only for delay times longer than about 200ms:
w ww.freewebs.com/valvewizard2/PT2399QuantizationNoise.mp3

Here a close-up image of the noise. Even after passing through my sound card you can still see the triangular bumps on the waveform!

[Hides-His-Eyes]

Here's a question: is there a "digital BBD" (shift register) type RAM?

Yes. Or at least there used to be. FIFO/shift register memory existed. Not cheap, but it existed. The problem then becomes how to change the length of the delay. Purely changing the clock speed works if everything is stable at a variety of clock speeds. If you have to change the length of the delay channel by accessing more/fewer locations, then you have to do a fair bit of logic to make the address counters increase/decrease and to make sure that when you increase the delay loop in memory it does not contain grak from previous use.

is it possible to make a delay without a PIC controlling the read enable/write enable bits and bobs?

Yes, but a PIC or other uC is by far simpler to do and get running. There were hard-logic controllers to do the read/write and address loop length stuff, but programming a controller is much, much simpler. It is possible to do field programmable gate arrays to to the job, but anything beyond the simplest FPGA is a job for experts withe experience.

Could you make a delay of arbitrary length with a PIC's ADC, a DAC chip and a RAM chip

Yes, in theory. The PIC has to be fast enough to complete all actions, no matter what the controls tell it to do, in the time between one sample and the next. For CD quality, that's 1/44000 S or about 22.7uS. That probably means at least a 20MHz PIC (or similar). Even then a PIC only gets 113 instructions in that 22.7uS. Maybe another controller would get 400-500 instructions if it gets one instruction per clock. However, you're rapidly getting out of cheap microcontrollers.

that can read and write simultaneously, if such a thing exists?

You don't need one that can read and write simultaneously. Just one that does each so fast that it's an insignificant part of 22.7uS, and a controller fast enough to tell it what to do.

I thrashed all of the above pretty thoroughly over the years; I have the scars to prove it. One thing I did was to approach Princeton Technologies about producing either a bigger-memory PT2399 or a PT2399 with an external memory interface. They pointed out that the PT2395 is an earlier version of the 2399 with an external memory interface, albeit limited, and that they were not interested in making any changes in either one, even for guaranteed quantities in the thousands. I'm pretty sure if you could guarantee millions in sales that would work; as my friend in the contracts-negotiation group put it "There's always a number."

Thanks for the in depth response.

If you guys are too 'small fry' for something better out of princeton I won't hold my breath. I might like to give the shift RAM thing a go for a go at the "PDS" type delay with a 'hold' done through DIGITAL feedback...

[~arph]

I will see if I can do some clips over the weekend. I literally just pulled the four in series of the breadboard two days before this thread started. I still have a pedal where there are four in series so I 'll do clips of that. I did do some hefty filtering in there and I have a downward expander/ noise gate on the delay line, but you can hear that kicking in.
Here is a short clip with repeats taken from the second and fourth delay stage, plus a little feedback from the fourth.

http://www.friedair.com/audio/echodeck1.mp3

It doesn't show the noise I get though as the delay times are quite short and there is  lot of filtering.

[alparent]

Any chance of a sound clip? I'm having a hard time figuring out what sort of noise is being talked about, and whether it's just what's normal for the PT2399 or something else.

Alternatively does this clip suffer from what's being talked about, this is about as clean as I managed to get a PT2399 at longer times. http://www.eskimo.plus.com/fxstuff/13452.mp3 This is with a 47k pot giving about 700ms and makes a perfectly usable pedal, although I guess that depends on what you're trying to achieve.

I need to try changes suggested by Mark and swap PT (just to test).

But I'd be very happy if my build ended up sounding like yours!
Is that from a Rebote 2.5? Any mods you can share? Or would that be from your Echo Base?

[merlinb]

Has anybody obserevd any differences between the chips labelles with the seriff font and those with the sansseriff font? (I have the latter)


w ww.freewebs.com/valvewizard2/PT2399QuantizationNoise.mp3

[R.G.]

Has anybody obserevd any differences between the chips labelles with the seriff font and those with the sansseriff font? (I have the latter)

Sadly, you must assume that one of the two is counterfeit, or cloned. It could be a new/different fab producing for PT, or an update to the  chip, but caution and observation of the state of things right now says that counterfeit or a maybe-works knockoff is also likely.

A new/different chip rev is always a potential source of bad performance and an almost-the-same clone by a pirate fab is also a possibility. As small fish (i.e., users in quantities less than about 10K/month) we, all of us here, can only worry about it and do incoming test.

[.Mike]

A new/different chip rev is always a potential source of bad performance...

Differences between PT2399 versions here: Link.

Mike

[slacker]

Or would that be from your Echo Base?

Yeah that's from the Echo Base. I don't know if the circuit has a lot to do with it though, it's pretty similar to the Rebote. The only thing I can think that could make it less noisy is that I'm  using more gain in the PT2399 input and output stages, I guess making the signal hotter could mask the noise. It does have a little clock noise at maximum level, but most of the time in use this isn't noticeable.

[slacker]

That background hash when there is no signal is also coming from the PT, but only for delay times longer than about 200ms:
w ww.freewebs.com/valvewizard2/PT2399QuantizationNoise.mp3

That doesn't sound right to me,  I take it that's the signal from pin 14 after the output filter.
If it would be useful for comparision purposes, I'd be happy to let you have a known good PT2399 from my stash.

[tasos]

Well I have managed to improve it by increasing the integrating caps between pins 9-10, 11-12, to 100nF.

is there a possibility that this mod makes the delay worse?or is it sounding the same with the non moded?

[merlinb]

Well I have managed to improve it by increasing the integrating caps between pins 9-10, 11-12, to 100nF.

is there a possibility that this mod makes the delay worse?or is it sounding the same with the non moded?

Increasing those caps improves the noise for long delays, but decreases the bandwidth to ~2kHz.

[merlinb]

That background hash when there is no signal is also coming from the PT, but only for delay times longer than about 200ms:
w ww.freewebs.com/valvewizard2/PT2399QuantizationNoise.mp3

That doesn't sound right to me,  I take it that's the signal from pin 14 after the output filter.
If it would be useful for comparision purposes, I'd be happy to let you have a known good PT2399 from my stash.

Yes, standard topology. Dry channel is perfectly clean. Quick schem:


I only have one other PT (I bought them both at the same time), it sounds the same. I'd be grateful to try another! (But I'm in UK...)

[merlinb]

Just had a look inside a Danelectro Wasabi, which manages about 500ms of delay (I guess). Looks like it's using two PT2399s in series, with datasheet circuits all round (82nF integrating caps).

[Mark Hammer]

Well I have managed to improve it by increasing the integrating caps between pins 9-10, 11-12, to 100nF.

is there a possibility that this mod makes the delay worse?or is it sounding the same with the non moded?

Increasing those caps improves the noise for long delays, but decreases the bandwidth to ~2kHz.

Which is not always as big a hardship as many might think.  If the purpose is to have a faithful clone of the input signal, then sacrificing bandwidth is problematic, I agree.  But often, people merely want a background "wash" of something that sounds merely reminiscent of the input, in which case limiting bandwidth can serve to relegate the delayed signal more to the perceptual background, which helps out.

[tasos]

Well I have managed to improve it by increasing the integrating caps between pins 9-10, 11-12, to 100nF.

is there a possibility that this mod makes the delay worse?or is it sounding the same with the non moded?

Increasing those caps improves the noise for long delays, but decreases the bandwidth to ~2kHz.

as for the noise for long delays i have increased the 560pf cap to 3.3nf and no more noise!
i saw you made a schematic...is it making the delay totally clean?

[merlinb]

i saw you made a schematic...is it making the delay totally clean?

Not yet, I am having noise problems, remember! But I will post the project when finished.

[merlinb]

I have finally identified my noise problem. Actually I should say 'problems', because I managed to make every mistake possible along the way! Still, it was a wonderful experience since I know know just about everything I need to, to design for low noise next time.

Here's a breakdown of what my problems were:

• My maximum delay time was way too long. I had a 47k delay resistor, resulting in 500ms of delay; the sample frequency dropped down below 1MHz and the quantization noise was terrible. I settled on 10k in the end.
  
• Not enough post-delay filtering. I had to lower the LP cut-off frequency to around 1kHz to get rid of the last of the quantization noise.  Next time I will use at least 3rd-order LP filtering after the delay (ignore the datasheet at your peril...)
• Local ceramic decoupling cap on the PT. This was a rookie mistake, I was hoping the 78L05 and a 10uF would take care of the PSU, but I was very, very wrong  . A 100nF ceramic and a selected electro minimised the junk that the PT was dumping onto the 5V rail.
  
• Despite the above I was still getting a lot of hiss at the output, which confused me for ages since I was using very small resistances throughout. Eventually I tracked it down to the 5V rail which I was also using as Vref for the wet/dry mixing stage. A summing mixer operates with a high noise gain, so even after the junk on the 5V rail was minimised it was still being amplified many times by the mixer. Next time I will use a separate 4.5V Vref and power the PT from its own 5V supply. (Do other pedals like the Echobase or LittleAngle suffer this same hissing problem, since they use the 5V rail as Vref?)
  

PS: Thanks to Slacker for sending me a known good PT to try!

[tasos]

great job!is the delay now super clean?is the maximum delay less time?
as for the noise problem did you try  increasing the 560pf cap to 3.3nf as i told you?