Using data

I've been debating about getting a Jolly Logic AltimeterThree for about a week now as I want a easy to deploy altimeter that gives me data. AltimeterTwo gives me some good data that I would like to see (big enough chute, how accurate sims are, etc). What I'm curious about is whether or not the app interface gives depth to the data that a small display can't. My first reaction is that it is an "ooooooooh" factor but after looking at some of the screens, there may be more that I'm missing that actually may prove to be useful when analyzing data.

Who here analyzes their data and uses Jolly Logic altimeters? I know we all like to know stats but I'm talking real in-depth analysis to see what went right, what went wrong, what could be improved, and what may have been overdone. There are some sharp guys on here that probably can tell if fin flutter occurred or if a bird passed gas 130 yards away causing the rocket to change vector. I'd like to learn how the data is used and what it translates to.

With respect, I'm not really interested in discussing who makes the best altimeter. I want something that gives data without the need for an e-bay or external batteries as I like to fly with a chute release for the time being. If there is a huge problem with the AltimeterThree (ie it is missing an important sensor that would allow night and day difference in analytics), please advise. Other than that, I'm more interested in discussing data.

I really like the AltimeterThree, but mostly for the "ooooh" factor. I love being able to walk up to my rocket in the field and getting an attractive graph of the data on my phone before I even pick it up. IMHO, the only important piece of data that the AltimeterThree provides that isn't covered in the AltimeterTwo is descent speed. That can be really useful to see if your chute or drogue was the correct size. Other than that, I just like having a catalog of some of my best flights on my phone.

BDB said:

I really like the AltimeterThree, but mostly for the "ooooh" factor. I love being able to walk up to my rocket in the field and getting an attractive graph of the data on my phone before I even pick it up. IMHO, the only important piece of data that the AltimeterThree provides that isn't covered in the AltimeterTwo is descent speed. That can be really useful to see if your chute or drogue was the correct size. Other than that, I just like having a catalog of some of my best flights on my phone.

Click to expand...

Do you mind sharing some of your flights? I downloaded their spreadsheet from the Jolly Logic site but it was wonky.

Here's an example of flight data that I just exported from the app.


View attachment FlightReport.xlsx

I have the alt two. A friend has the Alt three. I've seen him futz with it: trying to get it linked up, loosing the link because the phone timed out, or lost data because his son picked up the rocket before he had a chance to download the info, etc..

Sorry, it does have a 'coolness' factor, but I find it's a case of "technology" getting in the way.

I just attach mine, turn it on, and put it on the pad.. I record my alt, speed, Gs decent rate, etc.. on paper. The Alt two seems to record numerous flights..

The alt 2 does give a decent rate / speed, of course, it is averaged..

dr wogz said:

The alt 2 does give a decent rate / speed, of course, it is averaged..

Click to expand...

I stand corrected. I didn't realize the Alt2 displayed decent rate, but as I was posting previously I thought that it wouldn't be hard to calculate an average decent rate from time to apogee, max altitude and total flight time.

You can export a .xlsx (Excel spreadsheet file) from the phone/tablet via email to yourself from the AltimeterThree app. From there you can analyze to your heart's content.

You can of course also zoom in on a particular part of the graph on your phone/tablet and look at the various data, both altitude and accelerations vs. time together or separately.

As for losing "data because his son picked up the rocket before he had a chance to download the info" - the data are still there until you tell it to record again from the phone/tablet and it automatically downloads upon re-linking with a device that doesn't already have the data on it whether it's a minute after a flight or a month after the flight. So I don't understand how that data loss is happening.

I will agree that the bluetooth connection business has it's frustrations from time to time.

Here's data from one flight of my Star Orbiter at NSL last year. As you can surmise from the descent trace in the graphs, there was also a Chute Release aboard. The graph with the accelerations is just a screen capture, not the exported graph from the app.





View attachment FlightReport.xlsx

