Lightspeed Attenuator a new passive preamp

Hi G,
would the sound deteriorate if two 470nF caps were fitted in parallel?
Would you notice the difference between F-3db changing from 7Hz to 15Hz?
To the first Q. I suggest you may not hear any deterioration.
To the second Q. I think you will hear F-3db going up to 15Hz. I would recommend going down below 2Hz if your equipment can cope with a widerband signal.
To achieve 2Hz the cap would need to be ~1.5uF for Zin=47k
 
I moved over to current drive.

It was not a direct comparison though because I implemented current drive with with series resistor / shunt LDR.

The shunt resistor is a 22K vishay bulk foil.

I am very happy with the sound it is incredibly clear & clean.

I bought some other resistors to check out the difference but I cannot motivate myself to try them because the sound is already excellent.

For me, well implemented current drive is clearly better than well implemented voltage drive.
 
Hi AndrewT

I do not care much about under 20-30Hz, but the experience shows a 470nF cap instead of a 100nF cap gives better bass, even with a 100k pot after it. Another fact, the AN M7 preamp is not good under 47k (the 3 tube riaa).
We can discuss about impedances in tube chains, but I'm afraid it is too off topic.
Thanks for your help, but I will not purchase new caps for my DAC and RIAA for sure.

Regards,

JG
 
mikelm said:
I moved over to current drive.

It was not a direct comparison though because I implemented current drive with with series resistor / shunt LDR.

The shunt resistor is a 22K vishay bulk foil.

I am very happy with the sound it is incredibly clear & clean.

I bought some other resistors to check out the difference but I cannot motivate myself to try them because the sound is already excellent.

For me, well implemented current drive is clearly better than well implemented voltage drive.

Are you refering to the CCS or something different? If it's something different, I'd be interested in the details.
 
Giordano said:
I'm happy that your concept is nearly the same, however I do not understand the fit function.

In our design for each channel we have 2 series LED/LDR per input (of which fortunately only one needs to be calibrated, the other is operated simply as a "switch" of sort, with just a trimmer to equalize the fixed "on" resistances) plus one common shunt.

We plan to make a modular design with an independent inputs+attenuator board (with its own uC) for each channel plus one or more uC board(s) for UI, display, remote, etc. (the automatic calibration system may be "split" between the UI controller board and the "channel" ones and/or require yet another subsystem on its own... not all the details have been addressed yet).

That is, e.g. for a "typical" stereo preamplifier with 4 inputs you'd have 10 LDR to calibrate. A larger system with 6 channels and 5 inputs each would require 36 calibrated LED/LDRs! :eek:

The problem is: the I/R charactiristic of the LED/LDR is neither linear nor equal between different samples... matching "by hand" such a large number of LDR is simply out of question.

If you want to have the possibility to "dial in" whatever attenuator you'd like using a significant fraction of the enormous dynamic range of the LED/LDRs without having to "re-calibrate" everything each and every time, you need to know in advance which currents to set in order to get whatever resistance value you'd need.

The easier way to do this would be to build a full "calibration table" with the LED drive current value required to get each resistance value that may be required, and store it on a eeprom. And of course this should be done for each LED/LDR in the system.

To get enough precision and dynamic range, you'd need at least a couple of 16bit words for each value pair, and you'd need to calibrate and store A LOT of them for each LDR!

This has quite some drawbacks. Most notably:
  • it would require a lot of memory... way much more than what would be available on any uC (unless resorting to an external memory chip, that is).

  • endless time required for the calibration procedure: LDRs are slow and very heat sensitive... the calibration procedure should be something like this:

    1. define some desired Rset value
    2. ramp up/down the LED current while measuring the LDR resistance until it approach the desired Rset value
    3. turn off LED and wait to let the device cool down
    4. turn on the LED at the last set current and check resistance
    5. if |R - Rset| < desired_precision we're done, else loop (back to step 2) :eek:
    6. turn off LED and wait to let the device cool down
    7. loop from step 1 for all required/desired resistance values... :dead:
      [/list=1]
    A valid alternative (suggested by Andy) that allows to save a LOT of memory (and not only that) is the use of a "fit" function. You find a simple function that "fits" with the I/R characteristic of the LDRs within a given precision and code it into the firmware. Then, instead of building and storing many large tables, for each LDR you only have to find and store just the few parameters of the fit function...

    at "run time", when you need some resistance value, instead of looking it up among the ones available in a large calibration table you can simply calculate the current which is required to get it.

    This way you can actually "dial in" (virtually build) whatever attenuator you'd like on the fly, directly from the unit UI, without ever reprogramming the system...

    imagine e.g. using different attenuation curves and/or different I/O impedances for different input channels to get the best match with the different sources... :cool:

    ...did I say that your imagination is the only limit to the flexibility and versatility of such a system?! :)
 
