Looking for volunteers to test a new altimeter

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
It's actually a very good idea and one of the methods that was evaluated. The issue arrises with the "after boost" part. You don't know when "after boost" is yet so it started by scaling a generic thrust curve and then fitting a least squares model for burn time, avg thrust/mass, and a (Cd*A)/m term. It actually worked surprisingly well for max speed but it could get tricked and trade burn time vs thrust, e.g. it would occasionally fit to a high thrust, short burn curve that gave a very similar coast to apogee.

The way it's currently implemented is much simpler and so far more reliable. The assumption is the acceleration is constant over a short interval. Integrating twice says you expect a 2nd order polynomial for altitude. You fit a least squares polynomial to the altitude data over that time interval and then going backwards, the first derivative of that function at the midpoint is the velocity and the 2nd derivative is the acceleration. You then slide over one time step and repeat for all of the data. If you only care about the velocity, it still works quite well with just a linear regression through the altitude data in the interval. For the Mini though, the accel term is also used to estimate the burn time and the 2nd order fit is still fairly easy to implement in code.

And this is why it's a good thing that these things are being implemented by people smarter than me. :) Seriously, looks like a great product.
 
Plus, it's not certified by the NAR for use in competition, yet . . .
What does NAR competition certification have to do with the price of beans in china? This is a beta testing process for a new altimeter and the Estes altimeters are crap, if the Estes Alts are certified for contest use, then the folks using them are giving themselves a huge handicap...

An $18 more capable and reliable altimeter is better than a $30 sometimes works/sometimes doesn't altimeter any day.
 
Why would anyone pay $30 for an Estes altimeter when Russ' $18 product does so much more?

Well, Russ's product is not yet commercially available.

What does NAR competition certification have to do with the price of beans in china?

Rich,

