Arduino altimeter - dual recovery for less than 20 dollar

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
yes that is a very good point. I do store the time each time I am saving a sample. I need to instagate why it does that ...
This is beta software so anybody with an idea let me know. Code is available on my site.
Leo maybe you have some tips for me....



ok I know why ... in fact I am measuring evry 76ms but excel is not showing all the numbers ....
 
Hi all
I am off on holidays for 3 weeks in a week time so will not be able to post some kits after the 6th of August.
For those who want to order price list is
https://rocket.payload.free.fr/Download/altimeter price list27-06-2013.pdf

I running out of alti Duo and missing some components for the datalogger, I will not have those before september.
However I have plenty of Alti uno and mini Alti Duo
Boris
 
Boris,

I have a question about the version 1.3 firmware.

In the code, if the user chooses to have altitude reported in feet, the beepAltitude fuctions basically take the altitude measurements and multiply by 3.28084 (the number of feet in a meter.) Doesn't this result in the altitude resolution still being in meters, just being reported in the nearest equivalent foot?

by this method I'd expect to see something like this:

100 m = 328 f (rouding down)
1000 m = 3281 f (rounding up)
1001 m = 3284 f (rounding down)

what happens if my altitude was actually closert 3282 feet?

continuing this line of thought, what if I were trying to hit 1 mile exactly? (I know this was a goal for the US SLI teams this past year)

1 mile = 5280 feet = 1609.34 meters
1609m = 5278.87f
1610m = 5282.15f

Of course everything I've been able to find for the adafruit bmp085 library pretty much handles it the same way. The library uses meters in the readAltitude() function, and if one wants feet, one multiplies the return value by 3.28084 (I saw some code that just used a factor of 3.28)

I haven't found a good source for figuring out the equation needed to convert the pressure in Pa to feet directly, at least not one that I can understand. (I'm guessing that the library's readPressure() function could be employed here.)

Maybe I'm just over-thinking this, and I should just go away and learn to love the metric system. :)
 
The BMP085/180 reports pressure in Pa, unsigned long integers. Within its rated operational range, (300-1100 hPa) this translates to a minimum 1 foot resolution, a little better at the higher pressures/lower altitudes. In a rocketry application in which the pressure is constantly changing, this is probably the best you're going to do anyway.
 
Boris,

I have a question about the version 1.3 firmware.

In the code, if the user chooses to have altitude reported in feet, the beepAltitude fuctions basically take the altitude measurements and multiply by 3.28084 (the number of feet in a meter.) Doesn't this result in the altitude resolution still being in meters, just being reported in the nearest equivalent foot?

by this method I'd expect to see something like this:

100 m = 328 f (rouding down)
1000 m = 3281 f (rounding up)
1001 m = 3284 f (rounding down)

what happens if my altitude was actually closert 3282 feet?

continuing this line of thought, what if I were trying to hit 1 mile exactly? (I know this was a goal for the US SLI teams this past year)

1 mile = 5280 feet = 1609.34 meters
1609m = 5278.87f
1610m = 5282.15f

Of course everything I've been able to find for the adafruit bmp085 library pretty much handles it the same way. The library uses meters in the readAltitude() function, and if one wants feet, one multiplies the return value by 3.28084 (I saw some code that just used a factor of 3.28)

I haven't found a good source for figuring out the equation needed to convert the pressure in Pa to feet directly, at least not one that I can understand. (I'm guessing that the library's readPressure() function could be employed here.)

Maybe I'm just over-thinking this, and I should just go away and learn to love the metric system. :)
When I get a chance I will have a look at creating low level function in the Adafruit library to directely convert to feet.
I am currently attenting a rocketry meeting in Spain so I will take a look at it when I am back to France.
 
Boris-

I saw on another thread, (and on the alti-duo page on your site) that you've sourced some transistors that aren't as tall. I was wondering if you could provide part numbers for them. I was thinking about trying to get my alti-duo to fit in a 38mm av-bay. (The current transistors make the unit just a touch too large.)

