Scratch Built Altimeter: Parts

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Originally posted by ghost
Do you accomplish this because of your processor or because of your programming?

Mostly the processor, but its programmed mostly in hardware, so its kind of both .

Its an adaption of existing code so I can't take all the credit :)

Did you take a look at the MCP3204 ADC?
 
Originally posted by basil4j
Mostly the processor, but its programmed mostly in hardware, so its kind of both .

Its an adaption of existing code so I can't take all the credit :)

Did you take a look at the MCP3204 ADC?

I looked, but it is only 12 bit and it uses 2.7V (not the 5V the schematics are designed around) and it uses 14 pins and the basic stamp manual shows you how to hook up an 8 bin ADC.

But if it is must faster, I'll use it.

And lastly, Do you think the LCD screen will be too heavy? I've seen commercial altimeters with them, so I think it'll work.
 
Instead of averaging consider using an IIR filter. They are really easy to implement, take very little CPU resources, and have much the same effect as an average.

Here's an example in C. The left shift amount can be tweaked to adjust the response time of the filter.
Code:
unsigned int filter = 0;

unsigned int iir( unsigned int val ) 
{
    filter -= filter >> 4;
    filter += val;
    return filter >> 4;
}
 
Originally posted by ghost
I looked, but it is only 12 bit and it uses 2.7V (not the 5V the schematics are designed around) and it uses 14 pins and the basic stamp manual shows you how to hook up an 8 bin ADC.

But if it is must faster, I'll use it.

And lastly, Do you think the LCD screen will be too heavy? I've seen commercial altimeters with them, so I think it'll work.

The MCP3204 can run on anything from 2.7V to 5V.
You would run yours on 5V (Vdd and Vref @ 5V)

You only need 3 pins connected to the stamp. CS, CLK and Data (Din and Dout can be connected together as they are never used at the same time).

:)
 
Originally posted by ghost
....I still don't see why debouncing would be a problem. As soon as the G switch activates (aka closes) - if only for a micro second - the transistor will still close... and remain closed. Maybe I'm missing something. If so, please elaborate.
..............

Safety Issues.

If you don't filter and debouce the G-switch, If someone moves the rocket wrong after arming, a wind gust makes the rocket move up or around wrong, or a bounce up and down happens on the pad POOF/POP/POW/OUCH..

then medics get called :eek:

Breakwire is much easier, even one 850 feet long,
why didn't I think of that John :rolleyes:
 
Originally posted by konkers
Instead of averaging consider using an IIR filter. They are really easy to implement, take very little CPU resources, and have much the same effect as an average.

Here's an example in C. The left shift amount can be tweaked to adjust the response time of the filter.
Code:
unsigned int filter = 0;

unsigned int iir( unsigned int val ) 
{
    filter -= filter >> 4;
    filter += val;
    return filter >> 4;
}

Interesting.

Im not familiar with C so forgive me if this has an obvious answer.

Would you run this function on just a single reading from the ADC?
An averaging function helps smooth out the readings, does this have the same effect?
 
Originally posted by konkers
Instead of averaging consider using an IIR filter. They are really easy to implement, take very little CPU resources, and have much the same effect as an average.

Here's an example in C. The left shift amount can be tweaked to adjust the response time of the filter.
Code:
unsigned int filter = 0;

unsigned int iir( unsigned int val ) 
{
    filter -= filter >> 4;
    filter += val;
    return filter >> 4;
}

:confused: :confused: I don't understand this at all :(
 
Originally posted by Art Upton
Safety Issues.

If you don't filter and debouce the G-switch, If someone moves the rocket wrong after arming, a wind gust makes the rocket move up or around wrong, or a bounce up and down happens on the pad POOF/POP/POW/OUCH..

then medics get called :eek:

Breakwire is much easier, even one 850 feet long,
why didn't I think of that John :rolleyes:

My design includes a breakwire (I think). In addition to the G Switch, it uses a normally closed switch. And a normal slide switch. When the slide switch is off, it is off. Period. No matter what. When the slide switch is on (closed), nothing happens unless the pin keeping the normally closed switch open is pulled. That will not be pulled, however, until right before flight. Then, if all of that happens, nothing will happen unless the G switch activates AND the gust reaches 850 feet (there is no deployment otherwise - motor ejection is my backup).

Is this safe enough?
 
