What's new
Van's Air Force

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

NavWorx tech issues - help each other

NO, anon is turned off.
Try having a friend track you to see what you are reporting.

This also works on the ground. We did this with several aircraft & we toggled from anonymous to N reporting. Amazingly, it cycles very quickly.
Probably have to be airborne, to pick up the rebroadcast.
 
Last edited:
How were you able to reach him? I have sent e-mails that are not responded to! I have a unit in there for repair since March.

Ralph, all my email exchanges with Navworx were all late afternoon. I don't know why, but Bill usually responded within ten minutes. I had four email exchanges over several days. Hope this might help you with your situation. Keeping my fingers crossed on my repair.

John
 
I got a call from Bethany @ NavWorx last night - my unit is being shipped back to me after repair. It was one of the very early units and needed firmware and hardware changes. From her description, the original hardware was not compatible with the 4.1.0 software (that we all upgraded to for their 'SIL' fix). She also indicated that since I'm using a 430W for the GPS source, I shouldn't need the hardware upgrade advertised on their website - we'll find out the full scoop on that after the AD comes out. I'll post an update when I get it reinstalled to let everyone know how it works out.
 
I got a call from Bethany @ NavWorx last night - my unit is being shipped back to me after repair. It was one of the very early units and needed firmware and hardware changes. From her description, the original hardware was not compatible with the 4.1.0 software (that we all upgraded to for their 'SIL' fix). She also indicated that since I'm using a 430W for the GPS source, I shouldn't need the hardware upgrade advertised on their website - we'll find out the full scoop on that after the AD comes out. I'll post an update when I get it reinstalled to let everyone know how it works out.

If some versions of the hardware are truly not compatible with 4.1.0, that would be another communication failure on Navworx's part. That should clearly be stated as part of the README for the upgrade. I've not been bitten by this issue, since Bill has upgraded my hardware multiple times. I might add at no charge, so there are some positive attributes of Navworx.

The Display Port 2 anomaly still seems to be present in my unit after being recently repaired by Bill. He mentioned to me that he was going to apply the fix to my unit, but it doesn't appear to be working. I've tried reaching out to both Bill and Scott, to no avail. It's not an urgent matter to me, so I'll probably just wait until the new AD and new release is available to look at it again. The Display Port 2 drives a WiFi dongle that allows passengers to view traffic and weather on their tablets and/or phones.
 
Mine was repaired without charge as well...hopefully, I can 'skate' the impending AD as I am using a 430W for the position source and have full compliant functionality without paying the additional big bucks...what took me to NavWorx in the first place was inexpensive compliance!

My port 2 is for my EFIS displays - hardwired so the USB/WiFi isn't part of the equation...I just haven't tested it yet as the instructions did not call out which serial connection was for port 2 - so I wired it wrong initially!

Update after this weekends reinstallation activities!
 
My port 2 is for my EFIS displays - hardwired so the USB/WiFi isn't part of the equation...I just haven't tested it yet as the instructions did not call out which serial connection was for port 2 - so I wired it wrong initially!

Ralph,

Do to the bug in 4.1.0, if it doesn't work, I would move it off Display Port 2 to Port 1. If it does work on Port 2, I would be very interested in that as well.

If my memory serves me correct, the Display Port 2 didn't even exist until after serial # 850. It was one of the later board changes.

bob
 
My port 1 is for RS422 - for my MX-20 display - and it works fine - definitely not going to mess with that one...if the port 2 doesn't work - I'll do without....and accept another functionality failure!
 
My port 1 is for RS422 - for my MX-20 display - and it works fine - definitely not going to mess with that one...if the port 2 doesn't work - I'll do without....and accept another functionality failure!

We're not talking the same terms.

Pin 5 - rS232 - display port 1
Pin 6 - RS232 - display port 2
Pins 12/30 - RS 422 - Display 1

The output to pin 6 is the bug in 4.1.0

It's unclear to me what is the relationship between the rs232 and the rs422 display 1 ports. Is it the same output to two different port types? It doesn't appear through the configuration program you can enable both at the same time, unless I missed something obvious.
 
The way Bill explained it to me a gozillion years ago is that since I was using 422 for display 1, I had to use port 2 (pin 6) for the 'other display...by selecting MX20 and 422 for display 1 it disabled pin5

