DasAltimeter – A homebrew rocketry altimeter.

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

slaak

Well-Known Member
Joined
Jun 19, 2014
Messages
52
Reaction score
4
I have been making my own Rocketry altimeters for a couple years now, but up until this point I’ve kept pretty silent about it and only used them in low power rockets for data logging purposes. I decided at BALLS this last year that I was going to bite the bullet and put the time into developing a full-fledged altimeter to log data, control dual deployment, and upper stage ignition with tilt sensing.

I am a Mechanical Engineer by trade so I have only taken basic courses involving electrical engineering and programming (I have I’ve dabbled in different programming projects over the years thought). Because of this there I’ve made many many revisions of my altimeters over the past couple years. But after reading probably a dozen books on embedded circuit design, embedded programming, electrical devices, countless hours doing internet research, and some reverse engineering I am finally confident that I have a viable flight altimeter.

On to some technical details about the altimeter!
• 4 channel output, each should be able to sink enough current to light a second stage if desired.
• Kalman filter incorporating pressure and acceleration data running aprox. 125Hz.
• Currently logging at 20Hz which includes time, altitude, 3D acceleration, 3D gyro, and velocity. Still tuning the logging logic, but I will probably have it log at 50Hz during accent and 5 or 10hz during decent. I have a 16 megabyte flash memory module onboard so a it can log for a couple hours no problem.
• SAMD21 running at 48MHz to do all the thinking.
• MS5803-14 Pressure sensor running in 0.2mbar mode.
• BMI055 IMU for +/- 16G accel and 2000 deg/s gyro.
• AD22286 +/- 70G Analog accelerometer to feed the Kalman when above 16G.
• Tilt lockout isn’t implemented yet, but I will be putting that in the firmware at some point down the road.
• Data is retrieved using a cheep FTDI dongle like the FTDI basic from sparkfun.

There is probably a bunch more to tell about this but I think that’s all I have for now, I hope to stuff this thing in a rocket soon and I will post some data.
If there is any comments or questions type away! Anyways heres some pictures.

DSC_1541.jpg
Top view.

DSC_1543.jpg
The brains.

DSC_1546.jpg
size comparison next to some commercial altimeters.

DSC_1547.jpg
DSC_1548.jpg
 
Obviously...”when can we get it and how much will it cost?”


Sent from my iPhone using Rocketry Forum
 
Nice!

I'm building my own homebrew altimeter but yours looks much nicer... How are you programming it? Arduino? CircuitPython?

I need to work on my soldering skills apparently... Looking good! I may steal your idea with the MS5803 as I have a BMP280 on a breakout, not exactly ideal... Don't know how I missed that one!
 
Extremely nice size profile for a 4-channel, accel-based board. Frankly size is the only reason I still have a Raven. Any comments on the software interface?

From the Ether...
 
Nice size, any guess on ballpark pricing?

I don't see where the FTDI would connect? The SWD header? Looks like the deployment switches are SI7232DN's? If they're MOSFETs then there's no current-limiting, eh? Curious, what is the large component in the first picture, top-left? Speaker, perhaps?

Always great to see more options, especially ones meant to support staging/airstarts.
 
Nice size, any guess on ballpark pricing?

I don't see where the FTDI would connect? The SWD header? Looks like the deployment switches are SI7232DN's? If they're MOSFETs then there's no current-limiting, eh? Curious, what is the large component in the first picture, top-left? Speaker, perhaps?

Always great to see more options, especially ones meant to support staging/airstarts.

Not sure but 2x5 is a standard FTDI form factor, so I bet it's the header at the top. I'd guess the black can is a piezo buzzer- not sure though.
 
Obviously...”when can we get it and how much will it cost?”


Sent from my iPhone using Rocketry Forum

Depending on how much time I have to devote to it over the next couple months I expect i'll have it polished enough by the end of summer to consider selling them. To be honest though I don’t know that I want to make a business out of this, but time will tell I guess. Id like to try and sell at least enough units to cover my costs but don’t have huge ambitions in that regard.

Nice!

I'm building my own homebrew altimeter but yours looks much nicer... How are you programming it? Arduino? CircuitPython?

I need to work on my soldering skills apparently... Looking good! I may steal your idea with the MS5803 as I have a BMP280 on a breakout, not exactly ideal... Don't know how I missed that one!

It looks like your altimeter is off to a good start! I wish I had gotten involved in this kind of project when I was closer to your age. I have been programming mine in good old fashion C using an Atmel-ICE debugger. There is an Arduino bootloader out there for the chip I’m using but you loose a lot of functionality using the arduino libraries and a ton of speed in a lot of cases.
I don’t know if id recommend the MS5803 to be honest, its way too expensive and the system noise + Kalman filtering negates and additional accuracy that it gives, unless you just want to use it because it looks cool. If you’re not happy with the Bosh chip your using id take a look at the MS5607, its what’s used by atlus metrum, missile works, and in the raven.