Have you ever flown NAR Competition ? ( note my NAR # 26128, since 1974, when Competition was much more prevalent and HPR did not exist )

I answered the initial quoted question with a valid reason, at this point in time. If he gets it approved by NAR for Competition, that would be great for those flyers !

Some altimeter info in the PDF below . . .

Dave F.
 

Attachments

  • Electronics_Comparison_Chart.pdf
    71.1 KB · Views: 45
Last edited:
I answered the initial quoted question with a valid reason

Uhh, no you didn't. The initial question was about the Estes altimeter which is not approved for competition, either.

What does NAR competition certification have to do with the price of beans in china?

Absolutely nothing. It is just Dave trolling around again and throwing red herrings into the conversation.
 
Rich,

As Buckeye noted, the Estes Altimeter isn’t approved for contest use. Only current generation PerfectFlite devices (APRA, Pnut, FireFly, Stratologger), the Altus Metrum MicroPeak, Jolly Logic Altimeters One, Two and Three, and the current-generation Adrel BMP are. https://www.nar.org/contest-flying/...pendix-e-altimeters-approved-for-contest-use/

After the FS Mini gets into production then we can cross that bridge. While it’s slightly bigger than the most commonly used competition devices (I worked returns at NARAM-60 and saw mostly FireFlys and MicroPeaks with the occasional Adrel BMP) it will actually fit in a smaller diameter tube than a FireFly. Being able to read it without accessing it physically could also be an advantage. My only concern is the last requirement in the list in 20.2 here: https://www.nar.org/contest-flying/...ting-code/altitude-competition/altitude-data/ as there is no indication on the FS Mini (at least in its current form) of its state. One can’t tell even if it’s powered up, never mind whether it’s armed for launch, by looking at it or listening to it. So....one thing at a time at least with respect to competition use.

That said, you are absolutely correct that this unit, at least for those of us who carry iPhones, blows away the gives-reasonable-data-when-it-works-but.... Estes Altimeter and gives the others anywhere near its price point a run for their money. I am looking forward to using it quite a bit.

Dave,

Some updates for your chart:

FireFly: first of all, it IS approved for TARC use since at least last year (and we saw several of them at the finals last year). Also, with the Field Data Display (https://www.perfectflitedirect.com/firefly-field-data-display/), it can be read in metric units, and the time to apogee and flight time are also available (and the peak speed value is still available after a power cycle).

Pnut: current devices charge via USB.

AltimeterThree uses the accelerometer for launch detect, similar to AltimeterTwo.

MicroPeak has been $35 for some time, no longer $50.

Russ,

Sorry for the thread drift......!
 
Last edited:
Rich,

As Buckeye noted, the Estes Altimeter isn’t approved for contest use. Only current generation PerfectFlite devices (APRA, Pnut, FireFly, Stratologger), the Altus Metrum MicroPeak, Jolly Logic Altimeters One, Two and Three, and the current-generation Adrel BMP are. https://www.nar.org/contest-flying/...pendix-e-altimeters-approved-for-contest-use/

After the FS Mini gets into production then we can cross that bridge. While it’s slightly bigger than the most commonly used competition devices (I worked returns at NARAM-60 and saw mostly FireFlys and MicroPeaks with the occasional Adrel BMP) it will actually fit in a smaller diameter tube than a FireFly. Being able to read it without accessing it physically could also be an advantage. My only concern is the last requirement in the list in 20.2 here: https://www.nar.org/contest-flying/...ting-code/altitude-competition/altitude-data/ as there is no indication on the FS Mini (at least in its current form) of its state. One can’t tell even if it’s powered up, never mind whether it’s armed for launch, by looking at it or listening to it. So....one thing at a time at least with respect to competition use.

Dave,

Some updates for your chart:

FireFly: first of all, it IS approved for TARC use since at least last year (and we saw several of them at the finals last year). Also, with the Field Data Display (https://www.perfectflitedirect.com/firefly-field-data-display/), it can be read in metric units, and the time to apogee and flight time are also available (and the peak speed value is still available after a power cycle).

Pnut: current devices charge via USB.

AltimeterThree uses the accelerometer for launch detect, similar to AltimeterTwo.

MicroPeak has been $35 for some time, no longer $50.

Russ,

Sorry for the thread drift......!

Russ,

Thank you for addressing my legitimate concern, regarding the altimeter and its current certification status, in a professional and courteous manner.

Hopefully, in the near future, this altimeter, and the ones that follow it, will be certified for NAR Competition !

Also, thank you for the updates to the comparison chart !

Best Wishes,

Dave F.
 
Bernard gets the credit for the data!

- I do enjoy seeing where the interest is in this area. I had not really considered NAR certification before. When I first read the requirements, it sounded like direct reading of altitude from the unit was required. Reading again, maybe the Mini could qualify. If there is sufficient interest, I would certainly look into certification. There is always the option for a smaller, lighter competition version if you are willing to trade convenience for performance. 13mm maybe?

How many of you are flying competition?
 
For the velocity profile, again your comment is the essence of why FlightSketch exists. For baro only units available today, that statement might be true. It is certainly not against the laws of physics though to calculate a velocity from a change in altitude over a change in time. The pressure lags we've seen are actually not that common, at least in the body of test models flown so far.
-Russ

It was just a suggestion, hopefully not a discouragement.

In some modes (if I remember correctly Raptor, Helicopter, Glider, Kite, Quadcopter, Experimental) AltimeterThree has a Climb/Sink graph which does what you're doing here. Those hobbies appreciate climb/sink rates, and understand that they are "changes in altitude," not speed.

Do rocketeers understand that your velocity is an abstracted vertical vector? Dunno. Consider that a rocket that weathervanes and arcs over at apogee will show zero velocity on your graph (and then negative velocity) even as the rocket may arc over and eject at high speed, causing a zipper.

For Rocket mode, I've chosen to only use the accelerometer for speed, and only up until boost (when the velocity vector can be safely assumed to be vertical (ish).

For what it's worth. Again, not to discourage. Keep going!
 
Do rocketeers understand that your velocity is an abstracted vertical vector? Dunno. Consider that a rocket that weathervanes and arcs over at apogee will show zero velocity on your graph (and then negative velocity) even as the rocket may arc over and eject at high speed, causing a zipper.

For Rocket mode, I've chosen to only use the accelerometer for speed, and only up until boost (when the velocity vector can be safely assumed to be vertical (ish).

John - thanks for that. That clarifies something that was nagging around the edges of my mind but that I hadn't yet articulated. With barometric only it's the VERTICAL component of velocity, not the actual velocity (whose vector could be pointed up to 180 degrees from positive vertical in the worst case) that is being measured and plotted this way.

A really stable model on a windy day, or a multi-stager that arcs over may well be going quite fast at apogee.....hmmmmmmmm

Bernard gets the credit for the data!

- I do enjoy seeing where the interest is in this area. I had not really considered NAR certification before. When I first read the requirements, it sounded like direct reading of altitude from the unit was required. Reading again, maybe the Mini could qualify. If there is sufficient interest, I would certainly look into certification. There is always the option for a smaller, lighter competition version if you are willing to trade convenience for performance. 13mm maybe?

How many of you are flying competition?

I suspect that the competition flyers, especially those looking for an alternative to stuff that is already out there, are a pretty small market. That said, the only thing that will fit in a 13mm tube that is available today is the Adrel.

I, myself, am an occasional competitor. There's not any going on in the area here at the moment though there have been a couple of attempts to revive competition in the 10 years I've been back to rockets. Otherwise, I've only flown competition at NARAM, and then only twice—though I am currently planning to go to NARAM-61 this year.

The NAR competition altimeter requirements have changed (and in some ways simplified) fairly recently. The requirement to read out directly from the altimeter disappeared with the last round of revisions. I suspect this was done to accommodate the Adrel-BMP, since it is used (exclusively, I think) in international competitions. It can only be read by downloading to a Windows-based computer. But by relaxing that requirement AltimeterThree also became eligible for NAR competition. FS Mini still needs to indicate readiness on the device (as I pointed to earlier)....but it might be plausible to get an exception for this requirement to be on the device in a similar way. I can ping a couple of folks and see what they think.....
 
- I do enjoy seeing where the interest is in this area. I had not really considered NAR certification before. When I first read the requirements, it sounded like direct reading of altitude from the unit was required. Reading again, maybe the Mini could qualify. If there is sufficient interest, I would certainly look into certification. There is always the option for a smaller, lighter competition version if you are willing to trade convenience for performance. 13mm maybe?

How many of you are flying competition?

It's great to see that you have interest in possible certification for NAR Competition . . .

According to articles I have read in the past 3-5 years, there are probably 600 - 1000 NAR Competition flyers, across the USA. Understandably, most of them are unable to attend NARAM's, for various reasons.

This number, in my opinion, could be greatly increased, if local clubs took an interest in Competition, as opposed to only Sport Flying of LPR / MPR & HPR . . . Unless, the Clubs actively promote Competition, interest will not grow significantly.

Frankly, I'd like to see Competition events added to HPR in the future !

Smaller and lighter is always a welcome feature, even for non-competition flyers !

Dave F.
 
There needs to be a standard format and API for flight data (if there isnt already). Have you considered publishing your API and format for anyone to log flight data?

If the major vendors could agree on a format and a central repository location it would be beneficial to everyone in the hobby and industry.
 
There needs to be a standard format and API for flight data (if there isnt already). Have you considered publishing your API and format for anyone to log flight data?

If the major vendors could agree on a format and a central repository location it would be beneficial to everyone in the hobby and industry.

Absolutely. The APIs are already publicly accessible. Documentation will be released whenever I have time to work it.

I have been busy this week trying to get all the motors and kits on the store so this sort of thing is on the back burner. Getting the Mini released is still priority but I would be happy to send you some info to get started. Same goes for anyone that would like to help develop or use the service.

My goal would be to have users upload any (known) format on the web and we would convert to our standard behind the scenes. If other vendors are interested in direct uploads, I would certainly support that as well.

Russ
 
There needs to be a standard format and API for flight data (if there isnt already). Have you considered publishing your API and format for anyone to log flight data?

If the major vendors could agree on a format and a central repository location it would be beneficial to everyone in the hobby and industry.

My two cents is that it's most important to agree on a public storage format—it can always serve as an easily portable integration point—then decide how to standardize things like APIs and protocols later, if at all. Those can be very implementation and interface-specific by their nature.

By way of history, AltimeterThree already has a full robust API and interactive protocol, but it's locked down on the Apple side (by Apple) to other apps and not published for Android. And the data files, while highly structured just like a JSON file, are binary (for compact size) and not (yet) accessible to users. There aren't that many people who can/want to write a flight app for iOS or Android, so an API has only been requested by a handful of people over the years.

AltimeterFour will introduce an easily-portable and accessible JSON file format, and I'm planning to publish and document that schema so that anyone can write an app (or script) on any platform that can access a file. That schema will be common-sense and plain text, tailored to time-series flight data, derived analyses, device information, and observations. And any zany elements that a particular vendor might want to add would be easy extensions of that schema, ignored by other apps.

The AltimeterThree app will be updated to include this JSON file format as a sharable data item (currently the only data option is an Excel file).
 
My two cents is that it's most important to agree on a public storage format—it can always serve as an easily portable integration point—then decide how to standardize things like APIs and protocols later, if at all. Those can be very implementation and interface-specific by their nature.

By way of history, AltimeterThree already has a full robust API and interactive protocol, but it's locked down on the Apple side (by Apple) to other apps and not published for Android. And the data files, while highly structured just like a JSON file, are binary (for compact size) and not (yet) accessible to users. There aren't that many people who can/want to write a flight app for iOS or Android, so an API has only been requested by a handful of people over the years.

AltimeterFour will introduce an easily-portable and accessible JSON file format, and I'm planning to publish and document that schema so that anyone can write an app (or script) on any platform that can access a file. That schema will be common-sense and plain text, tailored to time-series flight data, derived analyses, device information, and observations. And any zany elements that a particular vendor might want to add would be easy extensions of that schema, ignored by other apps.

The AltimeterThree app will be updated to include this JSON file format as a sharable data item (currently the only data option is an Excel file).

I wonder about OpenRocket and the other simulation software out there, it would be great if simulated flights could be converted to the same format or vice versa. I know I would love to be able to click a button and overlay my real flight on top of the simulated flight and look at the differences.

Also, imagine thrustcurve.org being able to show stats on 100 real flights with the selected motor and similar rocket dimensions. That would be super helpful too.
 
Absolutely. The APIs are already publicly accessible. Documentation will be released whenever I have time to work it.

I have been busy this week trying to get all the motors and kits on the store so this sort of thing is on the back burner. Getting the Mini released is still priority but I would be happy to send you some info to get started. Same goes for anyone that would like to help develop or use the service.

My goal would be to have users upload any (known) format on the web and we would convert to our standard behind the scenes. If other vendors are interested in direct uploads, I would certainly support that as well.

Russ
from the IOS app code it looks like API authentication is handled with the OAuth username/password flow but the usual OAuth formalities aren't there. Is it OAuth proper or did you implement your own? I want to play around with the API some tonight ( I won't POST anything in though )
 
A lot of the API stuff is based on Django REST Framework, including the tokens:

https://www.django-rest-framework.org/api-guide/authentication/#tokenauthentication

You can also use session auth if you are logged in with a browser. There is a developer html endpoint at https://flightsketch.com/api/rocketflights/ that might help.

Feel free to post away, you should have rights to delete anything you create under your username. The log files are just simple csv data files for now. The data download from the flight pages is the same format for uploads.

@John Beans , I'd consider adopting the Alt4 format. Do you have an ETA for when the format will be available? Any preview would help as well.
 
I wonder about OpenRocket and the other simulation software out there, it would be great if simulated flights could be converted to the same format or vice versa. I know I would love to be able to click a button and overlay my real flight on top of the simulated flight and look at the differences.

Also, imagine thrustcurve.org being able to show stats on 100 real flights with the selected motor and similar rocket dimensions. That would be super helpful too.

Yep, sim data in that format would be cool.

Not to go down a rat hole, but many interesting analyses that could be deduced from flight data (coefficient of drag, motor thrust profile) require data external to the altimeter—like rocket weight (which changes during flight), and weather, trajectory, and rocket geometry—would require inconvenient data entry from users. I think of this as the I/O problem; the code is easy, getting people to do the required additional input work makes the solution unattractive except for researchers.

The biggest source of error between the typical sim and the typical actual flight is trajectory (in my opinion). I think of trajectory as being a ~40% source of error, and motor thrust being a ~20% source of error. So you hear people say, "The sim said 2000 feet, the rocket only got to 1650 feet. What happened? Is the altimeter out of calibration?"
 
Yep, sim data in that format would be cool.

Not to go down a rat hole, but many interesting analyses that could be deduced from flight data (coefficient of drag, motor thrust profile) require data external to the altimeter—like rocket weight (which changes during flight), and weather, trajectory, and rocket geometry—would require inconvenient data entry from users. I think of this as the I/O problem; the code is easy, getting people to do the required additional input work makes the solution unattractive except for researchers.

The biggest source of error between the typical sim and the typical actual flight is trajectory (in my opinion). I think of trajectory as being a ~40% source of error, and motor thrust being a ~20% source of error. So you hear people say, "The sim said 2000 feet, the rocket only got to 1650 feet. What happened? Is the altimeter out of calibration?"
true, and not only does that data have to be manually entered but it also has to be accurate.

You can also use session auth if you are logged in with a browser. There is a developer html endpoint at https://flightsketch.com/api/rocketflights/ that might help.

the developer html endpoint is awesome! thanks
 
The biggest source of error between the typical sim and the typical actual flight is trajectory (in my opinion). I think of trajectory as being a ~40% source of error, and motor thrust being a ~20% source of error. So you hear people say, "The sim said 2000 feet, the rocket only got to 1650 feet. What happened? Is the altimeter out of calibration?"

Ha! The opposite is usually the case. People will say "The sim said 2000 feet, the rocket only got to 1650 feet. Rocksim sucks." 99% of the time, the problem is the user, not the simulator.

Though, I am glad you noted the altimeter calibration. I have been playing around with fixing barometric results by using nearby weather balloon sounding data, and the corrections can be significant, 5%-10% or more. Baro altimeters use a model, not "reality."

I disagree on the trajectory as 40% of the error. Simulations can model 2D flight trajectory. If you assume these models are good, and then vary wind or launch angle in the simulation (within reason), then the loss of altitude is not all that great. Motor thrust, drag coefficient, and temperature/pressure are the bigger sources of discrepancy in my experience. Monte Carlo or ANOVA analysis could easily prove out the main effects more rigorously.
 
@gtg738w:
The more I read in this thread, the more interested I am in a Mini. That being said, I am still an Android Only user.

So... Have you considered allowing a community development effort for the Android side of things? Maybe create a set of specific goals (dev. roadmap). Each goal requiring final approval from your dev team before moving on to the next goal, ala Linus Torvalds Linux kernel.

I would be willing to help beta test such development, though I confess I have an older Nexus 6 which is now at Google's EOL support. So I am locked at Android 7.1.1.

I realize it could/would require a lot of time and effort to keep development on track, but an Android app would certainly accelerate adoption of your FS Mini.
 
@Chad has sent me some info on a cross platform framework that seems promising so far. I would absolutely support community development and that is the driving reason for releasing as open source. Anyone that would like to help is welcome in any capacity.

Given the amount of interest so far, I don’t think Android support will be limiting growth anytime soon... I do see it as an important step in the future though. Especially considering devices like the Amazon fire tablets. Even if someone starts from zero, a Mini + a Fire is still a reasonable entry price.
 
Another launch canceled last weekend due to rain and this weekend due to the wind. Next weekend - fingers crossed.
 
@Chad has sent me some info on a cross platform framework that seems promising so far. I would absolutely support community development and that is the driving reason for releasing as open source. Anyone that would like to help is welcome in any capacity.

Given the amount of interest so far, I don’t think Android support will be limiting growth anytime soon... I do see it as an important step in the future though. Especially considering devices like the Amazon fire tablets. Even if someone starts from zero, a Mini + a Fire is still a reasonable entry price.
I think you're taking the right approach with open sourcing the software and selling the hardware. Altus Metrum takes this approach too and i'm sure others do as well. You leverage all the hobbyists out there who want to tinker but make them pay for the hardware first haha

I bring up the racing drone scene a lot on this forum, one of the cool things that scene did was write a Chrome Browser extension for configuring and tuning the flight controllers. That's a quick way to get platform independent software on its feet where a traditional web application won't work ( needing access to BT or USB for example ).

Here's a very sophisticated open source flight controller firmware and configuration utility, I used a variant of this when tuning PID controller for my racing drone
https://cleanflight.com/

when is more hardware going to become available? Once i have one in hand I'll write an Android version of the mobile application. If you like it great, if not, that's cool too.

btw, I've used the Electron framework for writing cross platform desktop software too, it works ok and I think other folks in the altimeter/flight controller world would should take a look. It's unorthodox and may be a major turnoff (it certainly has its share of detractors) but i think it's worth a look if for no other reason than being aware it's out there
https://electronjs.org/
 
Last edited:
I have some involvement with RC as well, I’ve been really impressed with OpenTX and the quad world has the advantage of experiencing their rapid growth period when this sort of technology is standard. I think the development model has certainly proved its worth. I just finished a “search and rescue” quad a couple of moths ago to hopefully help with recovery when the grass gets tall this year. It’s running iNav and I really like the chrome extension as well.

I have a handful of finished units in hand but they have already been allocated. More boards on on the way. Hopefully will arrive next week. I switched to a different solder paste to address some durability issues but it has negatively impacted yield. It will be slow for probably a couple more stencil turns.

Anyone who really wants one, the hardware is open as well ;). You can even buy boards direct from oshpark. Our page is here:

https://oshpark.com/profiles/flightsketch
 
I have some involvement with RC as well, I’ve been really impressed with OpenTX and the quad world has the advantage of experiencing their rapid growth period when this sort of technology is standard. I think the development model has certainly proved its worth. I just finished a “search and rescue” quad a couple of moths ago to hopefully help with recovery when the grass gets tall this year. It’s running iNav and I really like the chrome extension as well.

I have a handful of finished units in hand but they have already been allocated. More boards on on the way. Hopefully will arrive next week. I switched to a different solder paste to address some durability issues but it has negatively impacted yield. It will be slow for probably a couple more stencil turns.

Anyone who really wants one, the hardware is open as well ;). You can even buy boards direct from oshpark. Our page is here:

