Looking for volunteers to test a new altimeter

Firmware update done - just following the procedure above. Slick! I did not have to turn off/on the Bluetooth on my phone to get it to see the updated device.

I’m very much looking forward to the data being saved and the reduced power consumption (though I got a few spare cells in a recent Amazon order so am prepared there).

I will get it back in the air this afternoon. I think I’ll start with the same model (modelrockets.us Nexus) and motors (Estes C6-5, Q-Jet C12-6) as the Friday flights to allow direct comparisons with those logs. Then I’ll go to multiple-device flights.

I found it interesting that there were a bunch of other devices on the list that the firmware updater could see, including this iPad and my Apple Watch (I was running the process from my phone). That, of course, has nothing to do with the altimeter at all.....

Installed the update, looking to fly some on the weekend weather permitting

There is another app update (0.3.1) that looks like it was just posted to the App Store. There are a few significant changes:

As requested, flight stats are now parsed out of the downloaded logs and the website has been updated to display the data. Apogee, max speed, avg descent rate, burn time, time to apogee, and total flight time are logged. These are not yet displayed in the app, that will be coming soon.

The new algorithm for processing the velocity profile is implemented now. This seems to give much better agreement to the accelerometer data that has been provided so far compared to the previous method. This also significantly improves the burnout detection as well.

Weather data is now available based on your position when the data is downloaded. The app will now ask to use your location while it is open. Collected weather data is uploaded to the web with the flight logs. Launch/recovery location is not yet stored. I’m considering making this optional in the future.

Website was also updated to allow photos in flight logs.

For those who currently keep manual logs, what other fields would be nice to have? Anything can be put in the description but I’m interested if there are any stats that would be useful for sorting or filtering flight data.

Please let me know what you think,

Russ

