Searching \ for '[PIC]: Use in a rocket altimeter' in subject line. ()
Help us get a faster server
FAQ page: massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'Use in a rocket altimeter'.

Exact match. Not showing close matches.
'[PIC]: Use in a rocket altimeter'
2000\12\30@182320 by

Hey all,

Right off, I'm a beginner to PICs. The only microcontroller programming I've
done before now has been with a Ti-83 graphing calculator, if that can be
considered uC programming, but I have written programs in C++ for computers.

That said, my first project using a PIC will be an altimeter for model
rockets. A friend of mine got into rocketry and mentioned wanting to know the
altitude of his rocket without expensive electronics and I said it could
probably be done with a PIC, a pressure sensor, and if he didn't want to mess
with wireless stuff, a memory chip to hold the data. I'd like to write this
in C, if possible, but will use assembly if I have to. Which free C compiler
out there would you recommend?

After exploring how to go about doing this, I have a pretty good idea on what
to use. The friend got ahold of a Motorola Mpx4115 pressure transducer from
his work and its datasheet (so simple, *I* might even be able to figure it
out!) and I found a site where a guy used one to build his own telemetry
system using a transmitter, which gave me insight on what techniques could be
used. Basically my circuit will take the analog output of the Mpx, and modify
the voltage using op-amps so that from a range of 101kPa to 69kPa (0-10000
feet) the output will vary from about 0-5v. This will go through an ADC, the
altitude will be calculated by the PIC, and this value put on a chip.

My questions: I want the ADC to be 12-bit. If I use the converter built into
some PICs, I'd have to use a Pic16C773 or 774 to get this resolution. Should
I bother buying one of these and trying to figure out how to program it or
should I use an external ADC with a 16f84 (or similar)? Also, would an EEPROM
be a good idea for storing the results in this application, or should I go
with something else? An important part- when I get the converted output into
the PIC, I still need to do some calculations. I figured out a good equation
that is accurate +/- 2.5ft from 0-10000ft, but uses long coefficients (the
equation is at the bottom). Can the PIC handle this well, and can it do it 8
to 16 times per second or should I have it simply save the raw ADC value to
be computed on the ground? Finally, does the general idea sound doable?

Thanks in advance and sorry for writing a long, rambling letter. I tend to go
into detail when I write.........

-Tony

F(x) = -.01400624739751 * P^3 + 5.4327443467593 * P^2 + -928.47534934054 * P
+ 52868.578588933
where X=altitude in feet and P = atmospheric pressure in kPa

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

The general idea is certainly doable, there was an article in CircuitCellar
some time ago about a similar project that used an acceleration sensor.
Gotcha: he got periodic misreadings, I think due to the current consumed by
his eeprom chip during writing (influences the AD, maybe due to bad wiring
or battery impedance or too small decoupling elco). Are you sure the change
in pressure due to the velocity (the moving air gives less pressure thing)
won't give you trouble? I guess yes, but not at the highest point in flight.
There are a few free C compilers around, browse the list. FAIK the HiTech is
for 16x84 only, but at least BKD is for all PIC but limited to 1K. But when
you just write the lowest pressure to eeprom you could easily stick with
MPASM (free) or my Jal compiler (equally free). For all beginers: stick to
FLASH pics, unless you absolutely have to use a non-flash. If you can live
with the physical size take a 16F877, otherwise a 16F84. And for the
calculatons: what good does it do te let the poor PIC do arithemetic when
you will use a PC anyway to read out the data? Just store the raw AD value
and let the PC handle the brainwork.
Wouter

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

At 12:49 AM 12/31/00 +0100, wouter van ooijen & floortje hanneman wrote:
>The general idea is certainly doable, there was an article in CircuitCellar
>some time ago about a similar project that used an acceleration sensor.
>Gotcha: he got periodic misreadings, I think due to the current consumed by
>his eeprom chip during writing (influences the AD, maybe due to bad wiring
>or battery impedance or too small decoupling elco). Are you sure the change
>in pressure due to the velocity (the moving air gives less pressure thing)
>won't give you trouble?

It certainly does, at burnout, or max V.
Accelerometer approach has it's problems too.

There's also a pressure spike around mach that can cause problems.
If you're just logging, it's not such a problem, but many designs detected
max altitude by indicated baro pressure, or zero acceleration (as opposed
to negative during coast phase) and got fooled.

