What's new
Van's Air Force

Don't miss anything! Register now for full access to the definitive RV support community.

ADSB question

Mike S

Senior Curmudgeon
Here is a link to the NavWorx installation, presented as a block diagram.

http://www.navworx.com/PDFs/GRT-display-ADS-B-Traffic-block.pdf

Sorry, I cant figure out how to post the actual image:(

My question is the encoder input------it clearly shows the encoder going directly to the NavWorx box, and not to the transponder. Is this correct??

Should there also be an encoder feed to the transponder??

Should the encoder feed into/through the transponder to the NaxWorx unit?

If the encoder is already feeding the transponder, does the needed information back feed to the NavWorx unit over the RS 232 line??
 
Here is a link to the NavWorx installation, presented as a block diagram.

http://www.navworx.com/PDFs/GRT-display-ADS-B-Traffic-block.pdf

Sorry, I cant figure out how to post the actual image:(

My question is the encoder input------it clearly shows the encoder going directly to the NavWorx box, and not to the transponder. Is this correct??

Should there also be an encoder feed to the transponder??

Should the encoder feed into/through the transponder to the NaxWorx unit?

If the encoder is already feeding the transponder, does the needed information back feed to the NavWorx unit over the RS 232 line??

Q1. I do not think so. see Q2
Q2. yes, the transponder needs a pressure altitude feed. I believe the specs call for the ADSB and the transponder to use the same device for pressure altitude.
Q3 and Q4. I don't know, it depends on what the NavWorx can decode, formats and speed, etc., as well as what the transponder can send.

I do know that the GTX-327 can take in data (including pressure altitude) from the EFIS and send it back out (I forget the format). I use this to pass thru data from the HX to the 430W. Presumably that data includes the squawk code, as well as the pressure altitude, both of which the ADSB-out needs.
 
Navworx

Mike:
I am out of town and cannot reference my documents, but the back of the install manual for the Navworx shows all the required connections. I made no changes to the original 327 wiring but did add a link from the 327 to the ADS to pass along the transponder squawk. The pressure altitude link went from my GRT EFIS to the Navworx.
 
The 327 only has one serial out port available. When using it to control an ADS-B box like the navworx or the Freeflight it must be set to "remote out" , this setting does not contain altitude data. The ADS-B box requires serial altitude data from an efis (or encoder) as shown in the diagram.

And yes only one source of altitude data is permitted, so if the efis is driving the transponder the same data must be supplied to the ADS-B unit. Same goes if you are using an altitude encoder.
 
the back of the install manual for the Navworx shows all the required connections.

Yep, found that-------but it is not the same as what I linked in post 1. :confused:

I made no changes to the original 327 wiring but did add a link from the 327 to the ADS to pass along the transponder squawk.

So, the ADSB sends a squawk code also??

The pressure altitude link went from my GRT EFIS to the Navworx.

So, the transponder no longer sends altitude info, just the ADSB box???
 
1) Yes, ADS-B sends the squawk.
2) No, the transponder still sends the altitude.. they both do.. hence it should be same value :) (that's why same source has to feed both).
 
The 327 only has one serial out port available. When using it to control an ADS-B box like the navworx or the Freeflight it must be set to "remote out" , this setting does not contain altitude data. The ADS-B box requires serial altitude data from an efis (or encoder) as shown in the diagram.

OK, then how does the transponder get the altitude data??

And, what does the transponder "control" in the ADSB box?

And yes only one source of altitude data is permitted, so if the efis is driving the transponder the same data must be supplied to the ADS-B unit.

But you said above that the transponder cant send altitude data to the ADSB box, as there is only one serial port.

I am not trying to nit pick, just trying desperately to understand how all this goes together.
 
Mike,

He said 'no changes' in transponder wiring so I presume he had and still has a serial line from Hx to 327 (not shown in your diagram) for altitude data. And a second serial line Hx to UAT (shown) again for pressure altitude data to UAT. Serial line 327 to UAT carries squawk code (yes, transponder and UAT both send it).
 
OK, then how does the transponder get the altitude data??

And, what does the transponder "control" in the ADSB box?



But you said above that the transponder cant send altitude data to the ADSB box, as there is only one serial port.

I am not trying to nit pick, just trying desperately to understand how all this goes together.

1) The transponder will accept serial in or gray code altitude data.

2) The 327 will send squawk code and functional (stby, on, alt) control to the ADS-B box via the serial out port .

Don't get serial in and serial out confused. The 327 has 2 serial in ports and 1 serial out port.

And yes ADS-B sends squawk code and altitude data as well.
 
