The MyFlightBook thread

Lindberg said:
I have a different auto detection question for you. This is from a flight today direct from JWY to AQO. I tapped engine start and flight start at JWY, and I forgot to stop it until we'd driven to our destination (not TS46), but it had already auto detected the flight end time correctly. My question is, why does it think I landed at 2 intermediate airports and 1 after the flight ended, and why does it think I had 5 landings, only 1 of which was full-stop?View attachment 95825
Click to expand...
Not sure your account (send me your email at [email protected]?) so I can't look at the flight track, if available, but my guess is that it's false positive landings from spotty GPS signal. I use the GPS speed to distinguish takeoff from landing, so some low-speeds reported by the android's GPS can lead to false-positive intermediate airports. And I keep watching the GPS until engine end - not flight end, because you could take off again after a touch-and-go.
 
Does anyone have suggested best practices for logging landings at places that don’t have an airport identifier? So far most of my landings have been at airports, or a place that eventually became an airport. But I have a couple off-airport landings (both of them planned) and, if there’s a right way to log those, I want to do it.
 
Three suggestions, not mutually exclusive:
  • Go ahead and make up an identifier; it's fine if something in your Route doesn't match anything in the database.
  • You can also use @###N####W notation (or S/W). E.g., @36.18N111.80W is the grand canyon. It will map if you do this. If you press-and-hold the "append nearest" button (right next to the Route field) on the iOS/Android app, it will append your current location using this notation.
  • If you want it to show up in visited airports, then make up an identifier for it. On the website, go to Airports->Add/Edit airports. I suggest using a 5- or 6- character code to minimize the chances of potential conflicts with actual ICAO codes or GPS waypoints (or to avoid getting overwritten in the future). These may take a little while to migrate down to the iOS/Android apps (I only update those databases periodically).
 
EricBe said:
Not sure your account (send me your email at [email protected]?) so I can't look at the flight track, if available, but my guess is that it's false positive landings from spotty GPS signal. I use the GPS speed to distinguish takeoff from landing, so some low-speeds reported by the android's GPS can lead to false-positive intermediate airports. And I keep watching the GPS until engine end - not flight end, because you could take off again after a touch-and-go.
Click to expand...
Email sent.
 
EricBe said:
Three suggestions, not mutually exclusive:
  • Go ahead and make up an identifier; it's fine if something in your Route doesn't match anything in the database.
  • You can also use @###N####W notation (or S/W). E.g., @36.18N111.80W is the grand canyon. It will map if you do this. If you press-and-hold the "append nearest" button (right next to the Route field) on the iOS/Android app, it will append your current location using this notation.
  • If you want it to show up in visited airports, then make up an identifier for it. On the website, go to Airports->Add/Edit airports. I suggest using a 5- or 6- character code to minimize the chances of potential conflicts with actual ICAO codes or GPS waypoints (or to avoid getting overwritten in the future). These may take a little while to migrate down to the iOS/Android apps (I only update those databases periodically).
Click to expand...
Thank you! I just tested a route of the form KXWA @48.001N104.041W 13UEP715168. (No, I didn't really land on the grass next to Fort Union. That's just a more fun example than my real flights.) I rounded the latitude and longitude to the nearest 0.001 and truncated the MGRS/USNG to a 100-meter square, which seems to be enough precision for any sane use. The MGRS seems to be accepted by MyFlightBook as an "I don't know what that is but I won't complain about it" identifier and the lat/long lets MFB map it for me and tell me the route distance and average speed.
 
iamtheari said:
Thank you! I just tested a route of the form KXWA @48.001N104.041W 13UEP715168. (No, I didn't really land on the grass next to Fort Union. That's just a more fun example than my real flights.) I rounded the latitude and longitude to the nearest 0.001 and truncated the MGRS/USNG to a 100-meter square, which seems to be enough precision for any sane use. The MGRS seems to be accepted by MyFlightBook as an "I don't know what that is but I won't complain about it" identifier and the lat/long lets MFB map it for me and tell me the route distance and average speed.
Click to expand...
what's MGRS?
 
