FlightSketch Products for 2020

[BEC]

Ok question... Where is the CSV file on an Android Phone. I went to the directory listed in the manual, and there are sub-directories for Files, and Cache, and no files in either.

I did 2 flights over the weekend. Both downloaded, ok. Then saved to local storage, AND upload to web. The files show in my "Logbook" in the Flightsketch App. But that just has the summary information, and not the full DATA. At the bottom of the summary are now 2 options. "UPLOAD TO WEB" or " DELETE FLIGHT". The files are fine on the WEBSITE, and I did download the CSV files from there and have them saved... but would be nice to figure out where they are saved locally. What am I missing?

....well, I hate to say it, but in testing on an Android device (a small Lenovo tablet) I had a heck of a time getting "saved locally" files to actually save. When it actually did, the files are where the manual says they should be. I don't know enough about Android stuff to know if there's some trick here or what. On iOS "it just works" but on Android, sometimes it did for me and often it didn't, even if I tried to save the file several time. It told me it did, but as for you, the files weren't there when I went to look at them.

Do ones that you can't find in the directory the manual says to look in actually upload to the web from the logbook function? If so, they have to be somewhere on your device. But I expect that if you try to test that you'll find they aren't really there.

I just fired up that tablet and looked at where the files are on it—the ones that I was actually able to save. They are right where Russ' documentation said they would be—/Android/data/com.flightsketch.flightsketch/ They are at the same level, not in the folders named "cache" and "data"

 

[Tractionengines]

The files downloaded fine Saturday, from the MINI to the APP. Then uploaded to the Flightsketch website ok. Then they seemed to save locally ok, but didn't. There are listings in the APP Log page (first image), and clicking them, pulls up a summary page (second image). But that is it.
&
I have a Samsung Galaxy S9, and there are 2 directories I found that were created when I installed the APP. Following are screenshots of both paths "internal storage" & "SD Card". Both places, and their sub directories have no files.

I will steal (borrow) the kids "stomp-rocket" and play to see what I can figure out.
I was able to save and review the CSV file from the flightsketch.com website. So I have them, but extra steps to upload, then download to my own directory seems less than ideal.

OTHERWISE THE WORKED GREAT, AND WERE EASY TO USE.

 

[BEC]

Yeah.....that's less than ideal.

Here I think more people who use Android devices and also perhaps someone who writes Android apps will have to jump in because local storage has worked from the beginning on iOS but for me, and apparently for you as well, it's not reliable on Android.

When playing with the stomp rocket be aware that launch detect on the FS Mini/Comp requires 50 feet of altitude and 30 ft/s velocity.

 

[Huxter]

FWIW, IIRC, I have a Samsung S7 android phone. My one flight, I clicked "Save Locally", then "Upload". I do not remember a message after that (ie successful or not). I did note, that both options were still available to click at that point. (I am a programmer!)

I did not download any data from the web to my phone, yet I still had the csv file:

I'd rather not talk about that flight tho

 

[BEC]

FWIW, IIRC, I have a Samsung S7 android phone. My one flight, I clicked "Save Locally", then "Upload". I do not remember a message after that (ie successful or not). I did note, that both options were still available to click at that point. (I am a programmer!)

I did not download any data from the web to my phone, yet I still had the csv file

You should see messages that it was saved in both cases. And sometimes it does actually save locally on Android....but I'd say, in my own experience at least, it's maybe 1/3 of the time I try to do so. So you can have the .csv file where it's supposed to be on an Android device—it's just far less of a sure thing than doing the same with iOS, where, to my knowledge of hundreds of flights over well over two years of flying these things, it has always worked.

I always both save locally and upload immediately if I can (if I have cell coverage). And I don't depend on an Android device or I'd be REALLY frustrated at it by now. In my experience AlimeterThree's Android app works pretty much as well as the iOS one does (again, only used a little, to help do testing for the developer) but such is not the case, with respect to local data storage, with the FlightSketch app. I don't know how Russ is doing cross-platform development, but, as with AlimeterThree, the iOS version came first, which makes me think the initial coding was for iOS. I figure some kind of cross-platform tool then was used to create the Android app...and maybe there's some kind of subtlety in writing files to the Android file system that either isn't accounted for by these tools, or it doesn't work correctly, or perhaps is inconsistent across Android versions or something.....

 

[Huxter]

I'd say, in my own experience at least, it's maybe 1/3 of the time I try to do so. So you can have the .csv file where it's supposed to be on an Android device