Originally posted by basil4j
The MCP3204 can run on anything from 2.7V to 5V.
You would run yours on 5V (Vdd and Vref @ 5V)

You only need 3 pins connected to the stamp. CS, CLK and Data (Din and Dout can be connected together as they are never used at the same time).

:)

Cool. I'll order that also. Thanks :D
 
Originally posted by basil4j

Would you run this function on just a single reading from the ADC?
An averaging function helps smooth out the readings, does this have the same effect?

This function is run on each sample as you read it. It's a low pass filter so, yes, it smooths out the readings. Using it looks something like:

Code:
while(1) {
    sample = wait_for_sample();
    sample = iir(sample);
    do_something(sample);
}

-Erik
 
Originally posted by konkers
This function is run on each sample as you read it. It's a low pass filter so, yes, it smooths out the readings. Using it looks something like:

Code:
while(1) {
    sample = wait_for_sample();
    sample = iir(sample);
    do_something(sample);
}

-Erik

Is each sample a number? Or a single bit?

How do you turn each sample (if it isn't a number) into a number?

Thanks!:)
 
Originally posted by konkers
This function is run on each sample as you read it. It's a low pass filter so, yes, it smooths out the readings. Using it looks something like:

Code:
while(1) {
    sample = wait_for_sample();
    sample = iir(sample);
    do_something(sample);
}

-Erik

Ahhh nice.

So if one were to use this on top of averageing 10 samples, you could get some pretty accurate readings?
 
Originally posted by basil4j
Ahhh nice.

So if one were to use this on top of averageing 10 samples, you could get some pretty accurate readings?

Would this affect that excel spreadsheet you made? Or would this ismply make it more accurate?

Also, when you say:
Code:
do_something(sample);
Does that mean that "sample" equals the number? Or just a piece of it. If it is the number, than do_something could compare it to the target.
If it is just a piece of it, it would turn that piece into a whole number.

Is my logic correct?

Thanks!!!!!!! :) :p :D ;)

EDIT: PS: the parts are ordered!!!
 
Originally posted by ghost
Would this affect that excel spreadsheet you made? Or would this ismply make it more accurate?

Well the values in the spreadsheet are meant to represent the final ADC reading after all the filtering, averaging etc.
Its the formulas in the spreadsheet which are most important rather than all those numbers I put in :)

Those are just to check my formulas are working as expected.
 
Originally posted by basil4j
Well the values in the spreadsheet are meant to represent the final ADC reading after all the filtering, averaging etc.
Its the formulas in the spreadsheet which are most important rather than all those numbers I put in :)

Those are just to check my formulas are working as expected.

I see. But in my altimeter, instead of converting the ADC output to feet, I want to compare the ADC output to a number from your spreadsheet in column 2 (before any conversions). This will hopefully speed things up.
 
Originally posted by ghost
I see. But in my altimeter, instead of converting the ADC output to feet, I want to compare the ADC output to a number from your spreadsheet in column 2 (before any conversions). This will hopefully speed things up.

Ahhh ok. Makes sense. So you are just going look up the max ADC value when the rocket has landed and get the altitude that way, rather than making the stamp figure it all out?