Last edited:
Just to clarify, the EFIS sends pressure altitude to both the transponder and the Navworx through separate wires. IE: different serial ports but same info. The connection from 327 to Navworx sends the sqawk code and on off info.

When I am at the airplane on Sunday I can refer to all my wiring records and serial port settings by phone if you like.
 
The EFIS serial port can send the same data to both devices without using an extra serial port. A serial out stream can go to one device or 15 devices, just by tying more wires into the serial out port wire.

So, the altitude encoder information from the EFIS goes to the 327 and the ADS-B using the same wire. You may be able to use separate ports and separate wires, but why would you want to use up a port for that.
 
The EFIS serial port can send the same data to both devices without using an extra serial port. A serial out stream can go to one device or 15 devices, just by tying more wires into the serial out port wire.

One RS232 TX source can get away with feeding multiple RX device inputs that are all simply parallel connected to the same wire but I've not had much luck feeding more than 4 or 5 at a time before it added up to too much load on the transmitting device's output driver. There are cheap active splitters and repeater/boosters available that you can use to supply many more RX inputs from one TX data source.
 
Granted. I was, of course, just making the point that you can parallel the output. I can't imagine a scenario where more than 4 or 5 items would need the same serial data in the modern EFIS world.
 
Granted. I was, of course, just making the point that you can parallel the output. I can't imagine a scenario where more than 4 or 5 items would need the same serial data in the modern EFIS world.

Actually the most RS232 serial RX devices I've ever had to feed from a single TX device output in an airplane was 3 at a time and the simple parallelled wire connection worked perfectly fine for that.

Now at my job, I've had to feed 10 to 16 RX devices at once from a single 911 phone system's ANI-ALI RS232 output, and bought a couple of BlackBox serial output distribution multiplexers for that.
 
Thanks gang !!

OK, I think I have absorbed all this.

Take the existing encoder output from the GRT to the transponder, and "Y" it into the NavWorx box also.

Output a control line from the transponder to the ADSB box.

Output a "suppression" line from the ADSB box to the transponder.

Correct??

Now, for another question-----------the transponder is going to end up remote mounted, and controlled from the GRT screen------does anyone know if this is done with the same serial line as the encoder uses, or does it require a separate serial line??? As things stand now, it looks like both serial in lines are used up. One from the encoder, and the other from the ADSB to "suppress" the self image on the traffic readout.
 
Mike,

Are you talking about the Trig TT22? If so stop, do not pass go, you do not need the 600-B UAT.

Bob
 
Last edited:
Bob, no not Trig.

I have a Garmin 327, GRT HX, and the NavWorx ADSB. Just trying to get them to all play nicely in the same sandbox.

Due to panel real estate issues caused by installing a GTN 650, I want to remote mount the transponder, and control it with the GRT units.
 
Last edited:
I didn't know the 327 could be remote mounted and controlled by the Hx.

For the remoted Trig TT22, one serial line carries control info and pressure altitude data. The suppression signal has its own (not a serial line) input pin.
 
I'm going to ask a dumb question

just so I can be shamed into doing this...

I didn't know the 327 could be remote mounted and controlled by the Hx.

For the remoted Trig TT22, one serial line carries control info and pressure altitude data. The suppression signal has its own (not a serial line) input pin.

My panel upgrade, presently being lashed up on the bench but nearing actual installation phase, will feature a GRT HXr and the Trig TT22 without control head (controlled only by the EFIS). My ADS-B IN will be via USB-connected DualXGPS-170. My ADS-B OUT solution is to be determined... Hopefully just a matter of adding a compliant external GPS source to the EFIS.