EricBe said:
what's MGRS?
Click to expand...
Military Grid Reference System. https://en.wikipedia.org/wiki/Military_Grid_Reference_System

I find it to be the most convenient coordinate system to use. It is marked on U.S. Topo maps and the Forest Service's maps of the local hiking trail system, all my GPSes can use it (except for my G3X Touch, which can show it but has a bug that I hope Garmin fixed in their latest software update), and it's easier to communicate coordinates because you don't get bogged down in ambiguous decimal degrees vs. decimal minutes vs. seconds.

And, since it lets me designate a 100-by-100-meter square with exactly two digits, three letters, and six more digits, it seems like a pretty safe form of made-up identifier to use with MFB. :)
 
Huh, maybe I should add support for MGRS. 11 characters is more than I allow for identifiers in the database (currently limited to 6), but no inherent reason I couldn't support this natively. I'll investigate
 
EricBe said:
Huh, maybe I should add support for MGRS. 11 characters is more than I allow for identifiers in the database (currently limited to 6), but no inherent reason I couldn't support this natively. I'll investigate
Click to expand...
The full format is 12ABC0123456789 which defines a 1-by-1-meter square, located in grid 12A, 100km-by-100km-square BC, 01234 meters easting and 56789 meters northing from the origin of that square (the southwest corner). You can just truncate digits from the easting and northing to refer to larger squares. There are polar quirks where a slightly different system is used but I think the coordinates format is the same. I haven't spent enough time in the polar regions to worry about that.

ForeFlight accepts MGRS coordinates prefaced by MGRS@ such as MGRS@13UEP715168. I tested it and the minimum it will accept is 13UEP, it won't just let you plug in 13U. But you can enter any level of precision from 100km 13UEP down to 1m 13UEP7157316689.

Your path of least change may be to imitate ForeFlight and parse location entries of the form MGRS@x as MGRS coordinates. Of course, the downside there is that fly-over entries of the form @MGRS@x would look really weird.
 
Nah, the path of least change is to pattern match on the syntax of an MGRS coordinate that is at least a given level of precision (1km?) and then use the CoordinateSharp to convert it to a latitude/longitude for me. No need for a special syntax.
 