Well, if the series resistor/shunt LDR is as good (in CCS form anyway!) would it not simplify matters to go with this configuration initially for the auto-calibrate model? Apologies if this has been teased out before!

In the completely opposite direction to the simplification above - has anybody considered this for a differential vol control - posiible with auto-calibration!
 
jkeny said:
Well, if the series resistor/shunt LDR is as good (in CCS form anyway!) would it not simplify matters to go with this configuration initially for the auto-calibrate model?

indeed we planned to drive the LEDs using voltage controlled CCSs driven by a DAC; not by chance I was talking about the "I/R" rather than "V/R" characteristic of the LED/LDR. :)


In the completely opposite direction to the simplification above - has anybody considered this for a differential vol control - posiible with auto-calibration!

it would be possible and not much more complicated than the "normal" solution. But would it be really useful?
 
it would be possible and not much more complicated than the "normal" solution. But would it be really useful?

I'm not an expert but keeping the signal differential bestows some noise advantages in CMRR, I believe? I'm looking at using the Zeus amplifier which accepts a differential input!

"I/R" rather than "V/R" characteristic of the LED/LDR
Ah, I missed that but are you not also dealing with series LDR/shunt LDR config? Does just using shunt LDR not simplify matters?
 
jkeny said:


I'm not an expert but keeping the signal differential bestows some noise advantages in CMRR, I believe? I'm looking at using the Zeus amplifier which accepts a differential input!

well, you need to have BOTH a source with differential (truly balanced) output and an amplifier with differential input... indeed there are some, though it's not very common.


Ah, I missed that but are you not also dealing with series LDR/shunt LDR config? Does just using shunt LDR not simplify matters?

according to George, LDR/LDR does sound better... and I assume I can trust his experience with these devices (though our design can be somewhat different from his own).

Apart from that, using two LDRs allows for much greater flexibility and dynamic range. If you use a fixed series resistor, you can not change the I/O impedances that much... then such a sophisticated (and complex) design would become mostly pointless.
 
Thanks Unixman,
For clearing these points up & I agree George is the expert in this area.

Final question for now - I was left a bit confused by the tube discussions above - can the impedance be matched to tube use with your auto-calibration method? (BTW, have you given this a name yet, auto-vol or something?)
 
jkeny said:

Final question for now - I was left a bit confused by the tube discussions above - can the impedance be matched to tube use with your auto-calibration method? (BTW, have you given this a name yet, auto-vol or something?)