Still, the ADC value you will compare to the one in my spreadsheet will be after all the filtering and stuff. (I guess you don't have to filter, but it would be less accurate)
 
Originally posted by basil4j
Don't mean to brag, but I have a routine which can do 10 sample average of 12bits in <0.5ms ;)

Ok back on topic Alec, brag time over :D

I just designed a board that can average 10 14-bit samples in 30 usecs. It uses the TI 8-ch TLC3548. The processor is a TI tms320c6720 running at 350MHz, and does 2 Billion Floating point operations per second.

I'm not bragging though. ;)
 
Originally posted by basil4j
Ahhh ok. Makes sense. So you are just going look up the max ADC value when the rocket has landed and get the altitude that way, rather than making the stamp figure it all out?

Still, the ADC value you will compare to the one in my spreadsheet will be after all the filtering and stuff. (I guess you don't have to filter, but it would be less accurate)

Hmm... Maybe I'll turn the ADC output into pressure (so filtering is OK) and compare pressure. Then, the Stamp's logic will have two variables: deployedAt and apogee. Both will be stored as pressure. Once the rocket starts descending, the altimeter will stop reading, convert the variables to feet, and display them on the LCD. How's this sound?
 
Originally posted by darkhelmet
I just designed a board that can average 10 14-bit samples in 30 usecs. It uses the TI 8-ch TLC3548. The processor is a TI tms320c6720 running at 350MHz, and does 2 Billion Floating point operations per second.

I'm not bragging though. ;)

:eek:
That's fast...
:eek:
 
Originally posted by ghost

Code:
do_something(sample);
Does that mean that "sample" equals the number? Or just a piece of it. If it is the number, than do_something could compare it to the target.
If it is just a piece of it, it would turn that piece into a whole number.

Is my logic correct?

It's the whole number after running the filter on it. You could just compare it to the target.

-Erik
 
Originally posted by basil4j
Ahhh nice.

So if one were to use this on top of averageing 10 samples, you could get some pretty accurate readings?


You should not need to average your samples if you are running an IIR on them. It's important to realize that filtering (or averaging) your samples will not necessarily make them more accurate. All it will do is filter out high frequency components of the sampling. If those high frequency components are important and not just noise, you're making your data less accurate.

-Erik
 
Originally posted by konkers
It's the whole number after running the filter on it. You could just compare it to the target.

-Erik

Ahh... Genius!! :)

So... "waitForSample()" returns the full sample. That makes me assume that "waitForSample()" takes care of putting the bits together into the whole number. How does this work, though? I assume there isn't a simple premade method I could use to get the whole number from the ADC... or is there???
 
Originally posted by darkhelmet
I just designed a board that can average 10 14-bit samples in 30 usecs. It uses the TI 8-ch TLC3548. The processor is a TI tms320c6720 running at 350MHz, and does 2 Billion Floating point operations per second.

I'm not bragging though. ;)

Bah lol, ill stick with my 80Mhz 8 core MCU :D
 
Originally posted by ghost

So... "waitForSample()" returns the full sample. That makes me assume that "waitForSample()" takes care of putting the bits together into the whole number. How does this work, though? I assume there isn't a simple premade method I could use to get the whole number from the ADC... or is there???

The details of reading an ADC value is specific to your microcontroller and ADC. As my allergy to BASIC is almost as strong as my allergy to PIC assembly, I'm not much help with the details of your platform.

-Erik
 
Originally posted by konkers
You should not need to average your samples if you are running an IIR on them. It's important to realize that filtering (or averaging) your samples will not necessarily make them more accurate. All it will do is filter out high frequency components of the sampling. If those high frequency components are important and not just noise, you're making your data less accurate.

-Erik


Yeah, I thought as much.
Thing is, the way the code is written, it takes ~0.1ms to do a single sample ,and ~0.4ms to do an average of 10 samples lol go figure. Thought I might as well do the averaging :)
Your right though, I don't want to make the data too artificial :)
 
Originally posted by konkers
The details of reading an ADC value is specific to your microcontroller and ADC. As my allergy to BASIC is almost as strong as my allergy to PIC assembly, I'm not much help with the details of your platform.

-Erik

Does anyone have/know of BS1 code for doing this?

Thanks :)
 
Originally posted by basil4j
Yeah, I thought as much.
Thing is, the way the code is written, it takes ~0.1ms to do a single sample ,and ~0.4ms to do an average of 10 samples lol go figure. Thought I might as well do the averaging :)
Your right though, I don't want to make the data too artificial :)

How do you figure out the time it takes? How do you clock it? Is there some equation, or does the compiler just tell you?
 
Originally posted by ghost
Does anyone have/know of BS1 code for doing this?

Thanks :)

For coding the Stamp, the best place to start would be the Parallax forums for the Stamp.

https://forums.parallax.com/forums/default.aspx?f=5

Im sure there are people on this board who could help (and have done already), but the Parallax boards are dedicated to Stamp programming. :)

Hope this helps!
 
Originally posted by ghost
How do you figure out the time it takes? How do you clock it? Is there some equation, or does the compiler just tell you?

I wish it were that simple lol.

You record the clock count before you begin the reading and calculations. Then you record the clock count afterwards.
then multplie the difference on clock counts by the freq of the processor and there you go :)

E.g (I made these clock numbers up)

Clock before sampling/filtering : 19067
Clock after sampling/filtering : 20456
Difference : 1389 clock cycles

If the CPU is running at 1Mhz, then one clock cycle would take 1/1000000 = 0.0001ms

1389 clock cycles x 0.0001ms = 0.1389ms to perform samples

:)
 

Latest posts

Back
Top