Peak acceleration (G's) would be a fun statistic to have. Have been enjoying these recent updates and way things are headed. I was able to use it on a couple Estes kits last weekend and was easy enough to set up. It took less than 5 minutes to figure out and use. Hard to complain with Bluetooth capability and a low cost altimeter

The acceleration curve is starting to look pretty reasonable. The general shape and the zero crossing for burnout look great now but the peak values aren't that reliable. I think this is just the limit of a barometric only setup. I don't think it's worth reporting if the data can't be trusted. When we get a board that has an accelerometer on it, it will be there for sure - and then some.

gtg738w said:

The acceleration curve is starting to look pretty reasonable. The general shape and the zero crossing for burnout look great now but the peak values aren't that reliable. I think this is just the limit of a barometric only setup. I don't think it's worth reporting if the data can't be trusted. When we get a board that has an accelerometer on it, it will be there for sure - and then some.

Click to expand...

There are too many things that can cause odd spikes in barometric data (especially around deployment/ejection events) that reporting peak accelerations based on that data does seem like quite a stretch to me.

Got the updated app installed on both phone and iPad. With a little luck will get a little data tomorrow and more on Sunday. But my main reason for being at the field both days will be for TARC official observer duty....and I'll only be able to be up there for about three hours, max, Saturday.

gtg738w said:

The app will now ask to use your location while it is open. Collected weather data is uploaded to the web with the flight logs.

Click to expand...

Since you are collecting weather data, how about correcting the Standard Atmosphere model in your altimeter to local temperature, pressure?

I had thought about applying temp. correction but I think it’s preferred not to. It’s nice being consistent with other altimeters. The weather data also isn’t perfect. Since the check happens on the iPhone, there is really no guarantee that’s what the weather was for the flight. If there is enough drift you could even end up with data that is farther from the truth than the original. Plus, if you don’t have data and can’t get weather, you would have some flights corrected and some flights not. I think it’s cleaner just to use the pressure.

I would consider adding a corrected apogee alongside the original in the flight stats as an option. That might be the best of both worlds.

I agree with Russ....at NARAM-60 we wound up not using the Adrel software’s built-in temperature correction function, but telling it the temperature was 15 degrees C, so that we could apply the same after-the-fact temperature correction to data from all the altimeters used at the meet in the same way. And today I observed a fairly large discrepancy (12-15 degrees F) between the weather data gotten by the app (from wherever it comes) compared to data from an on-site measurement. So clearly we would want/need the standard atmosphere-based altitude data to remain available.

I have flown the FlightSketch mini alongside AltimeterThree and MicroPeak and am seeing very good agreement between multiple devices on the same flight. More tomorrow in between observing TARC flights.

The weather data is coming from darksky.net. I'm open to alternatives if anyone has suggestions. I'm a little surprised by 15º, that is more of an error than I would expect. Maybe I'll make a front end for the weather that can be used outside of the log uploads so it's easier to check (often) & compare. Thanks for the input.

Russ

Finally got to fly my FlightSketch Mini today and it worked great. Why would anyone pay $30 for an Estes altimeter when Russ' $18 product does so much more?

billdz said:

Finally got to fly my FlightSketch Mini today and it worked great. Why would anyone pay $30 for an Estes altimeter when Russ' $18 product does so much more?

Click to expand...

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

Your velocity curve does not look good at all. Velocity from baro data is iffy at best. If you want data, then dangling the altimeter from the nosecone is not a good idea.

For a "disposable" altimeter, this unit looks pretty neat. The Bluetooth connection and web uploads are nice features.

Buckeye said:

Velocity from baro data is iffy at best. If you want data, then dangling the altimeter from the nosecone is not a good idea.

Click to expand...

I’m looking forward to changing your mind @Buckeye

That perception seems to be common in the hobby and in years past, maybe there was some truth to it. Obviously, I disagree, and really, that is a big motivation for this project. The Mini was originally planned as the 2nd release in the family but I think there is a lot of value in this class and wanted to get it out there for this season. The Mini will not be the most comprehensive data that you can possibly get but it extends the range for small models and hopefully for users that haven’t considered an altimeter before. The goal isn’t to have a step down in price from other options. The goal is to convince people who have never flown electronics to step up. If you’re looking for more data, don’t worry, it’s coming.

And yes, the velocity extraction has some work needed still. That is one of the main objectives of this test. Hopefully we collect enough data to make it robust over a variety of flights. So far, the data the testers have provided has been extremely helpful. There are more improvements coming in the next app release.

-Russ

No flights past weekend. I am going to try to fly this weekend.

Much better weather data agreement between onsite wind/temperature meters and the data from Dark Sky yesterday and again this afternoon evening. I now suspect that my initial estimate of the discrepancy up in post 39 is due in part to my wind/temp meter being in a black plastic case....

Several more flights’ data including some comparisons with an AlitmeterThree posted to the logs on the FlightSketch web site. I need to enhance the comments a little for a couple of the flights. It got kind of crazy as the TARC team I’d been mentoring was doing test and qualification flights as evening was waning.

gtg738w said:

I’m looking forward to changing your mind @Buckeye

And yes, the velocity extraction has some work needed still. That is one of the main objectives of this test. Hopefully we collect enough data to make it robust over a variety of flights. So far, the data the testers have provided has been extremely helpful. There are more improvements coming in the next app release.

Click to expand...

Numerically differentiating velocity from altitude is inherently noisy and has large errors, so no amount filtering and smoothing can overcome all of that. billdz's velocity plot above looks really bad. Integrating from accel is always preferred, at least for the "up" part of the flight. Perfectflight and Missileworks already do a good job of extracting reasonable velocity curves from the baro, but I always double check them against a simulation.

I agree, FlightSketch looks like a nice entry point for altimeter beginners. Good luck with the project.

Russ, would it drain the battery too much to leave the altimeter on ready to launch for an extended period, say two hours? My wife would not let me take her iPhone to yesterday's launch, thought about setting it before leaving but was not sure if that was a good idea. My phone is an Android.
Bill

billdz said:

Russ, would it drain the battery too much to leave the altimeter on ready to launch for an extended period, say two hours?

Click to expand...

When it is ready to launch with barometer on, the system uses about 700uA. That is still low enough to get ~50hrs from the CR1225 so 2hrs shouldn't be an issue. With the barometer in standby, I've gotten the system down to ~150uA with Bluetooth advertising, so battery life jumps to ~250hrs on the same cell. That's why the barometer gets shut down.

If you do leave it armed for two hours, there is a chance of other issues though. A false launch trigger is possible from opening a car door or assembling the model. The system reference pressure is also locked when it is armed so you may get a good amount of drift over that time.

Sorry to have seen this just now. If you end up needing more testers, I would like to volunteer. We’ve an electrical hardware engineer in the household. We use two Jolly Logic Alt 3’s already. We have Estes low and mid power rockets too.

Heather said:

Sorry to have seen this just now. If you end up needing more testers, I would like to volunteer.

Click to expand...

The first batch of test units went quite fast... A lot of progress has been made in the last month. We should have parts in this week to build a short run of what will hopefully be the first released version. These boards are functionally the same as the beta but will include some changes to the assembly process for durability. If these perform as expected, release will be a couple of weeks after.

The big software issues that were identified in test have been mostly fixed. There will be another App & firmware release in the next week or two and the long term improvements will come as updates down the road.

gtg738w said:

Hello all - as the title says, I’m looking for some help to test a new altimeter. It is a small, recording altimeter - just data logging, no events. The device connects wirelessly to an iOS app to download flight data from the unit (altitude & vertical velocity) and then upload it to a web service. The web site will then log all of your flights and create zoomable/scrollable plots of the data. You can see an example here: https://flightsketch.com/flights/22/

I’m looking for a variety of test platforms, about 5 people. This is primarily geared towards low power models but I would like to see how it performs under more extreme flight profiles as well. This sensor/code will be the base (hopefully) for future, more capable versions. We have tested so far in normal av-bay layouts as well as just being tethered to the shock cord in a simple model with a couple of static ports drilled. You should be able to drop it in almost anything (18mm tube+) if you’re willing to poke a couple of holes. Same with users, we’re looking for feedback from experienced modelers that can fly it next to proven computers to compare data as well as people who have never flown electronics before.

Basic specs/requirements are:

• 4.2g with battery installed
• 0.65” wide x 1.2” long, Fits in 18mm body tubes
• Requires iPhone 6 or newer (or a recent iPad) with iOS 11+
• Can be mounted with double sided tape in av-bay or tethered to shock cord in a vented body tube

If you would like to help, please let me know and I will send you a sample for (almost) free. It will be $0.01 so we can test the store and shipping system as well.

This project is also open source - I’ll answer any questions you have but I would like to keep this thread technical so it will hopefully stay here. I will post product/store info in the vendor area when it is appropriate to do so.

Thanks for the help - this forum has been incredibly useful. The community as a whole has been inspiring, hopefully we can give a little back.

Thanks,
Russ

Click to expand...

Russ, can the RF connection remain during flight, or is it only before and after flight while the rocket and iOS device are stationary? It sounds like the latter, but I would love to see real time data.

Tom

slothead said:

Russ, can the RF connection remain during flight, or is it only before and after flight while the rocket and iOS device are stationary? It sounds like the latter, but I would love to see real time data.

Tom

Click to expand...

Yes to both... It will send altitude data in real time as long as you are within Bluetooth range, ~300ft. Since most flights are above that though, it is effectively arm before launch and download after recovery. You may get a connection again on the way down if it hasn’t drifted much.

Long range data is coming on another member of the family.

gtg738w said:

Yes to both... It will send altitude data in real time as long as you are within Bluetooth range, ~300ft. Since most flights are above that though, it is effectively arm before launch and download after recovery. You may get a connection again on the way down if it hasn’t drifted much.

Long range data is coming on another member of the family.

Click to expand...

Cool, I'll stay tuned.

Some great work and community help here. Congrats on a working unit, and for the Apple compatibility.

I would gently suggest (as others already have) that the velocity graph will be janky as often as it will be useful. When it works, it'll be cool, but it quite often it won't.

Pressure lagging in less-than-well-vented small rockets is quite common, and filtering can't compensate for that (unlike noise). And you really shouldn't rely on it at all after boost, since the casual assumption that motion is vertical becomes more and more untrue (it is 100% true at launch, and 0% true at/after apogee; odds are best during boost).

One small future thing to think about is that you have two switches, and you could reduce that to one (maybe for next time). Not a huge deal, but while a hard slider is reassuring and familiar, you can't control it from code to be able to completely power down for unintended long term parking in a car trunk or a corn field. I can tell you how to do that if need advice (you very well might not).

Jolly Logic products and the Tesla Model 3 (the first car ever) have something subtle in common: every control is a momentary one that software can control, versus controls that snap to a state that only a person can put back.

Great work!

slothead - I have observed flying a beta unit the reconnecting while on descent that Russ mentioned - sometimes as high as maybe 500 feet. It will then be connected until the model lands. The connection is then lost until you get close enough to it. So....not for real time data downlink but kind of cool.

John - Russ and I have been discussing "pressure lagging in less-than-well-vented small rockets" actually. One model I have LOTS of data on has pretty small vents which are more than enough for apogee detection but probably not good enough for trying to derive velocity from pressure data with any precision. As you may have seen, I've been flying a FlightSketch Mini beta unit in the same model alongside an AltimeterThree which has produced some interesting comparative data. FS Mini is already way better than some others at getting reasonable velocity values this way than some other devices I can name.

John Beans said:

I would gently suggest (as others already have) that the velocity graph will be janky as often as it will be useful. When it works, it'll be cool, but it quite often it won't.

Pressure lagging in less-than-well-vented small rockets is quite common, and filtering can't compensate for that (unlike noise). And you really shouldn't rely on it at all after boost, since the casual assumption that motion is vertical becomes more and more untrue (it is 100% true at launch, and 0% true at/after apogee; odds are best during boost).

Click to expand...

First, thank you John, your comments mean a lot coming from your background. It certainly has not been easy getting to this point and I know you can relate to that.

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. Perhaps we're biased towards advanced users but most of the rule of thumb methods out there for venting bays seem to be not that bad. On top of that, I don't think users intentionally undersize static ports to compromise data, they just need to know how big of a bit to use. Everything we're learning now will certainly be provided to make sure it's possible, and likely, to record high quality and useful data. Even in Bernard's case where we're saying there's an issue, it was a 190ms difference in burn time and a 10% difference in max speed. Now obviously I can only provide data and instructions, there is nothing stopping someone from putting this in a sealed chamber and wondering why it didn't do what they thought it should... There will always be a way to make it fail. I'm sure you've seen your fair share of that over the years.

It should also be noted that the Mini only attempts to provide vertical velocity. Because of this, it's actually most accurate after boost and making this distinction is important. I don't want to create confusion thinking the data is anything different.

Anyway, thanks again for the feedback, it is appreciated and please keep in touch. Hopefully, as more data comes in, we can put this to rest. I'd also be more than happy to send one your way if you'd like to fly it!


-Russ

Interestingly I am finding (in a separate project) that it's actually pretty hard to seal a payload section tightly enough to get so much lag that the apogee reading comes out significantly incorrect. It IS possible, but it takes some work. See the comparison graph in Dan Wolf's "The Care and Feeding of Altimeters for NAR Competition" article in the Jan/Feb 2019 issue of Sport Rocketry. The graph is on the top of page 35. But of course that's the moment that velocity is zero so if the pressure change readings lag by even a half a second it'll only miss by four feet (assuming a free fall from apogee).

Getting the max velocity, at the time that it is maximized (the moment of burnout), is a different matter altogether. I need to look at that with the same research model I've been using for the apogee project. That might be interesting. I'll need at least two FS Minis that I can have running at the same time in the same model to do that project....

(It occurs to me that I have some FireFly data from some of those flights that I might be able to look at to see about venting size and reported max velocity. Hmmmmmmm.....)

I may be thinking of this too simplistically, but it occurs to me that deceleration after boost in the first couple of thousand feet of atmosphere is an equation with relatively few unknowns:

a = -g - Drag/mass

Drag = 0.5 * drag coefficient * frontal area * air density * V^2

You have temperature and air pressure at launch, so you know air density. In theory, a user could enter diameter and mass, though that may not be strictly necessary depending on the power of the curve fitting. That leaves velocity and drag coefficient as the only unknowns. It seems like it ought to be relatively easy to fit a curve to the measured altitude data using those relationships, possibly with an addition of an "off-vertical" factor. That may need to happen on the phone as opposed to on the altimeter depending on computing power needed.

I know that in reality, the air density drops as the rocket rises. If that drop is less than a couple of percent in the first few thousand feet, it might be handwaved away.

boatgeek said:

I may be thinking of this too simplistically, but it occurs to me that deceleration after boost in the first couple of thousand feet of atmosphere is an equation with relatively few unknowns:

a = -g - Drag/mass

Drag = 0.5 * drag coefficient * frontal area * air density * V^2

You have temperature and air pressure at launch, so you know air density. In theory, a user could enter diameter and mass, though that may not be strictly necessary depending on the power of the curve fitting. That leaves velocity and drag coefficient as the only unknowns. It seems like it ought to be relatively easy to fit a curve to the measured altitude data using those relationships, possibly with an addition of an "off-vertical" factor. That may need to happen on the phone as opposed to on the altimeter depending on computing power needed.

I know that in reality, the air density drops as the rocket rises. If that drop is less than a couple of percent in the first few thousand feet, it might be handwaved away.

Click to expand...

If you are doing on the phone then it can be integrated over the air density and velocity to give you a precise curve. This will be complex calculus, however, the end result will be a smoother curve though still not as great as an accelerometer.

boatgeek said:

I may be thinking of this too simplistically, but it occurs to me that deceleration after boost in the first couple of thousand feet of atmosphere is an equation with relatively few unknowns

Click to expand...

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.