AVR-Chat

I need some way of measuring/displaying velocity of a projectile.  
This is for my coil gun experiment.  Heres how I think I might go 
about it.  Two matched pair IRdiode/phototransitor sensors, placed in 
a tube one inch apart.  This tube is then slipped over the end of the 
barrel. Use a AVR to start timing after first LED beam is broken and 
stop timing after second is broken.  Then make some formula to calc 
feet/second and display the result by either LCD or LED display.  Any 
coments on what the code might look like.  Also which AVR Should I 
use?  Could The Tiny serries handle this?

A tiny26 programmed with BASCOM would do nicely.  The free demo is enough to
do it all on a Tiny26 (www.mcselec.com)  You get a semi-accurate 16mhz
internal oscillator which would give you plenty of resolution over 1"  and
Bascom has built in LCD libraries which would get your display going very
fast.

I would just spin waiting for the first event, then loop incrementing a
counter until the next event, then divide the count into some number to get
furlongs per fortnight, or whatever units you want.

You can get fancier by using a timer and grab the current count when the
events occur.  That way you get more resolution.  Say, run the timer at
clock/16, or 1us/tick.

Cheers!

-----Original Message-----
From: William Nachefski

I need some way of measuring/displaying velocity of a projectile.
This is for my coil gun experiment.  Heres how I think I might go
about it.  Two matched pair IRdiode/phototransitor sensors, placed in
a tube one inch apart.  This tube is then slipped over the end of the
barrel. Use a AVR to start timing after first LED beam is broken and
stop timing after second is broken.  Then make some formula to calc
feet/second and display the result by either LCD or LED display.  Any
coments on what the code might look like.  Also which AVR Should I
use?  Could The Tiny serries handle this?

Even a slow processor should be fast enough.  Let's look at the 
math...

An object going 100 MPH will travel 1 inch in 0.568 ms.  Assuming a 
slow 1 MIPS processor, you'd get 568 instructions (counts) in that 
time.

In fact, that same processor could track something up to 56,800 miles 
per hour across that 1".

Mike


--- In AVR-Chat@yahoogroups.com, "LightYearCS" <lightyearcs@z...> 
wrote:

> You would most likely need a high speed timer to do this.  The
> microprocessor can read the results but I'm not sure if the built in
> timers would be fast enough to record the events.  You would have to
> define the parameters regarding accuracy.
> 
>  
> 
> What are your acceptable tolerances?
> 
>  
> 
> Barry

if the projectile shows magnetic properties, may be
you can use another coil, through which the projectile
will travel, and the induced voltage can be recorded
by a peak detector circuit.


--- William Nachefski <slaphappysamy@yahoo.com> wrote:
> I need some way of measuring/displaying velocity of
> a projectile.  
> This is for my coil gun experiment.  Heres how I
> think I might go 
> about it.  Two matched pair IRdiode/phototransitor
> sensors, placed in 
> a tube one inch apart.  This tube is then slipped
> over the end of the 
> barrel. Use a AVR to start timing after first LED
> beam is broken and 
> stop timing after second is broken.  Then make some
> formula to calc 
> feet/second and display the result by either LCD or
> LED display.  Any 
> coments on what the code might look like.  Also
> which AVR Should I 
> use?  Could The Tiny serries handle this?
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you�re looking for faster
http://search.yahoo.com

At 05:34 AM 3/10/2004 +0000, upand_at_them wrote:
>Even a slow processor should be fast enough.  Let's look at the
>math...
>
>An object going 100 MPH will travel 1 inch in 0.568 ms.  Assuming a
>slow 1 MIPS processor, you'd get 568 instructions (counts) in that
>time.

Bullets are typically fast, designing around 1400M/S at the high end 
wouldn't hurt.
A 100 MPH bullet wouldn't be all that interesting.

Actually, using findchips.com, I noticed the MM74C923 and MM74C923
aren't cheap either at $6.82 US in small quantities.

 

Barry

-----Original Message-----
From: upand_at_them [mailto:upand_at_them@yahoo.com] 
Sent: Tuesday, March 09, 2004 9:34 PM
Subject: [AVR-Chat] Re: Speed Trap

 