The A3 is not lacking an important sensor. It measures time, pressure (altitude), and acceleration. That is all there is to it. Everything else is derived from these first principles. (Other flight computers may add temperature and GPS coordinates.) If you want to analyze data, you are probably better off exporting it from the device and doing it yourself. If you want good data, it is in your best interest to securely orient the A3 in a vented e-bay and not dangling from a string on the nose cone.

I look at data. A lot. Not in the field, but at home, post-flight. Some electronic devices are better than others for processing and exporting data for more detailed analysis.

Oh, and I use simulations to determine the accuracy of the measurements, not the other way around. :wink:

BDB said:

Here's an example of flight data that I just exported from the app.

View attachment 339641View attachment 339643
View attachment 339642

Click to expand...

BEC said:

You can export a .xlsx (Excel spreadsheet file) from the phone/tablet via email to yourself from the AltimeterThree app. From there you can analyze to your heart's content.

You can of course also zoom in on a particular part of the graph on your phone/tablet and look at the various data, both altitude and accelerations vs. time together or separately.

As for losing "data because his son picked up the rocket before he had a chance to download the info" - the data are still there until you tell it to record again from the phone/tablet and it automatically downloads upon re-linking with a device that doesn't already have the data on it whether it's a minute after a flight or a month after the flight. So I don't understand how that data loss is happening.

I will agree that the bluetooth connection business has it's frustrations from time to time.

Here's data from one flight of my Star Orbiter at NSL last year. As you can surmise from the descent trace in the graphs, there was also a Chute Release aboard. The graph with the accelerations is just a screen capture, not the exported graph from the app.

Click to expand...

Thank you guys for these. I guess it really does output the files like this which is really odd but a preference perhaps. I deal with raw data and make my own format so this seems really clunky to me. Though this does demonstrate the chute release effectiveness and deployment time which is something most people could appreciate. The app seems to demonstrate most of the useful data, the excel spreadsheet seems less useful at least to my untrained eyes.

Buckeye said:

Oh, and I use simulations to determine the accuracy of the measurements, not the other way around. :wink:

Click to expand...

Well, not sure which approach is more appropriate. I can't vouch for the accuracy of simulations nor the accuracy of recorded sensor data. What I do know is that they disagree most of the time despite my efforts to make accurate models in the simulators. Being a former programmer and coming from a background that uses sensors to measure processes, I tend to trust sensors more than a computer simulation. But, with everything, there are always exceptions.

Performance nut said:

Thank you guys for these. I guess it really does output the files like this which is really odd but a preference perhaps. I deal with raw data and make my own format so this seems really clunky to me. Though this does demonstrate the chute release effectiveness and deployment time which is something most people could appreciate. The app seems to demonstrate most of the useful data, the excel spreadsheet seems less useful at least to my untrained eyes.



Well, not sure which approach is more appropriate. I can't vouch for the accuracy of simulations nor the accuracy of recorded sensor data. What I do know is that they disagree most of the time despite my efforts to make accurate models in the simulators. Being a former programmer and coming from a background that uses sensors to measure processes, I tend to trust sensors more than a computer simulation. But, with everything, there are always exceptions.

Click to expand...

Did you see the raw data in the 'Data' tab on the excel spreadsheets that we posted? The Alt3 does provide it, but if you are looking for raw data for post-flight analysis without all of the bells and whistles, then the Alt2 can do that for less money.

Performance nut said:

Thank you guys for these. I guess it really does output the files like this which is really odd but a preference perhaps. I deal with raw data and make my own format so this seems really clunky to me. Though this does demonstrate the chute release effectiveness and deployment time which is something most people could appreciate. The app seems to demonstrate most of the useful data, the excel spreadsheet seems less useful at least to my untrained eyes.



Well, not sure which approach is more appropriate. I can't vouch for the accuracy of simulations nor the accuracy of recorded sensor data. What I do know is that they disagree most of the time despite my efforts to make accurate models in the simulators. Being a former programmer and coming from a background that uses sensors to measure processes, I tend to trust sensors more than a computer simulation. But, with everything, there are always exceptions.

Click to expand...

