Garmin XM Antenna/Receiver Protocols?

OK, this is a seriously geeky question, so those of you that hate data protocols might want to exit now....

I'm curious if anyone has looked into the serial I/O protocols from the XM antenna/receiver used on the 396/496's. I'm curious if it is a one way "broadcast" communication, where the receiver just umps out data to whatever is listening, or if it requires a two-way handshake.

Why am I interested? Well....if it is a one-way transmit type thing, one could theoretically build a "Y" cable and feed two 396/496's in the same airplane with one XM receiver - for instance one in the front seat, and one in the back seat of an -8......Since this appears to be a USB connection (it must be - you use the same port on the 396 to connect to a PC USB port), it might be possible.

Of course, I am pretty much a novice on USB protocols - RS-232 I understand, but this newfangled stuff....

OK geeks, what do you think?

Paul

Paul, I think you guys need to launch a shuttle - you have too much time on your hands to think up geeky stuff.

Re XM, I don't know much, but it is clearly a two way between my IPAQ (Anywhere Map) and the XM receiver. Don't know about Garmin's unit. Plus, there may be no need for a two way handshake when the stuff is all internal to the unit.

Speaking of geeks, three cheers for your top NASA guy Griffin for his climate change discussion with the NPR guy Inskeep. That was some of the clearest, most concise statements about the topic I've read.

Paul,

I did some thinking about this already in the past, here it is!

First of all, the 396/496 are just a modest respin of an existing product, the 296, which originally has 2 independent serial ports tied to the stupid round 9 pin connector.

Well, both the 396 and 496 only have one serial port now, and the XM active antenna plugs into the USB port... my take is that the USB logic in the 396/496 now includes an USB-to-serial bridge that turns the USB port into a master, and simply feeds the XM data in and out between the XM antenna and the Garmin unit.

Having said that, there surely is a phase whereby the Garmin unit talks to the active antenna for initialization purposes (e.g. security keys initialization and channel selection when listening to radio), but apart from that the data feed should be mostly unidirectional, except maybe for some keepalive packets.

Speaking in Internet Protocols terms, my take is that the data flow is similar to a connectionless UDP-like protocol. It should not be that hard to tap into the data flow, the only gotcha being the possible use of encryption between the active antenna and the unit...

Me, I neither have a US Garmin 496, nor I live where XM has a weather service, so I can't do much more than this kind of speculation from this side of the pond!

Let me know how things evolve!

Ciao, Luca

You mean the shuttle doesn't have a USB port on it!?

Think of USB as a client-server protocol. Any bus for USB is made up of a host and one or more devices. Devices connect to hosts and you can't have more than one host on a given bus. Devices can pass through one or more hubs that aggregate / synchronize signaling and provide for power boost but the hubs are essentially transparent and do not act as hosts.

I don't have a 496 (and my 196 doesn't have USB on it) but looking through the manual for the 496 it seems that there is a bit of trickery going on. When the 496 is connected to the PC it _should_ be acting as a device since the PC by default behaves as host. However, when you connect the GXM 30 I would have expected the antenna to be the USB device and the 496 to be the host. It could be the other way around but that's just kind of weird.

So, this probably means that they're sensing the device that's connected (could probably just sense the power lines and if you've got juice you're connected to a host) and switching the USB mode accordingly.

So ... assuming that the GXM is indeed a valid USB device and not just some serial device with a USB plug on it, the configuration suggested doesn't look like it would work. What you'd need to do is introduce a custom box in the middle that has a bridge controller that allows it to masquerade as dual USB devices to connect to the dual 496's while simultaneously providing host services to the GMX. In addition to this there would need to be a bit of firmware for processing and synchronizing the protocol data between the two 496's so that the GMX doesn't just barf... this would be a big old mess if there's state assumed to be stored on the GMX (like channel selection) because if you change the channel on one 496 but you don't have a way to notify the second 496 that the channel was changed, you'd get one really confused situation.

We've got USB protocol analyzers at work if you want to sniff out the data and dissect it to confirm that it is indeed USB traffic. If it is, this is going to turn into a major effort to accomplish.

-Rick

The Shuttle? You must be joking....the Data Processing System is from the late 1970's.....our General Purpose Computers have a massive 256K (yup, that's a "K") of RAM!!

Of course, we carry about a dozen laptops and both a wired and wireless LAN to do a lot of payload-related activities....I chatted with some of our young computer geeks, and got a similar education as what Rick described above....so nope, this won't work.

Mostly a thought experiment anyway...woudl have saved one antenna and it's cable when I have a backseater...

But learning is always fun - thanks!

Paul

Aw... don't feel too bad about the shuttle. All the CPU and memory just goes to graphics and bloatware anyway. Check out this article from earlier in the week about how much productivity gain the last 21 years of engineering has given us in personal computers:

http://hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins

I know it's not completely fair but it certainly says something. I do this stuff for a living and it annoys the heck out of me. I wish I could get by just building airplanes.

Paul, an interesting tidbit related to your idea ... we're working on a new product that accomplishes most of what we'd need to make this work. We'd just need to convince the firmware guys to implement the GMX protocol instead of universal video class. Doh!

-Rick

Ironflight said:

The Shuttle? You must be joking....the Data Processing System is from the late 1970's.....our General Purpose Computers have a massive 256K (yup, that's a "K") of RAM!!

Click to expand...

Hey, I remember when the shuttle's backup computer was a HP-41C calculator.

the_other_dougreeves said:

Hey, I remember when the shuttle's backup computer was a HP-41C calculator.

Click to expand...

Got mine right here....and it still works!

Protocol is part of the needed information

Even RS-232 there are options that the system designer has to select (start bit, stop bit, etc.) and you need to get all of the requirements and study the implementation to get a working system. Admittedly, I have been out of the business for a while but there are several things you need to know in order to design a working system to satisfy you needs. The number of wires in the antenna to the receiver will tell you whether the interface is serial or parallel and my bet would be on serial. The data format at the byte level will be fixed along with the basic communication protocol so that reliable communication can be maintained using high speed hardware devices to code, transmit, receive and decode the information. The controls probably come in the levels of protocols above the basic I/O. Everyone developing or maintaining a system wants independent monitor capability and I'm sure that people tap into the interface and see the communication without killing the link. I'm also pretty sure that if you are resourceful enough you can come up with the system you want but without complete knowledge of the interface the cost and frustration can eat you alive. Have you noticed how expensive cables are these days?

Of course you could do like I do, learn as much as you can and cut and try it.

Bob Axsom