Navpilot 500

[dbenn]

I am in the process of upgrading the nav system on my boat from NNvx2 to NN3D.
The new system consists of: NN3dBB, DRS12,SC30,BBWX2 and a MSTZ system.
Left from the old system are: Navpilot 500,2-GP35's,and a PG500R.
The old system used a toggle switch system to switch between gps sources 1 or 2 and
nav sources NNv2x or Maxsea for the autopilot input. This sytem was not working(no
nav data to autopilot). I plan on keeping the same autopilot and redoing the NMEA 0183
system. My questions are:
Can the Navnet 500 use 2 nav different sources without a toggle switch?
Wich ports are 1 and 2 (NMEA IN/OUT or nmea in out/rs232)? It is not clear in the
instalation manual. Is there a more detailed wireing/installation manual avaliable other
than what is on your website?
Can my new SC30 be used to enhance the operation of the Navpilot 500? If so how?

Thanks,
dbenn

 

[Johnny Electron]

Can the Navnet 500 use 2 nav different sources without a toggle switch?

Yes, you can easily switch between NMEA port 1 and NMEA port 2 source by holding the NAV button until it tells you the source is changed.

Wich ports are 1 and 2 (NMEA IN/OUT or nmea in out/rs232)? It is not clear in the
instalation manual.

The RS232 NMEA port is considered NMEA port 2. You should use either the In/Out RS422 NMEA in for port 2 or the RS232 IN/Out for port 2 but NOT both.

Is there a more detailed wireing/installation manual avaliable other
than what is on your website?

No, the best quick reference for wiring normally is the interconnection diagram at the back of the installation manual.

Can my new SC30 be used to enhance the operation of the NavPilot 500?

Yes, the SC30 would enhance the pilot "a little" but you would require the IF-NMEASC interface to properly ensure the heading is interfaced to the pilot. (there might be another possible interface once the TZT releases, but it would need to be tested with the pilot to know if it will work for this purpose) I would stick with the PG500.

 

[dbenn]

Thanks for the reply Johnny but I an still confused about witch ports are 1 and 2.
I have attached two docs please let me know if I am correct.

Dbenn

 

[Johnny Electron]

dbenn
It is best to look at the interconnection diagram at the back of the install manual for wiring information. In the case of the RS232 port, the book isn't very clear. I see your handwriting saying "port 1" beside the RS232 port (TB4) but that is incorrect. The RS232 input is considered data 2. Just to verify, I connected and RS232 source to the pilot on TB4 and the pilot even says "PORT 2" as the NAV data drives it. You might want to change your hand written note in your manual.

 

[duffy]

I am also trying to use 2 input sources for NAvpilot - or preferably not use PG500 at all.
The boat I am fitting autopilot to uses old SC-60 (which Navpilot brochure says is compatible). Seems no way Navpilot will accept AD-10, and does not seems to read GP-HDT sentence from the HDG OUT of the SC-60 (which in manual says it sends at 100ms intervals). Is the only possible input through pins 1 and 2 of the HDG port on Navpilot, or can it be made to read heading data from any other port?

 

[Johnny Electron]

The NavPilot 500 can only use one heading source. The SC60 should work instead of the PG500. In general a Sat Compass will work much better than a Fluxgate compass. I will look into the details on the setup and get back with you.

 

[Johnny Electron]

I would recommend setting your SC60 for a HC talker (explained on page 3-10 of your manual) and send the HDT heading sentence at IEC61162-1 (4800 baud) to the pilot at 100ms. Heading should be connected to Pin 1 (+) and Pin 2 (-) on the TB8 of the pilot. The PG500 would not be used. In the dockside setup of the pilot you should change the compass type to "Other" and ensure the baud rate is set to 4800.

 

[Anonymous]

Just reviving this thread as I am working on a similar problem and need to confirm the manual's information. This is a new to me boat with no wiring diagram for the nav electronics, so bear with me as I work thru this and document as I go.