Currently, I have not included a wire in my harness for the own-ship suppression feature of the Trig transponder which Bob mentions above. My question: I'll be sorry if I don't go back RIGHT NOW while it's readily accessible and add this pin and wire while it's easy, won't I? I'm just lazy enough not to want to cut that lacing job up and open that Trig D-sub connector again :(

-Stormy
 
yes/no

just so I can be shamed into doing this...



My panel upgrade, presently being lashed up on the bench but nearing actual installation phase, will feature a GRT HXr and the Trig TT22 without control head (controlled only by the EFIS). My ADS-B IN will be via USB-connected DualXGPS-170. My ADS-B OUT solution is to be determined... Hopefully just a matter of adding a compliant external GPS source to the EFIS.

Currently, I have not included a wire in my harness for the own-ship suppression feature of the Trig transponder which Bob mentions above. My question: I'll be sorry if I don't go back RIGHT NOW while it's readily accessible and add this pin and wire while it's easy, won't I? I'm just lazy enough not to want to cut that lacing job up and open that Trig D-sub connector again :(

-Stormy

The Dual ADSB-in box does not have a suppression line, so no wire is needed for that. I think but am not sure that once you have ADSB-out the traffic data will have your N number attached to it and tbe HXr will filter your airplane out from its display(?). However, you may see yourself on an iPad program.

BUT, did you run a wire for your future approved position source? This does not go thru the HXr but rather directly to the TT22 (look at the notes shown on the grt TT22 supplement. One note says "connect future approved position source here").
 
Shielded Wires

Is it necessary to use shielded wires with the ends grounded as the pin outs show for connecting the transponders, efis,and adsb boxes. Thanks Barry
 
who knows?

Is it necessary to use shielded wires with the ends grounded as the pin outs show for connecting the transponders, efis,and adsb boxes. Thanks Barry

These are high level digital signal lines. Left unshielded tbey may radiate enough to cause trouble somewhere; or maybe not. Many have used unshielded wires for short runs. The longer the wire, the more the odds go up of causing trouble. Personally, if the transponder is more than a few feet away I'd use shielded cable. The cost and effort aren't that much more to do it as best as you can.
 
just so I can be shamed into doing this...

I'm just lazy enough not to want to cut that lacing job up and open that Trig D-sub connector again :(

-Stormy

BTW, Stein sells a little tool called a "wire spoon" which lets/helps you shove a few more wires inside a pre-exisiting bundle, so you don't have to cut the ties and start over.
 
Well, again thanks to all who have responded to this thread, both by posting in the actual thread, and the email and PM messages I have received.

As it turns out, I cannot do the upgrade in the manner I want to, as the GRT HX will not control the transponder.:mad:

I have to use the GTN 650 to control the transponder, or just leave it where it is, and see if there is something else I can move to make room for the 650.:confused:

Or, I need to get another transponder.:(
 
Mike - I'm in the "been there, done that" camp with respect to what you're trying to accomplish.

I'll suggest that going with a TT22 might end up being your best option for a number of reasons. While the 327 is an excellent unit, it is bulky and not amenable to remote mounting, as you've so painfully discovered. The TT22 fits the same footprint as many altitude encoders (e.g. the ACK line of encoders) so it is small and designed for remote mounting.

The TT22 will require one set of control lines between it and the HXr, plus it will require a serial line for GPS position. With your GTN650 setup you can immediately wire the GPS serial line into the TT22 and have a compliant ADS-B-OUT solution. This leaves you footloose and fancy free to choose whatever ADS-B-IN solution you might want.

By selling your 327 the cost of going to the TT22 is not going to be huge. If you have enough wire to have considered "remoting" your 327 then swinging that wire over to a TT22 should be quite do-able.

In terms of dollars per unit of panel space freed up, it's a pretty good deal.
 
Mike - I'm in the "been there, done that" camp with respect to what you're trying to accomplish.

I'll suggest that going with a TT22 might end up being your best option for a number of reasons. While the 327 is an excellent unit, it is bulky and not amenable to remote mounting, as you've so painfully discovered. The TT22 fits the same footprint as many altitude encoders (e.g. the ACK line of encoders) so it is small and designed for remote mounting.

The TT22 will require one set of control lines between it and the HXr, plus it will require a serial line for GPS position. With your GTN650 setup you can immediately wire the GPS serial line into the TT22 and have a compliant ADS-B-OUT solution. This leaves you footloose and fancy free to choose whatever ADS-B-IN solution you might want.

By selling your 327 the cost of going to the TT22 is not going to be huge. If you have enough wire to have considered "remoting" your 327 then swinging that wire over to a TT22 should be quite do-able.

In terms of dollars per unit of panel space freed up, it's a pretty good deal.

Mike would also have to sell the UAT system he's already invested in, too.

Slight note: While I have every confidence it will work, and may come under the new "clarification" just issued by the FAA wrt 91.225, as of this time Trig's web site does not show the 4xxW nor the GTN stuff as "approved sources" for the TT22. (They do list the 4xxW with the TT31, and show the 4xxW as approved for European uses with the TT22). Hopefully this will happen, but it concerns me that they accidentally announced this at OSH last year but so far only the 31 shows accepted on their web site. Why does it take so long? Is it that hard?
 
Isnt the Trig just an output device??

How do I get the ADSB weather, traffic etc onto the GRT HX screen if I go with the trig??
 
Use the navworxs box you already have

Yep, pretty much what I plan to do.

And, after just now taking a fresh look at the panel -------- well, there is no reasonable way to relocate other stuff so I can keep the xpndr in its original place.
Plus, after looking at the Garmin tutorial about how to remote control the xpndr, this is starting to look like the best solution to the issue.

And, it is also the cheapest:D
 
Back
Top