Extremely nice size profile for a 4-channel, accel-based board. Frankly size is the only reason I still have a Raven. Any comments on the software interface?

From the Ether...
The user side software is where the bulk of my work still lies, right now it’s a command line and I’m working on getting everything functional before making a pretty GUI to go with it. I know the user side software is a big gripe with a lot of currently available altimeters so that is something I’m going to be sure to make user friendly. Right now the computer side code is in Python but I plan to convert it over to JAVA for to make it easier to deploy.
cmd interface.PNG

Nice size, any guess on ballpark pricing?

I don't see where the FTDI would connect? The SWD header? Looks like the deployment switches are SI7232DN's? If they're MOSFETs then there's no current-limiting, eh? Curious, what is the large component in the first picture, top-left? Speaker, perhaps?

Always great to see more options, especially ones meant to support staging/airstarts.

If I had to just throw a number out there on price id guess something like $150 because that’s what other people charge for similar? I could change up some components and cut the costs dramatically but at the moment the material costs is around $70 and assembly takes about an hour and a half.
Good catch on the lack of FTDI header, my programmer/debugger doesn’t use pins 6 & 8 on its header so I put a USART port there and just have a custom cable that hooks up. I really hate requiring custom cables though so I think when I finish tuning my firmware I will replace the Cortex debugging header with USB since the chip in using supports it natively.
DSC_1549.jpg
SI7232DN is correct, they dump current from the battery side of my LDO and the large Supercapacitors on top is isolated from them at 3.3V so no browning out if there is an igniter hooked up(I hope) .
Yes the flat round thing in the first picture is a little buzzer.
 
I don’t know if id recommend the MS5803 to be honest, its way too expensive and the system noise + Kalman filtering negates and additional accuracy that it gives, unless you just want to use it because it looks cool. If you’re not happy with the Bosh chip your using id take a look at the MS5607, its what’s used by atlus metrum, missile works, and in the raven.

Mostly I was looking for something relatively solderable... The BMP280 is a tiny LGA package that's way smaller than I want to deal with, so I have it on a breakout board. It looks like the MS5607 is the same thing. Any other ideas for barometers in decently usable packages?
 
Mostly I was looking for something relatively solderable... The BMP280 is a tiny LGA package that's way smaller than I want to deal with, so I have it on a breakout board. It looks like the MS5607 is the same thing. Any other ideas for barometers in decently usable packages?

You might want to look at the MS5637, it's only four pads and they're on the corners so you can probably hand solder it if you tin the pads first and reheat them. You certainly can do it with a hot air tool.
 
You might want to look at the MS5637, it's only four pads and they're on the corners so you can probably hand solder it if you tin the pads first and reheat them. You certainly can do it with a hot air tool.

That looks promising... I'm not a huge fan of I2C because of the need to keep track of addresses, but that looks to be pretty manageable assembly wise. I still have a few feet of your solder left over from my Eggfinder... I'll have to give it a try and see how much fiddling it takes, keeping in mind that this may be eventually going in a kit... I'm trying to keep everything around egg-level difficulty- how do you think this compares to a GPS module?
 
Last edited:
That looks promising... I'm not a huge fan of I2C because of the need to keep track of addresses, but that looks to be pretty manageable assembly wise. I still have a few feet of your solder left over from my Eggfinder... I'll have to give it a try and see how much fiddling it takes, keeping in mind that this may be eventually going in a kit... I'm trying to keep everything around egg-level difficulty- how do you think this compares to a GPS module?

Judging by the 0604 SMT passives, the .80mm pitch parts, and the proximity of the parts, I think your soldering skills are beyond most of my customers (and possibly mine). I try to avoid anything smaller than 1.27mm pitch and 0805 SMT's.
 
Judging by the 0604 SMT passives, the .80mm pitch parts, and the proximity of the parts, I think your soldering skills are beyond most of my customers (and possibly mine). I try to avoid anything smaller than 1.27mm pitch and 0805 SMT's.

slaak's maybe... Mine not so much. slaak- sorry for completely hijacking this thread!

Should we discuss this in the ArdIU thread instead of here?
 
Mostly I was looking for something relatively solderable... The BMP280 is a tiny LGA package that's way smaller than I want to deal with, so I have it on a breakout board. It looks like the MS5607 is the same thing. Any other ideas for barometers in decently usable packages?