If 4.1.0 is the bug for pin 6 then I should expect it to not work when I reinstall.

I probably have the terms mixed up - but when I told Bill I was using 422 for my mx 20 , he immediately indicated that I needed to use pin 6 for my AFS/GRT display input RS232.

I guess we all need a software update!
 
The way Bill explained it to me a gozillion years ago is that since I was using 422 for display 1, I had to use port 2 (pin 6) for the 'other display...by selecting MX20 and 422 for display 1 it disabled pin5

If 4.1.0 is the bug for pin 6 then I should expect it to not work when I reinstall.

I probably have the terms mixed up - but when I told Bill I was using 422 for my mx 20 , he immediately indicated that I needed to use pin 6 for my AFS/GRT display input RS232.

I guess we all need a software update!

It may be worth a ten minute test and swap them around, Display 1 = RS232 and Display 2 = RS422.

What's not know if the Display Port 2 issue is only on the RS232 port or both port types. I suspect that the ports aren't disabled, but are in parallel. Then the question is that if the MX22 and the AFS use the same data format.
 
UPS just sent me an update - my box from NavWorx is due this afternoon.
I'll try Bob's ten minute test tomorrow after I get it all in and running.
 
Update on my installation...

Based on my manual (240-0008-00-39 dated 2016-2-12 - the one currently available on the NavWorx website);

pins 12/30 are the TX -/+ for RS422, pins 5/24 are for
DISPLAY PORT 1 RS232 TX/DISPLAY PORT 1 RS232 RX,
pin 6 is a ground, and
pin 25 is listed for DISPLAY PORT 2 RS232 TX.

I have the 12/30 wired to my MX-20 and it worked fine before I sent it in for repair - I expect that it should be OK. I have the 5/24 TX/RX wired for display 2 - this is the one that Bill indicated needs to be pin 25 TX only (he actually said port 2 - which I translated to pin 25 from the manual).
 
Unit reinstalled

Unit arrived last night - I reinstalled it this morning.
Unit came up properly - ready for flight - no TX/RX error. Looks like my initial issue was resolved.

On to configuration and ground testing for the rest of the stuff!
And Bob's ten minute test!
 
Ten minute test

The UAT console did not allow me to configure port 2 for MX-20.
My port 2 is currently not functioning - like everyone else.

Maybe the software update is coming.
 
Some success - more questions

Simulator shows traffic to both my MX20 and 430W units.
After turning the simulator off - looks like there was some real traffic @ 7000 over head - watched it slowly disappear from my screen...I would guess that was aircraft to aircraft as I was on the ground in my hangar!

Now for my questions...:

My MX20 has a little display box showing "FID 1200" - I'm guessing this is my SL-70 transponder code as my transponder was set to 1200 and it showed up in the messages in the UAT console...Since I'm in my hangar, I changed my transponder to 1234 - the messages in the UAT console and my little box in the MX20 didn't change. I was in the Altitude mode and the transponder is set up for EXTended data output. Anyone else have issues with their squawk code? Is there an interaction required to set the transponder code?

Thanks!
 
Last edited:
My MX20 has a little display box showing "FID 1200" - I'm guessing this is my SL-70 transponder code as my transponder was set to 1200 and it showed up in the messages in the UAT console...Since I'm in my hangar, I changed my transponder to 1234 - the messages in the UAT console and my little box in the MX20 didn't change. I was in the Altitude mode and the transponder is set up for EXTended data output. Anyone else have issues with their squawk code? Is there an interaction required to set the transponder code?

Thanks!

Are you using the "transmon" device to sniff the squawk code? In the hangar, your transponder may not be getting 'pinged', so it won't transmit, so the transmon detects nothing, so you don't see the change?
 
Thanks - NOT using TRANSMON...I have a direct serial connection from my SL-70 to the NavWorx box. I know the connections is good as that is how the NavWorx box is getting altitude...

I just verified that pin 33 that I am using is what was specified - doublecheck my work.

Good response - I appreciate it....
 
Bill responded to my request for help with a couple of things to check.

One possibility is that my MX-20 is set up as the controller instead of the SL-70. Gotta figure out where that setting is and change if it is wrong! Then I can check the status field.

