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?

Views: 149

Reply to This

Replies to This Discussion

Hello,

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.

For the "Mobile FliteDeck VFR" Team,

Markus

Please discuss with the team and maybe even do some direct comparison with i.e. Skydemon, which also uses vector charts, but has shown to significantly draw less current.

Hello,

After some flights I can second this. Other solutions eat up about 4-6% of battery per hour. MFDVFR uses 20% per hour.

And yes, it lags worse than other apps I have had.

It may be that it is because I have installed all of europe - but still: this should be addressed. The Vectorized cards may be of influence... but that's something that other apps use as well.

In addition, Bitmap-Based Apps don't necessarely use less power...

Tobias

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.

Best regards

Mark

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 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?

Hi Mark,

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.

Best regards

Mark

Hi EuropeFlyer...

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?

Thanks Tobias,

that helps. We will have a look into this specifically. Made a ticket.

Br

Mark

Hi (again)

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.

Best regards

Mark

You're welcome.

As I said: I really like the completeness of data (and the prewarnings etc.) The data provided is better than in any other app currently existing IMHO.

But... the app is missing some crucial features.

Tobias


Mark Neumann said:

Thanks Tobias,

that helps. We will have a look into this specifically. Made a ticket.

Br

Mark

Reply to Discussion

RSS

Forum

PRODUCT SUPPORT

In this category you find discussion which should support you in finding answers regarding general or technical questions.

118 discussions

PRODUCT TIPS & TRICKS

Here we share useful information about new features and functions of Jeppesen Mobile FliteDeck VFR.

1 discussions

© 2017   Jeppesen   Powered by

Badges  |     |  Terms of Service