Quick background, I have dual NavNet 1 MFD/Radars with BBGPS and BB Sounder, a separate GPS32, a Navpilot 500 and IC30 instruments. Heading comes from either a SC-60 or a PG500 (toggle switch used to select which is used...SC used 99% of the time and, yes, the switch works just fine).

I am attempting to connect a PC for navigation (OpenCPN) via a serial-to-USB converter that is already in place and providing position data from one of the NavNet unit and a GP32 GPS (as backup). All works just fine at present as a nav data "consumer". I want to drive the AP with OpenCPN, as a back up to the NavNet units...OpenCPN is just a lot easier to create routes with, so I might eventually reverse roles and use the NavNets as backup at some point.

Currently there is no RS-232 input connected to the AP (TB4), but there are connections to TB8 (heading sensor) and TB5 (I am guessing this is the IS30 connection). The Navnet connection looks to be on TB7 (again, have not traced the wires to be certain).

As noted in the posts above, TB4 is "Port 2" on the AP, but can you confirm what TB is considered "Port 1"? I have connected RS232 wires to the appropriate ports on TB4...the USB-serial converter has lights on it that shows data transmitted and received. As well, there is a green light on the NavPilot control unit board that lights up when I plug in the TB4 connection. In OpenCPN, I have configed an AP output port (Com8 set for 4800baud...outputting only APB, GGA, VTG, RMB, and RMC as noted in the AP manual). I can see most of these in the datastream from inside OpenCPN, but have no idea if they are making it to the AP.

