PDA

View Full Version : Garmin 430 Flight plan upload.


CMDR114
8th Apr 2009, 07:15
A Cirrus owner mentioned to me the other day that Garmin are bringing out a software update to allow flight plans to be uploaded.

Not sure I understand how this can be done unless an unused serial port is used.
Has anyone heard anything similar or have additional information, as I would be very interested as I am sure would others.

John

S-Works
8th Apr 2009, 07:23
Rumour has it that it will be uploaded via a data card written using the USB programmer we use for writing the database cycles to card.

However when I called the Garmin techs for a look in order to write an article for the magazine they said it was a long way down the pipeline and may not actually appear.

CMDR114
8th Apr 2009, 07:39
I hadn't thought about using the data card slot.

I was also told the Nav data would contain VRP info sometime this year but that also seems to have gone very quite.

CMDR114
26th May 2009, 08:39
Update to my original post for those interested.

Here is the link to the required software for flightplan transfer to the GNS530W/430W https://buy.garmin.com/shop/store/downloadsAgree.jsp?id=4471&product=010-00416-01&cID=194&pID=8052.
It uses the Terrain Data card slot and accepts flightplans (.fpl files) from software such as Jeppesen Flightstar. You need to purchase the Flightplan Transfer kit from Garmin.

IO540
26th May 2009, 08:55
Jeppesen do a bit of software called a Flight Plan Migrator (or something like that) which processes a routepack from Flitestar, and writes the stuff onto the Garmin flash cartridge.

It would be great if this worked over a serial port (or even bluetooth - imagine simply syncing your laptop flight plans to the GPS at the press of a button) but we haven't yet got to the 1970s in this business ;)

CMDR114
26th May 2009, 13:30
I work for a Bluetooth chip manufacturer and agree with you 100%. The big problem is that there are too many luddites that think that anything digital must be unreliable, and wouldn't buy it. The more electronics and the less mechanical the better as far as I am concerned. :ugh:

ShyTorque
26th May 2009, 14:22
No criticism meant, a genuine question - what advantage is there to this software, over simply inputting a flightplan manually on the day?

Thanks.

IO540
26th May 2009, 14:33
I work for a Bluetooth chip manufacturer and agree with you 100%. The big problem is that there are too many luddites that think that anything digital must be unreliable, and wouldn't buy it. The more electronics and the less mechanical the better as far as I am concerned.Maybe I picked the wrong example ;) Bluetooth (which I have used widely) is reliable in common retail stuff like phones/headsets and flakey in much other stuff. The devices get debugged where there is the strong commercial incentive to do so, and low volume stuff is often never fixed. Someone like Garmin could put resources into developing / incorporating a bluetooth radio into a unit of theirs. They would have to be careful though - the problem is that one is then left with a wide variety of laptops, with their various crappy bluetooth stacks. I think they would have to specify compatible laptops and specific bluetooth driver versions on them which are known to work, and everything else is unsupported (the de facto situation in IT).

I think the issue is certification, and this involves validating the input data, which with a bluetooth radio connecting to potentially anything within range would probably be impossible. That I am sure is why Jepp/Garmin have gone the "text file on a flash cartridge" route, because the validation of such data can be done to very narrow criteria.

No criticism meant, a genuine question - what advantage is there to this software, over simply inputting a flightplan manually on the day?Purely the time.

Take an FL100 airways flight plan EGMD LYD DCT KONAN L607 RUDUS L984 ASKIK Z74 KOSEK L603 OBEDI/N0150F150 L172 VIW/N0150F140 L608 DOL P173 KOMAR L187 DBK R45 RODON N732 PITAS LGKR

Most GPSs cannot take the airway names, so you have to put in the waypoints and my waypoint count for the above route is 59, most of which are 5-character names. I could paste them all here but won't :)

Enetering this lot into the GPS, with its 2-knob user interface, takes quite a while. A lot of the time one departs while a 2nd pilot enters them in... not ideal. Not something I fancy doing single-pilot, in turbulence :)