EricBe said:
Nah, the path of least change is to pattern match on the syntax of an MGRS coordinate that is at least a given level of precision (1km?) and then use the CoordinateSharp to convert it to a latitude/longitude for me. No need for a special syntax.
Click to expand...
13UEP7116 is a 1km-by-1km square. Even if you go to 10km squares you have a minimum of 7 characters. The maximum is 15. Neither end of that range should conflict with any identifiers in the aviation database. (I don't think that there are any 12ABC-format real identifiers out there, but the 5-character length may be a risk.)
 
Just coded up support (web only) for @xxx where xxx is mgrs. Will take it live in a few days.
 
EricBe said:
Just coded up support (web only) for @xxx where xxx is mgrs. Will take it live in a few days.
Click to expand...
I've often wondered this ... What different treatment, if any, does your code give to @KXWA vs KXWA? I normally enter flyover waypoints with an @ and places I landed without it, but maybe that's not necessary?
 
Here's how it works:
  • XXX ==> Matches Airport XXX, IF it's a perfect match. E.g., KSFO or SFO both match perfectly to San Francisco International. "Airport" here means Airport, Heliport, or Seaport (i.e., not a navaid or fix)
  • XXX ==> Matches Navaid XXX, IF there is no airport/heliport/seaport that is a perfect match. E.g., "AW" is a fix here in the northwest that doesn't match any airport.
  • KXXX ==> Matches XXX (allows for US airports where the "K" prefix is not uniformly followed). So, for example, Jefferson County airport is 0S9, but it *doesn't* have an ICAO code, so "K0S9" is technically wrong. But people use it anyhow. Similarly, Maui is OGG but its ICAO code is PHOG. But KOGG works. (It works in reverse too - if you type XXX and XXX isn't in the system, but KXXX is, then I'll match to KXXX)
  • @###N###W ==> Becomes an "Ad-hoc" fix at the specified latitude/longitude. N and W can, of course, be E and S. This is NOT treated as an airport.
  • @13UEP7116 ==> Becomes an Ad-hoc fix at the specified MGRS coordinate (coded up, not yet live on the website)
  • @XXX ==> If XXX matches a navaid in the database, matches that even if XXX is also an airport. E.g., @SFO is the San Francisco VOR.
  • @XXX ==> If XXX is NOT a navaid in the database but IS an airport, then this creates an ad-hoc fix at location of airport XXX. E.g., @KSFO is a "flyover" fix over San Francisco International Airport. I just added this a few days ago - precisely for "flyover" airports as you describe. That way, they map, but they do not count as visited airports nor should they count towards ratings progress (e.g., when you need to land 150nm away from point of departure).
 
Thank you. On the off chance you're not sick of hearing it yet, I appreciate all that you do with MFB, especially communicating with users like this.
 
@EricBe … this screen shot is how your currency widget looks on my iPhone X.

98EB4FDE-4F34-4905-9918-9F7BF6F14C92.jpeg
​
I like using a green font color to indicate I am current, but there using enough contrast to be easily readable.

Could you see if an alternative is better?

An idea: use a stop light graphic and then black text
 
Yeah, the issue is the translucency over a light colored background image. I should see if I can increase the opacity of that background
 
Widgets aren't working on my Galaxy S9. They just show as a black box and no amount of resizing the widgets changes things. Known issue or am I doing something wrong?
 
Airborne now without my Android; will check later
 
@EricBe .... Just used your "Check Flights" function for the first time.

Thank you thank you thank you for providing that!!!

The tool caught several mistakes and omissions, especially XC time.

Logbook totals looking much better now that I used that function.
 
baboss said:
Widgets aren't working on my Galaxy S9. They just show as a black box and no amount of resizing the widgets changes things. Known issue or am I doing something wrong?
Click to expand...
Huh, just tried on my emulator (running Android 10 on an emulated PIxel) and they work fine. I don't have a physical device with me (won't be home until Monday), but it's working in that. What version android are you running?
 
If you need specific device tests I can load it up on an LG.

(Offering since it’s an oddball.)
 
EricBe said:
Mind trying to set up widgets with the latest build and report back if it works? Thanks!
Click to expand...
Currency works, Totals is blank.

Literally the first time I've loaded the Android version so not much experience with it. I did do a pack and go just in case that might help it behave, no change.

I'll throw a reboot in here in a sec for good measure since it is Android after all... Heh.
779973b37b82f90133eef670970b6087.jpg
a6b32516ee9c7b222c1f79f11d4fc658.jpg
 
Ahh got it. It's Night mode that turns it all black.

Turn off night mode it looks fine.
 
EricBe said:
I was going to say - that looks like black-on-black. I'll have to file a bug to ensure that I handle night mode correctly. Thanks! https://github.com/ericberman/MyFlightbookAndroid/issues/230
Click to expand...

Glad to assist. No big deal really — I figured it was something like that.

I leave my devices in dark mode or themes all the time.

Bright white backgrounds bug me. Grew up looking at green CRTs. Ha.

Not to mention how much unused screen real estate most web pages have. Bleh. Pay for a 4K monitor, silly web pages show ten lines of text.

Guess I’ll always be a terminal guy. Haha.
 
I've checked in a code fix for the widgets - it wasn't respecting night mode. Maybe will try for an update of the app next week or so.
 
