Need a little design help on my latest project
in [Design]
|
Prev: Magnetism is really -- WHAT?
Next: low-end scope
From: JosephKK on 3 Mar 2010 02:18 On Mon, 01 Mar 2010 14:09:41 -0800, Charlie E. <edmondson(a)ieee.org> wrote: >On Mon, 1 Mar 2010 12:57:49 -0800 (PST), whit3rd <whit3rd(a)gmail.com> >wrote: > >>On Mar 1, 8:54 am, Charlie E. <edmond...(a)ieee.org> wrote: >> >>> Sensor is simply an RGB LED and a >>> phototransistor, buffered by some amps, and then digitized by a PIC24. >> >>Your digitizing scheme is not what you really need; the small current >>can easily be integrated onto a capacitor, and a comparator input >>with one of the nice timer sections can give a single-slope >>digitization of the noisy input. Using instead the DAC section, your >>noise bandwidth is quite high. >> >>Current-input D/A conversion is easy, and voltage conversion then >>voltage DAC has no real benefit here. > >Hmmmm... interesting idea. > >So, I just feed the emitter of the phototransistor directly to a cap, >and use a comparator input to determine when it has reached a >reference voltage. I probably need to hit it before and after with a >ground to clear the cap for the next sample... > >Charlie Integrating the collector current should have better properties.
From: JosephKK on 3 Mar 2010 02:30 On Tue, 2 Mar 2010 18:48:11 -0800 (PST), George Herold <ggherold(a)gmail.com> wrote: >On Mar 2, 12:06 pm, dagmargoodb...(a)yahoo.com wrote: >> On Mar 1, 10:03 pm, MooseFET <kensm...(a)rahul.net> wrote: >> >> >> >> >> >> > On Mar 1, 8:54 am, Charlie E. <edmond...(a)ieee.org> wrote: >> >> > > Hi Guys, >> > > Ok, going to put myself in harms way, and ask for a little design >> > > advice. I have been working on this project for a while now, and it >> > > has gone through several iterations, and I keep having the same >> > > problem! >> >> > > First, the project: I am designing a small color reader for the >> > > visually impaired. Really simple operation - put it against the >> > > object you want to tell the color of, and it will say "RED" or >> > > whatever the color is. Sensor is simply an RGB LED and a >> > > phototransistor, buffered by some amps, and then digitized by a PIC24. >> > > So, what's the problem? I can't get a stable reading. In normal >> > > operation, this thing will run for about two seconds, and then be >> > > turned off. To test, however, I run it in debug mode for hours. When >> > > I first turn it on, and calibrate it to a white sample, I will get one >> > > set of calibrations. Let it sit for about two minutes, and it starts >> > > to drift. In about half an hour, I will have readings totally off the >> > > scale. >> >> > > So, why am I baring my soul to ya'll? I need your help identifying >> > > where the gain drift is coming from, and some ideas on how to control >> > > them. I have the schematic here: >> >> > >http://edmondsonengineering.com/Documents/Rainbow%20color%20Reader%20... >> >> > > Basic description - MCU turns on an LED. The phototransistor is first >> > > buffered by a non-inverting opamp with a gain of 2, and the signal is >> > > split. Part goes directly to a PGA where it is first attenuated, and >> > > then the PGA boosts it up. This gives me a calibration control to >> > > deal with difference in output of the LEDs. The original and PGA >> > > signal are added, and this is then applied to another non-inverting >> > > opamp with a gain of 2. I also have one feed before this opamp to an >> > > ADC input on the PIC. >> >> > > Problems I have already solved: >> > > First, each LED has a different output level. Red needs a gain of >> > > around 2, BLUE a gain of around 5, and GREEN a gain of about 7. The >> > > PGA was added to give me an adjustable gain from around 2 to 14, with >> > > the two different taps into the separate input channels of the PGA. >> > > This gives me 16 different gain levels to play with. Using the tap to >> > > the second ADC channel, it actually gives me 32 different levels. >> >> > > Right now, RED uses this lower gain channel, and is steady as a rock. >> > > Part of this may be that my VCC is 3.3 volts, and only RED has a >> > > forward voltage below this. Both GREEN and BLUE have forward voltages >> > > of 3.4 volts. >> >> > > So, potential problems? could it be that repeated use warms up the >> > > GREEN and BLUE LEDs so that they become more efficient? Could the >> > > power supply drift higher as it warms up? Could the opamps drift with >> > > slight changes in temperature? Any advice ya'll can give will be most >> > > appreciated. >> >> > > Thanks, >> > > Charlie >> >> > How about: >> >> > Schottky LED >> > Vcc ---->!--------+-----/\/\---->!----GND >> > ! >> > ===C >> > ! >> > PIC port >> >> > When you pull the port pin low, the capacitor gets >> > charged. When you take it high again you get a pulse >> > of light from the LED. >> >> Absolutely. Instead of using a PIC port, he could tie the cap to his >> DC-DC converter's switch node. That makes a common Vled supply, ... >> >> Vcc >> -+- >> | >> V D1 >> ._. --- >> _| |_ C1 | D2 Vled >> >------||---o-->|--o-----. >> | | >> --- C2 | >> --- | >> | | >> === | >> | >> .--------+--------+ >> | | | >> R1 R2 R3 >> | | | >> | LED-R |LED-G | LED-B >> V ~> V ~> V ~> >> --- --- --- >> ----. | | | >> | Q1 | | | >> |-|>-' Q2 | | >> PIC |------|>-----' Q3 | >> |---------------|>-----' >> | >> ----' >> >> The phototransistor Hfe drifts a lot with temperature, but that's >> common to all channels; software can remove it. >> >> Seconded: Tim's suggestion for optical feedback on the LEDs' output. >> >> -- >> Cheers, >> James Arthur- Hide quoted text - >> >> - Show quoted text - > >Excellent! And I'll vote for feedback... (as if a vote matters) > >George H. Alas, i believe that Charlie mentioned the RGB led is common cathode.
From: Fred Bartoli on 3 Mar 2010 02:52 JosephKK a �crit : > On Mon, 01 Mar 2010 14:09:41 -0800, Charlie E. <edmondson(a)ieee.org> wrote: > >> On Mon, 1 Mar 2010 12:57:49 -0800 (PST), whit3rd <whit3rd(a)gmail.com> >> wrote: >> >>> On Mar 1, 8:54 am, Charlie E. <edmond...(a)ieee.org> wrote: >>> >>>> Sensor is simply an RGB LED and a >>>> phototransistor, buffered by some amps, and then digitized by a PIC24. >>> Your digitizing scheme is not what you really need; the small current >>> can easily be integrated onto a capacitor, and a comparator input >>> with one of the nice timer sections can give a single-slope >>> digitization of the noisy input. Using instead the DAC section, your >>> noise bandwidth is quite high. >>> >>> Current-input D/A conversion is easy, and voltage conversion then >>> voltage DAC has no real benefit here. >> Hmmmm... interesting idea. >> >> So, I just feed the emitter of the phototransistor directly to a cap, >> and use a comparator input to determine when it has reached a >> reference voltage. I probably need to hit it before and after with a >> ground to clear the cap for the next sample... >> >> Charlie > > Integrating the collector current should have better properties. That's base current that's really interesting, since it doesn't depends on the transistor's current gain (temperature, operating point,...) Something like a miller integrator will do. | .-. | | | | '-' | +-----+--> ADC | | | --- | --- | | \| | |---+ <| | | +-|| === ->|| GND +-||---> Reset | === GND -- Thanks, Fred.
From: MooseFET on 3 Mar 2010 09:28 On Mar 2, 8:54 pm, dagmargoodb...(a)yahoo.com wrote: > On Mar 2, 10:29 pm, Joerg <inva...(a)invalid.invalid> wrote: > > > > > dagmargoodb...(a)yahoo.com wrote: > > > On Mar 2, 9:45 pm, Joerg wrote: > > >> dagmargoodb...(a)yahoo.com wrote: > > >>> On Mar 2, 9:15 pm, Joerg wrote: > > >>>> dagmargoodb...(a)yahoo.com wrote: > > > >>>>> The RGB LED is common-cathode? Oh. Then this would work: > > >>>>> +3.3v > > >>>>> -+- > > >>>>> | > > >>>>> .--------+--------+--------. > > >>>>> | | | | > > >>>>> |<' |<' |<' |<' > > >>>>> -| Q1 -| Q2 -| Q3 -| Q4 > > >>>>> |\ |\ |\ |\ > > >>>>> | | | | > > >>>>> | | | | > > >>>>> | | LED-R |LED-G | LED-B > > >>>>> | V ~> V ~> V ~> > > >>>>> | --- --- --- > > >>>>> | | | | > > >>>>> | D1 | | | > > >>>>> +---|<---+--------+--------' > > >>>>> | | > > >>>>> |_ L1 --- C1 > > >>>>> )|| --- > > >>>>> )|| | > > >>>>> _)|| === > > >>>>> | > > >>>>> +--->Vsense (to switching current regulator, > > >>>>> | e.g. ZXSC310) > > >>>>> .-. > > >>>>> | | > > >>>>> | | Rsense > > >>>>> '-' > > >>>>> | > > >>>>> === > > >>>>> GND > > >>>>> This approach is efficient, stable, inexpensive, small, and provides a > > >>>>> wide-compliance range. It needs no level-translation, which saves six > > >>>>> parts or so. A resistor-DAC to the Vsense node could modify the > > >>>>> individual LED currents, if desired. > > >>>> A negative voltage can work and if you use FETs instead of the BJTs you > > >>>> save three more parts, the base resistors. > > >>> I personally like FETs; I put in the PNPs for you. They're cheaper. > > >>> <grin> > > >> But only in mass production where SMT placement is cheap :-) > > > >>>> However, make sure the 3.3V hangs on, is strong enough. Also the > > >>>> switcher frequency must be high so load changes are handled fast enough. > > >>>> C1 can't be too large. > > >>> Or omit it altogether. C1's optional, really. > > >> Careful, then you modulate the LED current with tons of switcher ripple. > > >> That could lead to weird color shifts. > > > > I actually /was/ going to suggest modulating the LEDs deliberating, > > Arrgh. "deliberately" > > > > then using a.c. amplification and synchronous demodulation on the > > > detector side. That rejects ambient light and eliminates drift. > > > I don't know enough about Charlie's LED but modulating might result in > > it sweeping through a narrow swath of spectrum all the time. And if > > Murphy strike this will modulate or beat with some other stuff from > > fluorescents in the room and the poor uC doesn't know what to do with > > all that. > > I doubt the spectral sweep's a disadvantage here, but you do have to > choose intelligent chopping frequencies to avoid beats. That's easy-- > just integrate over a line cycle. Half a line cycle, to reject > fluorescents. 0.1 seconds is a very nice time. It is 6 cycles of 60Hz and 5 cycles of 50Hz. You don't need to adapt to the local mains.
From: JosephKK on 3 Mar 2010 09:49
On Mon, 01 Mar 2010 08:54:53 -0800, Charlie E. <edmondson(a)ieee.org> wrote: >Hi Guys, >Ok, going to put myself in harms way, and ask for a little design >advice. I have been working on this project for a while now, and it >has gone through several iterations, and I keep having the same >problem! > >First, the project: I am designing a small color reader for the >visually impaired. Really simple operation - put it against the >object you want to tell the color of, and it will say "RED" or >whatever the color is. Sensor is simply an RGB LED and a >phototransistor, buffered by some amps, and then digitized by a PIC24. >So, what's the problem? I can't get a stable reading. In normal >operation, this thing will run for about two seconds, and then be >turned off. To test, however, I run it in debug mode for hours. When >I first turn it on, and calibrate it to a white sample, I will get one >set of calibrations. Let it sit for about two minutes, and it starts >to drift. In about half an hour, I will have readings totally off the >scale. > >So, why am I baring my soul to ya'll? I need your help identifying >where the gain drift is coming from, and some ideas on how to control >them. I have the schematic here: > >http://edmondsonengineering.com/Documents/Rainbow%20color%20Reader%20Schematic.pdf > >Basic description - MCU turns on an LED. The phototransistor is first >buffered by a non-inverting opamp with a gain of 2, and the signal is >split. Part goes directly to a PGA where it is first attenuated, and >then the PGA boosts it up. This gives me a calibration control to >deal with difference in output of the LEDs. The original and PGA >signal are added, and this is then applied to another non-inverting >opamp with a gain of 2. I also have one feed before this opamp to an >ADC input on the PIC. > >Problems I have already solved: >First, each LED has a different output level. Red needs a gain of >around 2, BLUE a gain of around 5, and GREEN a gain of about 7. The >PGA was added to give me an adjustable gain from around 2 to 14, with >the two different taps into the separate input channels of the PGA. >This gives me 16 different gain levels to play with. Using the tap to >the second ADC channel, it actually gives me 32 different levels. > >Right now, RED uses this lower gain channel, and is steady as a rock. >Part of this may be that my VCC is 3.3 volts, and only RED has a >forward voltage below this. Both GREEN and BLUE have forward voltages >of 3.4 volts. > >So, potential problems? could it be that repeated use warms up the >GREEN and BLUE LEDs so that they become more efficient? Could the >power supply drift higher as it warms up? Could the opamps drift with >slight changes in temperature? Any advice ya'll can give will be most >appreciated. > >Thanks, >Charlie Charlie, i would never have tried this with just an RGB LED. I would use several spaced at about 50 nm apart. LEDs are pretty nearly monochromatic (having spectral widths not more than 10 nm). It would be real handy to have enough lines to estimate the spectral response with, so as to not end up calling orange brown or black. Now as to drive, how about something like this: $----------+ +--||-------+--\/\/\/\---> +V | | ) P/O | G L1 ) PIC | ) LED | |-----+---->|----+ +---------------||<-+ | | |--+ G | | | G ~ One led drive shown Use chopped drive and steady high from uC for off. The chopper freq (also 2x and 4x for different properties) is used to demodulate (synchronously) the desired signal from photo device output. You can adjust F or PW or both to compensate for battery voltage changes. L1 may work better in modified discontinuous current mode. If battery life is problematic insert a nfet driving a pfet switch between the resistor and +V. Perhaps all LED channels at the same time. -- Transmitted with recycled bits. Damnly my frank, I don't give a dear ---------- |