Would this still be true for ONLY firmware 29 flights? It has to be fixed on some update - agreed? (said like a Borg! )

 

[BEC]

No. I haven’t actually tried any firmware 29 flights controlled from my Android tablet. This is an app issue and has been there since there was an Android version of the app and has nothing to do with the altimeter firmware — or that’s how it appears to me.

The data are getting into the phone/tablet so the Mini is doing its job. It’s the app to file system process that’s sketchy.

 

[Huxter]

OIC - it's the android OS that's in error. When we click the "Save Locally" option, I wonder what the message is when the Save operation fails? It should save the csv file or fail? I do not remember what mine said, but the FS app should get the OS response on the save command/operation - no?

 

[BEC]

Either the OS or what the app is doing with it—yeah that’s how it looks to me.

I’ve never seen a “save failed” message from a local save. I’ve seen a few upload errors but not locally.

 

[gtg738w]

Hi Guys - I'm mostly caught up from the holiday and wanted to try to answer a few questions. I think Bernard got most of it but I'll add a few points.

The Mini has a separate power circuit for everything except the processor that can be turned on/off in software. When it's "off" the power is completely removed from the sensors to extend the battery life as much as possible, It's only ~400nA for the processor in deep sleep. The Comp doesn't have this and thus draws significantly more current in the "off" mode than the Mini. You should always disconnect the battery to store it but if it's stuck in a tree or you just don't want it broadcasting it's name or something, you can still sleep the processor from the app.

Lithium battery shipping has different restrictions if you ship them alone vs with the product. Batteries without the electronics must be shipped by ground which to HI is possible but obviously a bit different than the rest of the US. Even to the lower 48, most of the time it actually costs more for ground service to make sure it doesn't end up on a plane. If the battery is installed in, or packed with the equipment, they can go by air for these sizes.

On Android, there have been several cases where the files seem to be missing. I have a Samsung Galaxy Tab S2 that I use for testing and I can't get it to happen there. The odd part is the upload process also requires the file to first be saved to the same storage path so if that works, the files are most likely saving. What's probably happening is they are hidden or getting purged by some other OS "feature" or something. Browsing from windows seems to be the best workaround so far but also isn't 100%.

Let me know if I missed anything else. Thanks!

 

[BEC]

On Android, there have been several cases where the files seem to be missing. I have a Samsung Galaxy Tab S2 that I use for testing and I can't get it to happen there. The odd part is the upload process also requires the file to first be saved to the same storage path so if that works, the files are most likely saving. What's probably happening is they are hidden or getting purged by some other OS "feature" or something. Browsing from windows seems to be the best workaround so far but also isn't 100%

So, Russ, then what happens to the file then if the app has to store it locally for the upload but then the user doesn’t also opt to “save locally”? Where in the process is it deleted (or hidden somehow?)? If if there’s such a process, is it perhaps, on Android, happening in the wrong order or something? I may have to get the Lenovo tablet out and at least working with the data stored in all the Minis and Comps I have see if I can figure out a pattern or something. It has always seemed to be random to me up to now.

If you really are saving it locally before upload to the web, why not just automatically save it locally whenever a flight’s data is downloaded (like AltimeterThree does)? Granted, that would bypass the opportunity to rename the file, I suppose, but still….

 

[Huxter]

Thanks. Please let me know which works better so I can put an order in with my son.

Give your boy the STL file - it is not material specific. He can modify and slice it for his printer and any material he has.

The TPU plugged up my nozzle printing that case! It's unplugged now, but need to find out why it plugged? Never had a problem w this filament before?

 

[Ronz Rocketz]

I would be concerned not about the altimeter (directly) but about the battery. BR1225s are low drain batteries by design. If you try to draw too much current, how is the battery going to respond? If it implodes/explodes, you lose the battery, the altimeter and the rocket. Hmmmm.....

The only thing I can think of is do a ground test. Put the battery in a flame proof enclosure and connect it with long leads to the Mini; a little creativity required there. Then you put the entire setup in the back of a pickup truck and drive around so the Mini has to do the GPS calculations, which what will drive some of the current demand. The transmitter draw should be constant? Ideally you would use metering to see how much current is being drawn so you know what the Mini is demanding. My electronics knowledge falls short of figuring that out.

If the battery doesn't fail under that scenario, then it may be OK.

I received the pack of CR1225 from eBay so I'm good now.

