Arduino altimeter - dual recovery for less than 20 dollar

Just about every MCU platform has its own IDE, whether their a "hobby" platform like Arduino or PIXAxe, or a "professional" platform like PIC's MPLABX. Wheels come in all shapes and sizes...

Although it's sometimes annoying that Arduino hides the stuff under the covers because you can't easily tell if your code is getting bloated, you don't have to mess with make files and the like, so it's a really simple prototyping environment. I hadn't touched C in about 20 years, but it was easy to take it up again.

gdjsky01 said:

Way to reinvent the wheel...

Click to expand...

hello
I have been porting all my code to the ATtiny 85 and 84
This was actually a lot of troubles especially with the sensor library (BMP085) where I had to re-write the "pow" function from the math.h lib in order to make it more efficient + I had to patch my linker so that it could work with prog > 4k
This all compile nicelly for both chip.
This now becomming very interesting because I can do smaller boards for exemple a single deployment altimeter built with an ATTiny 85 with classic components measure 75mm x 19mm and the weight is between 15 and 20g

I was looking at the code... it seems like it could be sensitive to turbulence once it clears the 50 meter arming altitude; has this been an issue in test flights?

yes I have had successfull test flight and ground test as well.
what do you mean by sensitive to turbulence?
If you have any improvements in the code please feel free to send them to me

bdureau said:

yes I have had successfull test flight and ground test as well.
what do you mean by sensitive to turbulence?
If you have any improvements in the code please feel free to send them to me

Click to expand...

If I understand the code fully, once the arming altitude is reached, if the current pressure is higher than the previous loop iteration's pressure, then it registers apogee. If the vent hole were too large (or awkwardly placed, or something like that), then potentially pressure fluctuations could occur, leading to early apogee deployment.

Perhaps a first-order filter of some sort could reduce sensitivity to that sort of thing without adding too much complexity.

A short timer, .5-1 sec, to see if you've actually nosed-over would do it too. Both that and a filter would be better, but you might have trouble trying to squeeze things into a Tiny once you start getting fancy.

For the ATmega 328 version the code is about 11k
For the ATtiny 84 version the same code compiled is about 6k (I have been hacking the BMP085 library and rewrote the pow function)

So yes I could add some digital filtring on the 328 but will be difficult with the ATtiny version
Not too sure what you mean by "A short timer, .5-1 sec, to see if you've actually nosed-over"

After each sample check to see if the timer has elapsed since the previous "maximum altitude" sample, if it has then it's a safe bet that you've passed apogee. You don't want to make this too long, but at 1 sec you're only moving at about 32 ft/sec... vertically, at least. This is plenty slow enough for even a main chute.

bdureau said:

For the ATmega 328 version the code is about 11k
For the ATtiny 84 version the same code compiled is about 6k (I have been hacking the BMP085 library and rewrote the pow function)

So yes I could add some digital filtring on the 328 but will be difficult with the ATtiny version
Not too sure what you mean by "A short timer, .5-1 sec, to see if you've actually nosed-over"

Click to expand...

If the rocket is higher than before, overwrite the 'max altitude reached' variable.

If the rocket is lower than the 'max altitude reached' variable every sample for half a second, then that's Definitely apogee (aside from Mach effects).

I guess that it is a simple methode to remove the noise from the sensor.
The bit I would like to make safer is the lift off detection.

bdureau said:

I guess that it is a simple methode to remove the noise from the sensor.
The bit I would like to make safer is the lift off detection.

Click to expand...

What's wrong with it now? Do you want it to continuously update so that more significant pressure changes (e.g. opening the av-bay) or atmospheric changes won't cause it to go off?

gdjsky01 said:

Way to reinvent the wheel...

Click to expand...

Altimeters should be programmed in Forth, right Jeff?

jderimig said:

Altimeters should be programmed in Forth, right Jeff?

Click to expand...

LOL!!!! It was the the original real-time high level language. Or ACTION!

jderimig said:

Altimeters should be programmed in Forth, right Jeff?

Click to expand...

LOL!
Great throwback, John!

Or COBOL. Been doing it for 30 years... IBM systems just won't go away.

jderimig said:

Altimeters should be programmed in Forth, right Jeff?

Click to expand...

CarVac said:

What's wrong with it now? Do you want it to continuously update so that more significant pressure changes (e.g. opening the av-bay) or atmospheric changes won't cause it to go off?

Click to expand...

I just want to make sure that it does not blow up while on the pad. Imagine one silly mesure > 50 m because of some noise and you have premature ejection on the pad.

You're not likely to get a single gust of wind that registers as a 50m altitude gain, however you CAN get that effect if your rocket sits on the pad long enough and the ambient baro pressure/temperature rises. Out here in the desert, if you fly early in the morning that is entirely possible as it warms up. To combat that effect, take a temperature-compensated baro reading ever few seconds while on the pad, and use a weighted average into your base "ASL altitude" reading. For the Eggtimer, I take 5 readings over 10 seconds as a baseline at startup, then average a reading every 15 seconds into the ASL altitude with a 20% confidence level (i.e., .2 x new reading + .8 x old average). As the ambient pressure rises, so will your base ASL altitude reading, so the net effect on your flight's AGL readings will be zero.

