I agree, Tim. The live PLOG would be a great place for this.

Just to mention it once more: a cumulative column for time (i.e., EET), fuel and distance would be a very useful addition in the PLOG, particularly for planning. It allows me to find the best spot for a stop over when trying to maximize my range in a particular leg. Currently I have to do the running sums in my head.

Greetings, -- Chris.

All of this discussion serves to highlight why the two "PLOGs" actually should have quite different functionality. I don't like the fact they're both called PLOGs, even, because it's confusing. We want:

1. A "static" PLOG designed for printing and to contain everything you might need to perform your flight with dead reckoning if you don't have a GPS.
2. A "live" PLOG designed for helping you navigate your way through a flight, giving live statistics and possibly helping to make in-flight modifications to your route.

Really we want to rewrite the specification for both of these features to see exactly where they overlap, and more importantly, where they differ.

In my RAF Navigator days the "static" PLOG was called a Flight Plan and the "dynamic" PLOG was called a Log

To me, static PLOG and live PLOG are actually one and the same, just as the flightplan turns into a log as I pass each checkpoint and mark down my actual values at that point. So the flightplan gradually turns into a flight log as the flight progresses.

Similarly, the static PLOG is used during flight planning. It has things like EOBT, ETA, EET, where the initial letter E stands for "estimated". The live PLOG has AOBT, ATA, AET, where the A stands for "actual" in all instances that the event (i.e., passing a waypoint) has already happened and maintains a continuously updated list of "E-values" for the ones still in the future. This matches the metaphor of a plan turning into a log perfectly.

There are many potential columns which might be displayed in the PLOG. Actually, there are too many to display them all everytime. Things that come to mind are: Waypoint name, Lat/Lon coordinates, Leg altitude, Wind direction/speed, True heading, Wind correction angle, True course, compass variation, magnetic course, planned speed, ground speed, leg time, leg distance, leg fuel burn, cumulative time, cumulative distance, cumulative fuel burn, ETA, ETE, EOBT, ATC frequency used for the leg, and probably some others I missed.

I don' think there is a one-size-fits-all solution. Therefore I advocate SD offer a list of all possible columns and let the user pick the ones he likes. All under the premiss that data in these columns (where applicable) are calculated either as E- or, wherever possible, as A-values.

Another idea: the frequency suggestions SD offers are -- at least in the regions I have flown -- often times inaccurate or missing. In many cases there is an official frequency but local knowledge or custom has people use a different one. Case at hand: the VFR advisory frequency in Austria is 124.4 MHz, except around Vienna where it is 118.525 MHz. You have to know this. If you don't, the guys at 124.4 will just tell you to contact them on 118.525. Therefore I would appreciate the possibilty of a user enetered leg-frequency just like the user can enter a leg-altitude. This frequency column may be prefilled by SD as a form of suggestion and I can then review these and make changes where appropriate. These leg frequencies are also available as a possible column selection in the PLOG.

What do y'all think?

-- Chris.

I'm with Chris.  When I'm flight planning the static plog can be printed for those times when the wings get in the way of the gps receiver.  

It would be useful to me to have the static plog become active when flying, and update the ETA with the ATA when a waypoint is reached, and reforecast the ETA for the next waypoint.  I can then use the plog after landing to record takeoff/landing in the plane's Tech Log, and also my logbook.

Dave

I'm with Chris and Dave on this as well.

Mike
_________________________________________

We've started to think about how the PLOG is best enhanced. We do plan to add options for more columns as part of this exercise.
If you could have an extra three columns in the PLOG, what would they be?

Obviously, the potential for the PLOG becoming overcrowded is high. On a mobile device there may literally only be room for three or four columns before the display becomes hard to read. Do you think it would be a good idea to have different column-visibility settings for the planning PLOG and the in-flight PLOG?

In Landscape orientation, the Menu tabs across the top of the screen are:-

Route, Undo, Mapping, Setup, Logs, Pilot Log, Simulate, Go Flying

In Portrait orientation, Mapping, Setup and Simulate disappear and combine under (...)

Is it perhaps feasible to use a similar approach for Plog columns? Just a thought.

Mike
_________________________________________

Not easily, no, because we want to use HTML as a good format for the PLOG. We want to use HTML because it's great at finding the best layout for tabular data and letting the user pinch zoom in and out. It also makes it straightforward for us to offer the same PLOG across multiple platforms.

Not being a coder, HTML et al is a complete mystery to me, but now that you've explained it, I understand where you are coming from.

Mike
_________________________________________