Erratic FlightSketch Mini data

[Dane Ronnow]

Flew my MPR Scratch Build on a G80-10T yesterday. Nice flight—straight up, perfect parachute deployment, long descent (4-plus minutes [edit] 5-plus minutes). But the data retrieved from the FS Mini is erratic. Apogee and Max Velocity are good, as is the weather data, but everything else is scrambled. FWIW, the Mini worked flawlessly on two previous flights, both of them three weeks earlier.

The Mini rides in the nose cone altimeter bay, with the vertical axis parallel to the long axis of the rocket. It is secured in a pouch that lets it breathe, but protects it from shock of ejection, landing, etc.

I powered up the Mini right before inserting the nose cone into the body tube, then connected to it with the smartphone. Voltage was ~2.8v. Following motor insertion, I placed the rocket on the rail, inserted the igniter and connected the clips, then walked back to the launch station and armed the Mini for launch. Time between arming and launching the rocket was ~2 minutes.

As mentioned above, the parachute deployment was very smooth, and the landing was very soft.

Any ideas what would cause the erratic data?

 

[Dane Ronnow]

Just to add to the above, the airframe is vented to the outside atmosphere—three 3/32" holes, 3" below the top of the body tube, and the distance between me and the launch pad when arming the Mini is ~75 feet.

As mentioned in the post above, the Mini worked on two previous flights. Here's the data from the second of those flights, on a G74-9W:

 

[BEC]

@gtg738w ?

There are a small number of "flights" that look like that posted to the online log. There was speculation some months ago about the unit failing to purge old data or something. I don't think I've had this happen to me....or if I have, I've forgotten it.

It's gotta be someting memory-related with those overlapping traces on both the barometric and accelerometer data. But Russ will have to tell us what he thinks the mechanism for that might be....and he's apparently been busy with other things for a couple of months at least.

 

[Dane Ronnow]

There are a small number of "flights" that look like that posted to the online log. There was speculation some months ago about the unit failing to purge old data or something. I don't think I've had this happen to me....or if I have, I've forgotten it.

It's gotta be someting memory-related with those overlapping traces on both the barometric and accelerometer data. But Russ will have to tell us what he thinks the mechanism for that might be....and he's apparently been busy with other things for a couple of months at least.

Thanks for the response. I hope Russ can shed some light.

 

[Dane Ronnow]

I was thinking about the recovery on this flight. I usually have my smartphone when I go to retrieve the rocket, so I can download the data immediately, and power down the Mini. But this time, I was halfway out to the rocket when I realized I'd left the phone on the launch control table. So, between the end of the flight and the point at which I downloaded the data, there would have been some jostling of the nose cone (where the Mini rides) as I packed up the parachute and shock cord, then walked back carrying the rocket, all of which took about 10 minutes.

I have no idea if this may have caused or contributed to the problem, but I wanted to throw it out there for consideration.

Another thing that may have been a factor was when I launched this rocket three weeks earlier. Following the second flight (G74-9W, flight data shown above in post #2), I powered down the Mini before prepping the rocket for the third flight, and neglected to download that data right away. Then I powered up the Mini for the third flight and connected with the smartphone, but failed to arm it for launch after the rocket was placed on the rail. (I know, bad form, failing to follow my checklist). So the Mini flew while connected, but not armed. It wasn't until after that third flight that I realized my mistake. That was when I downloaded the data from the second flight.

Again, no idea if that contributed to the problem.

 

[Tractionengines]

I have had this happen with the Flightsketch mini. Note even tough you think you have a good apogee, v-max, etc. it is very likely all invalid. (I thought the same as you [some data ok, some flakey], but proved it was artifacts from previous data sets.)

Note,The weather data is not part of the saved information in the flight log, it is pulled from the web by the app when you download. So data corruption doesn't change it.

Look at the flight time data, if it is all negative, then the data set is corrupt. (Your summary is negative for time to burnout, and negative total flight time.)

Do a couple of tests via "Simulated flights" in a jar or syringe. If you arm it pull some vacuum quickly (simulated launch) then release slowly (simulated descent) then look at data. If data looks good do a real flight. If data is still all negative times... memory corruption is still there. Then do these steps, and retest after each, at some point it will clear up.
1) can try a simple arm and simulated flight again. (A couple of times.)
2) pull the battery, wait 10 min, reinstall, arm, do simulated flight.
3) do a firmware update, its not needed for the firmware, but that seems to to a complete "reset" of all data bits and fixed issue.

