MLB100 Traffic

DavidBunin wrote: Does your shop have experience with NavWorx installations? In other words they have "done a couple" of NavWorx installations or Avidyne installations?

Both.  I know they were familiar with the NavWorx and it's console, but they knew not to mess with the Avidyne using the console.

The shop purchased some external piece of ADS-B equipment that can transmit UAT/1090 targets and that's what they've used, so they know it kinda works with those targets, but they were concerned there was some piece of programming they were missing (i.e. aircraft ID or hex code, etc.) for it to function correctly.

I was just told today the IFDs and the MLB's can't be powered up simultaneously due to some issue with the A429 bus or A735B data.  Like the MLB100 falsely putting out incorrect SSMs on the labels and never working correctly after that point (this is my assumption based on the info provided).  I'll let Avidyne comment since it is a known issue to them and I'm just putting together 3rd hand info I was told today.

TogaDriver,

I learned a little more about the "powering up together" problem last night.  Here is what happens:

The IFD outputs a test set of coordinates during the power-up self test (what I call the "lawyer screen" when the CDI is active, before you press ENTR for the first time).  If you pause there for any length of time, the MLB100 finishes its internal power up sequence, and can process these coordinates from the IFD as real.

Then you press ENTR and the Lat/Long data flags.  The MLB holds on to the last data it had.

At some point, the IFD comes up in a navigating mode and starts outputing your real/actual coordinates.  The MLB sees the airplane jump instantly to a location that is hundreds, if not thousands, of miles from where it "knows" it just was, and it ignores that as bad data.

So yes, the immediate work-around is to pull the MLB100 circuit breaker and don't power it up until after you're in a normal working mode on the IFD.  (Or use the breaker to cycle MLB power after the IFD is up and running.)

I think that if you are quick enough on the ENTR button, that you might get the IFD past the test coordinates before the MLB is listening for them, but I don't have a good way to test that theory.  My airplane is down for maintenance.  If you want to try it, please let us know how it goes.

NavWorx is already working on a software update to fix it.  (I happened to be there when they  duplicated the problem on the bench.)

David

roltman wrote: I was wondering if turning off the MLB100 Wx In and setting that output port to Aviation Out may then fix the traffic issue for me.

It may, as long as you don't also have some other port already configured to be "Aviation" data.

I didn't think to see if the data appears on the first port that is set to Aviation data (i.e. the first one chronologically when settings are made/saved) or if it's the first port in the list (i.e. port #1) that continues to pump out the "Aviation" data when multiple ports are set for it.

It stands to reason (in my mind at least) that either traffic or weather information needs to have some kind of position data in order to display on the right part of the screen.  So the fact that MLB100 traffic arrives via ARINC 429 wiring and weather via RS-232 wiring really makes no difference.

Looking at the data port selections, and applying a little of my own critical thinking, I would guess that ADS-B Out requires a level of positional/timing precision that is not available in the Aviation dataflow.  I see in the manual that "ADS-B (Avi)" is the data used for the AXP340.  My guess is that the "ADS-B (Avi)" output is also going to be needed once the MLX200 product comes online.

David Bunin

Maybe I'm not waiting long enough on ground to delay the turning on the box.

I've been telling pilots to cycle the MLB power after the GPS indication (top right of the IFD screen) turns green.  That seems to be working well.

I have heard of "quadrant errors" and/or "mirror errors" on other ADS-B systems, but not on the Avidyne products (until now).  I think G-brand had an issue for a while with their portable devices.  I have not experienced this problem on my airplane.

David Bunin

That's an interesting theory. One I haven't heard before. I suppose a little for flight data and experimentation would reliably prove (or disprove) its veracity.

I will ask some people I know, and see what they say.

Again, the issue has not presented itself in my airplane, so I can neither confirm nor dispute the theory.  (And I'm down for maintenance right now anyway, so more flight experience is not available to me).

David Bunin

David,

If you're happy with the performance of your unit as-is, there is no benefit to loading the new software.  I only did it because NavWorx asked me to.  There aren't any new functions or features in 4.0.8 as far as I know.

David