yes, of course. Using uC controlled calibrated LDRs you can get just about whatever input impedance you need. In practice, anything between a few K up to 100K or there about (in principle even much more, but goin' too high becomes unpractical due to higher non-linearities in the LED/LDR response).

Needless to say, if you go up with impedance you can no longer use the device as a stand-alone passive "preamplifier" - you must either include it within an integrated amplifier or add an active stage (at least a buffer).

My goal would be to design a flexible, "universal" input selector & attenuator system. Whether to use it as a "passive preamplifier" or as the front-end of an active preamp or integrated amp would be up to each user.
 
UnixMan said:


In our design for each channel we have 2 series LED/LDR per input (of which fortunately only one needs to be calibrated, the other is operated simply as a "switch" of sort, with just a trimmer to equalize the fixed "on" resistances) plus one common shunt.

We plan to make a modular design with an independent inputs+attenuator board (with its own uC) for each channel plus one or more uC board(s) for UI, display, remote, etc. (the automatic calibration system may be "split" between the UI controller board and the "channel" ones and/or require yet another subsystem on its own... not all the details have been addressed yet).

That is, e.g. for a "typical" stereo preamplifier with 4 inputs you'd have 10 LDR to calibrate. A larger system with 6 channels and 5 inputs each would require 36 calibrated LED/LDRs! :eek:

The problem is: the I/R charactiristic of the LED/LDR is neither linear nor equal between different samples... matching "by hand" such a large number of LDR is simply out of question.

If you want to have the possibility to "dial in" whatever attenuator you'd like using a significant fraction of the enormous dynamic range of the LED/LDRs without having to "re-calibrate" everything each and every time, you need to know in advance which currents to set in order to get whatever resistance value you'd need.

The easier way to do this would be to build a full "calibration table" with the LED drive current value required to get each resistance value that may be required, and store it on a eeprom. And of course this should be done for each LED/LDR in the system.

To get enough precision and dynamic range, you'd need at least a couple of 16bit words for each value pair, and you'd need to calibrate and store A LOT of them for each LDR!

This has quite some drawbacks. Most notably:
  • it would require a lot of memory... way much more than what would be available on any uC (unless resorting to an external memory chip, that is).

  • endless time required for the calibration procedure: LDRs are slow and very heat sensitive... the calibration procedure should be something like this:

    1. define some desired Rset value
    2. ramp up/down the LED current while measuring the LDR resistance until it approach the desired Rset value
    3. turn off LED and wait to let the device cool down
    4. turn on the LED at the last set current and check resistance
    5. if |R - Rset| < desired_precision we're done, else loop (back to step 2) :eek:
    6. turn off LED and wait to let the device cool down
    7. loop from step 1 for all required/desired resistance values... :dead:
      [/list=1]
    A valid alternative (suggested by Andy) that allows to save a LOT of memory (and not only that) is the use of a "fit" function. You find a simple function that "fits" with the I/R characteristic of the LDRs within a given precision and code it into the firmware. Then, instead of building and storing many large tables, for each LDR you only have to find and store just the few parameters of the fit function...

    at "run time", when you need some resistance value, instead of looking it up among the ones available in a large calibration table you can simply calculate the current which is required to get it.

    This way you can actually "dial in" (virtually build) whatever attenuator you'd like on the fly, directly from the unit UI, without ever reprogramming the system...

    imagine e.g. using different attenuation curves and/or different I/O impedances for different input channels to get the best match with the different sources... :cool:

    ...did I say that your imagination is the only limit to the flexibility and versatility of such a system?! :)


  • Hi UnixMan,

    Yes, my imagination is running wild. Thanks so much for your description. It sounds like the best 'most-general' solution.

    I have only one possibly-'negative' observation:

    Using curve-fitting to derive a 'fit function' equation will certainly save a lot of run-time memory, compared to storing the raw data points for each opto's R vs I. BUT, I don't see how that will help much, or maybe at all, with the calibration procedure burden. It seems like you would still need to collect all of the same calibration-data points, for each LED/LDR device, to be able to derive each device's 'fit function' equation (unless there is something that can be assumed about the device characteristics that could simplify that procedure). Or am I missing something?

    And, actually, at run-time, a lookup table, probably no matter how large, would almost certainly be much faster than an equation calculation. But that shouldn't matter, anyway, since it wouldn't be done very often. [However, isn't memory very cheap and very small?] Also, the program code needed for table-lookup might be much smaller than the code needed to evaluate the 'fit' equation, depending on whether or not evaluating the equation would require including, say, floating-point library routines in the executable code, especially if those would not otherwise be required. At the least, there might be a trade-off that's worth considering, there.

    Another somewhat-similar approach, to save memory space, might be to (automatically) analyze the calibration data points to decide how many could be discarded, which would effectively give you a piecewise-linear approximation of the original data (in a new, much-smaller lookup table), within whatever error margin you specify. It might not save quite as much memory as using a fit function. Or, it might. But it might be more-straightforward to implement. It's difficult to say, at this point. But it's an alternative approach to consider.

    By the way: There is an (analog) way to almost-perfectly linearize the R vs I response of any LED/LDR device, over almost its entire range, which I have been investigating (for more than just audio purposes). However, it requires the use of a second 'identical' LED/LDR device, and some opamp circuits, for each LED/LDR that is to be linearized. It is all analog circuitry, so far. It works very well in simulation and I have progressed to the point where I am now just optimizing the LDR resistance's step-response for control-voltage inputs [having finally adjusted some of my Perkin-Elmer "Vactrol" device models to match the specified turn-on and turn-off rise and fall time characteristics, as given in the VTL5Cn datasheets. (Does anyone have such timing data for the Silonex devices??)].

    The mis-matching between the LED/LDR to be linearized and the other 'calibration' LED/LDR in my circuit WILL affect the final linearity. But, for some device types, at least, it seems like a simple 'DC offset' of the control current for one LED/LDR might be able to make it match another, quite well. [However, the Perkin-Elmer 'Vactrol' devices have 'dual' models available. Those appear to be one LED and two LDRs, effectively. So that might help a lot, with the matching requirement. I have some of those on order, but have not yet received them. So I can't tell, yet, how well they might help to eliminate the matching problem.]

    Your digital system, since it would already have the R vs I data points, either in a table or as an equation, actually already intrinsically includes such a linearization capability, since you would have the ability to linearly sweep the 'commanded resistance' input and would then actually get an almost-perfectly-linear LDR resistance response (within the error margin of your calibration test data table or equation). Doing it all digitally, as you are planning, with either a table or an equation from each device's actual data, is probably the better way, at least in the sense that you won't have my control LDR vs target LDR mis-match problem.

    So, even though it might eliminate your existing 'calibration data' problems, it would probably just replace them with the problem of calibrating for any mismatch between the two LDRs that are required for the analog linearization of one of them, and would also require significantly-more-complex analog circuitry. So, I guess you can forget everything I said about the analog LDR linearization. :)
 
gootee said:
By the way, what type of VCCS (Voltage-Controlled Current Source) topology are you considering using, to drive the LEDs?

not yet decided... do you have any good suggestion?

We most likely will need a good CCS also for calibrations (to inject a known current into the LDR and read the voltage across it to measure its resistance...). The problem there is that we have to make precise measurements across over 4 decades, from a few 10s ohm way up to over 100K! :dead:
 
Thanks UnixMan for the explanation on fit function.
Yes, gootee, probably to calculate on the function would take about 20x more time than the lookup table, but that is still something like 200us on a 4MHz clock pic. So, does not matter at all.
The reason why I'm on the lookup table side, I can not program pic in C. In assembler, math is not so easy. I did a DDS control once, the biggest job was to devide a 4 byte number with a 3 byte number - which would be nothing in C.

jkeny just placed the question I was about to make. Yesterday evening I have seen datasheet of the NSL-32SR2S and I was surprised on the maximum resistance of 1Mohm. Than I did not understand the point why it is a problem to match it with a usual impedances in tube based chains. I was thinking the same, I do not care non linear drive mA/resistance function, but isn't it the case that distorsion goes up also ? If not, than for the uC controlled version, the 100k would not be a problem at all.

I did read the first and the last 10 page. I'm sorry if you guys already responded to this question, but I would like to try it now in a shunt config and for that, I would need some LDRs desperately. Somebody mentioned Farnell, but in the catalog I just found NSL 32 with 500 and 2k on resistance. This is probably not the NSL-32SR2S with 40ohm on resistance.

Can you please suggest a source for me ?

Thanks,

JG
 
Giordano said:
The reason why I'm on the lookup table side, I can not program pic in C. In assembler, math is not so easy. I did a DDS control once, the biggest job was to devide a 4 byte number with a 3 byte number - which would be nothing in C.

that was exactly the same reason why I suggested the lookup tables in the first place... one more chip (a few euros... who care?) but much simpler to code. Though I never worked with uC and know very little about them, so I'm not the best one to judge. Others on the audiofaidate.it forum suggested and preferred the fit function idea, and that was just fine for me. Nevertheless, since nothing was done yet on that side... I guess we're still in time to change our minds. :)