Status update next weekend when I get to the hangar to try it out!
 
Found the MX-20 settings - it was set to display only - turned the edit code off as well - no change.

Tried it with the MX-20 turned off - no change.

Using 7600 (NORDO) for the alternate squawk code so I don't mess anyone up if they receive my transponder.

I am getting traffic flying overhead so I know the unit is receiving air to air at least. Don't want to fly like this as I am close to a bunch of MOA's and I get a squawk code assigned on a regular basis.

Sent Bill the screen capture of the UAT Console showing the green status, the N number and the squawk code.
 
Last edited:
More things to show to Bill at his request...

Wiring of SL-70 to 600B - pin by pin...:

My SL-70 pin 3 (Serial Ground) is wired to 600B pin 32 (Serial Ground) - this circuit is grounded when both devices are disconnected from the wiring harnesses, both pins 3 and 32 'see' ground
My SL-70 pin 5 (Transponder TX) is wired to 600B pin 33 (Transponder RX) - this circuit is open when both devices are disconnected from the wiring harnesses - continuity between pins 5 and 33 is good through the wiring harness
My SL-70 pin 19 (Suppression in) is wired to 600B pin 35 (Suppression Out) - this circuit is open when both devices are disconnected from the wiring harnesses - continuity between pins 19 and 35 is good through the wiring harness
Per pages 51 and 74 of the 2016-2-12 manual.
I rang out the circuits to verify completeness and ensure that pins 5/33 and 19/35 are not inadvertently grounded through the wiring harness...they are not.

And screenshots of the Transponder selection (SL-70 1200Baud DB37-33) and status screen - all green alt mode with 1200 instead of 7600 selected. The 1200 baud is selected because my MX-20 will only take altitude at 1200baud - and is configured from the same serial port - since 1200 baud is an option - it should work!
 
Spent some time on the phone with Bill yesterday - troubleshooting my SL-70 control-head issue. My SL-70 is transmitting serial data at 1200Baud - that setting is required since the MX-20 serial input will only take 1200Baud. Bill acknowledged that it should work and we did a bunch of tests while we were on the phone with different settings and baud rates.

Questions for the group - anyone else out there running a SL-70 (as a control head for the NavWorx box), MX-20, and NavWorx box (any type)? Is your SL-70 sending altitude to your MX-20 and the NavWorx box? What baud rate are you using between the SL-70 and MX-20? Are you able to change the squawk code in the SL-70 and have it recognized in the UAT Console status?

I attempted to capture the serial data from the SL-70 to the other devices using HyperTerm and an old XP box I had...came out looking like gobbledygook - but I captured and sent two sets - one at 1200 Baud and one at 9600 Baud...the streams also contained changing the squawk code from 1200 to 1234 to see if the change was transmitted.

More questions for the group - anyone else able to capture and view the data streams from the SL-70? What software and settings did you use?

Thanks,
 
More data for the SL-70 output to the ADS600B...:
As I was doing the data capture, the 1200 baud streams were shorter than the 9600 baud streams - which doesn't make sense unless the 9600 baud streams contained more data.

Sent Bill the SL-70R manual that I had scrounged along with the newest SL-70 manual that I had (it was from Oct 1999).

Anyone have a newer SL-70 manual - that references EXTended mode?!

Thanks,
Ralph
 
More testing on my own

I did some more testing here in the hangar.

I remoted my 430W antenna so it would come up with Lat/Long and turned off the Altitude input on my MX20 so it wouldn't display error messages.

I set the SL70 to 9600 baud - it was set to 1200 baud to interface with the MX20.

1. I configured the ADS600B to SL70R as the control head (I have the SL70 panel mount). The UAT displays the proper status and info and catches the squawk code change from 1200 to 1234 to 1200 to 7600 to 1200 pretty much instantaneously.

2. I changed the ADS600B to SL70 (9600 Baud) and the UAT would no longer acknowledge the changes like the last test.

Since the only difference in configuration in these two tests was the setting of the ADS600B from SL70R to SL70, that might point to one part of the problem...

I forwarded the results to Bill for his use. I know how to get my unit to function - even though ti takes away full functionality from my system. Hopefully, this is a simple case of software missing from the two SL70 sets of options...if so, version 5 is gonna have some good updates for us!
 
