Almost certainly the issue is that I'm preserving the search (in the address bar, do you see "fq=..." in the URL?) The idea is that you realize "oops, I made a mistake on 5 flights in October of last year", so you search for something that matches those flights, then you edit each flight, returning to the search results so that you can quickly edit the next one. You can clear things pretty simply: click Logbook->Add Flights (or choose anything from the drop menu, or just click on the "Logbook" tab). That will throw away all of the state that it's trying to preserve and start fresh.
Hey, Eric! Thank you for the response. Next time I get on my computer, I will take a look to see if the “fq” is in the URL. However, I actually have gone to Logbook->Add Flights many times. That is basically how I add each trip and I have had this issue for about a year.
As a side note, this seems to only happen on my desktop. The apps are fine, but I always add flights on the computer. Abram Finkelstein N685AS
Use the drop-down from the menus at the top,not the button. The button keeps state because it doesn’t hit the server.
Is there a way to track the exception for night currency for turbine aircraft pilots that have passed a 142 program in the past 12 months? This is a fairly complex alternative to the 3 full stop night takeoff and landings. 14 CFR § 135.247 , a, II ?
I think it already does. I know my King Air night landing currency is often different than my AMEL currency. You do need to enter your 135 checks into the logbook.
Hmmm...I *do* support 61.57(e)(4), which looks suspiciously identical to this. Too early here in the morning (traveling in Portugal at the moment) for me to do a word-by-word comparison for any subtle differences, but just doing a quick alt-tab back-and-forth between the pages I'm not noticing any obvious differences. I do 61.57(e)(4) computations automatically (nothing you need to do), and often get pilots confused because they are "more" night current than they thought they should be... Note that I have no way to know that you've done a 142 program...
Perfect 61.57(e)(4) actually references compliance with 135.247, so that will work… so nothing needs to be tagged for 61.57e4 to put night currency at 6 months? Mine happens to be showing 90 days so I figured I missed a property
Correct, no need to log anything special, but this code is complex. Do me a favor? I’m traveling in Europe until the weekend. Please email me (myflightbook@gmail.com) on Saturday or Sunday and I can look at the code against your specific logbook data and figure out what is or isn’t triggering. Thx
I don't tag anything special, and my night currency often looks something like this, like it does right now:
Follow-up: ja_user graciously let me share the results of my deep-dive into his logbook; I'm sharing it here because I think it will be interesting on this thread... Super. OK, here's what I'm seeing (using data from my site backup of yesterday morning, which seems at first blush to match what's on the live site in your account). And I need to disclaim that I've implemented the regs as I understand them; I'm not a lawyer, I may be interpreting them incorrectly, your mileage may vary, blah, blah, blah (short summary: use at your own risk). Anyhow... To compute Night currency, I compute a bunch of mini-currencies and combine them, using whichever gives you the MOST time. To further complicate things, you have at least 3 active night currencies: AMEL, AMEL-EMB-505, and AMEL-LR-45. I assume, though, since you mentioned the sim session, that you're referring to the EMB-505 session from May 9. 61.57(b) (i.e., 3 takeoffs/landings within 90 days): I show you current until Aug 7; this appears to be driven by your 20 landings/19 takeoffs in your May 9 sim session. Super. That pegs the date at Aug 7 (90 days from May 9) 61.57(e)(4)(d) says you must also have 1,500 hours (you do); AND have done 3 takeoffs/landings within the preceding 90 days in type (effectively the 61.57(a) requirement) - which is also true until Aug 7; AND have 15 hours of "flight time in the type of airplane" within the preceding 90 days AND have done (either 3 night takeoffs/landings in an aircraft within the preceding 6 months OR 6 night takeoffs/landings in a sim in the preceding 12 months). So the two limiting factors are in those last 3 requirements above: I only see 0.9 hours (ever, not just in the last 90 days) of flight time in an actual (i.e., not-sim) EMB-505, so you don't have the 15 hours, and you've never done the 3 takeoffs/landings at night in the 505 so 61.57(e)(4)(i)(D) can't apply. You do meet the 6 takeoffs/landings-in-12-months-in-sim requirement, of 61.57(e)(4)(ii)(D), but that doesn't save you from the 15 hour requirement. Note that the definition of flight time if you click on it using the link above does not seem to allow for your sim time to count towards the 15 hours, since it requires an "aircraft" and it requires movement "under its own power for the purpose of flight", none of which applies to a sim. If I modify (on my development machine, not the live site) your 0.9 hours to be 16.9 hours, then you meet that requirement until Aug 10 (90 days from May 12). So at that point, your currency expiration by 61.57(e) becomes the EARLIEST expiration date of all of the required component currencies. That is, the earliest of: 1,500 hours - (never expires) 61.57(a) in type - 8/7/2023 (since you only did 2 takeoffs/landings on the 12th, you have to go back to May 9 to find the required 3rd landing 15 hours within the preceding 90 days: 8/10/2023 (due to my edit above) 61.57(b) night currency within the preceding 6 months (never current in a real aircraft) OR double that within 12 months in a sim (valid until 5/31/2024) MIN(never, 8/7/2023, 8/10/2023, 5/31/2024) = 8/7/2023. I then compare the LATER of that with 61.57(b) (i.e., basic night currency) and report whichever is LATER (i.e., giving you the most time before losing currency) 61.57(b) expires 8/7/2023, so I'm reporting MAX(8/7/2023, 8/7/2023) = 8/7/2023. I do also want to clarify that it's important to remember that this reg doesn't "make you current for a year". The only thing it does is *potentially* extend the amount of time since your last night takeoffs/landings. E.g., for your specific scenario, you did your night landings in the sim on May 12. So if you do no more night takeoffs/landings until a year from now (May 14 2024), you *might* still be night current, or you might not. It completely depends on whether you maintain your 15-hours-in-90-days in a 505 AND maintain your 61.57(a)-in-a-505 for that time. If you do that, then (by my interpretation), you will be night current all the way through May 31 2024 despite not having done a night takeoff or landing for more than a year. But if you don't keep up those experience levels, you lose the night currency. (See why I needed to dive into your specific logbook to answer your question? )
Not so much a MFB question as (maybe) a Foreflight question, but MFB has no problem recording a track log when it's in the background or even if the ipad is in sleep mode. It just keeps on tracking. Foreflight, on the other hand, does NOT continue tracking if you switch to another app (speaking about the "Track Log" feature here, not the Logbook, which of course I don't use, MFB being superior!!!). Even Foreflight's FAQ says that it will not work when using a wifi-connected GPS receiver (like a Stratus) - but will work using a Bluetooth GPS OR the internal GPS on a cellular model. Since I use a Stratus most of the time, connected via wifi, why can MFB continue tracking but Foreflight can't? My assumption, of course, is that @EricBe is smarter than the whole Foreflight team.
Heh, heh, no (but I'm flattered at the thought). But I thought if you pressed the "REC" button on the foreflight page it will run in the background?
