Searching \ for 'PIC_k You Brains' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'PIC_k You Brains'.

Truncated match.
PICList Thread
'PIC_k You Brains'
1998\10\08@235507 by Dr. Ed Edmondson, Jr. Ph.D.

picon face
I am really glad to see that all you picsters are so easily amused :-)).
Technical people with a good sense of humor are hard to find.

What I need to do is just PIC your brains a little.  I have all the hardware,
software and books to learn what to do with these PIC devices.  What I need is
a little bit of direction.  I am wanting to build a model rocket launcher for
a friend who has an asthmatic son.  I have seen some simple designs but tend
to lean towards the flair for bells and whistles.  So what I will have a very
I/O intensive little PIC.

I want to use 10 LED's for the launch sequence (10, 9, 8, 7, ....2, 1, L).
These LED's will count down in sequence with the last LED "L" flashing at
about 1-2 Hz at launch.  I want to use a piezo alarm to sound a launch warning
for the last 4 counts (LED's 4, 3, 2, 1, L).  Then there would be a dual
RED/GREEN LED for the Fuze continuity check and a button for this test (maybe
it could be automated).  Then we have a flashing (1-2 Hz) red LED to indicate
the countdown has been halted due to emergency and a button to activate this
feature.  There is also a flashing yellow LED (1-2 Hz) to indicate a temporary
hold on the countdown sequence and the button to hold and restart the
countdown.  Two buttons for on and off and a green LED to indicate power "ON."

I also want a master reset button (Must be held in for 5 -10 seconds) to reset
the whole system to a known state and disable the launch circuit.  I am
planning on using a key switch for the master interlock on the launch circuit.
This and maybe using a SSR to isolate the launch and Fuzing circuit will
enhance the safety issue.  I want the unit to also go "To Sleep" after 5 or 10
minutes of inactivity.  Pressing any key would reawaken the system in the
state it was in prior to "Sleep."

Finally it would be great to have some form of battery condition indicators.
Maybe a small LCD voltmeter to measure battery voltage or current.  Maybe a
battery gas gauge like Benchmarq sells for high priced power tools.  Maybe use
the display for a clock too?  Want to be able to use alkaline or rechargeable
batteries to power the thing.  It would be great if it could be charged from
an auto cigarette lighter!!

What I need is suggestions on  what PIC  might really fit the bill here.
There is a lot of I/O, a watch dog timer, maybe an A/D, should be able to
drive LED's, an SSR, a piezo audio indicator, determine battery condition and
charge state.  And much more.

With all these bells and whistles this asthmatic young teen could have the
ABSOLUTE neatest model rocket launcher at the contests.  This is his only form
of recreation due to his exacerbated condition.

What I will get out of this journey, in addition to his smiles, is the
knowledge earned from getting this thing designed and built.  I have MPLAB on
a Compaq Presario 1610 and a PIC Start Plus Programmer.  I have all the PIC
books written by anyone I could find.  I have a free source for the PIC chips.
What I need is direction and suggestions along the way.

Want to help??  The only real concern is SAFETY to prevent an accidental
launch which might cause an injury.  This can be avoided with some old
fashioned design criteria and common sense.  I have until December 24th to get
this done.  Any direction and comments would be greatly appreciated by the
recipient and myself.

Ed

1998\10\09@010249 by James Cameron

flavicon
face
Since you are design phase, Ed, I'd suggest a few other changes ...

Add a wide angle passive infrared motion detector to the launch pad, so
that it refuses to commence a countdown if people are close to it.
Maybe even abort a countdown.

Since some of the system has to do with safety, I would avoid placing
those features in code in the PIC, but rather as hardware interlocks
outside the code.  See the "Risks Digest" for the past ten years for
good reasons why.  ;-)

--
James Cameron                                    (spam_OUTcameronTakeThisOuTspamstl.dec.com)
Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800

1998\10\09@010606 by paulb

flavicon
face
Dr. Ed Edmondson, Jr. Ph.D. wrote:

> I want to use 10 LED's for the launch sequence (10, 9, 8, 7, ....2, 1,
> L).

 No way!  You want two large, bright 7-segment displays.  Of course,
these can also display voltage etc., though a number of small ones as
well (note my previous comments on multiplexing) would be great.  Have
you not seen all the neat patterns you can play on 7-seg. displays?

 Need a sun-hood.

> What I need is suggestions on  what PIC  might really fit the bill
> here.

 Prototype on 16C84, then on 16C71(x)/JW if you need ADC, burn on
16C71.  If you use interfacing right, that'll do.

> I have a free source for the PIC chips.

 Oh weellll!
--
 Cheers,
       Paul B.

1998\10\09@042630 by ruben

flavicon
face
Hello Ed
.....
> This and maybe using a SSR to isolate the launch and Fuzing circuit will
> enhance the safety issue.
....
> Want to help??  The only real concern is SAFETY to prevent an accidental
> launch which might cause an injury.  This can be avoided with some old
> fashioned design criteria and common sense.  I have until December 24th to get
> this done.  Any direction and comments would be greatly appreciated by the
> recipient and myself.
>
> Ed

About safety.