ShyTorque
26th May 2009, 14:41
I see your problem.

I am generally obliged to invent my own waypoints and insert them as lat/longs as we usually stay off airways - thankfully not anywhere near as many points as you need.

Looks like I'm as well off keeping with my present "otj" (on the job) manual loading method.

IO540
26th May 2009, 14:44
Another reason for loading the whole route in is that if you have an accurate fuel totaliser, linked to the GPS, you get a continuously updated computation of your fuel on board (FOB) at the destination. 1% accuracy is achievable, and it makes diversion etc planning much easier.

CMDR114
27th May 2009, 11:31
With high speed Bluetooth version 3 now available, you get 802.11 speeds and better security.
Garmin already have experience with Bluetooth so it would not be that new to them.

I agree that simple low level data with wired connection has its advantages but should not preclude new technologies.

When we first started Bluetooth I remember getting our first devices back from the Fab and the best we could do was a 1200
baud data connection over an 8 cm link, how things have improved!
Unless we push the boundaries we will never make progress.

I have to say that I think this software change has been implemented to try to stop some of the criticism they have had from what
was a pretty bad oversight on their part.

I guess they have tried to do the best they could without having the customers implement new wiring changes to bring out any
spare serial channel for the data connection so good on them for that.

As for why we need it, as has been said, its about time on the ground.
My IO-540 uses enough fuel as it is without wasting any more than I have to. :)

IO540
27th May 2009, 12:31
I guess they have tried to do the best they could without having the customers implement new wiring changes to bring out any
spare serial channel for the data connection so good on them for that.

I don't think these GPS units have any means of loading the flight plan via a serial link. They do have plenty of RS232 and in some cases ARINC interfaces but none of them provide a straight means of loading the route, with its waypoint names, etc.

It has been widely stated that this is to save the mfg from having to get involved in the certification of the data source (which, in the case of windoze, or even the somewhat flakey Jepp software, would be a nightmare) but I have never found a reference for this requirement.

What you could definitely do with the Garmin x30 units is to make use of the crossfill feature which is (I believe) an ARINC connection between two of them. If they both have the same database cycle, you can transmit a route from one to the other. Obviously, this interface could be faked so that any route description coming out of a PC is made to look like another Garmin x30, and away you go. I have not heard of anybody having done this, but if they did they would obviously not be advertising it. I reckon, with a protocol analyser, the specification would be a day's work and then somebody has to write a bit of code, and get an RS232 (or USB) to ARINC converter (a few hundred quid). The interconnection may even be RS232 - I have the installation manual for these but not to hand right now - which would be trivial to drive from a PC.

The higher end versions of the G1000 glass cockpits come with a keypad for waypoint etc entry - this is something pilots have been asking for for years and I don't understand why it has been so long coming.

Tinstaafl
27th May 2009, 16:34
Buggered if I know why Garmin et al don't just include a USB port on the front of their devices.

Add a software modification to upload via the USB port using a simple delimited text file so just about anything can write the file, and a routine to compare the data with the internal database and allow corrections using the hardware's controls.

bjornhall
27th May 2009, 17:34
I reckon, with a protocol analyser, the specification would be a day's work and then somebody has to write a bit of code, and get an RS232 (or USB) to ARINC converter (a few hundred quid). The interconnection may even be RS232 - I have the installation manual for these but not to hand right now - which would be trivial to drive from a PC.

Anyone who tries this would have to ask themselves where they reckon any syntax checking takes place... Since the interface in question is not meant to be externally available, it could well be systemized under the assumption that any device transmitting on the interface will know what it is doing; i.e., hardly any syntax error protection. In that case, second worst case scenario is that a factory reset will bring the unit back to life again...:sad:

Anyone able to pull that stunt off is probably doing embedded systems for a living, so it might be a bit of a busdriver's holiday to do it for free on one's spare time... But go right ahead! :)

