All of the IFR High Enroute charts are in a single file, you either get it or you don't - It's not done by state like the others.
Interesting. I turned it on on the iPhone and it didn't "want" to download a new file. Bug?
I also played around with the "Reload Download List" in the Settings App, and it never wanted to download anything then either. Thought that was interesting. Maybe that's not the purpose of that slider?
Latest version, on iPhone, on WiFi at the time.
[/QUOTE]
Not correct - The old ones will hang around (and be used) until the new ones become effective at 0901Z on the rollover Thursday. THEN they get deleted.
Forgot it'd hold on to the old ones while they were still valid. Have only had to deal with that once... apparently I've not caught the update cycle that often. Cool, a new way to tell when I'm not flying enough.
[/QUOTE]
Like I said, it's about 7GB. On my 10Mb/s cable modem connection, it takes about 2 hours. (With network overhead, 10Mbit/s =~ 60MByte/min, or 3.6GB/hour).
Are you doing the maximum bandwidth math for your connection, or are you measuring actual download speeds. I've seen Foreflight's servers serving data significantly slower than my maximum bandwidth available when I'm on the work dual-DS3 speed connection to Level 3's backbone.
Of course, that router is "outsourced" and handled by the idiots at a company called Masergy who couldn't figure out what was wrong with a DS3 from DEN to California for two weeks.
Since it was IT's problem, not mine, I just stayed out of it. It's a five minute test to set up end-to-end, and then the downtime equals how long you want to run the test pattern.
I never looked to see who Foreflight's hosting is handled by or which backbone they're on, just 'cause I'm too lazy to sniff the IP address from the iPhone at my border analysis box with tcpdump that sometimes is connected where it should be (heh heh) between the outgoing switch on the home network and the Cable Modem. Mainly 'cause it's turned off right now, and hasn't been on in a while...
I wasn't particularly interested until now. Might be fun to see how they're handling authentication and encryption... if they are... or if they're open to a Distributed Denial of Service attack via "He who dies with the most bandwidth wins" techniques.
Assuming they have round-robin DNS as a bare minimum with multiple boxes responding for whatever name their download app is using, for redundancy... the choice may not be the optimal server when coming from Level 3, or there could be a bottleneck elsewhere. Or their download server could be throttled. It's a rare server I run into that I can run full-data-rate from work from. There's a couple of .gov Linux mirrors that'll max out the pipe though... those are fun.
Sniffing H.323 and SIP at work is getting boring. Maybe it's time to go spelunking on my home network again someday soon and see what some of the newer software apps around here that I've not sniffed yet, are actually doing. You find interesting things... hardcoded usernames and passwords sent in cleartext... or none at all... no encryption on personal data... software is notoriously bad for hiding its naughtiness in how it handles network connections. And server admins on the other end are also naughty... DNS servers without DNSSEC... round-robins with dead machines in them... all sorts of fun stuff to find.
But then again, that's a little too much like "work" to sit around sniffing stuff here at the house anymore. Maybe 10 years ago it was interesting... now I seem to always have something more important to do.
I have done it over 3G (I still have unlimited data
) and that takes 6-7 hours. But you'd only ever do that in a pinch.
It's a good reason to keep only States you're actually flying in, in your activated list. I did have one nav cycle pop up when I was away from home and staying at a house where WiFi was some "newfangled gadget" they hadn't yet ever purchased. I downloaded over 3G, and had unlimited service at that time. Now I don't... but they upped the cap to 4GB so I'd still be okay if I weren't downloading the entire U.S.
(They were a Mac household, and by two days into that silliness, I just went over to their hard-wired Ethernet-fed iMac and turned on WiFi network sharing so my gadgets would work without having to grab their Ethernet cable and turned off automatic Sleep mode on their iMac. Put it all back before I left. LOL!)
Huh? The other one is Bluetooth - No cable.
Oh it is, eh? Okay. I don't own one. I assumed it had a cable.
I wouldn't really call that a wildcard. The iPhone 4 on Verizon has GPS, doesn't it?
Who says the chipset in the iPad 2 is the same chipset as the VZ iPhone 4?
(Yes, it's about 99.9% likely that it is, but until we've seen a tear-down... which is what I kept saying... no one really knows. Developers access the location data in code via the Location Services API... so Apple can change the hardware at-will as long as the API keeps working for Devs.)
Aaaaaaaargh! This is my most-hated misconception about the iPad.
The GPS in the iPad *IS* a "real" GPS. Period, end of story. Yes, it is part of the cellular chipset - But that's because it can get a quick initial fix by getting assistance from the cell network, so you don't have to wait more than a few seconds to get that initial fix like you do.
You do NOT need to have cellular signal to get or keep a fix. It simply gets you the initial fix much faster than a "real" GPS. So, we would NOT be "lucky" if Apple went to using a "real" (non-a)GPS.
[/QUOTE]
I should have been more careful with this comment. I have read some reports that the chipset has problems with exceedingly long "cold-start" GPS acquisition -- if it can't get a 3G cellular signal at all.
I therefore always fire up Foreflight in GPS mode on the ground and would endeavor seriously to avoid ever having to do a "cold-reboot" of the iPad in-flight.
Scenarios where the iPad would have to "cold-start" the GPS are things like a completely dead battery or an iOS crash, core dump, and restart. Not going to happen very often.
(By the way, this is where the majority of security-related problems on the iPad look to be about to spring forth from in the security-research world... at least one person has claimed -- but not published in the wild -- that forcing the iPad to core dump gives access to encryption keys and other personal data in RAM... one of the oldest Unix tricks in the book. iOS doesn't apparently have a mechanism (or it isn't being used) to keep certain data out of core dumps if you run the thing out of memory. And memory is tied directly to swap (on the flash) without an out-of-memory killer or mechanism to say "nope, I won't allocate that much to you", so getting it to core is a simple matter of allocating all available memory. iOS will keel over like a deer shot with a rifle for that old trick, apparently. We'll see if anyone can figure out how to exploit it fully... before Apple plugs that iOS hole. That one's pretty straightforward, but there's certainly got to be other just-as-effective ways that aren't quite so "brute force" to core the OS, keep the core file in flash, and grab it after a reboot.
Anyway, back to the on-board GPS... it has some obscure little engineering problems that are just pesky on the ground... and ones I'm willing to live with. It wasn't designed to do aeronautical navigation, after all.
How the CDMA chipset (VZ) handles ALL of this... there's no data out there yet on which chipset really got used, and no one has looked over the datasheet to see what the worst-case scenarios are for start-up time from a cold-start with no CDMA clock and location data to sync to.
Someone with a good faraday cage or completely RF dead zone for cellular could test this pretty easy, but it'd have to be a repetitive test with different numbers of GPS birds in view overhead each time, preferably very few and way out at the horizon.. to get the true worst-case.
I lost my access to a seriously RF-tight enclosure a couple of years ago.
An dead zone up in the mountains somewhere a long way from people, a campfire in the middle of nowhere, an engineering notebook, and beer. The true hacker way. +1 for being down in the bottom of a valley to block the sky view of the GPS constellation so your testing could be done in truly awful conditions.
Now you have me thinking -- are there any Apps that show the currently tracked GPSs in the cluster and signal strengths for the iPad, or is that data not available via the Location Services API? I know you get an accuracy number (Foreflight uses it), but can you get raw GPS receiver data from the hardware?
If that data is available, it would be nice to have a "Satellites in view" signal strength page inside Foreflight or on another App on the iPad.