If you really are saving it locally before upload to the web, why not just automatically save it locally whenever a flight’s data is downloaded (like AltimeterThree does)? Granted, that would bypass the opportunity to rename the file, I suppose, but still….

Sorry if I'm missing something in the discussion. Wouldn't it be easier to download the file from the website rather than find it on your Android directory? What happens if you turn off cell signal to the Android (if it has it), save locally, then upload when you get back to your wifi? Any loss of data?

I always Save Locally and Upload to Web after each flight just to make sure. I'm using my iPhone with cell signal. I could try it on my Android tablet but now I'm scared to. I was taking a screen shot of the Ready for Flight screen to verify but hasn't been problem. The only issue I run into is that it sometimes doesn't show the API wind info. For the following, it doesn't shows the wind for one flight but did for another on the same day using the same altimeter using firmware 27. I haven't tried the Minis yet on the 29. This weekend, I plan to test the API wind to the weather station I bought.

https://flightsketch.com/flights/2568/

 

[BEC]

Sorry if I'm missing something in the discussion. Wouldn't it be easier to download the file from the website rather than find it on your Android directory? What happens if you turn off cell signal to the Android (if it has it), save locally, then upload when you get back to your wifi? Any loss of data?

The issue is inconsistent local saving by Android devices/software. Russ said that this is odd because in order to upload to the web the app has to save it locally first in the same place it would be saved if one had tapped "save locally", which some of us have had problems with—on Android devices only. And I was asking that if that's really the case, why doesn't the app just go ahead and save locally every time one downloads to the phone (as does AlitmeterThree's app) rather than asking the user to do it.

You can upload later....if the local save was successful. Otherwise the data aren't there to upload (or so was my experience when I was testing on Android). I've never had this issue with iOS devices.

I always Save Locally and Upload to Web after each flight just to make sure. I'm using my iPhone with cell signal.

This is what I do as well unless I'm where there isn't signal (BMR's field over in eastern Washington).

I could try it on my Android tablet but now I'm scared to. I was taking a screen shot of the Ready for Flight screen to verify but hasn't been problem. The only issue I run into is that it sometimes doesn't show the API wind info. For the following, it doesn't shows the wind for one flight but did for another on the same day using the same altimeter using firmware 27. I haven't tried the Minis yet on the 29. This weekend, I plan to test the API wind to the weather station I bought.

Sometimes the weather data doesn't work for me, too. I've never tried to figure out what the circumstances are....I think I've even had it happen on some flights for a particular trip up to Sixty Acres and work OK for others.....but I may be misremembering that.

 

[Ronz Rocketz]

The issue is inconsistent local saving by Android devices/software. Russ said that this is odd because in order to upload to the web the app has to save it locally first in the same place it would be saved if one had tapped "save locally", which some of us have had problems with—on Android devices only. And I was asking that if that's really the case, why doesn't the app just go ahead and save locally every time one downloads to the phone (as does AlitmeterThree's app) rather than asking the user to do it.

You can upload later....if the local save was successful. Otherwise the data aren't there to upload (or so was my experience when I was testing on Android). I've never had this issue with iOS devices.

So it's the mystery of the ghost data? Somehow sometimes the file is uploading to the website so it can be downloaded but not able to find the file on the Android. Does it show up in the App Logbook but not in the Android directory?

This is what I do as well unless I'm where there isn't signal (BMR's field over in eastern Washington).
Sometimes the weather data doesn't work for me, too. I've never tried to figure out what the circumstances are....I think I've even had it happen on some flights for a particular trip up to Sixty Acres and work OK for others.....but I may be misremembering that.

Yeah, it's weird. Perhaps there's something about the API wind that won't upload to the app at weird times.

 

[BEC]

So it's the mystery of the ghost data? Somehow sometimes the file is uploading to the website so it can be downloaded but not able to find the file on the Android. Does it show up in the App Logbook but not in the Android directory?

My recollection during Android testing is that there is an entry in the logbook but no actual data file to upload, and so an upload attempt from the logbook later would fail. I'll have to boot the Lenovo tablet back up tomorrow and see if I remember correctly. It should be fairly easy to see if I have files that I can see behind all the logbook entries or not.

 

[Tractionengines]

What I found this weekend: (First time using them.)
1) All the preliminary items were fine. (Turn on. Connent to app. Arm for launch. Reconnect at after landing.
2) Then collect data from altimeter. Seemed ok. (See graphs of altitude, velocity, and acceleration, etc.)
3) Add Description of flight. Seems ok.
4) Hit button to upload to website.
That worked. https://flightsketch.com/flights/2607/
5) Hit button to save locally. Seemed to work.
6) Turn off altimiter, and closed app.
7) Go to show others.
A) Flights ARE listed in app Logbook.
B) Picking an entry fromthe Logbook, shows a flight summary page. At the bottom are 2 options. Upload to web. (or) delete flight. (No graphs, or links to data, or anything else.)
C) Go thru file system (not App) to the Flightsketch folder, and no files there.
D) Go to website and show others the graphs there and download *.cvs file to a directory of my choosing, show them data in the CSV file. All good.
8) Post here asking where I can find files locally, show Logbook, Summary, and empty Directories screenshots.
9) BEC replied that Android app saved locally inconsistently.