Use two separate channels (2 processors with 2 different programs preferably
by two different programmers), both handling all safety parameters in parallel.
Both channels have one 2 pole positive action (safety) relays where one pole is
used for output in series with one of the other channels relay. The other pole i
s
used for crosschecking the relay outputs between the two channels (both
channel are checking the other channels relay). The processors should have a
pulsed output to activate the safety relays, through for example a transformer
(so that a static output can't activate the relay).

The two processors should have some sort of communication between them in
order to be able to check each other (check that the programs are working and
that they have the same result on safety related conclusions).

Use two separate sensors, one for each channel, for every safety related input.
Design the input stage so the processors can check short circuited active
inputs (one output can turn off the input stage, check that the processor input
for the safety function can be set to inactive state by the output when the safe
ty
sensor is activated). To control the actual input - make it dynamic (so that the
program can check that it at some point is off and not shorted to the active
state). For example for a push button initiate the action when the button is fir
st
pressed and then released. Or, for static inputs have a maximum time
difference between the two sensors (two channels) for them to be able to
activate an event and set it as a condition that the sensor must be deactivated
at
power up (so a short is detected).

All safety related electronics should be designed so that a failure in one
component doesn't lead to a potentially dangerous state if it can't be discovere
d
by the processors. Test that no potentially dangerous state can be initiated by
a
shortcircuit between any two pins/legs on a any circuit or terminal. (If the sho
rt
circuit isn't detected restart the test with the pins shorted, do this up to thr
ee
levels if another short circuit is undetected). A processor which, when reading
an output pin reads the actual pin and not the output latch is good here.

In the program flow: Both channels continuously checks each other through the
communication lines. If the response is unexpected put the channel that found
the error in an interlocked state which can't be aborted and turn the safety rel
ay
off. Continously check the other channel's relay - if it doesn't match this
channel - go to interlock state.

Safety related RAM registers should continously be checked that they can be
changed and that a write to some other RAM register doesn't affect this
register. At power up the integrity of the program should be checked by some
sort of checksum test of the EPROM (can't be done in a PIC, use a SCENIX).
Also, all instructions used by safety related functions should be checked at
power up.

One channel could handle all the whistels and bells plus the safety and the othe
r
channel could handle just the safety.

This may sound a bit overworked but it is how a human safety device of
category 4 is done for industrial purposes (light barrier, light courtains,
emergency stops etc.)



--------------------------------------------
Ruben Jvnsson
AB Liros Elektronik
Box 9124, 200 39 Malmv, Sweden
TEL INT +4640142078
FAX INT +4640947388
.....rubenKILLspamspam@spam@2.sbbs.se
--------------------------------------------

1998\10\09@124914 by Morgan Olsson

picon face
Ruben Joensson wrote:

-big snip of a very thorough safety strategy-

>At power up the integrity of the program should be checked by some
>sort of checksum test of the EPROM (can't be done in a PIC, use a SCENIX).

I have not used a PIC17, but I believe we can use the table read to read
all program memory?

For PIC16, i have been thinking: as we have two processors, they might be
able to set each other in serial programming mode and read each other by
use of little external hardware... No, much better use PIC17 or other
processor...

I want to add:

The program memory check sould be run now and then, as the eprom slowly
degrades by age, and is probably more possible that the first erroneous
reading will take place during normal execution (!), as the EPROM is
sensitive to both voltage and temperature (and supply noise too), which
will vary during execution.

To achieve a margin, we better test the eprom at slightly worse conditions
than when runnig the safety routines.  Therefor, the testing should be run
at bot slightly lower, and slightly higher supply voltage trying to stress
up errors of "0" and "1" bits respectively.

This can easily be achieved, as one pin can via a resistor be connected to
the voltage regulator feedback loop (i.e on a LM317-regulator), and use all
three states (High/Tristate/Low).
Take care in design so there is not too fast change or overshoot.

Timing proposal:

RESET:
Initialize to output "safety violated" state
Set lower voltage
wait to stabilize voltage (sleep, and wake of timer interrupt?)
-Check system-
Set normal voltage         ;Two-step to minimize overshoot
wait to stabilize voltage       ;
Set higher voltage              ;
wait to stabilize voltage       ;
-Check system-
MAIN:
Set normal voltage
wait to stabilize voltage
[Run a safety pass]
Set lower voltage
wait to stabilize voltage
-Check system-
Set normal voltage
wait to stabilize voltage
[Run a safety pass]
Set higher voltage
wait to stabilize voltage
-Check system-
GOTO MAIN

Also, all theese "-Check system-" routines above should check EEPROM to a
checksum, and also test as much as possible of the rest of the chip (all
that possibly can be tested-restored, or checksum compared etc), Like XOR
FF twice to every RAM and see if it still reads the same.  Check if timer
or other things give interrupt correctly, etc.
Also run a small routine tht use all CPU hardware and see that it always
give the right result.  Best also to run for different input values.

I wonder what do Mchip use to test the chips;  They should be able to tell
a complete chip test scheme for every processor :)

Best also to test external cirquitry during over/under voltage.

The test routine can of course be split to do part of the test each time.
Also the safety routines might sometimes temporarily be too busy doing
something, but when finished, continue with the system check. (safety: max
time set by watchdog)

I think I better stop now...
I was going to suggest a small simple RF-sweep oscillator that the PIC
enables to inject noise on supply during test... Oops.. I did   ;)

I have never used anything except watchdog and brown-out yet...

BTW, a better Watchdog might be good, like one that needs toggling within
defined time high and low *windows*.
So, also talking too much with the watchdog causes reset.
I believe Maxim or LTC make them.
Or wire your own.
Or, maybe cheapest, use a 8-pin PIC !

Regards
/Morgan
/  Morgan Olsson, MORGANS REGLERTEKNIK, SE-277 35 KIVIK, SWEDEN \
\  mrtspamKILLspaminame.com     ph +46(0)414 70741     fax +46(0)414 70331 /

1998\10\09@130351 by Justin Crooks

flavicon
face
Use a PIC16C74.  Lots of I/O pins, A/D no problem.  My battery check ckt is
nice and simple.  For 9V batteries, I use a 2N2222A transistor.  Connect a
digital I/O pin to the base via a 100K resistor.  this is your on/off so
the ckt does not draw current when not needed.  Connect a 2.2k resistor b/w
emitter and ground.  A 9.1K goes b/w collector and Vbat+.  The analog
voltage at the emitter (with a high applied to the base) will convert to
your battery voltage in tenths of volts if your Vref is +5V.

I recommend the abort key be instant, without delay (safety).  with a
PIC16C74, each LED could have its own I/O pin, with pins for future
enhancements readily available.

----------
> From: Dr. Ed Edmondson, Jr. Ph.D. <.....DreaejrphdKILLspamspam.....AOL.COM>
> To: EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU
> Subject: PIC_k You Brains
> Date: Thursday, October 08, 1998 9:52 PM
>
> I am really glad to see that all you picsters are so easily amused :-)).
> Technical people with a good sense of humor are hard to find.
>
> What I need to do is just PIC your brains a little.  I have all the
hardware,
> software and books to learn what to do with these PIC devices.  What I
need is
> a little bit of direction.  I am wanting to build a model rocket launcher
for
> a friend who has an asthmatic son.  I have seen some simple designs but
tend
> to lean towards the flair for bells and whistles.  So what I will have a
very
> I/O intensive little PIC.
>
> I want to use 10 LED's for the launch sequence (10, 9, 8, 7, ....2, 1,
L).
> These LED's will count down in sequence with the last LED "L" flashing at
> about 1-2 Hz at launch.  I want to use a piezo alarm to sound a launch
warning
> for the last 4 counts (LED's 4, 3, 2, 1, L).  Then there would be a dual
> RED/GREEN LED for the Fuze continuity check and a button for this test
(maybe
> it could be automated).  Then we have a flashing (1-2 Hz) red LED to
indicate
> the countdown has been halted due to emergency and a button to activate
this
> feature.  There is also a flashing yellow LED (1-2 Hz) to indicate a
temporary
> hold on the countdown sequence and the button to hold and restart the
> countdown.  Two buttons for on and off and a green LED to indicate power
"ON."
>
> I also want a master reset button (Must be held in for 5 -10 seconds) to
reset
> the whole system to a known state and disable the launch circuit.  I am
> planning on using a key switch for the master interlock on the launch
circuit.
> This and maybe using a SSR to isolate the launch and Fuzing circuit will
> enhance the safety issue.  I want the unit to also go "To Sleep" after 5
or 10
> minutes of inactivity.  Pressing any key would reawaken the system in the
> state it was in prior to "Sleep."
>
> Finally it would be great to have some form of battery condition
indicators.
> Maybe a small LCD voltmeter to measure battery voltage or current.  Maybe
a
> battery gas gauge like Benchmarq sells for high priced power tools.
Maybe use
> the display for a clock too?  Want to be able to use alkaline or
rechargeable
> batteries to power the thing.  It would be great if it could be charged
from
> an auto cigarette lighter!!
>
> What I need is suggestions on  what PIC  might really fit the bill here.
> There is a lot of I/O, a watch dog timer, maybe an A/D, should be able to
> drive LED's, an SSR, a piezo audio indicator, determine battery condition
and
> charge state.  And much more.
>
> With all these bells and whistles this asthmatic young teen could have
the
> ABSOLUTE neatest model rocket launcher at the contests.  This is his only
form
> of recreation due to his exacerbated condition.
>
> What I will get out of this journey, in addition to his smiles, is the
> knowledge earned from getting this thing designed and built.  I have
MPLAB on
> a Compaq Presario 1610 and a PIC Start Plus Programmer.  I have all the
PIC
> books written by anyone I could find.  I have a free source for the PIC
chips.
> What I need is direction and suggestions along the way.
>
> Want to help??  The only real concern is SAFETY to prevent an accidental
> launch which might cause an injury.  This can be avoided with some old
> fashioned design criteria and common sense.  I have until December 24th
to get
> this done.  Any direction and comments would be greatly appreciated by
the
> recipient and myself.
>
> Ed

1998\10\09@132652 by John Payson

flavicon
face
part 0 919 bytes
First of all, I think that rather than spending oodles of effort to
make the PIC foolproof it's probably better to simply have hardware
outside the PIC to prevent launch in unsafe conditions.  The simplest
way to do this would be to have a "deadman" switch for the launch
current in series with the igniter: for the countdown to proceed the
switch must be held pressed; if the switch isn't pressed the PIC is
completely unable to launch the rocket no matter how it malfunctions.

Since nobody should be pressing the switch any time the launch pad is
not safe, nothing in the operation of the PIC should be able to pose
any hazard.  If the PIC malfunctions it may cause the rocket to launch
sooner after the contact closure than it would otherwise, but if any
sort of reasonable launchpad safety precautions are taken (e.g. don't
push the button while someone's at the launchpad) that shouldn't be a
problem.

1998\10\09@185012 by Mark Willis

flavicon
face
A safety tip I'll add;  Shorting the firing leads except when launch
is imminent isn't a bad idea.

 Also: You can use a pair of big 3PDT switches, wired with an
appropriate flashlight bulb (or buzzer) and a resistor, so that in safe
mode, the input wires are across the bulb/buzzer, and the output wires
are connected together, through that resistor, to reduce any chance of
static or induced RF currents;  In "Fire" mode, it's just a
straight-through connection from the controls to the launch pad.

 Put one or even two of these in series (Set one 10 feet away from the
control station, one 10 feet from the rocket launchpad) is an safety
trick that I like (The 1k resistor can be a short, I've heard arguments
re: RF transmissions as to which is safer, but not kept up on that;
Twisted pair wire isn't a bad idea if you do use a short.  Probably
pretty safe either way, so long as your wires are kept close together!)

 As you walk down range, with safety key in your hand, you flip the one
& then the other safety to "Safe" and then continue.  Hard to get an
accidental launch this way!  Then as you walk back to the launch
console, you flip each to "Fire" as you pass.  AGAIN, do not flip the
circuit to "Fire" if the light bulb there is lit or the buzzer's
buzzing, as that's a really bad sign <G>

 I sketched this for a guy who had a blasting permit and had some idiot
handle his blasting box while he was putting in 30 pounds or so of ANFO
explosives to blow a big stump; His has LOUD buzzers so he knows when to
panic <G>  It's not a bad design for model rocketry; maybe a little
over-paranoid to use two, but one of these set to "Safe", 10 feet away
from a Multi-F engine cluster would make ME for one a lot less paranoid
about sticking my face in close to examine the ni-chrome ignitor
connections!  Safety console keys can be faked, I value my eyes.  (I
always used a pre-soldered rig with a paper clip loop etc. for even
3-C-engine clusters, less mis-fires that way.  Just 2 connections &
you're set.)

 Mark, mwillisspamspam_OUTnwlink.com

Dr. Ed Edmondson, Jr. Ph.D. wrote:
>
> I am really glad to see that all you picsters are so easily amused :-)).
> Technical people with a good sense of humor are hard to find.
>
> <snipped>

1998\10\09@195227 by James Cameron

flavicon
face
Mark Willis wrote:
> A safety tip I'll add;  Shorting the firing leads except when launch
> is imminent isn't a bad idea.

Assuming of course that you have used twisted pair all the way from the
point of short to the fuse, and you are certain there are no large
sources of EMF around.

I'd heard that explosives experts do _not_ short the cable at the end
they are rolling out, because that creates a loop circuit in which any
radio energy will just _have_ the be consumed by the detonator.

Just rumour.  I'm not qualified to advise on this.

--
James Cameron                                    (@spam@cameronKILLspamspamstl.dec.com)
Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800

1998\10\09@201758 by g.daniel.invent.design

flavicon
face
Morgan Olsson wrote:
>
> Ruben Joensson wrote:
>
> -big snip of a very thorough safety strategy-
>
> >At power up the integrity of the program should be checked by some
> >sort of checksum test of the EPROM (can't be done in a PIC, use a SCENIX).
>
Morgan,
PIC 16C715 has integral checksum fail reset built in to prog memory.
(adds that litle extra time to coding the down loader)
regards,
Graham Daniel,
Electronic Product Enhancements.

1998\10\10@222709 by Nicholas Irias

flavicon
face
I think any recommendation regarding missile safety is incomplete if we dont
also recommend dual launch switches, located at least 6 feet apart, that
must be pressed simultaneously.  That way, a single crazed rocketeer cant
launch your rocket.

1998\10\11@015119 by Dr. Ed Edmondson, Jr. Ph.D.

picon face
Ruben:

Thank you very much for the contribution on the safety mechanism for fuzing
and accident prevention.  Since these PIC's are so very inexpensive the
thoughts you suggested are really not far out of the realm of consideration.
I do see where it might take a lot of program development.  Would you use
something like I2C to communicate between the two processors?  Or is there a
simpler or better method for two PIC's to cross communicate with one another?

Ed

1998\10\11@020401 by Dr. Ed Edmondson, Jr. Ph.D.

picon face
Paul,

If you use LED displays why not just use a backlit LCD display.  The back
light for the late evenings?  The LCD would remove the need for a hood over
the display and the washout effect of the sun light.  The display could even
be a smart module available from Dontronics or Wirz Electronics.

Probably not as impressive as a lot of LED's but certainly overcomes the
problem of wash out.  If I used LED's I was going to use the newer low current
high output types.  I was going to have them in a fluted polycarbonate clear
lens assembly extending from the front panel about 0.250."

The display idea might be more manageable because of the ability to multiplex
the data and signal lines with the control switched and buttons.  I was going
to use a keypad and overlay for these functions.  It may be more coding and
software since you might want to toggle "ON - OFF" with one button.  Have
another as a "Hold - Resume" count switch?

Comments??

Ed

1998\10\11@020816 by Dr. Ed Edmondson, Jr. Ph.D.

picon face
James,

Where do I find this RISK document you have referenced?

Ed

1998\10\11@022453 by Dr. Ed Edmondson, Jr. Ph.D.

picon face
Morgan,

Your input is really great.  What do you think about the saga of discrete
LED's Vs LED or LCD displays?  I was thinking LED's for effect but there might
be a washout problem with the sunlight.

What about using opto isolators to isolate the firing link.  I built a very
simple launcher for my son about two years ago.  It used an FET and large
capacitor to ignite the fuze.  At the end of the countdown the counter turned
on the FET and dumped 6VDC and the charge from the capacitor into the fuze.
The wire shipped with the ESTES (the rocket kit, engine and fuze manufacturer)
is nothing more than gray zip cord (2 conductors) like they use to wire CHEAP
car stereo speakers with (approximately 22 gauge).  They supply 25 feet with
small clips on the ends.  The fuzes are extremely low resistance wire with an
ignitor substance deposited on the wire.  The fuze is only about 3" long.  The
primary fuze failure mode is not getting enough of a current pulse to the
fuse, hence the 2,000 plus uF capacitor hanging out there.

I am sure this will bring out a few other questions.  How about a clever way
to detect fuze continuity without igniting the fuze?  Or maybe, using a
circuit to charge a few caps and dump the charge on launch.

Ed

1998\10\11@022913 by Dr. Ed Edmondson, Jr. Ph.D.

picon face
Justin,

Your suggestion is duly noted.  Since I was in the Bells and Whistles mode for
the teen users age group that PIC would definitely have room for more
features.  Maybe even >> How about launching several (2 -6) rockets in
sequence.  The kids in the clubs do this sometimes. Like all launch at once or
in quick sequence.  Hmmm??

Ed

1998\10\11@023042 by James Cameron

flavicon
face
G'day Doc,

Dr. Ed Edmondson, Jr. Ph.D. wrote:
> Where do I find this RISK document you have referenced?

On the web at the URL http://catless.ncl.ac.uk/Risks or via USENET news
at news:comp.risks

Risks is a moderated discussion forum for issues relating to risks to
the public from computer systems, of all sorts.

It is fascinating reading, and well worth keeping up to date with, or
scanning if an issue is personally affecting me.  There is post-accident
review discussion and topical events.

--
James Cameron                                    (KILLspamcameronKILLspamspamstl.dec.com)
Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800

1998\10\11@023507 by Dr. Ed Edmondson, Jr. Ph.D.

picon face
Well, Mr. Supercat.....

They say KISS.  This might be the best and simplest safety idea yet.  Since
the rocket engines are only moderately dangerous.  I have never seen one
explode but the misfire and potential of being burned is more serious.

Anyone ever see one of the engines explode?  Look at some of the other
comments I have posted today and see what you think?  One main item is LED's
Vs Digital displays?

Thanks,
Ed

1998\10\11@024546 by Dr. Ed Edmondson, Jr. Ph.D.

picon face
Russell,

These are really great suggestions.  The reason for the PIC's is that I
already have a metric ton :-) of PIC related stuff.  I have two Picstart
Pluses, Microchips MP LAB software (the latest and greatest),  almost all of
Dontronics' SimmStik stuff, all kinds of LCD displays and nearly every thing
else in the way of parts and programmers.

I just need to get this thing designed (That is where your comments and
suggestions come into play), prototyped and built and delivered.  I plan on
getting the CCS C Compiler later this year.  Of course I realize the task
ahead of me since I have never designed any embedded (PIC or otherwise)
system.

Ed

1998\10\11@033019 by William Chops Westfield

face picon face
tick, tick, tick....

Come on people.  Safety design techniques applicable to space rated firing
systems for the Space Shuttle main engines, or blasting equipment that will
be used to detonate tons of explosives are NOT necessary for a model rocket
launcher (and indeed are not used in computer controllers for the
pyrotechnics industry, either.)  Most of your safety comes from more
common-sense techniques like not making the computer live while anyone is
nearby.

If I wanted to make a fancy countdown gadget for model rocketry, I'd put a
big pushbutton switch in series with the ignitor.  Then I'd have the circuit
send a small test current that simultaneously tested continuity, AND
actiavted the "countdown sequence."  So, press the button and hold for 5 to
10 seconds, and lights blink, sirens wail, and eventually the model
launches.  Want to abort the launh?  Let go of the push button and detect
that as well - if there's a failure and the software keeps counting down,
it's no big deal cause there's no longer a circuit for ignition current to
flow through anyway.  A additoinal keyswitch in the same series circuit
provides the positive interlock required by the safety code and appropriate
for the activity.

By the way, the way I read the model rocket safety code, they're pretty big
and an AUDIABLE countdown (at least 5 seconds.)  Around here (paranoid Ca,
most of the club launch system beep a piezo buzzer whenever the system is
armed (by LCO via footswitch), in addition to the countdown.  Want to add
bells and whistles?  This is a good place for electronic voice synthesis.
The other thing I'd add to be paranoid is some sort of sensort AT the clip
end of the system that detects voltage there (ie someone forgot to disarm
the keyswitch AND someone's leaning on the button.)

BillW

1998\10\11@033025 by William Chops Westfield

face picon face
Oh yeah.  Even "really bright" LEDs look pretty pitiful in bright sunlight.
Another good excuse for the voice add-on...

BillW

1998\10\11@033850 by William Chops Westfield

face picon face
   Anyone ever see one of the engines explode?  Look at some of the other
   comments I have posted today and see what you think?

You mean "Have you ever seen an Estes rocket motor explode in a manner
that would propose significant risk to someone standing a couple feet
away" ?

No, I don't think so.

Typical failure mode is that the black powder slug will detach from the
casing and fly out the front of the rocket (having torched the internals
pretty nicely.)  The (now discontinued) Estes Black powder E motors were
pretty famous for this.  Second common failure mode is to blow the nozzle
out.  Neither is a MAJOR hazard if you're beside the rocket instead of in
front or behind it.

I've heard that some of the larger motors (and not from Estes) have blown up
in a more spectacular (and dangerous) fashion...

BillW

1998\10\11@140200 by Dr. Ed Edmondson, Jr. Ph.D.

picon face
Bill:

Into model rocketry are we?  Looks like you have some knowledge of these
little Estes toys.  Some things which should be simple in theory always tend
to end up like an open can of worms.  Once opened, you are never able to
return the worms to the original can!

A rocket launcher for Estes type model rockets was the original idea.  All
five of my teenage boy and girls had to build and launch one of these as a
class project while in middle school.  Two of my boys still are interested in
these somewhat.

It was an asthmatic friend of my son who got me interested in building a
"better" or at least a neater one.  The unit Estes sells is great the first
few times (launches) but if you aren't rich enough to replace the 4 AA cells
after six to eight launches you will go through a lot of fuzes.  I built a
better launcher a couple of years ago and hung a big cap across the firing
line and that seemed to help a lot.  When the FET turned on it dumped the 6
volts and cap charge into the fuze.  We had a lot less misfires after this
little mod.

So now it appears we have a small unit constrained by the size of the
batteries used to power it.  An LCD display instead of LED's due to washout by
the sun light.  This display can also be used to display the battery status,
time or what ever.  It could also be back lit for late evening launches.  The
contrast and back light controlled by  digital pots?  I have an LCD
development kit from Wirz electronics.

 The keypad a 4 x 6 or 5 x 7 scanned matrix?  I have several friends who work
for companies who make membrane keypads and overlays.  A couple have indicated
they could make me up a couple if I can tell them what I want.  They can even
include the polarizer for the LCD display if that is the route to go.  I can
use a small mass produced plastic enclosure for the unit itself.

Has anyone used any battery charging / indication devices like BenchMarq make
for portable applications?  I have one built into my laptop battery pack.
This might be the way to go as far as monitoring battery status.  These can be
interfaced to a PIC or other processor.  I was looking at their web site and
they have a lot of neat items.

I still am looking for a clever way to dump the launch pulse down the wires to
the fuze?  I was thinking that using an opto isolator and high current FET
might work.  It would isolate the main circuitry from the firing circuit.  A
key interlock switch could be used to prevent accidental launch if the program
was set up as a one shot type of circuit.  If you don't return the key to the
off position after launch the unit will not launch again until reset.  This
could be coupled with the proverbial "Dead Man's" switch so the unit could not
be activated and then laid down to go check on something else or the rocket.
NO key turn + NO switch closure = NO Launch ability.

So now we are back to which PIC to use?  10 lines (??) for the key pad, a line
for the audio indicator, several lines for the LCD display, several lines for
the battery monitor, a line for the key switch, a line for the Dead Man's
switch, and ect.  That to me seems to be a lot of I/O?  A watch dog timer to
recycle the unit to the start up state if left unattended for "x" minutes.

The more I look the more I realize why embedded designers make so much money?
It is a never ending cycle.  Isn't it??

Regards,
Ed

1998\10\11@143828 by Mark Willis

flavicon
face
Dr. Ed Edmondson, Jr. Ph.D. wrote:
>
> <snipped>
>
> So now we are back to which PIC to use?  10 lines (??) for the key pad, a line
> for the audio indicator, several lines for the LCD display, several lines for
> the battery monitor, a line for the key switch, a line for the Dead Man's
> switch, and ect.  That to me seems to be a lot of I/O?  A watch dog timer to
> recycle the unit to the start up state if left unattended for "x" minutes.
>
> The more I look the more I realize why embedded designers make so much money?
> It is a never ending cycle.  Isn't it??
>
> Regards,
> Ed

 Good ideas on lots of alternate ways to make this work (Laptop
batteries aren't necessarily ideal though - this is a high current,
intermittent application, maybe a deep cycle "trolling" type battery
would be cheaper & easier as a power source?  And could be charged at
home on a normal charger.  Or just borrow power from someone's car <G>)
Or charge a low ESR cap with whatever battery (you do have at least the
length of the countdown to charge the firing cap., I've thought of
keeping that cap drained, except when the deadman switch is held down &
the firing key in "Armed"...)

 You can cut the number of I/O lines down by increasing parts count, by
using a shift register or a Johnson counter you can scan several rows or
columns of a keypad with two (or even one with a few more parts!) I/O
line.  (Your choices here <G>  Could use 6 lines to the shifter/johnson
counter, and 4 to the pic, to just use 5 or 6 total PIC I/O lines for
the keyboard, that cuts things down somewhat - at the cost of one more
IC.)

 Think of having a wind indicator near this launch pad, also (Robin has
asthma, I wouldn't want her downwind from a launch plume!  Black powder
smoke, would not be a good inhalant...)

 (A spare Maxair inhaler taped to the launch console?  It's an idea...
Robin LOVES that stuff, she can give it to herself - wonderful!)

 Mark

1998\10\11@145730 by shadedemon

picon face
Dr. Ed Edmondson, Jr. Ph.D. wrote:
> It was an asthmatic friend of my son who got me interested in building a
> "better" or at least a neater one.  The unit Estes sells is great the first
> few times (launches) but if you aren't rich enough to replace the 4 AA cells

 While I see the point of this being his only recreation,
no matter how nice you make the unit, it's function will be
the same and become routine almost instantly.  I can't help
but feel it would be a better service to him to make a good
straightforward launch controller and then concentrate on a
good data logging system, as several others have discussed
in the past.  Don't get me wrong, most of the stuff you're
proposing isn't that hard really, so go at it, but bells and
whistles are just that, and don't age very well.  The data
logging and science behind it will be a much more sustained
interest.  Even more than that, if he's over the age of 6 or
so, and especially if 10 or more, you should hook him up
with a simple pic programmer and some 16F84s and simple demo
boards and get him on the list.  Even more sustained
interest, and you'd be amazed at what a kid can learn and
enjoy, more so if they don't have other outlets.  Heck I
know a little girl who knows more about windows and what
goes on behind it than most adults, and she is only 7..

This
> could be coupled with the proverbial "Dead Man's" switch so the unit could not
> be activated and then laid down to go check on something else or the rocket.

 "Laid down" is the key idea.  Two or three small mercury
switches in series arranged to give only a medium window
where all of them make when the controller is held
diagonally or vertically is the way to go..  Just make it
broad enough to not have misfires but narrow enough to not
be able to lay it down and have any chance of both making.
And sample it with a pic pin often enough and ignore no
makes for <1/4 second or so, so a shaky hand doesn't mess
things up..
Alan

1998\10\11@150107 by Dave VanHorn

flavicon
face
>So now it appears we have a small unit constrained by the size of the
>batteries used to power it.  An LCD display instead of LED's due to
washout by
>the sun light.  This display can also be used to display the battery
status,
>time or what ever.  It could also be back lit for late evening
launches.  The
>contrast and back light controlled by  digital pots?  I have an LCD
>development kit from Wirz electronics.


Are you aware of rec.model.rockets?  Lots of rocket folks there.

My best suggestion would be to place the ignition battery at the pad,
and use a relay to close that circuit.
Continuity can be indicated by running a couple mA through the firing
circuit. You only have to worry about current when you start using
flashbulbs and thermalite.

A local switch at the pad gives you continuity/fire control. In the
open position, the safety switch and the firing relay are shunted by
the continuity resistance, plus an indicator. I use a superbright
green LED.
When you are ready, close the safety switch and walk back to the
controller.  With this arrangement, nothing you do at the controller
matters, until the safety switch is closed. You could remote that
switch to say 10' from the pad, so that even if everything goes wrong,
you're at a safe distance when it ignites.

For ABCDE engines, they recommend 10' of wire, but since I also fly
G,H,I motors, I use 100'  Even with the smaller engines, being farther
away from the pad makes it easier to track them.  Your asthmatic could
probably use the extra distance as well.   Since you are using a relay
at the pad, the extra wire length makes no difference electrically.  I
use that 100' roll-up telephone cable that Radio-Shack carries.

The controller can now be as fancy as you like, and you don't have to
use "life-support" precautions in building it.  I would though,
include a mechanical key switch (not those ones from PC cabinets) in
series with the firing circuit.

With the four conductors available in the phone cable, you can carry
ground, power, fire and continuity between the relay box and the
controller.

A 12V gell cell, even as small as 1AH, will fire modroc igniters just
fine.

For deluxe brownie points, add plug-in clipsets, so you can replace
them with a spare, or with different ends for "copperhead' igniters.

1998\10\11@150311 by Dave VanHorn

flavicon
face
Sorry, that was rec.models.rockets  :)

1998\10\11@155602 by Mark Willis

flavicon
face
Wanted to also mention:  I've seen more than one good launchpad design
where the battery is used to weight the launchpad, with a straight relay
in the launch base to fire the rocket (Put some metal sheet under the
rocket exhaust <G>) - then the wires to the control head do not have to
be heavy duty wire.  Putting the battery 5-10 feet from the launchpad &
a safety switch inline at that battery, might be good (put the countdown
display atop the battery? <G>)  Short heavy-gauge wires for high
currents is good <G>  Switch the relay (SSR?) current not the entire
current...

 Also, for fuze continuity (I always call them ignitors to be clearer)
I can say that an LED in series with a nice resistor works pretty well
(15-20 mA is nowhere near enough to touch off an ignitor.)  You could
wire these across the fire switch, or the relay contacts if you use a
remote relay to fire the ignitor.  Just be careful here to put the
resistor in the relay-end box, as a heavy short across -this- wire could
otherwise cause an accidental launch!  An optoisolator for remote
reading of continuity, isn't a bad idea at all...

 (Socket those optoisolators, too, in most designs, folks.  They *do*
fail, not here so much as in high-spike situations, where optoisolation
is necessary, and it's annoying to have to de-solder in the field.
Pulling a chip from a  socket & replacing it, OTOH, isn't half bad <G>)

 Mark, RemoveMEmwillisTakeThisOuTspamnwlink.com

Dr. Ed Edmondson, Jr. Ph.D. wrote:
>
> <snipped>
>
> The wire shipped with the ESTES (the rocket kit, engine and fuze manufacturer)
> is nothing more than gray zip cord (2 conductors) like they use to wire CHEAP
> <snipped>

1998\10\11@160020 by Mark Willis

flavicon
face
Dr. Ed Edmondson, Jr. Ph.D. wrote:
>
> <snipped>
> Anyone ever see one of the engines explode?  Look at some of the other
> comments I have posted today and see what you think?  One main item is LED's
> Vs Digital displays?
>
> Thanks,
> Ed

 One, once.  It may well have been tampered with, knowing the engine's
owner.  (I'd say 95% probability.)  Far more failures to ignite with a
perfectly good ignitor (I'm guessing that they coat the engines for so
much safety that they're *really* tough to ignite, to make sure they're
safe.)  Used to love this sport, got too busy to play lately!

 I've seen worse problems by far from model aircraft engines (more
likelihood of burns & "prop-chop" etc.)

 Mark, spamBeGonemwillisspamBeGonespamnwlink.com

1998\10\11@180309 by Alan Vogel

flavicon
face
How about placing a small filament lamp in series with the ignitor (mounted
in the hand-held firing box).  The voltage drop across the lamp prevents the
fuse from igniting until a momentary switch is pushed that shorts the bulb.

Alan
-----Original Message-----
From: Dr. Ed Edmondson, Jr. Ph.D. <TakeThisOuTDreaejrphdEraseMEspamspam_OUTAOL.COM>
To: RemoveMEPICLISTspamTakeThisOuTMITVMA.MIT.EDU <PICLISTEraseMEspam.....MITVMA.MIT.EDU>
Date: Saturday, October 10, 1998 11:32 PM
Subject: Re: PIC_k You Brains


[snip]
>I am sure this will bring out a few other questions.  How about a clever
way
>to detect fuze continuity without igniting the fuze?  Or maybe, using a
>circuit to charge a few caps and dump the charge on launch.
>
>Ed
>

1998\10\11@193417 by Mark A Moss

picon face
There are three "potentially" dangerous things I have seen small model
rockets do.  First, poorly designed rockets have had the tendency to fly
in unpredictable directions: up, down, even parallel to the ground.
There is nothing the launch device can do to prevent this.  Second,
engines that are not properly secured have fallen out during flight.
Again, there is nothing that the launch device can do to prevent this.
The last hazard that I have seen is when a rocket engine has ignited when
someone is too close to the pad.  Generally, this is because that they
are not following safety procedures.

Most model rocket launchers have two switches and a light bulb.  One
switch is closed by inserting a "key" into a jack in the launcher.  This
completes the circuit and allows a low current to flow through the light
bulb and the ignitor.  This give a visual go/no-go indication of the
ignitor.  The second switch is a push button in parallel with the lamp.
Pushing this buttons shorts the lamp and allows a large current (about
3A) to light the ignitor.  The large current that is required to heat the
ignitor to its ignition point probably nulls the possibility that a
strong RF field could ignite the rocket.

What I would do is this.  In addition to all the bells and whistles, I
would have the PIC drive two relays.  One would be placed in series with
the "key" switch.  This way, no voltage or current would exist at the
clips until the PIC wanted it to.  The second relay would be placed in
series with the push button switch.  With this setup, the only way the
rocket would launch is if both relays were closed, the key was in, and
the button was being pushed.   As long as proper safety procedures were
followed, it would be difficult to have any problems with unexpected
launches.


Mark Moss
Amateur Radio Operator, Technician, and General Tinkerer

___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
or call Juno at (800) 654-JUNO [654-5866]

1998\10\11@193432 by Dave VanHorn

flavicon
face
>How about placing a small filament lamp in series with the ignitor
(mounted
>in the hand-held firing box).  The voltage drop across the lamp
prevents the
>fuse from igniting until a momentary switch is pushed that shorts the
bulb.


This is safe for estes and copperheads, but I'm not sure where it
falls with other types. Lamp resistance is somewhat variable anyway.
An LED and resistor makes a much more predictable choice.

1998\10\12@030324 by ruben

flavicon
face
Hello Ed.

> Ruben:
>
> Thank you very much for the contribution on the safety mechanism for fuzing
> and accident prevention.  Since these PIC's are so very inexpensive the
> thoughts you suggested are really not far out of the realm of consideration.
> I do see where it might take a lot of program development.  Would you use
> something like I2C to communicate between the two processors?  Or is there a
> simpler or better method for two PIC's to cross communicate with one another?
>
> Ed

When I have done this I have just used two I/O lines, one clock and the other
data. The program cycle of both processors looks something like this:

1. Synch. Synchronize channel A with channel B (use clock or data line for
this) so that the timing between the two chanels are known.

2. Sample. Set up I/O lines and sample inputs. Save info for eval stage.

3. Eval. Evaluate sampled inputs and take appropriate actions. Sicne each
cycle generaly takes a couple of milli seconds it's easy to debounce inputs.

4. Communication. Channel B waits for info from channel A by reading a
predefined number of data bits on the falling edge of clock. Channel A then
waits for info from channel B. Since both channels are in synch and
communication only takes place in known timeslices and the number of data
bits transfered is low this works fine. The channel that sends controls the
communication I/O lines, the other channel sets these to inputs. To minimize
data error every bit is sent as two bits which can be either '01' or '10'. Any
other value is an illegal combination.

5. Activating safety outputs if they should be on.

6. Memory tests and other processor testing.

7. Go back to top.

Another thing about the safety outputs. To minimize the risk of the output being
activated if the program malfunctions (due to EEPROM failure, brownout, EMC
etc) is to never write to the portbit directly (eg bsf portx,safteyoutput) but
instead calculate the adress and bit of the output during the program cycle. For
instance at top of the cycle clear a register used for calculating the adress an
d
at appropriate stages in the program flow increment this register. If the progra
m
works Ok the register should contain a known value when the safety output
should be set (or toggled) manipulate this known value with a constant if needed
to get the desired value, extract the bit information and put the calculated por
t
adress in FSR and activate the output by indirect adressing. Make it even safer
and use two registers for calculating the portbit - use a cycle counter and at t
he
top of the cycle load the adress calculation register with different values for
different values of the cycle counter. The whole meaning of this is not to have
any code that directly manipulates the safety output.

As You have seen on this list though, the safety issues for this project could
probably be keept outside the electronics and processors alltogether by
disabling it (no power) with key switches or something when no launch should
be done.


--------------------------------
Ruben Jvnsson
EraseMErubenspam2.sbbs.se
--------------------------------

1998\10\12@085756 by Peter L. Peres

picon face
On Sun, 11 Oct 1998, Dr. Ed Edmondson, Jr. Ph.D. wrote:

> little Estes toys.  Some things which should be simple in theory always tend
> to end up like an open can of worms.  Once opened, you are never able to
> return the worms to the original can!

How nice that some people notice this early ;)

> I still am looking for a clever way to dump the launch pulse down the wires to
> the fuze?  I was thinking that using an opto isolator and high current FET
> might work.  It would isolate the main circuitry from the firing circuit.  A

Just thought I'd mention some things books say about drivers for such,
ahem, things:

- The battery voltage is to be too low to fire the fuse if connected
directly to it, for any length of time.

- The output to the fuse should be AC coupled (transformer secondary) and
matched to the line with suitable resistors.

- The a.c. generating device should be run off a charge storage device
(capacitors) charged at a voltage higher than the battery voltage.

- The a.c. generating device should not be able to operate from un-boosted
battery voltage.

- The firing should occur after a large amount of cycles in the a.c.
generating device (i.e. a few cycles are not enough).

- The previous point opens the possibility of precision timed firing
sequences (computer in each fuze counts pulses before firing).

- None of this is new, the magneto detonators used way back before WW2 all
worked like this, excepting the part on batteries (used none) and the part
on precision firing (?).

There is much more. This I've culled from mining & prospection explosive
handling textbooks. They should be available in a university bookstore.
Also describes fuzes and other interesting data, such as safety distances
and procedures. Compulsory reading for rocket people imho. <g>

hope this helps,

Peter

1998\10\12@112041 by Tom Handley

picon face
  Peter, this really does'nt apply to model rockets that are available here.
The engines are solid propellant manufactured to very strict standards and are
very similar to the Space Shuttle SRBs, etc. I can understand why such a hobby
is not available in Israel. In this country, you can go to most any hobby shop
and buy kits, parts to build rockets, and engines. Still, if your country would
allow the hobby under some kind of control (ie: engine purchase for educators),
it can be very educational, fun, and safe.

  I'm working on a response to Ed but, as is typical of this group, there has
already been many excellent replys. I have kind of a unique perspective as I
started back in the 60's with Estes rockets and engines. Back then they still
used fuzes that you lit with a match... Then the wire ignitor. Now days they
coat the ignitor with a material that improves the reliability of ignition.
I love this topic and this message is the first of a `flood' of messages that
I want to discuss from Ed's application to PIC-based payloads ;-)

  - Tom

At 02:24 PM 10/12/98 +0000, Peter L. Peres wrote:
>On Sun, 11 Oct 1998, Dr. Ed Edmondson, Jr. Ph.D. wrote:
>
>> little Estes toys.  Some things which should be simple in theory always tend
>> to end up like an open can of worms.  Once opened, you are never able to
>> return the worms to the original can!
>
>How nice that some people notice this early ;)
>
>> I still am looking for a clever way to dump the launch pulse down the
wires to
{Quote hidden}

1998\10\12@120643 by Peter L. Peres

picon face
On Mon, 12 Oct 1998, Tom Handley wrote:

>    Peter, this really does'nt apply to model rockets that are available here.
> The engines are solid propellant manufactured to very strict standards and are
> very similar to the Space Shuttle SRBs, etc. I can understand why such a hobby
                     ^^^^^^^^^^^^^^^^^

Ouch. I get the point but that was not such a good example imho. If the
failure rate of model rocket engines would equal the SRBs that hobby would
have disappeared a long time ago.

> allow the hobby under some kind of control (ie: engine purchase for
> educators), it can be very educational, fun, and safe.

I agree. But...

> started back in the 60's with Estes rockets and engines. Back then they still
> used fuzes that you lit with a match... Then the wire ignitor. Now days they
> coat the ignitor with a material that improves the reliability of ignition.

Actually I did not SAY that I did not DO such things. Small lightbulbs
with the glass removed and embedded in alcohool-wetted black powder make
excellent ignitors in my memory (after drying)... They are fired with
about 4 * over-voltage and reach the melting temperature of Tungsten, plus
produce a small arc when they burn through. Just like modern fuze caps ;)
Don't try this at home please, getting the variables right involves some
amount of destruction.

Peter

1998\10\12@135654 by paulb

flavicon
face
Dr. Ed Edmondson, Jr. Ph.D. wrote:

> The contrast and back light controlled by  digital pots?

 No way!  These are controlled by PWM outputs from the PIC.

> I was thinking that using an opto isolator and high current FET might
> work.

 Why do people have this fetish for optocouplers?  Reliability. let
alone costs, dictates you only want one battery if at all possible.

> So now we are back to which PIC to use?  10 lines (??) for the key
> pad,

 Ten lines?  What waste!  I presume your reference to 7 by 5 or 35
buttons suggests an almnost full alpha(-numeric) keypad, though I can't
for the life of me figure why.  At worst, use a CMOS 10-output counter
to strobe ten rows and sense three or four inputs.  The counter only
needs reset and clock, which can be multiplexed with other functions.

 I think we can easily restrict this to the 16F84!

> several lines for the LCD display,

 Six or seven, all bar one multiplexed with other things.

> A watch dog timer to recycle the unit to the start up state if left
> unattended for "x" minutes.

 Eh?  This is a software feature surely?

> The more I look the more I realize why embedded designers make so much
> money?

 Well, they *should*!
--
 Cheers,
       Paul B.

1998\10\15@065000 by Pavel Korensky

flavicon
face
At 07:06 10.10.1998 -0700, you wrote:
>I think any recommendation regarding missile safety is incomplete if we dont
>also recommend dual launch switches, located at least 6 feet apart, that
>must be pressed simultaneously.  That way, a single crazed rocketeer cant
>launch your rocket.
>

I thought that the talk was about hobby rocket models, not about the
trans-continental A or H missiles.
But seriously, if high safety is really necessary, maybe the control
circuit which will monitor the function of LEDs should be included. Once, I
designed the bomb countdown timer (for the police squad, not for the
terorists :-) and there was two LEDs green and red. When the timer was in
idle state, both LED was switched off. When the timer was in Ready state,
green LED was on. When timer was on Armed state, red LED was on. It was
necessary to include the test circuit which monitored the red LED current,
just to be sure that LED is not broken. It sounds funny, but during the
test phase, I met this condition once. Red LED suddenly died and I tought
that timer is in Ready state. Suddenly the relay clicked ....

PavelK

**************************************************************************
* Pavel KorenskyÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ *
* DATOR3 LAN Services spol. s r.o.ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ *
* Styblova 13, 140 00, Prague 4, Czech Republic      ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ *
*ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ *
* PGP Key fingerprint:Ê F3 E1 AE BC 34 18 CB A6Ê CC D0 DA 9E 79 03 41 D4 *
*ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ *
* SUMMA SCIENTIA - NIHIL SCIREÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ *
**************************************************************************

1998\10\15@140412 by William Chops Westfield

face picon face
The major safety concern with model rocketry and automatic launch equipment
is that model rocketry is currently safe enough to share "play space" with
other activities, given only peripheral awareness of the rocket launch.  If
Joe Schmoe's frisbe goes awry and he runs into the launch area during the
countdown, you must be able to abort the launch instantly.

Main causes of injuries during model rocket activities: tripping while
chasing rocket and not watching where feet are going, poking yourself on
the launch rod, falling while climbing trees to recover rocket, electrocution
while trying to recover rocket from power lines.  The number of people that
have been burned by rocket exhaust or hit and injured by flying rockets is
miniscule - lower than the number of kids killed playing little league
baseball...

BillW

1998\10\23@144459 by John Payson

flavicon
face
>>
Oh yeah.  Even "really bright" LEDs look pretty pitiful in bright sunlight.
Another good excuse for the voice add-on...
<<

If you can find them, "flip-mechanical" displays are excellent
in any light condition and generally have pretty reasonable
current requirements.  Not sure about surplus availability,
though--when new they probably cost a bundle.

Also, I go along 100% with much of what others have said re
safety: don't give launch authority to the PIC (except when
a button is being held down).  And then, of course, make sure
you clearly mark the thing and tell people never to push the
button if they're not expecting a launch.

Of course, some bozo will probably still manage to injure
himself by pusing the button when he doesn't think the thing
will really launch, but all too many bozos (even on occasion
police officers) pull the triggers on firearms and somehow
don't think they might fire ("I didn't know the gun was
loaded".)  Too bad so many people in this world have no clue
about how to use a modicum of safety-related common sense.




Attachment converted: wonderland:WINMAIL.DAT 2 (????/----) (0001BBDE)

1998\10\23@221358 by Mark Willis

flavicon
face
John Payson wrote:
> <snipped>
> Of course, some bozo will probably still manage to injure
> himself by pusing the button when he doesn't think the thing
> will really launch, but all too many bozos (even on occasion
> police officers) pull the triggers on firearms and somehow
> don't think they might fire ("I didn't know the gun was
> loaded".)  Too bad so many people in this world have no clue
> about how to use a modicum of safety-related common sense.

 From what a friend said about one police officer he knows who got to
buy himself a new TV due to an accidental discharge, it sounds like bad
habits cause "A.D.'s" - this police officer practiced dry firing with
his revolver properly unloaded for a time (which is good practice for
trigger control!) but then proceeded to, absolutely stupidly, go back to
his storage location, reload the revolver & then went back to the den to
try to continue to dry fire...

 This was, somewhat understandably, hard on the TV!  (Geraldo must've
been on?)  Stupidity/Bad habits hand in hand here...  Ack!  Where'd his
sanity go?!?

 Fortunately nothing damagable was in the line of fire besides the TV &
a wall, BUT...

 Always assume a rocket, firearm, car, wire, or whatever is live, and
potentially dangerous, unless you have really GOOD reason to believe
otherwise <G>

 Mark, RemoveMEmwillisEraseMEspamEraseMEnwlink.com

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...