Lighest Available Altimeter That Records Flight Duration

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Isn't that GPS only and not a combo unit?
I wondered that, but it appears that it does also have a barometric altimeter and that altitude data can be downloaded post flight: https://cdn.shopify.com/s/files/1/0594/0959/6623/files/BMK_SkyLink_434_22_09_2023.pdf?v=1695394791

However there is no accelerometer, and I don't see any evidence of any sort of rocket-specific filtering on the altitude data, which means that the messiness that happens around recovery deployment will likely not be handled well. Or that's what I would expect.
It's been done, just not sure how well it works for rocketry, or whether it's legal in the US.

https://bmks.co.uk/products/bmk-sky...95983&pr_ref_pid=7075076833487&pr_seq=uniform
Based on what Cris Erving sells (and how it differs outside the US) I expect this little goodie is not legal for US use. As I recall he mentioned that in the US, that 434 mHz area is used for cellular communication, and the frequencies his US trackers/telemetry devices use are used for cell phones in Europe/UK. I think that's what he told me/us....

I'm torn between "encouraging" Adrian to work on the Hummingbird actively and trying to leave him alone as he has his own priorities....which are not mine. :rolleyes: :)
 
Last edited:
434 MHz can be used in the US but you need a Ham license. Also, it needs to be able to send out your call sign.

The unlicensed band in the EU/UK that allows 100 mW is on 869 MHz, THAT is not allowed in the US for general use since it's used for cell phones.
 
Thanks for setting me straight, Cris. As is often the case, I remembered the general message but not the details.