Deploying a parachute at trans-sonic speeds is generally not a good idea.

--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

<<Wouter wrote:
The general idea is certainly doable, there was an article in CircuitCellar
some time ago about a similar project that used an acceleration sensor.
Gotcha: he got periodic misreadings, I think due to the current consumed by
his eeprom chip during writing (influences the AD, maybe due to bad wiring
or battery impedance or too small decoupling elco). Are you sure the change
in pressure due to the velocity (the moving air gives less pressure thing)
won't give you trouble? I guess yes, but not at the highest point in flight.

Dave wrote:
There's also a pressure spike around mach that can cause problems.
If you're just logging, it's not such a problem, but many designs detected
max altitude by indicated baro pressure, or zero acceleration (as opposed
to negative during coast phase) and got fooled.>>

I hadn't taken that into consideration. Do you think it would have affect the
data considerably? Considerably being +/- 15 feet at max alt. The spike at
mach I'd thought about, since my friend does intend to fire off a rocket that
busts mach before topping out above 3000ft. Possibly by installing an
accelerometer and comparing its data to the transducer's I could see where
problems lie in each one. The first few flights will have to be experiments
anyways.

<< There are a few free C compilers around, browse the list. FAIK the HiTech
is
for 16x84 only, but at least BKD is for all PIC but limited to 1K. But when
you just write the lowest pressure to eeprom you could easily stick with
MPASM (free) or my Jal compiler (equally free). For all beginers: stick to
FLASH pics, unless you absolutely have to use a non-flash. If you can live
with the physical size take a 16F877, otherwise a 16F84. And for the
calculatons: what good does it do te let the poor PIC do arithemetic when
you will use a PC anyway to read out the data? Just store the raw AD value
and let the PC handle the brainwork.>>

Thanks for the info. I had seen quite a few C compilers on the PIC beginners'
checklist but wasn't sure which one to use. If the HiTech is just for the
16x84 that's fine by me since that's all I'm using for now. I've been sure to
verify that when filling out an order form for PICs, I was getting the flash
vesion. On the next one I'll include a 16F877. As for arithmetic in the
computer, I think you're right. At first I figured since the PIC was probably
going to have little to do (read serial output from the ADC, send it to the
EEPROM) so why not have it do a few calculations. But the more I thought
about it, the more I realized it was just a waste of code and work for the
PIC. Not to mention the memory chip; straight output would take 12 bits each
reading, where-as computed data would take 14 bits for 0-10000 ft.

-Tony

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

>
>I hadn't taken that into consideration. Do you think it would have affect the
>data considerably?

Yes.

Still, as long as you're just logging, it won't be a problem.
Remember, you're not really reading altitude, you're reading air pressure
in the airframe. 'snot the same thing, except during parachute descent.

--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

<< >I hadn't taken that into consideration. Do you think it would have affect
the
>data considerably?

Yes.

Still, as long as you're just logging, it won't be a problem.
Remember, you're not really reading altitude, you're reading air pressure
in the airframe. 'snot the same thing, except during parachute descent. >>

Sure, I'm just logging the pressure. But the calculations are still going to
assume that the pressure is representative of the altitude at no speed. How
is that going to change it, since the point of the circuit is to find the
altitude throughout the flight?

-Tony

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

>
>Sure, I'm just logging the pressure. But the calculations are still going to
>assume that the pressure is representative of the altitude at no speed. How
>is that going to change it, since the point of the circuit is to find the
>altitude throughout the flight?

It depends entirely on where and how you vent the sensor to the outside.
It's not a simple relationship.
Check into rec.models.rockets, I'm sure someone there has the details.

--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

I've not been following this thread so forgive me if this has already been
posted....  I found this link, having a simple PIC based rocket altimeter
and other neat rocket projects...

http://www.tfs.net/~petek/projects.html

He uses a MPX4115 pressure sensor and also includes some op-amp signal
conditioning circuitry to increase the accuracy of the measurement. I plan
to build a similar circuit but with a 16F877, which has an on-board 12 bit
A/D converter.  Hope this is useful to you.

Freddie.

--- David VanHorn <dvanhornCEDAR.NET> wrote:
{Quote hidden}

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

On Sat, 30 Dec 2000, Tony Goetz wrote:

{Quote hidden}