According to Bill, there is a data difference between the SL70R and the SL70.
Meanwhile, we're all confused as to why it works when set to SL70R @ 9600 Baud and doesn't work when set to SL70 @ 9600 Baud...especially since I have a SL70!

More data points - hopefully Bill's research and testing will come up with something actionable for Version 5 of the software!
 
I had been told that the SL70R protocol was not the same as the SL70 protocol, but I don't know the nature of the difference.
 
Bill says they're different by one Byte. Interesting that my ADS600B works with my SL70 when I tell it that I have a SL70R. Bill called that another wrinkle in the problem.

Meanwhile, today I got a PAPR with my configuration - sent that to Bill for review as an additional data point.

We'll see what the AMOC guy thinks of it!
 
I was able to get an updated SL-70 Installation manual. I'll scan it in next week after I get back from business travel - it will be available to anyone here that needs it. I'll do the stare and compare evaluation to find the different byte and let folks here know.

Meanwhile, it works with the ADS600B set for SL-70R and the SL-70 set for 9600 baud only. Will be flying a PAPR flight and then depending on the results, requesting a global AMOC for 200-0013 and 430W as external GPS source.

If someone is already working on this or hears of someone - get the word out! While we need multiple folks to submit for AMOC's, we don't need to inundate them with repeat requests after they have approved a certain variation!
 
failing do to lack of N

I was failing the compliance reports with my 600-exp unit. I went into the programming app on the iphone and did an ICAO ID over ride.
The way the software treated my N number was to delete the N at the beginning. By doing the manual over ride, I was able to get the UAT to broadcast my full N number, with the N.
That made the FAA happy. I got a compliance report with no red flags today in Prescott. I let the app developer know what I did to get a good report. Others may have to do the same, unless he changes the app.
 
I saw.your email and will follow up with you this week. The N in the number should be ignored and the remaining characters generate the ICAO number. This has worked fine for a year with no changes but it's always worth checking for strange bugs and edge cases. Generally you do NOT want to override the ICAO so this is indeed strange.

I'll be looking into it. And thanks for letting me know.
 
Thanks for reply on forum Neil. I will do some additonal flights this week, to be sure I stay compliant. Will the SIL code drop back from 3 if new software is installed?
 
Neil,

As I understood it, the NavWorx box had an internal copy of the FAA registry. It only knows the ICAO address of tails numbers that already exist. I don't know how it handles new-build airplanes without using the override function.

In other words, I think you have to use the override if that tail number didn't exist a few years ago.

By the way, you should also use the override any time you operate using a call sign other than your tail number with ATC (like a charity flight or other special use).

David
 
Okay, good. That's an improvement they made at some point. I suggested that they go to a formula-based solution a few years ago. I even gave them an example of the formula.

You'll still need the override when operating with ATC under a call sign instead of a tail number.
 
ICAO

Bob is correct. The PC configuration tool had (and probably still has) a dictionary mapping from N number to ICAO but in the US the mapping is an algorithm, so I implemented that for the iOS app.

And that's a good point, David, about callsign - though I honestly don't know what ATC will want in 2020 for something like an Angel Flight mission. It would be a hassle to have to change the call for those flights. I suspect just leaving the N number will work since that is effectively what ATC maps the ICAO to on their scopes right now.

My own test box had to go back to the shop so I have no way to explore this possible problem until I get a replacement.

Neil
 
Last edited:
pro bono assistance in code writing

I appreciate Neil's pro bono work for us here on this issue.
> I have done some flights with special mission call signs in the past. Simply using the phrase with the next controller is most effective. They may give you a shortcut or put you to the head of the line for departure. I don't think having the ADS-B call sign reflect the mission will really do anything in the practical sense. The potential for errors, in re-programming the UAT each time would be something to think about.
> As a side note, here in the cool air of the southwest, I have queried controllers on a variety of questions at times... while flying with ADS-B.
Most respond like you are asking about Latin. They just weren't trained for it, or seem to care at this point. It illustrates how far from the mandated date we still are... despite the marketing and also press coverage in the GA magazines.
I take full advantage of the weather products as well as warnings of other planes nearby though.... I would hate to give that up going forward.
Thanks ALLTHUMBS
 