When I do this I used a second flightsketch mini in the test jar, so I could compare data sets. (Do you have a 2nd recording altimeter for data comparison?)

I think it may be a non-standard sequence of events that triggers this odd memory corruption, but can't figure out what yet.

Let me know if you need more help.

 

[Dane Ronnow]

Do a couple of tests via "Simulated flights" in a jar or syringe. If you arm it pull some vacuum quickly (simulated launch) then release slowly (simulated descent) then look at data. If data looks good do a real flight. If data is still all negative times... memory corruption is still there. Then do these steps, and retest after each, at some point it will clear up.
1) can try a simple arm and simulated flight again. (A couple of times.)
2) pull the battery, wait 10 min, reinstall, arm, do simulated flight.
3) do a firmware update, its not needed for the firmware, but that seems to to a complete "reset" of all data bits and fixed issue.

Thanks for your response. Extremely helpful.

I did four vacuum tests, all of which gave me positive numbers.

I did notice that the acceleration graph in the first test was completely different than the following three. Not sure what's going on there, but I'm thinking the first test may have still had a memory issue, which was cleared for tests 2, 3 and 4.

Below are the results from the first test: (altitude and vertical velocity, acceleration, flight stats).



Compare the acceleration graph above to these from tests 2, 3 and 4:



After the second test, I pulled the battery for about 15 minutes, then reinstalled and ran tests 3 and 4. Then I updated the firmware from v27 to v29.

I don't have a second Mini that I can use to verify data from the first. And, as much as I'd like to, I won't be getting out for another launch anytime soon. But when I do, I'll update this thread.

Meanwhile, if anything in those acceleration graphs strikes you as odd, please let me know.

And thanks again for your help!

 

[BEC]

On a bench test you'd normally see acceleration right around 1G (32 ft/s/s). I guess that the fact that there's that jittering is just noise in the sensor.

During that first test, did you bang the vacuum container the Mini was in at about 2s? But since the altitude data is all in negative time, that's probably irrelevant. That's still corrupted memory-type data.

The difference between firmware 27 and firmware 29 is changes to the filtering around apogee to cut down on the tendency for the reported apogee to overshoot the real value in too-short-delay cases. This was needed to gain the NAR contest use approval. As far as I know nothing changed with respect to the accelerometer data, but Russ will have to weigh in when he has a chance.

If you save the data locally to your phone/tablet at the field after a flight and upload later from the app's logbook function, the weather data (which come from Dark Sky) will be preserved. But as @Tractionengines noted, the data are from your location at the time of the download, not the time of the flight. The Mini (or Comp) doesn't have or know any of these data, they are a function of what the downloading device's location services reports to the app at the time of the download.

 

[Dane Ronnow]

During that first test, did you bang the vacuum container the Mini was in at about 2s?

Probably. Here's the altitude data from tests 2 and 3. Both in positive time.

If you save the data locally to your phone/tablet at the field after a flight and upload later from the app's logbook function, the weather data (which come from Dark Sky) will be preserved. But as @Tractionengines noted, the data are from your location at the time of the download, not the time of the flight. The Mini (or Comp) doesn't have or know any of these data, they are a function of what the downloading device's location services reports to the app at the time of the download.

That's good to know. Saves me a lot of head scratching. And thanks for your response. I appreciate it.

 

[BEC]

Yeah, I saw that you uploaded all the tests. All of them except the first one look pretty normal for an on-ground test.

 

[Tractionengines]

Looks good.

I have nowhere near the history of @BEC but I fly with up to 3 kids with me (9, 6, 4) so there are a lot of "false starts". That is when this data corruption has happened a few times now...