Even a slow processor should be fast enough.  Let's look at the 
math...

An object going 100 MPH will travel 1 inch in 0.568 ms.  Assuming a 
slow 1 MIPS processor, you'd get 568 instructions (counts) in that 
time.

In fact, that same processor could track something up to 56,800 miles 
per hour across that 1".

Mike


--- In AVR-Chat@yahoogroups.com, "LightYearCS" <lightyearcs@z...> 
wrote:
> You would most likely need a high speed timer to do this.  The
> microprocessor can read the results but I'm not sure if the built in
> timers would be fast enough to record the events.  You would have to
> define the parameters regarding accuracy.
> 
>  
> 
> What are your acceptable tolerances?
> 
>  
> 
> Barry







Yahoo! Groups Sponsor



ADVERTISEMENT
 
<http://rd.yahoo.com/SIG=12co1ue19/M=274551.4550177.5761904.1261774/D=eg
roupweb/S=1706554205:HM/EXP=1078983265/A=2019528/R=2/SIG=1413o4dmt/*http
:/ad.doubleclick.net/jump/N3349.yahoo1/B1282054.27;abr=!ie4;abr=!ie5;sz=
300x250;code=18634;dcopt=rcl;ord=1078896865603826?> 

 Click Here
<http://ad.doubleclick.net/ad/N3349.yahoo1/B1282054.27;abr=!ie4;abr=!ie5
;sz=300x250;code=18634;dcopt=rcl;ord=1078896865603826?> Click Here 


 
<http://us.adserver.yahoo.com/l?M=274551.4550177.5761904.1261774/D=egrou
pweb/S=:HM/A=2019528/rand=559397230> 

 

  _____  

Yahoo! Groups Links

*         To visit your group on the web, go to:
http://groups.yahoo.com/group/AVR-Chat/
  

*         To unsubscribe from this group, send an email to:
AVR-Chat-unsubscribe@yahoogroups.com
<mailto:AVR-Chat-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
  

*         Your use of Yahoo! Groups is subject to the Yahoo! Terms of
<http://docs.yahoo.com/info/terms/>  Service.

At 06:18 AM 3/10/2004 -0800, LightYearCS wrote:

>Actually, using findchips.com, I noticed the MM74C923 and MM74C923 arent 
>cheap either at $6.82 US in small quantities.

Which is why we use micros, and why such chips have very limited sales. :)

At 08:34 AM 3/10/2004 -0800, LightYearCS wrote:

>Actually, sales of these parts seem to be quite brisk even though its a 
>relatively old part.
>
>Of course, in larger quantities, most likely I would have my CPU/MCU 
>perform the keyscan, but when it comes to say building 100 devices, 
>sometimes it just not worth the extra software effort.

??? I've done a lot of keyboards, from multi-million run production, to 
one-offs.  It really isn't that hard.
Scan the keys every 10mS, and don't worry about bounce.

LightYearCS wrote:
> You would most likely need a high speed timer to do this.  The
> microprocessor can read the results but I'm not sure if the built in
> timers would be fast enough to record the events.  You would have to
> define the parameters regarding accuracy.
>
>
>
> What are your acceptable tolerances?
>
>
>
> Barry


Wow, a 4MHz clock and timer running at full clock, would give him 250ns
resolution.
Suppose a 10cm apart sensors, and the projectile launches at 331m/s (sound
speed), then the two sensors distance 10cm would be covered within 302.115
microseconds.  The AVR counter would count a value of 1208.
Isn't that enough?

The correct division would generate 1208.4592 counts, but it will count only
1208.

The 250ns resolution would give him speed span of 10cm/250ns = 400km/second.
A round integer counting of 1208 would means 331.125m/s, but, if counting
bumps to 1209 it would mean 330.9m/s, at this range, one count would
represent a delta 0.225m/s

For further resolution, you can always use a faster clock (see AtTiny26) or
increasing the distance between the sensors.

I guess the worse nighmare would be to adjust exactly the distance between
the sensors. An physical installation error of 1mm (will happens easily)
(instead of 10cm you install them 9.9cm apart); a 331m/s projectile will
cover 99mm distance in 299.094 microseconds, 4MHz clock will count a round
integer of 1196, but you thinking it was 100mm distance will lead to a wrong
calculation, resulting in 0.1 / 1196 x 250ns = 334.448m/s.

So you see, the biggest problem in accuracy is to positionning exactly the
sensors.
Far distance between the sensors, better accuracy.

You could always calibrate the unit, but finding a "referente high speed"
will always be a problem.
You can't simply go to the store and ask for a 1000km/h speed reference. :)

The only easy way is to get a sinchronous AC motor, lets say 600rpm (10rps),
install a 1m diameter large disk at the shaft, make a mark at the edge,
measure the speed of that mark with the installed sensors 10cm apart.  1m
diameter = 3.14159 m circunference, 10rps = 31.4159m/s, 10cm apart =
3.178741ms, 4MHz counter should count 12714.96.  Reversing the numbers:  0.1
/ 12714 x 250ns = 31.46138m/s



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.600 / Virus Database: 381 - Release Date: 2/28/2004

Now what did I say?  Small quantities?  Signal Conditioning?  Key
Debouncing?  My Honest Opinion?? :-) heh

 

Don't worry about it, you're right.  There are lots of canned library
routines for keyboard scanning.

 

Although in the case of including a display, you will need a driver.  So
as long as the driver has a built in keyboard scanner, why not eh?

-----Original Message-----
From: Dave VanHorn [mailto:dvanhorn@cedar.net] 
Sent: Wednesday, March 10, 2004 8:47 AM
Subject: RE: [AVR-Chat] Re: Speed Trap

 

At 08:34 AM 3/10/2004 -0800, LightYearCS wrote:

>Actually, sales of these parts seem to be quite brisk even though its a

>relatively old part.
>
>Of course, in larger quantities, most likely I would have my CPU/MCU 
>perform the keyscan, but when it comes to say building 100 devices, 
>sometimes it just not worth the extra software effort.

??? I've done a lot of keyboards, from multi-million run production, to 
one-offs.  It really isn't that hard.
Scan the keys every 10mS, and don't worry about bounce.




  _____  

Yahoo! Groups Links

*         To visit your group on the web, go to:
http://groups.yahoo.com/group/AVR-Chat/
  

*         To unsubscribe from this group, send an email to:
AVR-Chat-unsubscribe@yahoogroups.com
<mailto:AVR-Chat-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
  

*         Your use of Yahoo! Groups is subject to the Yahoo! Terms of
<http://docs.yahoo.com/info/terms/>  Service.

>
>So you see, the biggest problem in accuracy is to positionning exactly the
>sensors.
>Far distance between the sensors, better accuracy.

Matching the optos will also be a problem. They aren't known for speed 
either, though that's solveable.
Breaking tensioned wires might be a lot easier and more repeatable.
IIRC the earliest chronographs used that..

Of course you could always grab a microwave burglar alarm and process the 
doppler ouput.
They are designed for <1MPH but that's all in the processing electronics, 
just take the homodyne mixer output directly.
I used to know the formula for doppler shift offhand, the typical alarm 
runs around 10.5 GHz

Depends on what the tolerances are.

 

I think I'll just stick to asking questions.

 

I'm mainly here to learn about AVR.  I'm setting up a port for the
uC/OS-II Real Time Operating System.  We looked at AVR and thought it
would be an excellent platform for our product.

 

Good luck with that magnetic cannon.

-----Original Message-----
From: Wagner Lipnharski [mailto:wagner@ustr.net] 
Sent: Wednesday, March 10, 2004 8:55 AM
Subject: Re: [AVR-Chat] Speed Trap

 

LightYearCS wrote:
> You would most likely need a high speed timer to do this.  The
> microprocessor can read the results but I'm not sure if the built in
> timers would be fast enough to record the events.  You would have to
> define the parameters regarding accuracy.
>
>
>
> What are your acceptable tolerances?
>
>
>
> Barry


Wow, a 4MHz clock and timer running at full clock, would give him 250ns
resolution.
Suppose a 10cm apart sensors, and the projectile launches at 331m/s
(sound
speed), then the two sensors distance 10cm would be covered within
302.115
microseconds.  The AVR counter would count a value of 1208.
Isn't that enough?

The correct division would generate 1208.4592 counts, but it will count
only
1208.

The 250ns resolution would give him speed span of 10cm/250ns =
400km/second.
A round integer counting of 1208 would means 331.125m/s, but, if
counting
bumps to 1209 it would mean 330.9m/s, at this range, one count would
represent a delta 0.225m/s

For further resolution, you can always use a faster clock (see AtTiny26)
or
increasing the distance between the sensors.

I guess the worse nighmare would be to adjust exactly the distance
between
the sensors. An physical installation error of 1mm (will happens easily)
(instead of 10cm you install them 9.9cm apart); a 331m/s projectile will
cover 99mm distance in 299.094 microseconds, 4MHz clock will count a
round
integer of 1196, but you thinking it was 100mm distance will lead to a
wrong
calculation, resulting in 0.1 / 1196 x 250ns = 334.448m/s.

So you see, the biggest problem in accuracy is to positionning exactly
the
sensors.
Far distance between the sensors, better accuracy.

You could always calibrate the unit, but finding a "referente high
speed"
will always be a problem.
You can't simply go to the store and ask for a 1000km/h speed reference.
:)

The only easy way is to get a sinchronous AC motor, lets say 600rpm
(10rps),
install a 1m diameter large disk at the shaft, make a mark at the edge,
measure the speed of that mark with the installed sensors 10cm apart.
1m
diameter = 3.14159 m circunference, 10rps = 31.4159m/s, 10cm apart =
3.178741ms, 4MHz counter should count 12714.96.  Reversing the numbers:
0.1
/ 12714 x 250ns = 31.46138m/s



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.600 / Virus Database: 381 - Release Date: 2/28/2004




  _____  

Yahoo! Groups Links

*         To visit your group on the web, go to:
http://groups.yahoo.com/group/AVR-Chat/
  

*         To unsubscribe from this group, send an email to:
AVR-Chat-unsubscribe@yahoogroups.com
<mailto:AVR-Chat-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
  

*         Your use of Yahoo! Groups is subject to the Yahoo! Terms of
<http://docs.yahoo.com/info/terms/>  Service.

Agreed.  But I was giving an example of the math to show that the AVR 
is indeed fast enough to time.

1400m/s, or about 3000 MPH, is still doable with even a slow 
processor.

Mike


--- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@c...> wrote:
> At 05:34 AM 3/10/2004 +0000, upand_at_them wrote:
> >Even a slow processor should be fast enough.  Let's look at the
> >math...
> >
> >An object going 100 MPH will travel 1 inch in 0.568 ms.  Assuming a
> >slow 1 MIPS processor, you'd get 568 instructions (counts) in that
> >time.
> 
> Bullets are typically fast, designing around 1400M/S at the high 
end 
> wouldn't hurt.
> A 100 MPH bullet wouldn't be all that interesting.

Wow!  what a response.  Actually my tolerances are quite large, + or -
 say 10 m/sec.  As for placement of the sensors I have no set length 
yet, I just threw 1" as an arbitrary number.  What distance would be 
best?  I do intend to condition the signal of the sensors before the 
uC.  As for accurate distance between them I was going to use a dial 
caliper.  Is that accurate enough, obviously the larger the distance 
apart the less important it becomes.  I think I will go with 10 
centimeters apart.

--- In AVR-Chat@yahoogroups.com, "upand_at_them" <upand_at_them@y...> 
wrote:
> Agreed.  But I was giving an example of the math to show that the 
AVR 
> is indeed fast enough to time.
> 
> 1400m/s, or about 3000 MPH, is still doable with even a slow 
> processor.
> 
> Mike
> 
> 
> --- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@c...> wrote:
> > At 05:34 AM 3/10/2004 +0000, upand_at_them wrote:
> > >Even a slow processor should be fast enough.  Let's look at the
> > >math...
> > >
> > >An object going 100 MPH will travel 1 inch in 0.568 ms.  
Assuming a
> > >slow 1 MIPS processor, you'd get 568 instructions (counts) in 
that

> > >time.
> > 
> > Bullets are typically fast, designing around 1400M/S at the high 
> end 
> > wouldn't hurt.
> > A 100 MPH bullet wouldn't be all that interesting.

At 09:23 PM 3/10/2004 +0000, William Nachefski wrote:
>Wow!  what a response.  Actually my tolerances are quite large, + or -
>  say 10 m/sec.  As for placement of the sensors I have no set length
>yet, I just threw 1" as an arbitrary number.  What distance would be
>best?  I do intend to condition the signal of the sensors before the
>uC.  As for accurate distance between them I was going to use a dial
>caliper.  Is that accurate enough, obviously the larger the distance
>apart the less important it becomes.  I think I will go with 10
>centimeters apart.

Your error will be mostly in the response time of the two phototransistors, 
and in the problem of determining exactly when the beam is to be called 
"blocked".
10% drop in light, or 90%, and what is the gain of this phototransistor 
today, at this temperature, anyway?

A photodiode, amplified by a current to voltage converter, is more 
repeatable.  Don't let that scare you, a current to voltage converter is 
just a simple op-amp circuit. Of course the op-amp you use also has to be 
fast enough to play this game..

A tip: Make the IR light sources LOUD, and make the optosensors relatively 
deaf.

On Thursday 11 March 2004 01:05, Dave VanHorn wrote:
> >So you see, the biggest problem in accuracy is to positionning
> >exactly the sensors.
> >Far distance between the sensors, better accuracy.

> Matching the optos will also be a problem. They aren't known for
> speed either, though that's solveable.

> Breaking tensioned wires might be a lot easier and more repeatable.

Erm... no ... not unless you're drawing your own wires or carefully
selecting the wires from a large spool. A few percent difference in
wire diameter "dramatically" changes its physical strength.

An old photography trick is to stick a microphone on a playing card;
with the microphone hooked up to an amplifier with the gain set to a
"critical" level in order to set off an electronic flash; then fire
the bullet through the card.

Of course it's useless doing that if you want to measure the speed
of the bullet because you slow it down by piercing the card.

I've thought of using a soap bubble instead; triggering when the
refraction through or reflection from the bubble changes. 

Make sure that the air isn't moving too much around the test
cell to avoid false triggers.

-- 
/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
\ /  ASCII ribbon campaign | I'm a .signature virus!
 X   against HTML mail     | Copy me into your ~/.signature
/ \  and postings          | to help me spread!

Since every wacky idea is being offered:
Use an accelerometer in the cannon itself to measure recoil
momentum.  If the mass of the projectile is known, then the
exiting velocity is also known.
Ken

At 09:21 AM 3/11/2004 +0800, you wrote:

>On Thursday 11 March 2004 01:05, Dave VanHorn wrote:
>> >So you see, the biggest problem in accuracy is to positionning
>> >exactly the sensors.
>> >Far distance between the sensors, better accuracy.
>
>> Matching the optos will also be a problem. They aren't known for
>> speed either, though that's solveable.
>
>> Breaking tensioned wires might be a lot easier and more repeatable.
>
>Erm... no ... not unless you're drawing your own wires or carefully
>selecting the wires from a large spool. A few percent difference in
>wire diameter "dramatically" changes its physical strength.
>
>An old photography trick is to stick a microphone on a playing card;
>with the microphone hooked up to an amplifier with the gain set to a
>"critical" level in order to set off an electronic flash; then fire
>the bullet through the card.
>
>Of course it's useless doing that if you want to measure the speed
>of the bullet because you slow it down by piercing the card.
>
>I've thought of using a soap bubble instead; triggering when the
>refraction through or reflection from the bubble changes. 
>
>Make sure that the air isn't moving too much around the test
>cell to avoid false triggers.
>
>-- 
>/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
>\ /  ASCII ribbon campaign | I'm a .signature virus!
> X   against HTML mail     | Copy me into your ~/.signature
>/ \  and postings          | to help me spread!
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>

On Thursday 11 March 2004 10:09, Ken Holt wrote:

> At 09:21 AM 3/11/2004 +0800, you wrote:
> >I've thought of using a soap bubble instead; triggering when the
> >refraction through or reflection from the bubble changes.
> >
> >Make sure that the air isn't moving too much around the test
> >cell to avoid false triggers.

> Since every wacky idea is being offered:

wacky idea? It's called "ideation".

> Use an accelerometer in the cannon itself to measure recoil
> momentum.  If the mass of the projectile is known, then the
> exiting velocity is also known.

Not quite.

-- 
/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
\ /  ASCII ribbon campaign | I'm a .signature virus!
 X   against HTML mail     | Copy me into your ~/.signature
/ \  and postings          | to help me spread!

I wonder if a hall sensor would work.  Or better yet, what about a 
laser beam.  I saw a couple of those laser modules at radio shack the 
other day (cheap too :) That would cut down reaction time.  As for 
AVR, I will use the mega8, I have a bunch of those laying around.

--- In AVR-Chat@yahoogroups.com, Bernd Felsche <bernie@i...> wrote:

> On Thursday 11 March 2004 10:09, Ken Holt wrote:
> 
> > At 09:21 AM 3/11/2004 +0800, you wrote:
> > >I've thought of using a soap bubble instead; triggering when the
> > >refraction through or reflection from the bubble changes.
> > >
> > >Make sure that the air isn't moving too much around the test
> > >cell to avoid false triggers.
> 
> > Since every wacky idea is being offered:
> 
> wacky idea? It's called "ideation".
> 
> > Use an accelerometer in the cannon itself to measure recoil
> > momentum.  If the mass of the projectile is known, then the
> > exiting velocity is also known.
> 
> Not quite.
> 
> -- 
> /"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
> \ /  ASCII ribbon campaign | I'm a .signature virus!
>  X   against HTML mail     | Copy me into your ~/.signature
> / \  and postings          | to help me spread!

William Nachefski said:
> I wonder if a hall sensor would work.  Or better yet, what about a
> laser beam.  I saw a couple of those laser modules at radio shack the
> other day (cheap too :) That would cut down reaction time.  As for  AVR,
> I will use the mega8, I have a bunch of those laying around.

I found some 38 kHz IR receivers that I plan to use for a pinewood
derby track timer now that I actually have 3 AVR Butterfly(s) in
my hands. The part number for these is ELIRM-8601 and they are
fairly cheap.

Mike

--- In AVR-Chat@yahoogroups.com, "Capricon" <capri5@n...> wrote:
> Does anyone know why do we need AVR ISP IN-System programmer?

Well...for one thing it makes REGULAR programming a heck of a lot 
easier

It's kind of like being able to download software from the internet for 
you PC,
as opposed to taking out your hard drive, putting it in a dedicated 
programmer,
then putting it back in the PC.

With ISP, I can take my laptop to one of my designs, hook up a cable,
download the program, and it's ready to go.

Regards,
   JJ

On Friday, Mar 12, 2004, at 00:21 US/Eastern, Capricon wrote:

> Does anyone know why do we need AVR ISP IN-System programmer?
>  
> Capricon
>
<image.tiff>

>
> Yahoo! Groups Links
>
> • 	To visit your group on the web, go to:
> http://groups.yahoo.com/group/AVR-Chat/
>  
> • 	To unsubscribe from this group, send an email to:
> AVR-Chat-unsubscribe@yahoogroups.com
>  
> • 	Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>

-----Original Message-----
From: John Johnson [mailto:johnatl@mac.com]
Sent: Friday, March 12, 2004 4:12 AM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] Avr ISP

It's kind of like being able to download software from the internet for you PC,
as opposed to taking out your hard drive, putting it in a dedicated programmer,
then putting it back in the PC.

With ISP, I can take my laptop to one of my designs, hook up a cable,
download the program, and it's ready to go.

Regards,
JJ

-----Original Message-----
From: John Johnson [mailto:johnatl@mac.com]
Sent: Friday, March 12, 2004 4:12 AM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] Avr ISP

It's kind of like being able to download software from the internet for you PC,
as opposed to taking out your hard drive, putting it in a dedicated programmer,
then putting it back in the PC.

With ISP, I can take my laptop to one of my designs, hook up a cable,
download the program, and it's ready to go.

Regards,
JJ

Capricon wrote:
> What is the difference between a stk500 and a avr_ISP?
>
> Capricon

STK500 and AVR-ISP?

Size, Price, appearance, functions, operation.

If you plan to program your AVRs on their own boards, the AVR-ISP is better
since it is smaller and cheapper than the STK500.

Perhaps you should visit http://www.atmel.com and read a little bit about
both units.

Wagner Lipnharski - email:  wagner@ustr.net
UST Research Inc. - Development Director
http://www.ustr.net - Orlando Florida 32837
Licensed Consultant Atmel AVR _/_/_/_/_/_/
March 12, 2004 12:44 pm




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.600 / Virus Database: 381 - Release Date: 2/28/2004

>not unless you're drawing your own wires or carefully
>selecting the wires from a large spool. A few percent difference in
>wire diameter "dramatically" changes its physical strength.

Depends on the wire.
Piano wire won't stretch much, and besides, it should be extremely consistent.
As long as both sides stretch the same, then we just moved the sensing point.

Dave VanHorn wrote:
> At 09:23 PM 3/10/2004 +0000, William Nachefski wrote:
>> Wow!  what a response.  Actually my tolerances are quite large, + or
>>  - say 10 m/sec.  As for placement of the sensors I have no set
>> length yet, I just threw 1" as an arbitrary number.  What distance
>> would be best?  I do intend to condition the signal of the sensors
>> before the uC.  As for accurate distance between them I was going to
>> use a dial caliper.  Is that accurate enough, obviously the larger
>> the distance apart the less important it becomes.  I think I will go
>> with 10 centimeters apart.
>
> Your error will be mostly in the response time of the two
> phototransistors, and in the problem of determining exactly when the
> beam is to be called "blocked".
> 10% drop in light, or 90%, and what is the gain of this
> phototransistor today, at this temperature, anyway?
>
> A photodiode, amplified by a current to voltage converter, is more
> repeatable.  Don't let that scare you, a current to voltage converter
> is just a simple op-amp circuit. Of course the op-amp you use also
> has to be fast enough to play this game..
>
> A tip: Make the IR light sources LOUD, and make the optosensors
> relatively deaf.


If using the same kind of phototransistor and light source, the
environmental error will be common to both, including the time response of
the thing.  The first will sense the blocker object (projectile) the same
exactly way as the second, so, a lazy sensor will answer late the same way
as the second.  The time delay between both sensors will be the same, no
matter temperature, air pressure or anything else.  I am considering two
exactly the same sensors and light source, also physical installations.

It would be different if only one sensor is to be used.  The sensor could
measure the darkness period of time, in true it would be measuring how long
the "no-light" situation takes in microseconds. Knowing the projectile size
it would be easy to calculate speed. This idea is no good, since due
environmental conditions a phototransistor could conduct faster than cut...




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.600 / Virus Database: 381 - Release Date: 2/28/2004

This isn't my experience.  I find wide variations among sensors -
particularly after soldering them into boards.  Even sensors that are
suppose to have tight tolerances.  And incidental environmental light can
make the situation even worse.

-----Original Message-----
From: Wagner Lipnharski
...

If using the same kind of phototransistor and light source, the
environmental error will be common to both, including the time response of
the thing.  The first will sense the blocker object (projectile) the same
exactly way as the second, so, a lazy sensor will answer late the same way
as the second.  The time delay between both sensors will be the same, no
matter temperature, air pressure or anything else.  I am considering two
exactly the same sensors and light source, also physical installations.

It would be different if only one sensor is to be used.  The sensor could
measure the darkness period of time, in true it would be measuring how long

Larry Barello wrote:
> This isn't my experience.  I find wide variations among sensors -
> particularly after soldering them into boards.  Even sensors that are
> suppose to have tight tolerances.  And incidental environmental light
> can make the situation even worse.

Of course, it all depends on technique.
I for one, always make sure the light from the source will be the only one
to hit the receiver.
The best way to do that is creating a dark tunel for the source (minimum
2"), and a 2 to 3" dark tunel for the receiver with 2 black disks in between
the opening and the sensor. A small hole (3mm) aligned to the source will
eliminate almost completely any external interference.  Just the straight
light from the source will hit the sensor. The two disks with the hole, 1"
apart will create a narrow angle of light hiting the sensor.

Of course, in nature everything is exposed to imperfections, but we can try
to improve it by all means.




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.600 / Virus Database: 381 - Release Date: 2/28/2004

Take a look at this line of parts for working with photodiodes:

http://www.maxim-ic.com/quick_view2.cfm?qv_pk=3760&ln=

-----Original Message-----
From: Dave VanHorn [mailto:dvanhorn@cedar.net] 
Sent: Wednesday, March 10, 2004 1:37 PM
Subject: Re: [AVR-Chat] Re: Speed Trap

At 09:23 PM 3/10/2004 +0000, William Nachefski wrote:
>Wow!  what a response.  Actually my tolerances are quite large, + or -
>  say 10 m/sec.  As for placement of the sensors I have no set length
>yet, I just threw 1" as an arbitrary number.  What distance would be
>best?  I do intend to condition the signal of the sensors before the
>uC.  As for accurate distance between them I was going to use a dial
>caliper.  Is that accurate enough, obviously the larger the distance
>apart the less important it becomes.  I think I will go with 10
>centimeters apart.

Your error will be mostly in the response time of the two
phototransistors, 
and in the problem of determining exactly when the beam is to be called 
"blocked".
10% drop in light, or 90%, and what is the gain of this phototransistor 
today, at this temperature, anyway?

A photodiode, amplified by a current to voltage converter, is more 
repeatable.  Don't let that scare you, a current to voltage converter is

just a simple op-amp circuit. Of course the op-amp you use also has to
be 
fast enough to play this game..

A tip: Make the IR light sources LOUD, and make the optosensors
relatively 
deaf.

 
Yahoo! Groups Links

You can use the same emitter/receiver pair for both beams. I'm no  
Michel Asciio, but I'll give it a shot:

-----/-----\-----
-----u-----^-----

/ and \ represent mirrors (front surface?).
u is a receiver.
^ is an emitter (laser diode?).

With a bright enough source, this mirror pattern could continue down  
the tube, so you could get multiple velocity readings.

You can also use one emitter/receiver and no mirrors to measure the  
velocity. The length of the projectile is known, so you only need the  
dark/light time to determine the velocity.

Another thought: at the target, use a sandwich of three pieces of foil,  
insulated from each other. When the outer two pieces make contact,  
start a counter, and when the inner two pieces make, stop the counter.  
I like the optical ideas better.

Regards,
   JJ

On Friday, Mar 12, 2004, at 22:14 US/Eastern, LightYearCS wrote:

> Take a look at this line of parts for working with photodiodes:
>
> http://www.maxim-ic.com/quick_view2.cfm?qv_pk=3760&ln=
>
>
> -----Original Message-----
> From: Dave VanHorn [mailto:dvanhorn@cedar.net]
> Sent: Wednesday, March 10, 2004 1:37 PM
> Subject: Re: [AVR-Chat] Re: Speed Trap
>
> At 09:23 PM 3/10/2004 +0000, William Nachefski wrote:
>> Wow!  what a response.  Actually my tolerances are quite large, + or -
>>  say 10 m/sec.  As for placement of the sensors I have no set length
>> yet, I just threw 1" as an arbitrary number.  What distance would be
>> best?  I do intend to condition the signal of the sensors before the
>> uC.  As for accurate distance between them I was going to use a dial
>> caliper.  Is that accurate enough, obviously the larger the distance
>> apart the less important it becomes.  I think I will go with 10
>> centimeters apart.
>
> Your error will be mostly in the response time of the two
> phototransistors,
> and in the problem of determining exactly when the beam is to be called
> "blocked".
> 10% drop in light, or 90%, and what is the gain of this phototransistor
> today, at this temperature, anyway?
>
> A photodiode, amplified by a current to voltage converter, is more
> repeatable.  Don't let that scare you, a current to voltage converter  
> is
>
> just a simple op-amp circuit. Of course the op-amp you use also has to
> be
> fast enough to play this game..
>
> A tip: Make the IR light sources LOUD, and make the optosensors
> relatively
> deaf.
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor  
> ---------------------~-->
> Upgrade to 128-bit SSL Security!
> http://us.click.yahoo.com/LPJzrA/yjVHAA/TtwFAA/dN_tlB/TM
> --------------------------------------------------------------------- 
> ~->
>
>
> Yahoo! Groups Links
>
>
>
>
>