"Clean" PAPR

Went for a flight today and got a "Clean" PAPR in my e-mail inbox.
I'll be submitting a Global AMOC for the 200-0013 ADS600B unit with a GNS430W as the external GPS source.

I have already had a number of conversations with the FAA folks in Ft Worth about this. Their last instruction was to submit the info requested in the 30-9 along with your PAPR.

Fingers crossed!
 
Global AMOC request submitted

I submitted my request for global AMOC for 200-0012 and 200-0013 connected to Garmin 4XXW and 5XXW series GPS (with requisite software to support ADS-B OUT+).

Good vibes please!
 
AMOC

I had a great conversation with the FAA guys supporting the AMOC for the NavWorx AD. They are working two parallel lines...a global AMOC with a 'major industry group' and individual AMOCs for three of us that submitted requests. I expect to get my individual AMOC shortly and have been asked to assist in the Global AMOC project - which I agreed to.

At that point, having a known good environment and approved installation, I can lend my environment to assist in testing the Avidyne installations as a slide-in replacement.

For those of you with EXP boxes or contemplating the upgrade path from NavWorx/Dallas Avionics - I'll quote Bob Leffler's post...
"I was also told that anyone that upgrades the GPS to the ones that Navworx is offering on the web site, will also need an AMOC. Unfortunately, that is a chicken/egg scenario. Until somebody installs the upgrade, generates successful data through the FAA Public ADS-B Performance Report, they can't issue an AMOC. They did share that while they can't disclose details, they know of no reason the new GPS will fail. They were quite optimistic. They also couldn't disclose details of the EXP solution, but stated that they were optimistic with what they've seen to date. The EXP news has to come first from Bill before the FAA can comment publically." I have and can install another GPS antenna in order to assist in testing for those that may want me to assist them.
 
200-0013-02-10

I have downloaded them - no software yet!

I wonder if V5 will have the 1090 update?

I suspect there is no way for it to allow a 430w/480/530w/650/750/Avidine et al boxes to bump the SIL back up to 3 upon detection (I have a 200-0013-02-10). That would put them in the same hot water all over again. So they're either waiting for the global AMOC to release V5, or there will have to be a new release for each AMOC.
 
I wonder if V5 will have the 1090 update?

I suspect there is no way for it to allow a 430w/480/530w/650/750/Avidine et al boxes to bump the SIL back up to 3 upon detection (I have a 200-0013-02-10). That would put them in the same hot water all over again. So they're either waiting for the global AMOC to release V5, or there will have to be a new release for each AMOC.

In talking with Bill in person on Tuesday, he mentioned that he can't sell any new units, updates to existing units, or release 5.0 until the Global AMOC he has submitted has been approved.

If you read the service bulletin that was posted on 7/16 on the Navworx website, you'll see the answers to your specific questions.
 
NavWorx Global AMOC

Would have helped the community to know he was working on a Gobal AMOC! We might have been able to help him directly!
 
Going to eliminate the TransponSPE on my 600EXP

Initially I wired up my 600EXP for using the NW transponSPE and has been working that way OK since. But I do see some altitude drop out on the reports.

Going to change over to use the RS 232 out on a replacement GTX 327 X ponder ( Along with some other Navworx changes!). I see the connection diagram supplied with the EXP and see only two wires from GTX pins 20 and 13 go to 600EXP 1 and 2 respectively. After a change in configuration on the 327 and a change in config on the EXP, I understand that this will control the code and etc for the UAT .

Question is : will that data stream contain the altitude as well or will I still need to place my altitude source ( Dynon 180 Dek) also onto pins 3 and 4 of the EXP. like it was an encoder . ie do I need 2 conductor shielded or 4 conductor shielded for this changeover?
 
The GTX-327 can only output one kind of data at a time. It can output altitude, or it can output 'control' (squawk code). This is determined in the maintenance mode setup.

I recommend that you obtain the Control data from the 327 (because there is no other place to get it, besides the TransMON) and that you get the altitude data directly from your encoder (180DEK).
 
Thanks David, Looks like I get the 4 conductor shielded and some pins for this change up. I'm sure the 180 Dek will provide sufficiently for both the 327 as well as the EXP. Thanks again for the fast return reply . DRR
 
Back
Top