Like I said before, you're really pushing what you can do with a Tiny... best of luck to you!

bdureau said:

I just want to make sure that it does not blow up while on the pad. Imagine one silly mesure > 50 m because of some noise and you have premature ejection on the pad.

Click to expand...

While inspecting the sensor library I have also found some interesting functionalities such as presure reading resolution which I guess does what you are describing.

write8(BMP085_CONTROL, BMP085_READPRESSURECMD + (oversampling << 6));

if (oversampling == BMP085_ULTRALOWPOWER)
_delay_ms(5);
else if (oversampling == BMP085_STANDARD)
_delay_ms(8);
else if (oversampling == BMP085_HIGHRES)
_delay_ms(14);
else
_delay_ms(26);

raw = read16(BMP085_PRESSUREDATA);
raw <<= 8;


I am not doing too bad with the Tiny, after the porting of my code I still have 2k free!!!!
I will publish the code on my web site in the next few days.
Including the modifications to the sensor library which I guess could be usefull for other projects.

That's the oversampling function in the BMP085, see the Bosch data sheet. Basically, the chip internally takes a bunch of samples to produce a more accurate result, supposedly. I say "supposedly", because in my tests I have not seen any significant difference between the low res mode which takes 5 ms, and the highest res mode which takes 26 ms. If you're moving at 500 ft/sec, 20 ms makes a big difference, you're likely to get noise introduced into the sampling just because you're moving and the air pressure is changing during the sampling time. Go with the lowest res setting (oversampling == BMP085_ULTRALOWPOWER).

The sampling process actually takes about 9 ms, 4.5 ms for the temperature sensor and another 4.5 ms for the pressure at low res. That plus however much time the rest of your code takes is going to be the constraint in your maximum sampling rate. If you are writing anything to the EEPROM, note that there is a 5 ms delay PER WRITE to allow the EEPROM to settle. That's a long time, so make sure that any writes are done after the sampling/comparison logic is done, and complete during the idle time between samples. If you are taking 10-20 samples per second, you are probably going to be OK.

I could try to keep the last 10 samples in an array in memory rather than storing it in the EEPROM
I think that I have a look at digital filtring
I guess I will have plenty of practical testing to do in the next few weeks

That's probably a good idea, if you aren't recording the samples for a flight graph then there's no reason why you need to put them into EEPROM. Let me know if you want the Kalman filter snippet from the Eggtimer software, I'll be happy to PM it to you.

Thanks for the offer, the problem is that I am publishing all my programs so you might not like seeing your code becoming public.
By the way I have looked at your site
https://www.eggtimerrocketry.com
and your are saying that you are re-writing some of the Arduino function to save some memory.
Here is the new pow function that I use in the BMP085 class (it saves about 1k on the attiny)
int pow(int a, int exp) {
if(exp == 0) {
return 1;
}
int temp = pow(a, exp/2);
if(exp % 2 == 0) {
return temp*temp ;
}
else {
return temp*temp*a ;
}
}

I have some digital filters to try first. I will show you my new code soon

The Kalman code is derived from a public source, so I have no problem publishing it. Let me know if you want it, and I'll be happy to PM it to you. I don't use the pow() function in the BMP code, just multiplication and shifting. I only use pow() for the pressure-altitude conversion. If there were LOTS of flash available, I'd probably entertain thoughts of building a lookup table, but the last time I looked I only had about 150 bytes left out of 32K. Since the Eggtimer uses VT100 terminal emulation for screens, a lot of that is taken up in strings but the upside is that there is no software on the client, so any client that can handle a terminal emulator and the Prolific 2303x USB-serial driver can be used.

OK in that case I will send you my email by PM

Thanks for the filter code; I have updated my website with my work on the attiny 84 and 85
https://rocket.payload.free.fr/index.php?option=com_content&view=article&id=10&Itemid=8&lang=en
and I have modified the code to use the filter
https://rocket.payload.free.fr/index.php?option=com_content&view=article&id=2&Itemid=2&lang=en
This is untested, It just compiles fine. Al components are on order, I am going to build some new prototype in the next few weeks

All this code and Kalman filter talk! Sounds like Greek to me!LOL BUT, if it makes a better product, I am all for it, just count me out of the conversation for any knowledgeable input...

Anyway, got my kit today from France! Had to open the package and have a look see..Looks like everything survived the transit across the 'big pond' to get here..Now, I gotta do some digging and find the soldering iron and some solder! Wish me luck!:wink:

cool that was fast. Just send me a pm if you are having troubles

Are there any more kits available? I'm definitely interested.

I am still waiting for the components to arrive. I will let you know when I get them
Otherwise I have just some board but it might be more expensive if you buy the components yourself in small quantities

I got my kit in the mail today. The board is really nice with solder masks and printing. In about 30 mins, I had it all soldered up and ready to go. I haven't tried to power it up or anything since, well, I don't have a programmer cable yet. There are a few little gotchas, the spacing between the baro and socket is a little tight, similarly between the 2x2 jumper header and one of the mosfets.

Kevin