denverpilot said:
Grew up looking at green CRTs.
Click to expand...
Showing those to today’s kids gets the same response as showing them a 8-track tape and explaining that back in the day how awesome you were for having a player in the beat up jalopy you had in high school.

Nate… we’re getting too old…
 
My night time currency is not updating as expected. It seems to have started recently, but even though I put in my night time and night landings, it doesn’t update.

DA83D699-551D-4067-BA72-8D35124CF0F4.pngB394E777-22CF-4B09-A34C-9604458C8D58.png
 
KaiGywer said:
My night time currency is not updating as expected. It seems to have started recently, but even though I put in my night time and night landings, it doesn’t update.

View attachment 97163View attachment 97164
Click to expand...

Is it possible that the plane you used (N7120V) isn't set up properly under the "Aircraft" tab? (And therefore isn't reading as an ASEL?)

And charge your battery! :D
 
RussR said:
Is it possible that the plane you used (N7120V) isn't set up properly under the "Aircraft" tab? (And therefore isn't reading as an ASEL?)

And charge your battery! :D
Click to expand...
I’ve never had a problem with the plane before, and it adds to my ASEL time, so I don’t think that’s the problem.

And yeah yeah, I’ll charge it soon ;)
 
All looks correct to me. 61.57(b) requires 3 full-stop landings AND 3 night takeoffs within the preceding 90 days of flight. If I search in your account for night takeoffs, I see 1 on April 1 and 2 on March 31. So while your 3 full-stop night landings on June 9 gave you 90 days of night *landings*, the limiting factor remains your takeoffs. March 31 + 90 days = June 29, which is what is being reported.
 
EricBe said:
All looks correct to me. 61.57(b) requires 3 full-stop landings AND 3 night takeoffs within the preceding 90 days of flight. If I search in your account for night takeoffs, I see 1 on April 1 and 2 on March 31. So while your 3 full-stop night landings on June 9 gave you 90 days of night *landings*, the limiting factor remains your takeoffs. March 31 + 90 days = June 29, which is what is being reported.
Click to expand...
That did the trick. Is that new? I never used to specify night takeoffs as a property, but it updated my night currency. Thanks for letting me know.
 
KaiGywer said:
That did the trick. Is that new? I never used to specify night takeoffs as a property, but it updated my night currency. Thanks for letting me know.
Click to expand...
Not new, but slightly modified a few months ago. PIlots are always lax about recording night takeoffs, so my rule has always been "if I don't see them, assume this pilot doesn't record them and just use landings but give a warning that night takeoffs haven't been found, but if you do see them then clearly this pilot does record them, so require them." What changed a few months ago is how I determine "do you record them." I used to just look for night takeoffs in the last 90 days. Now I look to see if you have any night takeoffs, ever.
 
EricBe said:
Not new, but slightly modified a few months ago. PIlots are always lax about recording night takeoffs, so my rule has always been "if I don't see them, assume this pilot doesn't record them and just use landings but give a warning that night takeoffs haven't been found, but if you do see them then clearly this pilot does record them, so require them." What changed a few months ago is how I determine "do you record them." I used to just look for night takeoffs in the last 90 days. Now I look to see if you have any night takeoffs, ever.
Click to expand...
Hmmm. What if the only reason someone ever recorded a night takeoff was to shut off the warning?
 
midlifeflyer said:
Hmmm. What if the only reason someone ever recorded a night takeoff was to shut off the warning?
Click to expand...
Recording 1 night takeoff will shut off the warning...but then you're not current because you only have 1. You should log 'em. Note that the warning isn't an alert - it doesn't pop-up or interrupt you or anything like that. It simply shows in fine print (not even red) underneath your night currency "Required night takeoffs not found; ensure they have actually been done!"
 
@EricBe … for iPad and iPhone, is there a setting or switch than can be flipped to put the “Overall” category of Flying Totals at the top of the page versus the bottom?

That would be a good spot right above total by category/class.
 
You must log in or register to reply here.
Back
Top