I would love a robust way to load a route from the laptop straight into the unit! If I was designing it I would definitely go for a proprietary format and a loader application on the laptop though, with USB rather than Bluetooth. Would not like the user to be able to push any kind of corrupt data right into the unit... Embedded systems tend to have somewhat sensitive digestive tracts, given the user is not supposed to interface with it directly... :eek:

fernytickles
27th May 2009, 17:40
Isn't this why we have "DTO" or "Direct To" buttons? Infact, isn't that why we have GPSs, so we can go direct?

Airways? Er, no thank you....unless we are reeeeeally, reeeeally bored... :bored: Maybe one waypoint en route, but thats enough for my fingers.... Repetative strain injury can cause a serious risk to one's medical....:p

IO540
28th May 2009, 08:16
Buggered if I know why Garmin et al don't just include a USB port on the front of their devices.

Add a software modification to upload via the USB port using a simple delimited text file so just about anything can write the file, and a routine to compare the data with the internal database and allow corrections using the hardware's controls.A "USB port", assuming you mean a USB slave and not the more complex USB controller function, would have to appear as a) one of the predefined USB devices e.g. storage, keyboard, mouse, in which case no driver is required on the laptop, or b) a non predefined device, in which case a laptop driver is required. Most USB ports on things like cameras or fancy phones can appear as storage devices so you just plug them in and the PC sees a new virtual hard drive and you just copy files to that.

I think this is what the current Jepp/Garmin x30W "flight plan migrator" solution is - except they use a flash cartridge as the transfer medium. This eases the verification requirements - not that GA avionics software undergoes all that much verification anyway ;)

Anyone who tries this would have to ask themselves where they reckon any syntax checking takes place... Since the interface in question is not meant to be externally available, it could well be systemized under the assumption that any device transmitting on the interface will know what it is doing; i.e., hardly any syntax error protection. In that case, second worst case scenario is that a factory reset will bring the unit back to life againThere has to be some validation already, otherwise a bad crossfill connection would corrupt the destination GPS.

Obviously the PC software would have to be written carefully, but this is no different to what has been available on non-IFR GPS units for many years, with programs like Navbox or Flitestar. All these manage it OK right now. And anyway one looks at the displayed route on the GPS screen before one flies with it, so if your flight to Norwich shows a waypoint in Mongolia, it will be readily apparent :)

The crucial point is that one makes a lot more mistakes doing manual waypoint entry, which is why most pilots would go for a direct transfer if they could get it.

Incidentally, Chelton have been offering a flight plan loading method using a flash cartridge, for some years, so they must have come to the same conclusion as Garmin have much more recently... writing the flight plan onto the flash cartridge is a fairly robust way to do it. It will however b*gger up the CF connector pretty fast; in normal use you swap it just every 28 days but if you fly a lot you will end up swapping it before every flight. CF connectors are too flimsy for this purpose - but so are all USB connectors.

If the connector was a serial port then it could be remotely mounted, and easily replaced if damaged.

Which brings us to bluetooth or similar, with all the software reliability / compatibility issues. I have a very nice Thinkpad laptop on which Bluetooth stopped working after SP3 trashed it - even though I restored the HD from an image. No bluetooth...

beerdrinker
28th May 2009, 09:01
Excuse the stupid question but is a "Garmin USB Aviation Data Card Programmer." the same bit of kit as a "Jeppesen Skybound" or "Jeppesen Services Update Manager Skybound G2?"

If so does one need to download "Aviation USB drivers required to program data cards using the Garmin USB Aviation Data Card Programmer."?

That being the case I assume I only have to download the "Garmin FlightPlan Migrator " to download Flight Plans from my Computer to a (empty) Nav Data Card to load them onto my 430W. (I assume that the Garmin Flight Plan Migrator erases data on the card before loading the required Flight Plan - in the same way as JSUM does before downloading the latest NavData)

dublinpilot
28th May 2009, 09:20
In case it's of any interest to anyone, I understand that the next version of PocketFMS will be able to output flight plan files, which can be directly imported to a panel mounted Garmin, via the data card.

dp