Someone mentioned a while ago a very interesting idea about using a pair
of Hall effect sensors, mounted 180 degrees apart, to detect apogee when
the rocket flipped over.  The idea was that they would sense the Earth's
magnetic field and reverse their outputs when they passed through 90
degrees rotation.  I think it was something that someone was actually
using, not just thinking about, so you may want to search through the
archives on that one.  Seems to me you could use that to decide when to
read the altitude, since you should be at max altitude and minimum speed.

{Quote hidden}

I have used CC5X and currently use CCS C.  CCS will give you far fewer
hassles when trying to port to a different compiler.  I hear great things
about Hi-Tech, but can't justify \$800 for hobby use, so I stick with CCS.
It's much closer to ANSI than CC5X.

Dale
---
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
-- Isaac Asimov

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

You don't need a seperate chip to store data on, if your using any of the PIC's
that are flashable, as they have EEPROM onboard.  There are even some really
cheap 8 pin OTP's (One Time Programmable, with onboard ADC) chips that have
EEPROM on board (they are limit to 4 byte stack space however).

Just throw the chip back into your programmer after flight, and read the EEPROM
to get the data.  There is usually enough EEPROM, where you could have it record
a new value to anothor EEPROM location once every 1 or 1/2 second after launch
(tie a pin to your battery ignition starter, and have it start logging when you
send power to it to lanch).

Maybe check out MicroChip's line card again, and look at the features of what
each chip offers.

{Original Message removed}
<< I've not been following this thread so forgive me if this has already been
posted....  I found this link, having a simple PIC based rocket altimeter
and other neat rocket projects...

http://www.tfs.net/~petek/projects.html

He uses a MPX4115 pressure sensor and also includes some op-amp signal
conditioning circuitry to increase the accuracy of the measurement. I plan
to build a similar circuit but with a 16F877, which has an on-board 12 bit
A/D converter.  Hope this is useful to you.

Freddie. >>

It hadn't been posted, but that's actually the site I found. I would use the
16F877 too, but it has a 10 bit ADC, not 12. 10 would be good enough for
this, providing around 10 foot resolution 0-10k feet, but 12 would be better
still, providing around 2.5 feet res. Supposedly the Mpx is sensitive enough
to detect a change in pressure between your head and your feet.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

I've not been following this thread so forgive me if this has already
been posted....  I found this link, which has a simple PIC based rocket
altimeter and other neat rocket projects...

http://www.tfs.net/~petek/projects.html

He uses a MPX4115 pressure sensor and also includes some op-amp signal
conditioning circuitry to increase the accuracy of the measurement. I
plan to build a similar circuit but with a 16F877, which has an on-board
12 bit A/D converter.  Hope this is useful to you.

Freddie.

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

Freddie Leaf wrote:
>
> I've not been following this thread so forgive me if this has already
> been posted....  I found this link, which has a simple PIC based rocket
> altimeter and other neat rocket projects...
>
> http://www.tfs.net/~petek/projects.html
>
> He uses a MPX4115 pressure sensor and also includes some op-amp signal
> conditioning circuitry to increase the accuracy of the measurement. I
> plan to build a similar circuit but with a 16F877, which has an on-board
> 12 bit A/D converter.  Hope this is useful to you.

You can find an even simplier design here under Apps/Misc:

http://www.devrs.com/pic

Jeff

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

> My questions: I want the ADC to be 12-bit.

There are some model rocketry folks on this list that I'm sure will pipe up,
but I don't understand why you need 2.5 foot accuracy for your altitude.  Is
the sensor even that accurate?  Can't atmospheric effects cause at least
this kind of noise when using pressure to determine altitude, even assuming
calibration right before launch?  And what about Bernulli effects?

Again, I have no experience with model rocketry, but my knee jerk reaction
is to look at a 16F876.  This part has built in 10 bit A/Ds, which will give
you 10 foot altitude resolution over your 0 to 10,000 foot range.  It also
has 256 bytes of EEPROM, which could store about 200 10-bit altitude values.
I don't know how long a modle rocket flight lasts, so I don't know whether
200 data points is reasonable.  I could imagine sampling more often on the
way up than on the way down, since the rocket is (presumably) going much
slower down.

The 16F876 has a built in UART so that the altitude data can be downloaded
easily after the flight.  The 16F series also come with some features to aid
low cost debuggers, which can be useful if you're just getting into PICs.
And all this comes integrated in a 28 pin package.

