MFDVFR power consumption

We did some comparing flights with several aviation moving map programs and Jeppesen was by far the most power consuming solution. Why is i.e. an iPad Pro on a 2.1 amps power line almost not charging, while all other solutions do, and when is Jeppesen going to fix that, if?

Replies to This Discussion

Thanks for sharing this. Due to the vector based charting rendering engine "Mobile FliteDeck VFR" might consume some more power than other apps, which use more static charts. I am flying a lot with "Mobile FliteDeck VFR", but I never realized that the difference is significant. I will discuss this with our development team. If I get more details, I will get back to you.

I partially answered this in another Thread. Yes, the vectorized depiction of our app might use more power than a static app. However 20% per hour seems a bit high. We should analyze this together if you like.

When comparing computing power, please also mind the form and compression of data, wodnload times and size of coverage.

all for granted, but what Tobias reports is what we see in the field. A little over 4 hours out of a charged iPad sounds familiar.

I have MFDVFR and Skydemon loaded on my prime flight-iPad. Coverage loaded into MFDVFR is significantly lower then in SD. Due to power consumption I only launch MFDVFR to get information not in SD available, such as certain georef'ed airfields and approaches. Time on battery for SD use is always sufficient for a full flying day and I only start to think when hours planned exceed 6-7 hours. MFDVFR is a totally different story and I usually talk time on battery max half of SD. In planning mode the two do not bite each other, but for flying there is a big difference.

Some processes in MFDVFR do eat battery to a large extend and the programmers may take a deep look. Maybe your continuous zooming feature, or your dynamic label play as programmed today is not such a bright idea power-wise in flight?

As I have told.... 73min Airtime, a little over 1h block, 2 legs... battery was down to 82%

It consumes massively more when flying - flight planning is not really a problem. I think the GPS / Moving Map function eats the power in the end. This would explain the laggy display on an iPad Air 2, too.

You should investigate this part if you ask me.

Tobias

Mark Neumann said:

Hello Tobias,

I partially answered this in another Thread. Yes, the vectorized depiction of our app might use more power than a static app. However 20% per hour seems a bit high. We should analyze this together if you like.

When comparing computing power, please also mind the form and compression of data, wodnload times and size of coverage.

Same with Airnav. Airnav uses about 5-10% battery per hour. And I have all europe loaded there, too.

Tobias

EuropeFlyer said:

Hi Mark,

all for granted, but what Tobias reports is what we see in the field. A little over 4 hours out of a charged iPad sounds familiar.

I have MFDVFR and Skydemon loaded on my prime flight-iPad. Coverage loaded into MFDVFR is significantly lower then in SD. Due to power consumption I only launch MFDVFR to get information not in SD available, such as certain georef'ed airfields and approaches. Time on battery for SD use is always sufficient for a full flying day and I only start to think when hours planned exceed 6-7 hours, MFDVFR is a totally different story. Some processes in MFDVFR do eat battery to a large extend and the programmers should take a deep look. Maybe your continuous zooming feature as programmed today is not such a bright idea power-wise?

as my iPad is without simcard it can't be the download at this point (wifi is even switched off in flight).

Just have a look. The 20% battery per hour is annoying, sure. But there's a workaround for it. I'd rather focus on the synchronization / export of data if I were you.

Tobias

Mark Neumann said:

Hello Tobias,

I partially answered this in another Thread. Yes, the vectorized depiction of our app might use more power than a static app. However 20% per hour seems a bit high. We should analyze this together if you like.

When comparing computing power, please also mind the form and compression of data, wodnload times and size of coverage.