Of course, I have yet to actually launch with this altimeter. I promise I will this season. (Just as soon as my club' high power field opens up.)
 
ref is IRLU024
Package is T0 251
This is what it looks like compear to the other one
new transistors.JPG
 
yes I suggest you get the second one
It is cheaper and can do 17A (this actually the one I have)

Yes the regulator is smaller because it does only power the microcontroller no point of using a 1.5 A one ..... The Emaches are not power via the regulator.
Anyway if you use the protection diode (and I suggest you do) it will limitate the current or act as a fuse !!!!
I have been using those smaller components all summer with lots of flight and they work well. I will do smaller kits at some point with the new bmp180 sensor from Bosh if it works well.
I am doing redondance (a minimum of 2 alti per rocket) even with single deployment rockets. I am not using any motor ejection anymore for my mid and high power rockets
I have cleaned some bugs from the 4 altimeters thanks to the help of various people and they are now quite stable. Next I want to attempt a mach flight just to prove that even cheap stuff works well
 
ok - I'm getting a lot more hits on mouser for the smaller package voltage regulator, what should I be looking for (other than the package size?)

Obviously, I know enough to be able to assemble kits, but not design them myself yet :blush:

Let me know if/when you have updated (smaller) kit designs. I'd be interested in building a couple - especially 2 pyro channels. I guess you already have the mini altiduo, but were you thinking about something even smaller?
 
I *think* its a 5v circuit. You need this one: 5v 0.5a

L78M05CDT-1

edit: Yup, it's a 5v circuit. Is 0.5a enough, Boris?


ok - I'm getting a lot more hits on mouser for the smaller package voltage regulator, what should I be looking for (other than the package size?)

Obviously, I know enough to be able to assemble kits, but not design them myself yet :blush:

Let me know if/when you have updated (smaller) kit designs. I'd be interested in building a couple - especially 2 pyro channels. I guess you already have the mini altiduo, but were you thinking about something even smaller?
 
Last edited:
Mine is a 78L05 it is 5v and 0.1A which is more than enought for the attiny and sensor.
The current drained by the pyro charges is not comming from the regulator
 
Used mine for the first time as a deployment device yesterday and worked perfectly. Previously I had let it go along for the launch with e-matches hooked up but no BP.

 
good glad it did.
I am working really hard on the datalogger which now has a Java interface so it will be able to run from Mac, Linux Windows .... Android would be nice as well because the interface will be bluetooth (no need to open the rocket elec bay to look at the flight data)
I will post the latest code in the next few days
datalogger.png
 
I have updated my web site with the latest code for the data logger
https://rocket.payload.free.fr/index.php?option=com_content&view=article&id=20&Itemid=2&lang=fr
Note that you will need Eclipse to run it because I have not made a build file yet.
This should work with few modifications on any altimeter that are Arduino based and use EEPROM to save flight data.
You do not need the Arduino environement to run the Java front end.
I am going to also update my GitHub repository so that people can make contribution
If someone can port it to Android phones then we would be able to read flight data and plot the curve on any Android smart phone without opening the rocket.
People might actually start looking at flight data if it is easy to get them !!!

I have also other ideas for the interface, I was thinking that I should be able to have a simple interface to configure the altimeter (such as altitude in meter of feet, trigger airstart etc...) and save the configuration on the microcontroller EEPROM.
I am also working a program that can store a GPS flight
 
Hey Boris,

The data logger has a bluetooth interface on it? I maybe could take a stab at interfacing to it with android.

Also, did you ever get my version of the altiduo firmware to work correctly?

Kevin
 
If if doesn't, you can always get a TTL-level Serial-Bluetooth interface card like THIS . They run about $8 on ebay, via slow boat from China. I've used one with the Eggtimer, they work fine for programming/downloading.

Hey Boris,

The data logger has a bluetooth interface on it? I maybe could take a stab at interfacing to it with android.

Also, did you ever get my version of the altiduo firmware to work correctly?

Kevin
 
Also, did you ever get my version of the altiduo firmware to work correctly?
Some of it but I want to be able to choose betwen the configurations without having to recompile the program
 
If if doesn't, you can always get a TTL-level Serial-Bluetooth interface card like THIS . They run about $8 on ebay, via slow boat from China. I've used one with the Eggtimer, they work fine for programming/downloading.

yes this is also what I am using. you can connect also with a laptop and a dongle. I guess the range is few meters but it is better than having to open the Rocket payload.
When turned on the datalogger just look for possible incomming messages from the PC (some sort of commands) and send back data.
 
Some of it but I want to be able to choose betwen the configurations without having to recompile the program

What do you mean by choose different configurations? Was it the feet/meters switch? About all it did was change the beeps and save the last max altitude.

Oh, expect order soon.

Kevin
 
What did you alter in the beep code?

I made it store the max altitude in eeprom. So it would report the last altitude during startup.

I consolidated the two beep routines into one (one used tone() the other used digitalWrite()).

The continuity beeps are different. For the Main it uses 1 beep (long for good, short for bad), for drogue it uses 2 beeps (long for good, short for bad). I found with the old sequence I couldn't tell which of the two channels had continuity if only one was good.

It still has two different number reporting schemes which are controlled by a compile time switch - the "New" one, which I think you did, Leo, and the "old" one.

Kevin
 
Ah, OK. I thought you changed something to my code. I was curious to see what you would have done.
 
What do you mean by choose different configurations? Was it the feet/meters switch? About all it did was change the beeps and save the last max altitude.

Oh, expect order soon.

Kevin
Kevin
I want to softcode everything into the EEPROM and have the user select what ever method they want to use for reporting the altitude.
I don't expect the end user to recompile the code each time they want to change the config.

As for the altimeters I am running out of the big Alti duo but the data logger can do the same except that it is slightly more expensive and has an extra pyro output and memory to store the flight.
Appart from that I have some mini alti duo and my "best seller" the alti Uno... people seam to like single ejection altimeter...
 
Kevin
I want to softcode everything into the EEPROM and have the user select what ever method they want to use for reporting the altitude.
I don't expect the end user to recompile the code each time they want to change the config.

I've been thinking of a way to use the two jumper inputs as a pair of buttons to allow for programming. Haven't really thought it through too much yet.

Kevin
 
Back
Top