Logbook functionality; should be compatible with EV3 or designed from scratch for best result?
We are considering removing the automatic time detections and switch to an entire manual toggling because with EV3 we see too many issues where takeoff and landing are wrongly determined, just as automatic flightmode enabling, let alone if we would add offblock and onblock also. The idea is sometimes its better to keep some things manually.
My preference would be automatic, but since this was badly working in EV3 I do appreciate the question.
Would it help if the airspeed is not the only parameter to determine the airborne time , but combine this with gps altitude, so even if airspeed is displayed at 0 for a short time, and altitude is not 0 continue with flight mode?
One solution could be that you design the „flight mode“ button as a popup menu with the buttons „off blocks“, „departure“, „landed“ and „on blocks“. I never had issues with the automatic detection, I am quite happy with it. Perhaps you could implement a switch between auto and manual...
I had no problems with automatic detection either, so I concur with Bastian's proposal
An export (and import?) to/(from) excel (or csv) please!
I never had a problem with automatic t/o and landing detection .. it was certainly a whole lot more reliable than my remembering to do it manually would be and I found that not automatically switching into flight mode when I departed yesterday very disconcerting. My feeling is that this is a fundamental function of an EFB and at the very least it is essential this is an option for those of us that value it.
I also was quite happy with the automatic detection. Preflight and departure checks are often quite plenty and imminent, so by manual detection only a feature you tend to forget!! I agree with a possible GPS function on speed and altitude (positive climb rate!)
Requested by Bob: https://easyvfr4.aero/community/feedback-on-features-and-functionalities/loogbook-departure-airfield-logging/#post-1379
This past weekend I flew into a few farm strips some in the database others not. So I created some userwaypoints and used them when flight planning as departure points. All fine so far.
Later when checking the logbook EV 3 had picked the nearest airfield to record the departure point even though a waypoint had been used in the flight plan.
I can understand why EV has done this but it look odd especially when I had created the departure airfield.
Something to think about for EV 4 perhaps
Please add automatic airborn and landing time logging, it is very important for me as i always forget to log the times manually.
It does not need to automatically switch to flightmode, just show a list of the start and landing times and the airfield name. It is not a problem for me to manually filter out additional wrong values.
I'd like to have it automatically.
I know it is a tricky feature as I had written such an application for android - and dind't entirely suffice. But not because it was not feasable, but because I didn't spend enough time for this and din't think enough about it.
Later, I wrote down an few notes for a new version (and never had time to implement it). Here they are:
- Monitor GPS data for movement
- Do movement check NOT based just on changed coordinates, but on vector. i.e.: check at least three or four fixes being in a straight line (with some degrees tolerance) and having a minimum distance of xxx meters. Could be a taxiing though ...
- Therefore: Monitor gps data for climbing rate
- Do climbing check NOT based just on changing altitude but on vector. i.e.: check at least three or four fixes being in a straight line (with some degrees tolerance) and having a total climb of at least xxx feet.
- If airplane state is "on ground" AND movement is in a straight vector AND speed is at least or more than xxx mph (V[to]/takeoff-speed) AND climbing rate is at least yyy ft/minute AND climbed altitude is at least zzz feet, then you have started.
- If you have started, backwards-calculate the real starting time.
- If you did not detect a starting condition but you detect doubtlessly a flying condition (e.g. based on speed) set this as a starting time together with a "to be reviewed" marker.
Detecting the "landed" state is easier: If airplane state is "in-flight" AND the speed is below V[s0] for more then xxx seconds, you have very likely landed. Backwards calculate the landing time (back to (when elevation was >= current-elevation + xxx feet) + yyy seconds)). This algorithm should even cover trouch-and go
All xxx, yyy and zzz values should be configurable per airplane.
Off-block/On-block is difficult. With modern tablets, a noise-detection could eventually help, together with a vibration/shock detection. But I consider an off-block detection very hard to develop and implement.
I personally set my off-block and on-block times usually to (take-off minus 10 minutes) and (landing plus 10 minutes) or so, depending on actual situation. Such behaviour could be implemented in eVFR as well, with a configurable plus/minus time per airplane and/or airport.
design from scratch please.
converter for compatibility.
most importantly i need automatic trigger time detection (offblock, airborne, go around/touch and go time/counter, landing time and onblock time detection. present it e.g. in an ACARS paper printer style or cash register receipt fashion 😉
? from scratch