The Cyber-Spy.Com Usenet Archive Feeds Directly
From The Open And Publicly Available Newsgroup
This Group And Thousands Of Others Are Available
On Most IS NNTP News Servers On Port 119.
Cyber-Spy.Com Is NOT Responsible For Any Topic,
Opinions Or Content Posted To This Or Any Other
Newsgroup. This Web Archive Of The Newsgroup And
Posts Are For Informational Purposes Only.
Subject: Re: Improving Rise/Fall times on Opto
References: <email@example.com> <firstname.lastname@example.org>
X-Inktomi-Trace: pc2-cmbg2-3-cust97.cmbg.cable.ntl.com 1039213648 4124 22.214.171.124 (6 Dec 2002 22:27:28 GMT)
Date: Fri, 06 Dec 2002 22:27:29 GMT
NNTP-Posting-Date: Fri, 06 Dec 2002 22:27:29 GMT
Organization: ntl News Service
On 06 Dec 2002, you wrote in sci.electronics.design:
> "Sharpness of the pulse" was the only thing I read in the
> message that sounded like what he wanted to improve. You're right, if
> there is also a problem with the output pulse edge not lining up with
> the input pulse edge quickly enough, then improving the "sharpness"
> won't help the problem.
The propagation delay is of no real concern. Im driving the input to the
opto from an RC receiver via a switched current source to maintain the
LED current at a fixed value.
My real concern is the output swictching. Im using the emitter-follower
constructed to drive the input of an Atmel AVR MCU. Timing is quite
crictical because I am measuring the pulse-width of the input signal to
get a speed demand value.
The resolution I need across the pukse is about 8uS. With a rise/fall
timein the opto of about 2uS at best Im concerned about the point at
which the micro will switch at points when the input pulsewidth is
borderlining between each 8uS timeslice..this is my reason for wishing
the rise/fall to be as square as possible:) I also need minimal
component coun and least $$ too:) anyone suggest a better way given the
Go Back To The Cyber-Spy.Com
Usenet Web Archive Index Of
The sci.electronics.design Newsgroup