> An important part- when I get the converted output into
> the PIC, I still need to do some calculations. I figured out a good
equation
> that is accurate +/- 2.5ft from 0-10000ft, but uses long coefficients (the
> equation is at the bottom). Can the PIC handle this well, and can it do it
8
> to 16 times per second

Your equation is a simple third order polynomial.  If you are measuring
pressure to 10 or 12 bits, there is no need for 15 digits of precision in
the coeficients.  24 bit floating point with 16 mantissa bits should be more
than adequate.  Yes, the PIC can handle this sort of thing well under your
62mS limit.  In one project I have a 16F876 at 20MHz doing a lot more PID
controller calculations than that every 10mS with at least 3mS left over for
other stuff.

> or should I have it simply save the raw ADC value to
> be computed on the ground?

I think that depends on which representation is more compact and if you need
real time altitude for any other reason.

> Finally, does the general idea sound doable?

It does to me.

*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinembedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

> I plan
> to build a similar circuit but with a 16F877, which has an on-board 12 bit
> A/D converter.

Not according to my line card it doesn't.  All the 16Fxxx are shown with 10
bit A/Ds.

*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinembedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

I think that a pressure altimeter that stores maximum will misread
copiously (upwards, in altitude)) about when the motor burns out (hint:
bernoulli suction on the pressure port at the maximum speed will fake an
altitude much greater than really attained. Worse, the peak in the record
will NOT indicate maximum altitude and there should be no way to read it
off the record - perhaps it would make a saddle curve and the bottom of
the saddle would be the apogee - if the horizontal speed would be
negligible - but it will not be ;-). The maximum altitude can be recorded
with an apogee switch, by pressure or otherwise. Now, who knows about a
reliable apogee switch (not the magneto resistive one please). Perhaps you
could use a horizon sensor with 4 photocells and sense tilt from
near-vertical.

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

I find it interesting that this should come up at this
time because I'm almost finished a similar project and
should be testing it in a week or two.

Mine is based on the basic stamp II (because I have a
friend who wanted to participate in it and is a
microcontroller beginner), and ended up being 1" by
2.5" (plus 1 23A battery, about the size of an N cell).
It uses the ADXL190 +/- 80G accelerometer from Analog
Devices. Weighs only about 20 grams (with battery).
Using the built-in serial interface, I can download
each flight's data to a terminal emulator on my Palm
M100.

I considered both types (pressure and accelerometer)
and the accel type really seems more practical to me.
No worry about air pressure changes due to velocity,
etc. I should be able to get a full profile of flight
acceleration, velocity, and altitude.

I'd be curious, Dave, to know what the problems with
accelerometers are that you mention. I have done quite
a bit of thinking about sources of error, and the
largest source seems to be angle error, which works out
to only about 6 meters off (for a 10 sec time to
apogee) even for 10 degrees off. Unless you have a
strong wind, I don't think you would get that far
off.In addition, a pressure sensor (is seems to me)
would be very difficult to calibrate very accurately,
whereas an accelerometer can be very accurately
calibrated by just turning it upside-down and then
right-side up again several times and averaging them
together to find out the +/- 1G response.

Sean

At 07:06 PM 12/30/00 -0500, you wrote:
It certainly does, at burnout, or max V.
Accelerometer approach has it's problems too.

There's also a pressure spike around mach that can
cause problems.
If you're just logging, it's not such a problem, but
many designs detected
max altitude by indicated baro pressure, or zero
acceleration (as opposed
to negative during coast phase) and got fooled.

Deploying a parachute at trans-sonic speeds is
generally not a good idea.

--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?
kc6ete-9

--
http://www.piclist.com hint: The PICList is archived
three different
ways.  See http://www.piclist.com/#archives for details.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

>
>I'd be curious, Dave, to know what the problems with
>accelerometers are that you mention.

You can read acceleration pretty easily.
SRB's are noisy, but integration solves that.
Accelerometers will show the engine burn and coast characteristics pretty
well, but they have no idea which way is up.  Unfortunately, it's not
uncommon, especially during a problem launch, for the airframe to be
horizontal at burnout, doing mach at 6' altitude.  You can have this happen
due to booster failure, fin failure, weathercocking, or a shear layer.

If we factor out the at-rest acceleration of gravity, what you expect is a
large acceleration, transiting to a surprisingly large negative
acceleration at burnout, which decays during coast to near zero. If the
flight is mostly horizontal, that zero doesn't occur!