Not sure what you mean as "clunky." I don't care for the xls file with formatted pages (simple csv would be better), but it contains all the raw data. That's what you want, right?

I am a big simulation advocate, so I balk at blind trust of measurements. For example, altimeter makers rarely mention that their devices use standard day conditions in their atmospheric model and do not correct for ambient conditions. In other words, the A3 thinks is it 101325 Pa and 15 deg C every time you launch your rocket. The NAR was trying to address this issue a few years ago for altimeter competitions and records, but I don't think anything came of it. By contrast, all the popular rocket simulation software will adjust the atmospheric model to your inputs. Now, which is more "accurate?"

BDB said:

Here's an example of flight data that I just exported from the app.

View attachment 339641View attachment 339643
View attachment 339642

Click to expand...

How was your A2/A3 mounted? Was it an off-vertical flight? The x, y, and z accelerations are all about the same magnitude, so it is hard to determine the direction of rocket travel.

Buckeye said:

Not sure what you mean as "clunky." I don't care for the xls file with formatted pages (simple csv would be better), but it contains all the raw data. That's what you want, right?

I am a big simulation advocate, so I balk at blind trust of measurements. For example, altimeter makers rarely mention that their devices use standard day conditions in their atmospheric model and do not correct for ambient conditions. In other words, the A3 thinks is it 101325 Pa and 15 deg C every time you launch your rocket. The NAR was trying to address this issue a few years ago for altimeter competitions and records, but I don't think anything came of it. By contrast, all the popular rocket simulation software will adjust the atmospheric model to your inputs. Now, which is more "accurate?"

Click to expand...

Clunky as in the data tab is separated into pages which makes the data discontinuous. A raw data dump would be like you said, a flat .csv file. Forget the ruler and the page breaks. The graph is a nice touch but also not necessary.

As for sensor inaccuracies, the same principle can be applied to simulators. The simulator doesn't automatically sense your field altitude, temperature, wind speed, etc. A user has to enter that data. Same principle applies to sensors, if you want really accurate data, you are going to have to go a few steps further. I think the argument is more about accessibility and ease. The simulator I use makes it fairly easy to change things around to compensate for environmental conditions, most devices with sensor data (because I can't say all since I don't know every device's capability) do not have the capability of entering field conditions at the device level. With that said, I'm fairly sure you could offset the data in Excel with calculations to approximate things better.

That almost sounds like a science experiment... only thing to figure out is a prime standard in which to validate it to.

Agreed. I have various atmospheric models programmed in excel to adjust simulation or altimeter data. Details, details.....

Buckeye said:

How was your A2/A3 mounted? Was it an off-vertical flight? The x, y, and z accelerations are all about the same magnitude, so it is hard to determine the direction of rocket travel.

Click to expand...

If I remember right, this one was just tied to the shock cord. That probably explains the accelerometer data and the jagged profile of the decent before the chute release deployed. This is a 4" rocket with an electronics bay; I have done full dual deploy with it before, but this flight was a test for using my chute release with a 48" chute. In retrospect, I think I need to use a drogue chute with this set up because, as the data shows, the descent was pretty tumultuous before the chute release deployed.

BDB said:

If I remember right, this one was just tied to the shock cord. That probably explains the accelerometer data and the jagged profile of the decent before the chute release deployed. This is a 4" rocket with an electronics bay; I have done full dual deploy with it before, but this flight was a test for using my chute release with a 48" chute. In retrospect, I think I need to use a drogue chute with this set up because, as the data shows, the descent was pretty tumultuous before the chute release deployed.

Click to expand...

Yeah, your descent data is more ragged than most since the barometric altimeter was flopping around. If you secured the A3 in a vented ebay, the descent data would be less noisy, I am sure. The accelerometer measures itself, so if it is loosely dangling from the nosecone, you get chaos in all three directions. I would rigidly attached it to the airframe with a set orientation. After ejection and during descent, the accel data is rather useless no matter what.

Yes, the data tab in the xls file is very annoying!