When just going thru the normal process: turn on, load, arm, launch, download, power off....repeat; I have not seen it.

On my L1 flight I did a few extra steps on-off cycles, check battery voltage, open parachute bay to check JLCR, etc. Even though I armed it right before flight, it was corrupted. Another time was after a igniter fault, where everything went thru reset for 2nd attempt. Another time was after a nozzle failure in a Q-jet, that required a new motor and launch attempt...

After that I numbered my mini's to see if it was the same one doing it, or not.... guess what...Hasn't happened since.

THIS IS COMPLETELY SPECULATION.... My current thought is this MAY happen when the rocket is armed, then there is an "event" other than a launch that causes "strange" pressure fluctuations (pull/install nose cone, cato, etc.); then the next "arming" doesn't reset the data correctly, and bits of the last "real flight" get left behind...

 

[Tractionengines]

Don't get me wrong: I like the Flightsketch products (mini & comp) and am waiting for more to be released.

Most flights are normal and give good data, just an occasional hiccup, that is either from something I did, or that is outside "normal flights".

If I can figure out a pattern I am sure Russ can correct it.... or maybe its all from the same altimeter, and it just has a "issue" and needs to be taken out of service...

 

[BEC]

Looks good.

I have nowhere near the history of @BEC but I fly with up to 3 kids with me (9, 6, 4) so there are a lot of "false starts". That is when this data corruption has happened a few times now...

When just going thru the normal process: turn on, load, arm, launch, download, power off....repeat; I have not seen it.

I usually manage to operate them just this way, though if I’m researching something I might leave one in a model and fly it several times in a session before turning it off again — the ability to do this is one of the great advantages of these little gadgets compared to most other choices. As I say, I don’t recall ever getting this sort of crazed data myself. I suppose I need to look on the online log and see….

On my L1 flight I did a few extra steps on-off cycles, check battery voltage, open parachute bay to check JLCR, etc. Even though I armed it right before flight, it was corrupted. Another time was after a igniter fault, where everything went thru reset for 2nd attempt. Another time was after a nozzle failure in a Q-jet, that required a new motor and launch attempt...

After that I numbered my mini's to see if it was the same one doing it, or not.... guess what...Hasn't happened since.

THIS IS COMPLETELY SPECULATION.... My current thought is this MAY happen when the rocket is armed, then there is an "event" other than a launch that causes "strange" pressure fluctuations (pull/install nose cone, cato, etc.); then the next "arming" doesn't reset the data correctly, and bits of the last "real flight" get left behind...

At least you have good recall of the circumstances which will help Russ, I am sure, when he surfaces again to look at this. (I hope he and his family are OK.)

I put a little label with the last four digits of the unique ID number each one has and the firmware version on all of mine. For FireFlys and MicroPeaks, which don’t have such IDs, I’ve just numbered them sequentially to tell ‘em apart. I label Adrels with their serial numbers.

 

[Dane Ronnow]

THIS IS COMPLETELY SPECULATION.... My current thought is this MAY happen when the rocket is armed, then there is an "event" other than a launch that causes "strange" pressure fluctuations (pull/install nose cone, cato, etc.); then the next "arming" doesn't reset the data correctly, and bits of the last "real flight" get left behind...

I think the data corruption in this flight may have been caused by my failure to arm the Mini for launch on the third and final flight three weeks earlier. I had just recovered the second flight, and I looked at the data, but I didn't download it. I powered it down, then prepped the rocket for the third flight. Before taking the rocket out to the pad, I powered up the Mini and connected. But I never armed it for launch.

The next time I used the Mini was three weeks later—this flight that we're talking about. I think my messing up the process three weeks earlier caused the errant data.

In any event, I'll wait and see what happens on the next flight. Not sure when that will be.

I have one question for you and/or @BEC : If I pull the battery for 10 or 15 minutes, will that 'refresh' the Mini? If it will, that strikes me as a pretty easy way to ensure that any data fragments left over from a previous flight are purged.

 

[Dane Ronnow]