I plan to play with it this weekend to see if I can find a pattern to hone in on what is tripping up the process. or if a specific order of events changes outcome, etc.
Mike

 

[Blast it Tom!]

What I found this weekend: (First time using them.)
1) All the preliminary items were fine. (Turn on. Connent to app. Arm for launch. Reconnect at after landing.
2) Then collect data from altimeter. Seemed ok. (See graphs of altitude, velocity, and acceleration, etc.)
3) Add Description of flight. Seems ok.
4) Hit button to upload to website.
That worked. https://flightsketch.com/flights/2607/
5) Hit button to save locally. Seemed to work.
6) Turn off altimiter, and closed app.
7) Go to show others.
A) Flights ARE listed in app Logbook.
B) Picking an entry fromthe Logbook, shows a flight summary page. At the bottom are 2 options. Upload to web. (or) delete flight. (No graphs, or links to data, or anything else.)
C) Go thru file system (not App) to the Flightsketch folder, and no files there.
D) Go to website and show others the graphs there and download *.cvs file to a directory of my choosing, show them data in the CSV file. All good.
8) Post here asking where I can find files locally, show Logbook, Summary, and empty Directories screenshots.
9) BEC replied that Android app saved locally inconsistently.

I plan to play with it this weekend to see if I can find a pattern to hone in on what is tripping up the process. or if a specific order of events changes outcome, etc.
Mike

In the past I've fiddled with Unix - my understanding is that Android is a Unix or Linux variant - and of course I cut my teeth on mainframe systems (DEC VAX), and MS-DOS. And I'm no Android expert to be certain. But it seems to me that they tend to hide things from the user. I don't like that. A file is a file and it's my device. So I should be able to see what's on it, even if I'm stupid enough to foul up critical files. Oh, I know, read the EULA...

I'm sure Russ will get it sorted out, that isn't limiting my enthusiasm for his products in any way!

 

[BEC]

What I found this weekend: (First time using them.)
1) All the preliminary items were fine. (Turn on. Connent to app. Arm for launch. Reconnect at after landing.
2) Then collect data from altimeter. Seemed ok. (See graphs of altitude, velocity, and acceleration, etc.)
3) Add Description of flight. Seems ok.
4) Hit button to upload to website.
That worked. https://flightsketch.com/flights/2607/
5) Hit button to save locally. Seemed to work.
6) Turn off altimiter, and closed app.
7) Go to show others.
A) Flights ARE listed in app Logbook.
B) Picking an entry fromthe Logbook, shows a flight summary page. At the bottom are 2 options. Upload to web. (or) delete flight. (No graphs, or links to data, or anything else.)
C) Go thru file system (not App) to the Flightsketch folder, and no files there.
D) Go to website and show others the graphs there and download *.cvs file to a directory of my choosing, show them data in the CSV file. All good.
8) Post here asking where I can find files locally, show Logbook, Summary, and empty Directories screenshots.
9) BEC replied that Android app saved locally inconsistently.

I plan to play with it this weekend to see if I can find a pattern to hone in on what is tripping up the process. or if a specific order of events changes outcome, etc.
Mike

My recollection during Android testing is that there is an entry in the logbook but no actual data file to upload, and so an upload attempt from the logbook later would fail. I'll have to boot the Lenovo tablet back up tomorrow and see if I remember correctly. It should be fairly easy to see if I have files that I can see behind all the logbook entries or not.

OK - I got out the Lenovo Android tablet and looked at what is actually there. The logbook function was introduced to the FlightSketch app in late spring of 2020. I have fifteen entries in the logbook on the Android tablet. In the directory where the flight data files are supposed to be on Android there are ten files that are new enough to have been written after the logbook was introduced. So clearly not all of them were saved.