The MS5803 might be your best bet if your looking to use a soldering iron, those little mouse bites on the side of the of the board give you a little bit of access to the pcb pad. I’d definitely opt to using solder paste and not a stick for something like that thought. Just a dab of paste on each pad, put the component down and touch tap the metal part of the mouse bite should be enough to flow the paste.
Judging by the 0604 SMT passives, the .80mm pitch parts, and the proximity of the parts, I think your soldering skills are beyond most of my customers (and possibly mine). I try to avoid anything smaller than 1.27mm pitch and 0805 SMT's.
I think only 3 of the passives on there are 0604 actually, the rest are 0402 :p (< -- the tongue out is actually pretty key to proper placements I’ve found). It definitely took some practice to get to where I could do 0402 and 0.5mm pitch QFN consistently, I’ve got plenty of boards laying around with globs of solder and burnt components on them :)

slaak's maybe... Mine not so much. slaak- sorry for completely hijacking this thread!

Should we discuss this in the ArdIU thread instead of here?

Any discussion is good with me! I went looking to see if I could find a suitable through hole pressure sensor for you after you asked that earlier (I couldn’t sadly) and realized that I have made a pretty stupid oversight in selecting the pressure sensor I’m using. When I was setting up a test circuit for this altimeter I bought the MS5607 breakout from sparkfun and for whatever reason they used the 14 bar version of the sensor and when I looked it up on digikey the only stock the 1 bar and 14 bar so I picked the 14. Anyways today on my search I realized there is a 2 bar version that digikey doesn’t stock and it is way more suited for an altimeter and has much higher resolution at quicker speeds. The primary bottleneck in my firmware right now is waiting for that dang pressure sensor to convert its value, but If I use the 2 bar version even on its lowest setting I can get three times the accuracy in 1/8th the time. So im actually pretty stoked you brought that up. Also feel pretty stupid for not realizing there was a better option out there.
 
Very nice! Looks like you are well on your way. Making your own flight computer can be fun and rewarding, but nerve wracking too! I've spent about 2 years working on mine and have got it pretty fine tuned. Here's a video from Airfest where it went Mach 2.0 and 18K ft.

[YOUTUBE]RWzlSlwZqlI[/YOUTUBE]

I get about 700 samples per second from the accelerometers and gyro, sample the baro sensor at 20 Hz, mag and GPS at 8Hz. I use LoRa telemetry (just like the new Featherweight system) to feed me UBLOX GPS coordinates and flight data to the ground station. I record everything to the onboard SD card, and pull flight settings from the SD card too. The ground station also records the flight data in case I lose the rocket or onboard data (as in a power loss).

I just got quaternion differentiation to work (finally) and it seems very accurate at just 100 integrations per second. My old simple algorithm was a bit rough, but did well enough for tilt-lockout of my 2-stage HPR flights.

Here's a link to my Github page: https://github.com/SparkyVT/HPR-Rocket-Flight-Computer
It has my code in it, though I suspect you don't need it. My coding skills are rudimentary at best. I'll post the new code with quaternions in a few days.

I'm always impressed by what you pro's come up with, especially how small you can make it. My system is HUGE and takes up quite a bit of space with all the breakout boards and what-not.
 
Very nice! Looks like you are well on your way. Making your own flight computer can be fun and rewarding, but nerve wracking too! I've spent about 2 years working on mine and have got it pretty fine tuned. Here's a video from Airfest where it went Mach 2.0 and 18K ft.

[YOUTUBE]RWzlSlwZqlI[/YOUTUBE]

I get about 700 samples per second from the accelerometers and gyro, sample the baro sensor at 20 Hz, mag and GPS at 8Hz. I use LoRa telemetry (just like the new Featherweight system) to feed me UBLOX GPS coordinates and flight data to the ground station. I record everything to the onboard SD card, and pull flight settings from the SD card too. The ground station also records the flight data in case I lose the rocket or onboard data (as in a power loss).

I just got quaternion differentiation to work (finally) and it seems very accurate at just 100 integrations per second. My old simple algorithm was a bit rough, but did well enough for tilt-lockout of my 2-stage HPR flights.

Here's a link to my Github page: https://github.com/SparkyVT/HPR-Rocket-Flight-Computer
It has my code in it, though I suspect you don't need it. My coding skills are rudimentary at best. I'll post the new code with quaternions in a few days.

I'm always impressed by what you pro's come up with, especially how small you can make it. My system is HUGE and takes up quite a bit of space with all the breakout boards and what-not.

Thats awesome Sparky! Its great to see that there is an end in sight where i might actually get to use this dang thing, feels like its been dragging out forever. It looks like your system does a heck of a lot, I've tried to integrate a telemetry link on the same board as the altimeter a couple times but couldn't get a very clean transmission with all the sensor noise.
What are you doing to filter your sensor data? I didnt see anything about a kalman filter but i bet that floating point unit on the teensy could crank out the kalman transformations pretty quick.
 