I usually manage to operate them just this way, though if I’m researching something I might leave one in a model and fly it several times in a session before turning it off again — the ability to do this is one of the great advantages of these little gadgets compared to most other choices.

I turn mine off after each flight just to save battery. It's the one thing I can remember to do

 

[Tractionengines]

This is my understanding from a few conversations and messages. It may not be 100% accurate. (That needs to come from Russ, but he is MIA lately.) Also, its proprietary so I'm sure, he simplifies, and limits, exactly what he gives out about programming.

Pulling the battery for that amount of time, does ensure that ALL parts of the system are fully "off". Then start-up, when the battery is put in.

The "retained" data from the last flight "should NOT" be lost by this process. The previous flight data "is erased" when you arm it for flight.

It then starts buffering data, so when a launch is detected, it can have the data leading up to launch.

Then when it senses it has stopped descending for a few seconds, it ends the recording.

 

[BEC]

It turns out I did experience data corrupted like this once….in March of 2019 (on a beta-test FS Mini). See https://flightsketch.com/flights/159/. According to my log book I flew that particular unit again on the next flight, same model and same motor type, most likely without even power cycling it, and got perfectly reasonable data: https://flightsketch.com/flights/160/

This was an early one with the big slide switch and the pushbutton switch to put it in DFU mode.

The production units with the pushbutton power switch are always a little bit “on” as long as the cell is in the holder, so pulling the cell should certainly reset the processor. The flight data will not be lost. As @Tractionengines noted, it is erased when you arm the unit for flight (whether or not you then actually go fly).

I do have one other flight in the log that has messed-up data that could be related to the craziness we’re discussing here: https://flightsketch.com/flights/3249/. Here I noted in my logbook that the voltage on the app display dipped below 2.1V briefly after arming it. Russ told me in an email conversation around “how low can you go?” that the unit needs 2.3V to erase the memory from the prior flight and that that was the limiting case on how far you could let a cell be depleted before it had to be replaced. For whatever that’s worth.

 

[Dane Ronnow]

Pulling the battery for that amount of time, does ensure that ALL parts of the system are fully "off". Then start-up, when the battery is put in.

The "retained" data from the last flight "should NOT" be lost by this process. The previous flight data "is erased" when you arm it for flight.

Thanks. That answers my question.

 

[Dane Ronnow]

Russ told me in an email conversation around “how low can you go?” that the unit needs 2.3V to erase the memory from the prior flight and that that was the limiting case on how far you could let a cell be depleted before it had to be replaced. For whatever that’s worth.

That's good to know. My Mini shows 2.8v when I power it up. It will dip slightly over the course of a few launches, but comes back to 2.8 the next time I power up.

 

[Dane Ronnow]

@Tractionengines @BEC -- I really appreciate your help with this. I think the key for me is in the process—power up, connect, arm, then download at the point of recovery. Beyond that, though, what I've learned just in reading your responses is immensely helpful in understanding how the Mini works. Thanks much!

 

[BEC]

That's good to know. My Mini shows 2.8v when I power it up. It will dip slightly over the course of a few launches, but comes back to 2.8 the next time I power up.

You will find that the voltage swings pretty widely if you watch long enough, depending on what it’s doing. Erasing the memory for arming is a big one, so is actual bluetooth communications, which apparently isn’t quite as continuous as it appears to be. Chilly days, of course, make it worse. With the saguaros in your avatar, I suspect you’re not too worried about that. It’s 40 degrees outside here right now….and the sun is out.

You can get an idea of temperature performance here: https://www.renatabatteries.us/sites/default/files/2017-12/CR1225_data_sheet_v07.pdf. This is the cell that comes with the FS Mini.

 

[Dane Ronnow]

With the saguaros in your avatar, I suspect you’re not too worried about that. It’s 40 degrees outside here right now….and the sun is out.

I'm in Las Vegas. It was 101 on the lake bed three weeks ago. As far as batteries ago, I always pack a spare. And based on what the voltage has been reading after four flights, I'd say it will be a while before I need it.