One sensor that does not get fooled about "up" and "down" is a three axis
magnetometer.
At launch, you back up in the data till just before launch, and call that
vector "up" (or rotate it till it's conveniently 0,0,0)

Aluminum launch rod highly recommended!

--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

Hi Dave,

Ok, it sounds like you are talking about problems
associated with using these systems for parachute
ejection. I thought you meant there were significant
problems with using accelerometer-based altimeters for
simple rocket altitude logging. If the rocket launch
fails in that way, I would hardly expect accurate
altitude data :-)

I just thought of another thing that you (or someone
else on the list) might be knowledgeable about: my
altimeter contains one crystal and one ceramic
resonator. Considering the mass and thrust of my
rocket, it should experience a peak acceleration of
about 14 G. Would this damage either the xtal or
resonator?

Thanks,

Sean

You wrote:

You can read acceleration pretty easily.
SRB's are noisy, but integration solves that.
Accelerometers will show the engine burn and coast
characteristics pretty
well, but they have no idea which way is up.
Unfortunately, it's not
uncommon, especially during a problem launch, for the
airframe to be
horizontal at burnout, doing mach at 6' altitude.  You
can have this happen
due to booster failure, fin failure, weathercocking, or
a shear layer.

If we factor out the at-rest acceleration of gravity,
what you expect is a
large acceleration, transiting to a surprisingly large
negative
acceleration at burnout, which decays during coast to
near zero. If the
flight is mostly horizontal, that zero doesn't occur!

One sensor that does not get fooled about "up"
and "down" is a three axis
magnetometer.
At launch, you back up in the data till just before
launch, and call that
vector "up" (or rotate it till it's conveniently 0,0,0)

Aluminum launch rod highly recommended!

--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?
kc6ete-9

--
http://www.piclist.com#nomail Going offline? Don't
email listservmitvma.mit.edu with SET PICList DIGEST
in the body

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

At 05:39 PM 12/31/00 -0500, Sean Breheny wrote:
>Hi Dave,
>
>Ok, it sounds like you are talking about problems
>associated with using these systems for parachute
>ejection. I thought you meant there were significant
>problems with using accelerometer-based altimeters for
>simple rocket altitude logging. If the rocket launch
>fails in that way, I would hardly expect accurate
>altitude data :-)

It's a common fault in design though, assuming that what the sensor tells
you means something that it doesn't, necessarily.

>I just thought of another thing that you (or someone
>else on the list) might be knowledgeable about: my
>altimeter contains one crystal and one ceramic
>resonator. Considering the mass and thrust of my
>rocket, it should experience a peak acceleration of
>about 14 G. Would this damage either the xtal or
>resonator?

Hard to say.  I've seen failures that looked like stopped clocks. I would
expect crystals to be more problematic than resonators. I would certainly
mount the crystal so that the maximum force was through the long axes of
the case, rather than through the thin part of the case.

Also, springy battery contacts are to be avoided.

--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

I'm not going to worry about the chip reading max altitude and storing that.
I'd like the thing to keep a log of the entire flight. That's why I'm going
to use an external memory chip; it may be necessary to store up to 10 minutes
of readings since the rocket could be on the pad for a while if it's a club
launch and other people are firing off before the altimeter equipped one. I'd
like the circuit to be "set it and forget it." Put the rocket on the pad,
press a start button, and after it lands press stop. Sure, the data will flat
line until launch and the flight will take up all of 30 seconds, but it will
all be there. Maybe a delay of a few minutes to take some of the dead
readings would help. But, whatever works.

-Tony

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

'[PIC]: Use in a rocket altimeter'
2001\01\01@175009 by
For the dead time on the pad, imho consider compressing the initial
readings if they are below a set threshold. You'd trigger logging if the
threshold is exceeded (launch).

Peter

PS: Most electronics (including most hard disks) withstand 20G shocks.
32kHz tuning fork crystals do not. RC clocks are the best but you may have
surprizes with ceramic capacitors which become piezo elements at such G's.
Use good quality SMD ones.

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

On Tue, 2 Jan 2001 00:46:23 +0200, you wrote:

>For the dead time on the pad, imho consider compressing the initial
>readings if they are below a set threshold. You'd trigger logging if the
>threshold is exceeded (launch).
>
>Peter
>
>PS: Most electronics (including most hard disks) withstand 20G shocks.
>32kHz tuning fork crystals do not. RC clocks are the best but you may have
>surprizes with ceramic capacitors which become piezo elements at such G's.
>Use good quality SMD ones.
..and avoid any caps that have a '5' in the dielelectric type.
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:

The bernoulli problem is well known, and has been solved aerodynamically
again and again, on just about every full-sized aircraft flying.  I'm
building an RV-6A kitplane, on which the designer spent quite a bit of time
fiddling with the "static port" as it's called in this case, to get it just
right so that the altimeter reads within about 20 or 30 feet over a speed
range from 50 mph to 220 mph or so.  It must be build exactly as the plans
show, as very small changes will introduce errors.

You can buy a "pitot-static assembly" made for light aircraft that is
calibrated up to several hundred mph, but it would be pretty heavy and
expensive for a model rocket.  On an airplane, a little tube sticking out of
the wing needs to be pretty strong to resist the wuffos and the guys that
drag the fuel hoses around.

If there's not already such a thing, someone with access to a wind tunnel
(at a university or somewhere?) could calibrate a simple probe to put on the
nosecone.  I would expect a soda-straw-looking thing a couple of inches
long.  If it were being read by computers, it wouldn't actually have to
cancel out the bernoulli effect things the way one for airplanes does, it
would just need to have a good equation to correct for it, based on wind
tunnel measurements.

> {Original Message removed}
At 11:14 AM 1/2/01 -0600, Don Hyde wrote:
>The bernoulli problem is well known, and has been solved aerodynamically
>again and again, on just about every full-sized aircraft flying.  I'm
>building an RV-6A kitplane, on which the designer spent quite a bit of time
>fiddling with the "static port" as it's called in this case, to get it just
>right so that the altimeter reads within about 20 or 30 feet over a speed
>range from 50 mph to 220 mph or so.  It must be build exactly as the plans
>show, as very small changes will introduce errors.

This is why it's proven to be impractical for hobby rocketry.
Plus, the static point moves around through mach, which causes problems.

You would have a very hard time finding two "identical" modrocs, with
static points in the same place, and by the time you fiddle it in, I expect
that the law of averages would have caught up with you. (in a ballistic sense)

--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:

I'm thinking very strongly about including an accelerometer in this thing.
The only one I can find that I can directly order is a 3-axis job from
Digi-key that costs \$25. I keep hearing about Analog Devices' accelerometers,
such as the ADXL190. What's the best place to order them in small quantities
(like 2 or 3)? Their site isn't very clear on buying the chip itself.

-Tony

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

>I keep hearing about Analog Devices' accelerometers,
>such as the ADXL190. What's the best place to order them in small quantities
>(like 2 or 3)? Their site isn't very clear on buying the chip itself.

Call yourself a suitable sounding commercial enterprise and then request a
couple of samples and they will arrive for free. Can take a few weeks for them
to arrive.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

<<
>I keep hearing about Analog Devices' accelerometers,
>such as the ADXL190. What's the best place to order them in small quantities
>(like 2 or 3)? Their site isn't very clear on buying the chip itself.

Call yourself a suitable sounding commercial enterprise and then request a
couple of samples and they will arrive for free. Can take a few weeks for
them
to arrive. >>

I suppose I could, but I'd rather buy them for cheap somewhere than BS the
guys. It's an option.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

Try Newark Electronics. I think that they carry Analog Devices'
accelerometers.

-Randy Glenn

My software doesn't have bugs; it develops random features.
=================================================
Randy_Glenn-at-tvo.org - PICxpert-at-picxpert.com
PICxpert-at-yahoo.com - PICxpert-at-home.com
http://www.picxpert.com/
=================================================

{Original Message removed}
Hi Tony,

I got mine from Analog Devices directly, as samples.
You don't have to lie, I told them that it was for a
model rocket altimeter project, gave no company name,
etc., and they still sent 2 of them to me. I think you
can also buy them from their site. Have a look at:

http://www.analog.com

If you search for ADXL190, you can then click on

Sean

You wrote:

I'm thinking very strongly about including an
accelerometer in this thing.
The only one I can find that I can directly order is a
3-axis job from
Digi-key that costs \$25. I keep hearing about Analog
Devices' accelerometers,
such as the ADXL190. What's the best place to order
them in small quantities
(like 2 or 3)? Their site isn't very clear on buying
the chip itself.

-Tony

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

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