Logbook functionality; should be compatible with EV3 or designed from scratch for best result?
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...
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!)
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 😉