The problem is that the AP will not navigate, as it says there is no nav data on either port 1 or port 2 (the NavNet "navigation" function works fine and is on Port 1, I just don't use that finction while I troubleshoot the RS232 connection). In the installation menu, I see receiving data for HGD or HDT (depending on head sensor in use) and I see RMB/RMC as well...nothing else. It's like the RS-232 connection is not plugged in. The manual says "NMEA IN and RS232C IN cannot be used at the same time". If NMEA is TB5, then this could be my problem?

Any ideas how to proceed? I will confirm the TBs in use currently and (hopefully) what they are connected to soon. For now, I could used confirmation of the NMEA IN TB and indeed a list the TBs for each processor port (table in 2.6 page 2-12 of the install manual) would be very helpful. Trying to rationalize this table with the block wiring diagram on the last page of the manual is...challenging.

Regards,
SteveCo in St. John's, NL

 

[Anonymous]

Update on this. I had another go at it today and it is now working. The issue was twofold:
1. I found one of the serial wires had slipped out of the TB4 connector. This explained a lot, as it was acting like there was no connection between the computer and the AP...and indeed there was not! Once this was fixed, the AP would now show the required NMEA sentences being input to the AP, but I could still not navigate a route output by OpenCPN. The nav request would show on the AP ("navigate to waypoint 0002 on Port 2" or something to that effect), but when activated, the AP would still show "NAV data not present".
2. When I first reviewed the SC-60 settings, I noticed it was set for true heading output only and this did work with nav output from the NAVNet units. The SC-60 manual hinted that HDT and HDG were set by default (as well as VTG and ZDA as show in section 3.8 of the manual), so I enabled all these. When things still would not work, I switched to the PG500 heading source...and viola, things started working. So, I changed the SC to HDG output only (same as the PG500) and now the NAV function worked as it should. I change the SC-60 back to output HDT only and that worked as well. Clearly the AP does not like HDT and HDG info from the heading sensor. I left the original SC config with HDT only output to the AP...since I can get HDG, VTG and ZDA from other sources for the AP, I do not need it directly from the SC in any case.

One other comment here: I found that I had to restart the AP sometimes to ensure it was accepting the config changes I was making. This might have been unnecessary if I gave things a little longer to work thru, but I wanted to confirm all the changes would be preserved across a power down/off in any case. They are, so I am now good to go. No sea trial yet...all this was done dockside. I will report back if there is anything of note when the sea trial gets done.

As a final test, I powered down everything on the bridge other that the laptop, USB/serial converter, the AP and used a USB puck GPS for position and heading from the laptop. This would be a the "last line of defense" should the other electronics fail catastrophically (yes, that would mean failure of 2 NAVNets, 2 heading sensors, two BBGPSs, a GPS-32 and a bunch of interconnecting hardware...an extremely unlikely scenario). The system works fine in this minimalistic mode. If the AP or rudder drive subsystem quits, I am toast for NAV...these are the only non-redundant item in the whole system...and would have to steer manually!

Regards,
SteveCo

 

[Johnny Electron]

If your current theory about both TB7 and TB5 are being used, then you have no possible connection for your PC to drive the pilot. (Other than remove one of the existing)

The NavPIlot 500 series allows for two NAV inputs to drive the pilot. You can quickly toggle which input is being used by holding your NAV button more than 5 seconds and it will toggle and tell you which input has been selected.

You can either use both TB7 and TB5 inputs (Normal RS422 NMEA) or use TB7 and TB4 (RS232).
You can NOT use both TB5 and TB4 for input. The previous info posted has a drawing that is incorrect that TB4 is shared with COM1 (TB7). The text I wrote and advice was correct, but the drawing seems to indicate that TB4 is shared with COM1 (TB7). It is in fact shared with TB5 (not TB7). So you can always use TB7 as an input but much choose either TB4 (RS232) ( or TB5 [RS442]) to use as your second (Com2) input.

 

[Anonymous]

Since my last post, I have been sea trialing the new OpenCPN connection to the AP and have noticed an odd behavior pattern that I am hoping you can help me figure out. As background, previous to the addition of the OpenCPN source to drive the NavPilot 500, the only "autopilot" functions used were basic AUTO to follow current heading and navigate to a quickpoint from one of the NavNET units. The SC-60 was always the heading source and things worked fine that way...well, the odd time to sat compass would lose it's fix if the boat was turned too sharply for too long. I had not used the PG500 for heading fix up to this time...although I know it does work as the previous owner used it many times.

So, I now have the NAVnets and OpenCPN available to drive the pilot...switch by pressing and holding the NAV button (or set the desired input via the AP menus). The SC-60 is the primary heading source and I have returned it to it's pre-OpenCPN out put settings of HDT only. Here's the issue. Once safely in open sea, I hit AUTO and the AP picks up the heading and steers...all good. After maybe 10 seconds, the helm veers sharply to starboard and the sat compass loses it's fix. Switch back to STBY and steer manually. When the sat compass regains it's fix, try again...same result. FWIIW, this happens regardless of NAV input selected (OpenCPN or NAVNet) and even happens with the OpenCPN computer disconnected. The same thing also happens if I try to navigate from OpenCPN....I did not try to navigate from the NAvNets, but suspect the same thing would occur.

If I switch to the PG500 at the heading source, all is fine...AUTO and NAV work as you would expect. The boat turns more aggressively than it did with the SC-60 but in many ways the flux compass works "better" than the sat compass...the boat tracked smoother and the turns were more confident (if that makes any sense). I did notice, after 100+ miles of cruising, that the turns grew less aggressive and assume the AP was "learning" how to use the inputs from the PG500 better. I have not been able to verify all the current settings on the PG500, but I believe the AUTO and STATUS lights are on and the TRUE light blinks in normal operation (after initial start up).

Any ideas what might be causing the wild steering deviations in AUTO or NAV mode with the SC-60? It worked well before my addition of the OpenCPN serial connection to Port B of the NAVPilot 500, so obviously I have something wrong along the way. Problem now is finding it. Any help would be appreciated.

Regards,
SteveCo

 

[Anonymous]

One other thing I neglected to mention and am not sure it is relevant, but just in case. I am getting a battery low warning on the SC-60. It seems to work fine, but I do see a flashing "!" in the upper right-hand corner of the display all the time and after the Low Battery warning is no longer displayed.

Regards,
SteveCo

 

[Johnny Electron]

Being that your SC60 heading is an output to the pilot and that the pilot itself doesn't feed anything to the SC60; I think you have some sort of crazy RF bleed over issue. I don't know if something (like RF noise) is feeding over your DC system or something is spewing RF into the air messing with the SC60 but the problem is much deeper than this forum can address. I would make sure the cables are not running near each other and maybe try some DC power chokes on your power feeds. It might take a good Furuno dealer on the boat to help you chase this down. Sounds like a tough one.

 

[Anonymous]

Johnny;
Thanks for the advice and it does appear to be an odd problem. Given I am several hundred miles from a Furuno dealer at present - and things are working fine with the flux compass - I will play things out a bit and do some more troubleshooting.

I fell it is unlikely to be a RF interference problem but that could be an issue. Given that the only change to the entire system is the addition of an RS232 serial cable from an existing PC to the existing AP...and some resultant settings changes, the problem is most likely in these areas. The AP works fine taking input from the flux compass, but has issues with the sat compass...and the nav function works fine from the PC.

So, I will disconnect the recently added serial line just to verify it's not hosing something, but I can envisage how this would happen for input from the sat compass and not the flux compass as noted above. I will also review the settings on the sat compass...I did change a few of these after all. I still believe the issue is related to the heading being provide by each heading device...HDT, HDG and/or HDM...not sure how or why, but it just feels like the issue. if none of that works, then a call to the local deal is in order for sure.

Regards,
SteveCo in St. John's

 

[Anonymous]

Update on this. I think I have figured out what was causing the issues experienced with the nav from OpenCPN to the AP-500. You will recall we had wild deviations from the nav course shortly after engaging the nav option with input form OpenCPN.

We found that the SC60, albeit clearly issuing a low battery warning for both the processing unit and the control unit, was losing it's settings. Specifically, it was reverting to factory for the install position (deck vs underside of desk in our case). When we supplied the correct install position, it seems to work OK...but still not perfect. Rather than experiment further, both units have been pulled to get the batteries replaced. I will report back once this is done to see if this was indeed the cause of the nav issues experienced.

Regards,
SteveCo in St. John's

 

[Anonymous]

The final word (I hope) on this. Had new batteries installed in both the processing and head units of the SC-60 by the local Furuno dealer. FWIIW, you could replace these batteries yourself - the processor battery is very similar to the older PC motherboard type backup batteries, but is spot soldered to the socket, has a clear plastic sticker over the whole thing and some heavy duty hot-melt glue for vibration protection. Certainly doable if you can remove the units and work on them at a bench with fairly standard electronics tools. We let the dealer handle it and update the firmware at the same time. The processor battery is just a standard 3v litum (number is in the manual), but the head unit battery is a specific Furuno part, so off to the dealer we went. The total job was under $100Cdn.

Reinstalled and reconfigured the processor and head units...it took maybe 6mins for it to get a firm fix and display heading the first time (not surprising). After that, it takes maybe 30sec for a 3D fix and another minute or two for heading to appear.

Did a 3 hour test cruise and the SC worked like a charm...interfaced with the NavPilot 500 exactly the same it had up until the issue last winter in AUTO mode...did not get to test NAV mode, but I have no reason to expect that will not work. I will report back if this is not the case.

So it would appear that some of the SC config parameters that were not preserved between power cycles was the issue. It might be advisable to have the batteries replaced at regular intervals even if there is not low battery indication. The manual suggest 3-4 years battery life, but that depends on how often the unit is powered on. I would suggest if you have not replaced the batteries and the unit is 5+ years old, replace them at your next earliest convenience and save the hassle.

Regards,
SteveCo in St. John's