I didn't, on first quick pass through that document, see any way to teach the little transmitter one's call sign. So on that basis it would still not be legal for use in the US, even for those of us who have at least a technician class license (and if I had been more up on things I would have remembered that that frequency band was available for amateur radio use.... :oops:

Added: there is an app setting to "rename" a beacon. I wonder if putting one's call sign as the name (or in the name, as in KG7AIE_1) would satisfy the call sign broadcast requirement....
 
That's why we don't sell the GPS "beacon" transmitters on the 70cm Ham band... they can't send out a call sign.
 
Several thoughts.

The BMK Skylink tracker is very similar to the Starlink-Flitetech Pyxis GPS tracker sold here in the U.S. I would very much like a lighter tracker (the Pyxis is 6g with battery) but more importantly I would like a unit small enough to fit in a 13mm tube and a shorter antenna. But the Pyxis unit functions extremely well and is very useful for 18mm and up rockets.

Adrian, I can tell you honestly that fliers routinely overestimate the value of lighter micro-altimeters. The general thought is that if it weighs less it will go higher. While that may be true when comparing a 1.6g Adrel to a 15g PNut, it is definitely not true when comparing a FS Comp to an Adrel. People who believe this have generally designed their rocket independent of altimeter mass. So lessening the altimeter weight a tiny amount will, indeed, make their rocket go a little higher. But this is not optimal design.

The reality is that, with the exception of the "Payload" events, altimeter mass is a critical stability tradeoff item with rocket body tube length and fin size. If I subtract 0.4 g in altimeter weight it means (for the same motor) my body tube will have to be a little longer or my fins will have to be larger, both of which increase drag which usually negates any benefit from a lighter altimeter. The incredibly tiny ultra-lightweight altitude record rockets I fly usually have added noseweight. In thousands of simulations and hundreds of builds my general experience is that for maximum altitude you are usually better to add noseweight to get the rocket as short and fins as tiny as possible. A slightly heavier altimeter (always placed as far forward in the nose as possible) just means slightly less added noseweight.

So, my point is that you shouldn't stress trying to shave another fraction of a gram off your altimeter for competition reasons. Concentrate instead on functionality.

All that being said I understand that there is probably a marketing advantage selling the lightest altimeter. I know that was true for the FS Comp which I was never a real fan of, for functionality reasons. I don't know if this truly helps but I wanted to add my 2 cents because my altimeter experience is different from most. Happy to answer any questions you may have about this issue or FAI stuff. Really happy to see you working on this.

Steve
 
One more note, about the Russian altimeters. Glad to see they have been able to produce one locally. World events aside, I have a number of good friends on the Russian team. For years I was their conduit for Firefly altimeters and readers for their altitude events. I probably sent them 30 over the years in several lots. I wondered what they've been doing for altimeters since all communication was cut off by the Russian government 3 years ago.

The Fireflys are just barely small enough to fit in an 18mm S1 sustainer. Too long, but workable, and nothing beat them on price. They're great units and I bet they're still functioning.
 
I wondered that, but it appears that it does also have a barometric altimeter and that altitude data can be downloaded post flight: https://cdn.shopify.com/s/files/1/0594/0959/6623/files/BMK_SkyLink_434_22_09_2023.pdf?v=1695394791

However there is no accelerometer, and I don't see any evidence of any sort of rocket-specific filtering on the altitude data, which means that the messiness that happens around recovery deployment will likely not be handled well. Or that's what I would expect.
What kind of barometric messiness are you referencing around recovery deployment? I record small fluctuations from the ejection charge and shock cord oscillations, but nothing messy. I don't use any rocket specific filters with my DIY projects, other than high-speed data collection at 80Hz.
 

Attachments

  • Altimeter.png
    Altimeter.png
    85.5 KB
What kind of barometric messiness are you referencing around recovery deployment? I record small fluctuations from the ejection charge and shock cord oscillations, but nothing messy. I don't use any rocket specific filters with my DIY projects, other than high-speed data collection at 80Hz.
John --

I wondered about the messiness as well but then I recalled reading here on TRF that competition fliers sometimes mount their altimeters to the shock cord ...

Maybe ?

-- kjh
 
John --

I wondered about the messiness as well but then I recalled reading here on TRF that competition fliers sometimes mount their altimeters to the shock cord ...

Maybe ?

-- kjh
I've heard the same thing with competition fliers. I have never attempted such a mounting location, but I can see it producing large over pressure fluctuations plus damage to the sensor. I record a venturi induced under-pressure event before the ejection charge over pressure cloud reaches the barometric sensor.
 
What kind of barometric messiness are you referencing around recovery deployment?
When the altimeter just has some wadding around it and placed the the body tube with the parachute; it sees pressure waves from the, powder burn, ejection event, nose separation, at end of cord, as parachute opens, etc.

Also if placed too close to the parachute (ie parachute, Altimeter, and shock cord all attached to loop on nosecone) then the "high pressure" area under the parachute can give a slightly lower than actual altitude reading. (In this case an severely oscillating chute will show up as steps in the descent trace.)
 
What kind of barometric messiness are you referencing around recovery deployment? I record small fluctuations from the ejection charge and shock cord oscillations, but nothing messy. I don't use any rocket specific filters with my DIY projects, other than high-speed data collection at 80Hz.
Well....several things. Barometric sensors are sensitive to being shaken around. Almost all deployment events involve some mechanical chaos even if they are perfectly timed. In competition, especially pure altitude competition, the ejections are almost always too early, so the mechanical chaos is heightened.

Also, not all ejections are timed right in other situations...and again there is a bunch going on for either early or late deployments.

Now...add in that the altimeter may not be in a separate compartment from the ejection gases. If the nose cone/payload section is the slightest bit reluctant to come off, then the place where it is will be pressurized above ambient for a brief moment. This shows up as a big downward spike in unfiltered altimeter data. Depending on the dynamics of the gases, the opposite can also occur (a slight vacuum is pulled, making the reported altitude spike upward).

Every commercial altimeter maker, at least those making altimeters where the actual reported altitude is the data we're looking for (as opposed to just trying to time a deployment charge) have some kind of filtering to smooth out/eliminate these sudden transients that come from sudden pressure or mechanical shocks.

I'll attach a few examples that I can locate quickly. I don't have time right now to do a bunch of searching. i'm trying to get ready for club launch tomorrow and a 10-day trip to the ocean the next day.

The first two compare an intentionally short-delay flight done while helping to get the FlightSketch devices contest accepted. It compares the latest FlightSketch firmware with a PerfectFlite Pnut. The two are plots I made with Magic Plot. NOTE that Perfectflite exports UNfiltered data only via their app. The next shot is what the PerfectFlite app itself shows for that flight — both raw and "smoothed" data. Note that the reported apogee (what a Pnut beeps or a Firefly blinks) is from the smoothed data.

Following that is an unfiltered set of data from an Adrel. Both of those spikes would be smoothed over similarly to what Perfectflite does when the "FILTR" is used. Using the filter is part of the process for recording flight scores at FAI competitions, including the 2023 World Spacemodeling Championships that were held near Austin, Texas, and at which my wife and I were half of the altimeter control team. Myself, @WillMarchant and Dan Wolf split the duty of reading and recording the data for each altitude flight at that event. (My wife had the fun duty of keeping track of who had which altimeter (by serial number) when and managing the "deposits" for the altimeters. I think she had the hardest job.)

The next two are from one flight using an Eggtimer ION, both the full flight and a closeup around apogee. @cerving is the only one whose device exports both unfiltered and filtered data (that I know of), which makes this comparison interesting to plot. His devices beep out and report via their WiFi interface the UNfiltered data, though he recently tweaked the ION firmware to change it to report filtered data....but as far as I know, he hasn't posted that version to his site.

The last is from an AltimeterThree. @John Beans' filter is quite good as one almost never sees any of the big spikes you see in the others with AltimeterThree.

That should get you started....
NovaPayloader5_flt42_apogee.pngNovaPayloader5_flt42_overview.png
Screenshot 2025-01-10 at 12.58.23 PM.png

AthenaPL_flt_3.pngGreenEggs2-flt22-dtl49_altitude.pngGreenEggs2-flt22-dtl49_apogee.pngFlightGraph.png
 

Attachments

  • SRP_flight_35.png
    SRP_flight_35.png
    73.8 KB
Last edited:
Bernard, outstanding! Are you sure you don't want to take me along to the beach so we can discuss this further. ;)

FAI requires altimeters with tracings for all competition flights.
NAR requires altimeters with tracings for all record flights.
The reason is what is so well demonstrated in Bernard's photos. Filtering the pressure spikes is very important, whether a separate altimeter compartment is used or not. Altimeters which solely beep or flash out the altitude are fun, but not trustable. Another benefit of the altimeter tracing is that you can tell what motor was used in the flight, which is why some think the NAR should require them for all competition flights. Not requiring them is an attempt to get more folks interested in altitude competition, which is actually a good enough reason for me.

I routinely fly record attempts without altimeter compartments, although the FAI flights are always contained just because of the nature of the airframes used. For a number of reasons all I use any more on my competition and record flights are Adrels, which do a great job of filtering spikes. The are a bit noisy on the way down (combination of flapping in the breeze and sunlight affect) but that is of no concern. They do a great job of figuring out peak altitude. Having looked at hundreds of tracings I almost never disagree with what the Adrel Filtered altitude reports.

The Adrels are also extremely robust. You will lose them before they go bad. Honestly, I've probably owned 40+ over the last 15 years and have only had a few fail, mostly because of bent pins. Only one that I can recall going bad with good pins. Could that have been from ejection damage, who knows? I even fly some of them in body tubes without wadding. The streamer material I use, aluminized kapton, is heat insensitive so that acts as wadding in many of my flights. Altimeter sits just above the streamer, open in the tube. Sometimes actually folded battery next to altimeter, in a 13mm nosecone. Ability to read well and reusability not an issue. I've also actually had one run over by a truck with no ill effect so when I say they are robust, I'm not kidding.

So to get back to Bernard's main point, for rocketry altimeters demonstrating the ability to effectively deal with ejection spikes is very important. As far as we can tell the new Serbian altimeters we will be using were tested only in drones. Not very comforting.
 
Bernard, outstanding! Are you sure you don't want to take me along to the beach so we can discuss this further. ;)
Pop on over. We'll have room. Beachcomber Resort, Ocean Shores, Washington.
The Adrels are also extremely robust. You will lose them before they go bad. Honestly, I've probably owned 40+ over the last 15 years and have only had a few fail, mostly because of bent pins. Only one that I can recall going bad with good pins. Could that have been from ejection damage, who knows? I even fly some of them in body tubes without wadding. The streamer material I use, aluminized kapton, is heat insensitive so that acts as wadding in many of my flights. Altimeter sits just above the streamer, open in the tube. Sometimes actually folded battery next to altimeter, in a 13mm nosecone. Ability to read well and reusability not an issue. I've also actually had one run over by a truck with no ill effect so when I say they are robust, I'm not kidding.
We had a couple during the WSMC whose LEDs stopped working, but they still operated fine. We held them out until we had to use them, which happened on S2/P day when both Jrs. and Srs. were doing the event the same time. We did also have one come back that was bent enough that trying to straighten pins didn't end well. They are tough little buggers. I'm sure their being essentially potted in epoxy everywhere they can be helps that.

To to get back to Bernard's main point, for rocketry altimeters demonstrating the ability to effectively deal with ejection spikes is very important. As far as we can tell the new Serbian altimeters we will be using were tested only in drones. Not very comforting.
This is why I'm also skeptical about the tiny GPS trackers/altimeters we've been discussing a little further up in this thread being suitable for rocketry uses, at least from the altimetry perspective. They could be super trackers.
 
Well....several things. Barometric sensors are sensitive to being shaken around. Almost all deployment events involve some mechanical chaos even if they are perfectly timed. In competition, especially pure altitude competition, the ejections are almost always too early, so the mechanical chaos is heightened.

Also, not all ejections are timed right in other situations...and again there is a bunch going on for either early or late deployments.

Now...add in that the altimeter may not be in a separate compartment from the ejection gases. If the nose cone/payload section is the slightest bit reluctant to come off, then the place where it is will be pressurized above ambient for a brief moment. This shows up as a big downward spike in unfiltered altimeter data. Depending on the dynamics of the gases, the opposite can also occur (a slight vacuum is pulled, making the reported altitude spike upward).

Every commercial altimeter maker, at least those making altimeters where the actual reported altitude is the data we're looking for (as opposed to just trying to time a deployment charge) have some kind of filtering to smooth out/eliminate these sudden transients that come from sudden pressure or mechanical shocks.

I'll attach a few examples that I can locate quickly. I don't have time right now to do a bunch of searching. i'm trying to get ready for club launch tomorrow and a 10-day trip to the ocean the next day.

The first two compare an intentionally short-delay flight done while helping to get the FlightSketch devices contest accepted. It compares the latest FlightSketch firmware with a PerfectFlite Pnut. The two are plots I made with Magic Plot. NOTE that Perfectflite exports UNfiltered data only via their app. The next shot is what the PerfectFlite app itself shows for that flight — both raw and "smoothed" data. Note that the reported apogee (what a Pnut beeps or a Firefly blinks) is from the smoothed data.

Following that is an unfiltered set of data from an Adrel. Both of those spikes would be smoothed over similarly to what Perfectflite does when the "FILTR" is used. Using the filter is part of the process for recording flight scores at FAI competitions, including the 2023 World Spacemodeling Championships that were held near Austin, Texas, and at which my wife and I were half of the altimeter control team. Myself, @WillMarchant and Dan Wolf split the duty of reading and recording the data for each altitude flight at that event. (My wife had the fun duty of keeping track of who had which altimeter (by serial number) when and managing the "deposits" for the altimeters. I think she had the hardest job.)

The next two are from one flight using an Eggtimer ION, both the full flight and a closeup around apogee. @cerving is the only one whose device exports both unfiltered and filtered data (that I know of), which makes this comparison interesting to plot. His devices beep out and report via their WiFi interface the UNfiltered data, though he recently tweaked the ION firmware to change it to report filtered data....but as far as I know, he hasn't posted that version to his site.

The last is from an AltimeterThree. @John Beans' filter is quite good as one almost never sees any of the big spikes you see in the others with AltimeterThree.
Thanks for the information. The raw unfiltered data and smoothed data gives me insight to the filtering methods being used. I don't agree with the exposure of barometric sensors to ejection charge gases, unless the sensor has a gel transfer medium. My opinion as a fluidics engineer in semiconductor manufacturing (retired).

I did find the Nova Payloader data very interesting. I converted a Mongoose to carry a DIY flight computer. I was wondering what the altitude penalty was for the 29 gram flight computer, not much.
 

Attachments

  • Mongoose Flight 5.png
    Mongoose Flight 5.png
    309.3 KB
You have calculated altitude transients in your flight data there as well as lots of craziness in accelerometer data around ejection. You even have several meter spikes in the data you posted when you asked the question. Contest altimeters typically aim for less than 1m error. Since that is the sort of altimeter this discussion has been about (mostly), dealing with even "small fluctuations" is important so that all contestants can trust the values.

In your Mongoose data above, at least the spikes at ejection in the altitude trace don't go above what I take to be the real apogee, which happened earlier. But you can't count on that happening. As I mentioned before, in pure altitude competition delays are almost invariably too short....which is why, I think, that Adrel created the device that NCR sells as the MaxDeploy. It's essentially an Adrel ALT-BMP that can fire a single pyro charge.

As for the penalty of 29 grams: that's a significant weight penalty for a model the size of the Nova Payloader (or the Mongoose, for that matter). Even with motor mass included that is ~30-40% over the liftoff mass it would have without one that heavy. This is why the Eggtimer ION is not a good candidate for small models if performance is to be maximized. An FS Comp is slightly less than 1g, and it looks like Adrian is headed in the same direction. An Adrel, with its standard 23 mAh cell is ~1.5g.
 
You have calculated altitude transients in your flight data there as well as lots of craziness in accelerometer data around ejection. You even have several meter spikes in the data you posted when you asked the question. Contest altimeters typically aim for less than 1m error. Since that is the sort of altimeter this discussion has been about (mostly), dealing with even "small fluctuations" is important so that all contestants can trust the values.

In your Mongoose data above, at least the spikes at ejection in the altitude trace don't go above what I take to be the real apogee, which happened earlier. But you can't count on that happening. As I mentioned before, in pure altitude competition delays are almost invariably too short....which is why, I think, that Adrel created the device that NCR sells as the MaxDeploy. It's essentially an Adrel ALT-BMP that can fire a single pyro charge.

As for the penalty of 29 grams: that's a significant weight penalty for a model the size of the Nova Payloader (or the Mongoose, for that matter). Even with motor mass included that is ~30-40% over the liftoff mass it would have without one that heavy. This is why the Eggtimer ION is not a good candidate for small models if performance is to be maximized. An FS Comp is slightly less than 1g, and it looks like Adrian is headed in the same direction. An Adrel, with its standard 23 mAh cell is ~1.5g.
3.8g sustainer.jpeg
Bernard, I know for many it's hard to conceive of models as small as we fly. The one above is 3.8 g, missing only altimeter and motor. The mass and position of the altimeter as far forward as possible in the nose and the overhang of the motor (yes, its measured before the motor is put in) is absolutely critical to stability in models this small. A 29 gram altimeter (equivalent to 7 of these models on the scale at once) would be a bit of a weight penalty.
 
You have calculated altitude transients in your flight data there as well as lots of craziness in accelerometer data around ejection. You even have several meter spikes in the data you posted when you asked the question. Contest altimeters typically aim for less than 1m error. Since that is the sort of altimeter this discussion has been about (mostly), dealing with even "small fluctuations" is important so that all contestants can trust the values.

In your Mongoose data above, at least the spikes at ejection in the altitude trace don't go above what I take to be the real apogee, which happened earlier. But you can't count on that happening. As I mentioned before, in pure altitude competition delays are almost invariably too short....which is why, I think, that Adrel created the device that NCR sells as the MaxDeploy. It's essentially an Adrel ALT-BMP that can fire a single pyro charge.

As for the penalty of 29 grams: that's a significant weight penalty for a model the size of the Nova Payloader (or the Mongoose, for that matter). Even with motor mass included that is ~30-40% over the liftoff mass it would have without one that heavy. This is why the Eggtimer ION is not a good candidate for small models if performance is to be maximized. An FS Comp is slightly less than 1g, and it looks like Adrian is headed in the same direction. An Adrel, with its standard 23 mAh cell is ~1.5g.
Craziness during this flight is the appropriate word. The Mongoose nose cone broke off at ~2.65 seconds. The Cd went from ~1.32 to ~2.13. Air flow over the vent port was highly turbulent. I'm amazed that it reached 540 feet with a concave nose plug. This is my first flight where I recovered data after a nose cone separation. Previous flights on other vehicles resulted in loss of data and flight computer. I need to study the spikes and run more simulations to understand the flow dynamics. The flight was only 3 weeks ago. The small fluctuations are not g load related. I've subjected Bosch barometric sensors to 900 g's without it affecting the output values.

I agree that motor pyro delays can vary by ±10%. I recently experienced variations of ±450 ms for C6-5 motors from the same production lot. I'm updating my 18mm & 24mm flight computers with air bag deployment drivers for dual deployment experience.

Attached is an altimeter project I was an advisor on a few years ago. Very similar to the Adrel, ~1.5g w/cell.
 

Attachments

  • Micro Insight.png
    Micro Insight.png
    329.9 KB
View attachment 688498
Bernard, I know for many it's hard to conceive of models as small as we fly. The one above is 3.8 g, missing only altimeter and motor. The mass and position of the altimeter as far forward as possible in the nose and the overhang of the motor (yes, its measured before the motor is put in) is absolutely critical to stability in models this small. A 29 gram altimeter (equivalent to 7 of these models on the scale at once) would be a bit of a weight penalty.
Nice looking rocket. Light enough to loft with one of my 8mm motors. What size motor do you use, and altitude do you expect?
 

Attachments

  • 20250112_083546[1].jpg
    20250112_083546[1].jpg
    1.9 MB
Craziness during this flight is the appropriate word. The Mongoose nose cone broke off at ~2.65 seconds. The Cd went from ~1.32 to ~2.13. Air flow over the vent port was highly turbulent. I'm amazed that it reached 540 feet with a concave nose plug. This is my first flight where I recovered data after a nose cone separation. Previous flights on other vehicles resulted in loss of data and flight computer. I need to study the spikes and run more simulations to understand the flow dynamics. The flight was only 3 weeks ago. The small fluctuations are not g load related. I've subjected Bosch barometric sensors to 900 g's without it affecting the output values.
That's pretty amazing — that the sensor took that many g's without perturbing the output. Perhaps with modern sensors, that portion of the explanation for the chaos in data around ejection is outdated.
I agree that motor pyro delays can vary by ±10%. I recently experienced variations of ±450 ms for C6-5 motors from the same production lot. I'm updating my 18mm & 24mm flight computers with air bag deployment drivers for dual deployment experience.
Half a second is good. I've seen much more than that. The certification guidelines from the National Fire Protection Association are ±20% or ±1.5s, whichever is greater up to a total of 3 seconds. I have seen variations outside that tolerance in 18mm model rocket motors, both via accelerometer data in flight and in some static tests. Some motors and some batches are nicely consistent. Others, not so much. And aging motors, especially composite ones, can be worse.
Attached is an altimeter project I was an advisor on a few years ago. Very similar to the Adrel, ~1.5g w/cell.
I like it! I don't suppose you're going to market that are you? :)
 
That's pretty amazing — that the sensor took that many g's without perturbing the output. Perhaps with modern sensors, that portion of the explanation for the chaos in data around ejection is outdated.

I like it! I don't suppose you're going to market that are you? :)
I tested 7 BMP280 sensors at 700 g's, two were further tested at 900 g's. One of the 700 g sensors did stop functioning a year later. One of the 900 g test sensors, I continue to use as a reference sensor. These tests were conducted in 2019. I had plans to test the TE Connectivity MS5611 sensor, but COVID, cost, and moving to Texas stopped the testing.


I would love to import the Micro InSight altimeter but shipping them in from Russia has been a problem.
 
Back
Top