jkeny just placed the question I was about to make. Yesterday evening I have seen datasheet of the NSL-32SR2S and I was surprised on the maximum resistance of 1Mohm.

if I remember correctly the R3s (which supposedly are more linear on the "audio side") have an even higher "off" resistance...


Than I did not understand the point why it is a problem to match it with a usual impedances in tube based chains.

to make a long story short, in the simple systems made by George and its clones (with or without CCS) it's a matter of device selection and pairing. The more you go high in resistance, the less linear become the I/R response. According to George, it may be difficult to get a good matching for anything over a few 10s of K.

Moreover, George insist on the use of the device as a purely passive "pre", without any active stage afterwards.

Of course, in such a configuration anything more than about 10 to 20 K would produce an output impedance way to high to be able to drive cables and load capacitances (nevertheless there are surely no problems to use a 50K or 100K version directly as the front-end of a tube gear...).


I was thinking the same, I do not care non linear drive mA/resistance function, but isn't it the case that distorsion goes up also ?

AFAICT, the distorsion does not depend on the resistance. It does depend only on current and voltage drops.


If not, than for the uC controlled version, the 100k would not be a problem at all.

that's what I believe, too.

BTW, AFAIK one of the good guys @ audiofaidate.it have made a "classical" simple LightSpeed clone (though using R3s, if I remember correctly) for a tubed system, and set it for some 40 - 50 K without much troubles.


Can you please suggest a source for me ?

RS components does have them. Quick and easy, though not the cheapest source, usually... :rolleyes: :(