I did a little comparing to figure out which logbook entries had files. The logbook gives the apogee as part of the info in the list. I opened the .csv files and compared to figure it out. Some of the saved files had names that were recognizable. I try to, but don't always succeed in renaming the files to include the name of the model and the flight number. So these were easier to cross match.

Then, to see what the app and the online log did when there was a mismatch, I tried to upload from the logbook a flight that I did not see a corresponding file for. After the process started, it gave me an error that basically said "I can't find it":

Up on the web log (flightsketch.com/flights) an entry for this was created....but which is inaccessible to the user. Picking it gives this:

I have never had this problem with iOS, though I admit I have not used the logbook function except sporadically as generally I have connectivity where I fly. I'll be using it again in October assuming the BMR launch planned for the first weekend is able to happen.

Looking at the error message from the Android app I have to wonder what the /emulated/0/ portion of the filename path means....

I have managed to generate this same server error by trying to replace the uploaded .csv file with another while editing the flight data on the log. I now know that if I want to fix something (typically it's been to replace a muddled-up .csv file name with one that I got right) I just upload again and delete the flight with the info I want to change. I figure that making the ability to upload a different file to a given flight in the log bullet-proof is a fairly low priority so I haven't bugged Russ about it.

 

[Tobor]

Like others I am no expert. In my experiences with Android (Nexus 6, Pixel 3 XL), the problem with accessing a file/folder in a specific location usually boils down to a permissions/restricted access issue. Very occasionally, changing the storage location (like moving up one level in the file tree) can correct the problem.

 

[Tractionengines]

the problem with accessing a file/folder in a specific location usually boils down to a permissions/restricted access issue. Very occasionally, changing the storage location

BINGO... (At least maybe.) The PERMISSIONS for storage was denied for some reason. Just changed it to allowed... bet that helps....
Wondering now, how I got the 2 from last weekend up to the WEB, if the first step of that process is to save locally in a temp file, then upload...

 

[kuririn]

Took a while, but my Comp finally got here.
Another perspective of the size:

The app connected right away.

Total weight of Comp and battery is .034 oz.
Will be launching with this as soon as the wind dies down.

 

[Huxter]

Holy hand grenade Batman - you have some big hands!!

 

[BEC]

Took a while, but my Comp finally got here.
Another perspective of the size:
View attachment 473388

The app connected right away.
View attachment 473389

Total weight of Comp and battery is .034 oz.
Will be launching with this as soon as the wind dies down.

It's hard to grasp just how tiny it is until you have one in front of you.

Looks like you need to charge the cell, though....fully charged will be ~4.2V. It'll run fine at 3.88V for awhile, but the cell itself won't like going below 3.5V (which is what Russ put on the box....I was going to say 3.2V).

 

[Huxter]

FS Mini flight ready in orange PLA. One vent hole added. Will use 2 wraps of tape to make sure it does not open.

 

[kuririn]

Flew the Comp in a Leading Edge Micro Yellow Jacket today.
Anybody flown an altimeter in a MicroMaxx rocket before?

98 ft. apogee
Woohoo!

 

[DaHabes]

Flew the Comp in a Leading Edge Micro Yellow Jacket today.
Anybody flown an altimeter in a MicroMaxx rocket before?
View attachment 474373
View attachment 474374


98 ft. apogee
Woohoo!

It might have broken 100 feet if you hadn't added all that weight of the battery and altimeter to the launch!

 

[Ronz Rocketz]

Im not sure what happened to the video of the launch.

 

[BEC]

Flew the Comp in a Leading Edge Micro Yellow Jacket today.
Anybody flown an altimeter in a MicroMaxx rocket before?
View attachment 474373
View attachment 474374


98 ft. apogee
Woohoo!

Yes, I have. https://flightsketch.com/flights/2592/

This is a T-3-based model that I threw together just to do this. It could clearly loose some weight and some wetted area so so as to go higher.

The current NAR record for C division (adults) for 1/8A altitude with altimeter is 84m (276 feet), posted by Steve Kristal (@Gus) not that long ago, using an Adrel:

Since even for my flight the delay was clearly too short, I wonder what Steve did to get another 100 feet. I can only imagine what piston-launching a MicroMaxx model must be like. But Steve holds a number of NAR altitude records, so he knows how to do it.

 

[kuririn]

Yes, I have.

Shoot, I thought I was the first.
Dang.