https://oshpark.com/profiles/flightsketch
you know, since the firmware is open source, it would be cool if you provided access to the SPI bus, power, and whatever else is needed so other people could build on to your boards. Also, some sort of plugin implementation in the firmware would be icing on the cake. Imagine wiring up an IMU and then writing a plugin that gets loaded by the main firmware. In fact, it may be early enough in your codebase to setup a plugin implementation and refactor the altimeter and logger as plugins.

any updates on hardware availability?
 
it would be cool if you provided access to the SPI bus, power, and whatever else is needed so other people could build on to your boards.

IMG_9958.jpg

Like this? My development boards had breakout pins but the intention was for monitoring signals, not so much expansion. I'm not sure it's worth penalizing the size/weight for a very small number of applications. I think if there is a compelling use for additional hardware, I'd be interested in building it in to begin with. I'll send you a message offline with some extra info.

One option I have considered is a Arduino nano shield with just the sensors & flash. There have been a surprising number of questions here about Arduino based projects and a drop in shield might make it a lot more accessible for those who want to tinker without getting deep into hardware design.

Just got the notice 20 pcbs shipped today. Expected here the end of the week. Should be on track to start shipping a few starting the week of 5/13.
 
I think you're taking the right approach with open sourcing the software and selling the hardware. Altus Metrum takes this approach too and i'm sure others do as well. You leverage all the hobbyists out there who want to tinker but make them pay for the hardware first haha
The Altus Metrum stuff is ALL open-source. The schematics and PCB details are available if people want to make the hardware. Personally I do that sort of thing for a day job so I will just pay the money for altimeters and telemetry systems.
 
Back
Top