Thats awesome Sparky! Its great to see that there is an end in sight where i might actually get to use this dang thing, feels like its been dragging out forever. It looks like your system does a heck of a lot, I've tried to integrate a telemetry link on the same board as the altimeter a couple times but couldn't get a very clean transmission with all the sensor noise.
What are you doing to filter your sensor data? I didnt see anything about a kalman filter but i bet that floating point unit on the teensy could crank out the kalman transformations pretty quick.

Yes, the FPU on the Teensy is pretty incredible; definitely cranks out the quaternion math in a hurry. Beats the heck out of the Arduino floating point math.

I haven't implemented a Kalman filter mostly because I haven't needed it yet. Its on my list of software upgrades though.

I don't filter any of the raw sensor data. I'm really only using the LSM303 accelerometer, BMP180 barometer, and L3GD20H gyro for most flights. I think they have some noise reduction behind the scenes because they are all pretty stable. The ADXL377 and ADS1115 are really only needed for extreme flights. I've done some recent work to calibrate the accelerometers and gyro better (and automatically) which helped get my integrated altitude closer to reality. I'm still working on it though and hope to get it within about 5%.

As for the telemetry, I really like the LoRa units. They are low power but get good range. On the flight I posted, I received 95% of the data packets at 15% power (30mW). I'm no RF expert (though I am a ham - KK4ELF), but I don't think that power level would interfere much with the sensors. My LoRa unit is a few inches away from my sensors. As with a lot of engineering, it probably depends.

Good luck with your project! Contact me if you think I can help in any way.
 
Seems like its about time for an update.

I think the board is on its fourth iteration since I first posted this, mainly some trace routing optimization and better placement of decoupling capacitors, but I also switched up the barometer for one with a more appropriate range, and went to a more modern and less expensive analog accelerometer its less sensitive at ±200 g but with this microcontrollers ability to oversample upto 18 bits really quickly I can still get some pretty accurate accel data out of it.

On a software side i think the altimeter is about 90% ready to handle dual deployment duties. I've flown it a couple times on some small estes rockets and the data looks beautiful. The logic seems to be detecting liftoff and apogee correctly and the kalman filter is behaving great so far.

Heres a plot from last weekend when i flew it using a Baro only kalman filter, ill probably fly it again this weekend using a baro+accel kalman filter which will switch to baro only after apogee and post that here after the flight.
Capture.jpg

I'm definitely loving the size of this altimeter, it easily fits in the 38mm coupler of my test rocket and I think it could work in a 29mm coupler with a little creativity as well.
20180424_191250.jpg
20180424_191420.jpg
20180424_191458.jpg
 
Bonus FrankenRocket picture that i'm using for testing at the moment.
20180424_195033.jpg
 
Heres a plot from last weekend when i flew it using a Baro only kalman filter, ill probably fly it again this weekend using a baro+accel kalman filter which will switch to baro only after apogee and post that here after the flight.
View attachment 343363

Um, if I am reading your plot correctly, the velocity curve looks suspicious. I assume it is derived from the baro altitude. 5 seconds to reach max velocity for an Estes rocket? Velocity at apogee equals 60 ft/s?
 
Um, if I am reading your plot correctly, the velocity curve looks suspicious. I assume it is derived from the baro altitude. 5 seconds to reach max velocity for an Estes rocket? Velocity at apogee equals 60 ft/s?

Your definitely correct to be skeptical of that velocity curve. Its coming from the output of the Kalman filter so it makes sense that the velocity would lag behind at apogee but its further off than it should be. I hadn't really considered how far off the velocity data was from real life before your comment. Im going to have to set up the program to switch to a different set of kalman gains when its in baro only mode, the velocity is really far off in this graph because it was using the gains calculated for baro+accel readings and its state equations. The baro only mode would normally only be used on the way down when acceleration should be relatively unchanging so leaving the incorrect gains in there might not make a huge difference anyway
 
I took the altimeter for another flight this morning to test out the liftoff and apogee detection with the kalman filter and it seems to of worked like a charm. The data from the ascent looks really good and the velocity isn't all screwed up this time, using the kalman filters velocity with velocity < 0 as the apogee trigger worked perfectly.
flight 2 accent.jpg

I still have some work to do on my filtering during the descent, i tried to set up a seperate kalman filter with a different set for state equations and gains for when the rocket was on its way down running on baro only but i seemed to of made a mistake somewhere. It looks like the state equations are not responding nearly enough to the barometer input so im going to have to look over my code again.
flight 2 with raw overlay.jpg
In this graph the yellow line is raw barometer data and black is raw acceleration. The raw accel spike just after apogee is the motor ejection and the one at about 17 seconds is when the parachute actually inflated (it got a little tangled opps) and it looks like it hit the ground at about t = 25. You can see how the filtered altitude (blue) starts diverging from the sensor data after apogee and that inturn throws the velocity calculation way off.
 
Back
Top