Visit our Popular Forums

verkerkbr · 16-03-2022, 09:41

Quote:

Originally Posted by SirChaunchy

Bram, I of course am wondering why it is so difficult too because obviously hundreds of people have made it work already. My AP is a SIMRAD AC-12 and requires NMEA 2000 instructions. Open CPN only talks in NMEA 0183. Will the approach you just laid out result in Signal K transmitting NMEA 2000 instructions (i.e., the equivalent of NMEA 0183 RMB, XTE, and maybe APB) directly to my NMEA 2000 backbone so those instructions are available to my AP? It doesn't do me any good to get NMEA 0183 instructions to my auto pilot.

Then you must convert SignalK output to NMEA2000. But SignalK to NMEA2K must support XTE and RMB.

Have you looked in the SignaK plugin lists ?

I'am not sure what your AP needs for information to work.

Bram

SirChaunchy · 16-03-2022, 15:34

Yes. Signal K does have a Signal K to NMEA 2000 convertor. My AC-12 autopilot needs PGNs 129283 (Cross Track Error), 129284 (Navigation Data), 129285 (NMEA Route Navigation & Waypoint Data), 129029 (GNSS Position Data), and 129291 (Set & Drift, rapid update). PGN 129283 (Cross Track Error) is equivalent to APB and XTE, 129284 (Navigation Data) is equivalent to some combination of APB, BWC, BOD and BWW; 129285 (NMEA Route Navigation & Waypoint Data) didn't seem to have a direct equivalent but mostly is achieved with RMB which is a combination of PGNs 129283 and 129284, 129029 (GNSS Position Data) is a combination of GGA, GLL, RMC, and ZDA; and 129291 (Set & Drift, rapid update) is equivalent to VDR. I don't know if SK has all of those, but I will try to go to the boat tomorrow and see if I can figure that out given the input you and others have given me.

rgleason · 17-03-2022, 07:21

Reformat Sir Chaunchy statement for
Simrad AC-12, requiring Nmea2000 PGNS:

129283 (Cross Track Error) equivalent to APB and XTE
129284 (Navigation Data) equivalent to some combination of APB, BWC, BOD and BWW
129029 (GNSS Position Data)
129291 (Set & Drift, rapid update)
129285 (NMEA Route Navigation & Waypoint Data) didn't seem to have a direct equivalent but mostly is achieved with
- RMB which is a combination of PGNs 129283 and 129284, 129029 (GNSS Position Data) is a combination of GGA, GLL, RMC, and ZDA
- 129291 (Set & Drift, rapid update) is equivalent to VDR.

Sir Chaunchy I have not looked carefully but are you certain your autopilot "requires" all of this? I would try with only what is absolutely needed. Also I would pursue Steve's suggestions below to complete that approach, and provide him with

"When you are on board, irrespective of whether you have any success with the YDNU-2, what would be great would be to capture the NMEA 2000 traffic transmitted when you are using your B&G display to control the AC-12. This is where the NGT-1 and actisense-serial & analyzer programs can be utilized to log the traffic."

It will help immeasurably with other work.

Then pursue verkerkbr's suggestions with SignalK.

This thread is proving to be a textbook example, thanks for your careful approach.

SirChaunchy · 17-03-2022, 09:33

Quote:

Originally Posted by rgleason

Reformat Sir Chaunchy statement for
Simrad AC-12, requiring Nmea2000 PGNS:

129283 (Cross Track Error) equivalent to APB and XTE
129284 (Navigation Data) equivalent to some combination of APB, BWC, BOD and BWW
129029 (GNSS Position Data)
129291 (Set & Drift, rapid update)
129285 (NMEA Route Navigation & Waypoint Data) didn't seem to have a direct equivalent but mostly is achieved with
- RMB which is a combination of PGNs 129283 and 129284, 129029 (GNSS Position Data) is a combination of GGA, GLL, RMC, and ZDA
- 129291 (Set & Drift, rapid update) is equivalent to VDR.

Sir Chaunchy I have not looked carefully but are you certain your autopilot "requires" all of this? I would try with only what is absolutely needed. Also I would pursue Steve's suggestions below to complete that approach, and provide him with

"When you are on board, irrespective of whether you have any success with the YDNU-2, what would be great would be to capture the NMEA 2000 traffic transmitted when you are using your B&G display to control the AC-12. This is where the NGT-1 and actisense-serial & analyzer programs can be utilized to log the traffic."

It will help immeasurably with other work.

Then pursue verkerkbr's suggestions with SignalK.

This thread is proving to be a textbook example, thanks for your careful approach.

Rick,
My plan when I get to the boat, hopefully later today, is exactly as you described it. I first want to check the "retransmit for autopilot" box that Steve mentioned and see if that solves my problem. If not I can try to collect the data he asked for when the G&G autopilot controller is used. I'm not sure exactly how to do that recording because I have not used the actisense-serial & analyzer program and the actisense reader and other programs are Windows-based programs and I'm using a Mac so I have to go through Parallels, etc. Also, remember that when using the NGT-1 I have it connected as a CANBUS to Signal K so what is being transmitted via the NGT-1 doesn't show up in the Open CPN Raspberry Pi NMEA debug window. So I've got to figure out exactly how to collect the data Steve asked for. I fully agree it would illuminate the problem if I could collect it. Assuming for a minute that I can figure out how to collect that data, the next issue is how to associate a particular entry in the log with an event on the controller such as pressing the "activate" button or the +1˚ or the Nav mode button. When you record something like this is spews out hundreds of lines almost before you can get your finger off the button and this thread only allows 1 K byte uploads. So is it clear to you and Steve if you saw such a printout which PGNs are being generated in response to a particular command? If these approaches that Steve recommended do not work, I plan to make a copy of the disk the RPi program is on and use that copy to pursue verkerkbr's approach, which also sounds like it will work. The fly in the ointment with his approach is figuring out how to get the desired PGNs that are generated in the SK to NMEA2000 translator through the NGT-1 or YDNU-2 to the NMEA 2000 backbone. I'm not sure how to do that last part. And finally, in response to your question, no I'm not at all sure that the AC-12 requires all of the PGNs I listed in my previous posting. I suspect it needs only a subset of those. Most of the people on this thread who are much more knowledgable than me on this matter seem to think that only RMB and XTE may be required so I would try to start with PGNs 129283 and 129284, 129029. If you or Steve have any additional detailed guidance on how to employ the actisense-serial & analyzer program to gather the requested data, please let me know because I will be heading for the boat hopefully in about two or three hours and I have much better internet here than at the marina.

SirChaunchy · 17-03-2022, 15:30

Quote:

Originally Posted by stevead

FFS, if you read those pages it states:and on page 32.You have a Simrad autopilot, not a Raymarine autopilot.

Clearly the YDNU-2 sends the proprietary Raymarine NMEA 2000 messages !

I suggest that you eliminate SignalK from the equation, it is only confusing the issue.

All you need is OpenCPN configured to receive NMEA 1083 data from the YDNU-2 and to output XTE & APB to the YDNU-2. You will need to configure the YDNU-2 to convert XTE & APB to NMEA 2000 and to transmit onto the NMEA 2000 network. I'm guessing SILENT OFF, 183_TX filter and a GLOBAL_TX filter.

Code:

SET SILENT OFF
FILTER 0183_TX ADD XTE APB
FILTER GLOBAL_TX ADD PGN  129283 129284 129285

To monitor what is sent on the NMEA 2000 network, use the NGT-1 and programs that are IIRC included with SignalK/OpenPlotter, namely the Canboat analyzer and actisense-serial programs. analyzer decodes NMEA 2000 messages and actisense-serial connects the NGT-1 and pipes the received data to analyzer. I think the command would be something like:

Code:

actisense-serial -r /dev/ttyS1 | analyzer

assuming /dev/ttyS1 is the name of the serial port the NGT-1 is connected to. You may also need to configure the baud rate.

But as I stated earlier, I think it is unlikely that you will be able to control the AC-12 autopilot using a gateway as the required PGN's may not be correctly generated and I doubt if any of the proprietary PGN's are transmitted by the YDNU-2.

Steve, Rick, and Bram: I'm back on the boat and have been experimenting/flailing for the past couple of hours to check things out and gather some data. Unfortunately, Steve, I did have the box checked in the Connections "output on this port (as autopilot or NMEA repeater), so that was not the problem and I had APB, XTE, and RMB in the output filter. Since I was already connected to the YNDU-02 as a serial port I started with that setup. When I open the Open CPN NMEA debug window I get GSV, GSA, GGA, XDR, MDA, HDG, DPT, MWV, VWR, MTW, VLW, VTG, VHW, DBS, GSV, VDM, RSA, and VWT sentences coming in and all of them are filtered out and dropped. I get these same NMEA 0183 sentences coming in to Open CPN whether the YNDU is set to NMEA 2000 or 0183 in the serial app device setup. As soon as I drop a waypoint and command "navigate to here" the RMB, APB, XTE, and RMC are received by Open CPN and RMB, APB, and XTE are transmitted in blue. RMC is filtered and dropped because it wasn't included in the pass filter. So the moral of this story so far is that the YNDU is properly converting NMEA 2000 data from the backbone and converting it to NMEA 0183 sentences and passing them on to Open CPN. Open CPN is appropriately sensing the waypoint location and the command to "navigate to here" and calculating the appropriate RMB, APB, XTE, and RMC sentences/data and sending it back to the YNDU serial port. So then I looked at the blinking LED on the YNDU. When no waypoint had been selected and no command had been given to navigate to it I see three green blinks and a 4th red blink. When I activate a waypoint and say navigate to here, I see green, red, green, red. From the page on the manual I sent you the other day this means "First signal is green if data was received from NMEA 2000 during the period (otherwise red). Second is green if nothing was transmitted to NMEA 2000 by the device during the period. Third is green if dat was transmitted to the PC during the period. 4th is green if no data was received from the P during the period. So I conclude from all this that when a waypoint is not activated, NMEA 2000 data is being received by the YNDU, nothing is transmitted to the NMEA 2000 backbone by the YNDU, data is being passed on to the PC, and data is received from the PC. When a waypoint is activated and the navigate to here command is given, the YNDU is receiving data from the NMEA 2000, it is transmitting data to the NMEA 2000 backbone, it is transmitting data to the PC (i.e., the Pi), and it's receiving data from the PC. So all that seems to be working. Whether it's sending and receiving the right data, I don't know. We know that the Pi is sending out the right NMEA 0183 sentences. We know that the YNDU is receiving something and transmitting something to the NMEA backbone. We don't know if the YNDU is properly converting the RMD, APB, and XTE sentences to PGNs 129283, 129284, and 129285. I attempted to follow Steve's instructions to record that, but I'm not sure how to do that. I also found the debug window in Signal K so disconnected the YNDU and connected the Actisense NGT-1 that is sending info to Signal K through the Pi. The data I could see didn't make any sense to me and didn't show any NMEA 0183 sentences or NMEA 2000 PGNs. So I didn't make any headway there. Steve when you gave me those instructions to type in are you saying open the Terminal in Open Plotter and type those commands in there, or open the terminal in the CANBUS app in the CANBUS setup and type them in there or where exactly are you saying to type those commands? Sorry this is so long, but there's a lot of detailed information to pass on. One last thing for Bram, I looked at the SK to NMEA 2000 translator and PGNs 129283, 129284, and 129285 are not listed as available PGNs to select so I'm not sure how to get the APB, XTE, and RMB sentences translated through either the NGT-1 or the YNDU and onto the NMEA 2000 backbone. That's the issue right now I think because the correct NMEA 0183 sentences are arriving at the YNDU or NGT-1 from the Pi side, but not getting to the NMEA 2000 backbone as the correct PGNs or they are and my autopilot isn't detecting them, or one last possibility is that I'm not sending all of the required NMEA 0183 sentences through the output filter so as far as the autopilot is concerned it is still "missing data".

stevead · 17-03-2022, 17:04

Sir Chauncy, before posting, please hit the preview button and edit your post into sentences & paragraphs that can be more easily read instead of one large blob of text. My eyes hurt !

From what you have described the YDNU-2 and OpenCPN are working as expected. The YDNU-2 is receiving NMEA 2000 messages, converting them to NMEA 0183 and sending to OpenCPN which is parsing them as expected.

When you select "navigate to here", OpenCPN is generating the APB, RMC and XTE sentences and with the output filter, transmitting XTE and APB to the YDNU-2 which presumably is converting these and transmitting onto the NMEA 2000 network.

Part of the problem could be that because we are not sending RMC sentences to the YDNU-2 (to prevent creation of a data loop), the YDNU-2 may not be able to correctly construct the necessary PGN's. We can only work this out if we can determine what exactly is being transmitted on the NMEA 2000 network.

With the Pi you should be able to simultaneously monitor the NMEA 2000 network using the Actisense NGT-1. The commands I mentioned are run from a Terminal Window accessed from either the Raspberry Pi menu or by pressing Ctrl Alt F1. I've no idea what menu options Open Plotter provides.

Code:

actisense-serial -r /dev/ttyS1 | analyzer

Alternatively you may be able to configure Signal-K with the Actisense NGT-1 (using the N2k to SignalK plugin) and no other outputs and monitor the NMEA 2000 traffic, however I can't recall how to log the raw NMEA 2000 traffic from SignalK so you may have to dig around.

However as I stated I have serious doubts that you will be able to control your AC-12 from OpenCPN using either the YDNU-2 gateway or with SignalK. Refer to the following for some further information re SignalK and Simrad autopilots.

Thanks very much for your perseverance and assistance.

Tehani · 18-03-2022, 05:46

I think it's time to put a little order to all this:
1- As it seems, SignalK is not capable of translating in the NMEA0183 -> NMEA2000 direction, so let's forget about SignalK.

2- RMB contains all the necessary navigation data, and when YDNU-02 receives it, according to its manual, it sends the following via N2k:
129283 Cross Track Error
129284 Navigation Data
129285 Navigation — Route/WP information
Just what the AC12 manual says you need, which matches every AP I know of. There is also no need to add XTE to the OpenCPN output list.

3- Steve, according to the YDNU-02 manual, the APB conversion is limited only to the XTE field, exclusively generating the PGN 129283 "Cross Track Error". Therefore, it is not needed in the OpenCPN output list.

4- RMC is confusing here. OpenCPN should not include it in the output, when it receives full RMC in its input. Although it is filtered, we see that internally it is generating it. For some time, I believe that it is a bug in the code of O.
If we see the VDR, we cannot know who the originating issuer is.
In this previous post: https://www.cruisersforum.com/forums...ml#post3591954
We see RMC issued as ECRMC (OpenCPN) and YDRMC (Yacht D.)
As in the NMEA0183 debug screen it is in red, it seems that it is filtered, so it is clear that YD is the original emitter.

5- At some point in N2k, the PGN 127258 Magnetic Variation is being generated. It can be the AIRMAR GPS itself, or in the Triton (its manual indicates it as output). We see a magnetic variation of 12.5E.

6- The sequence of colors in YD: green, red, green, red is compatible with NAV operation, but in reality, we don't know which PGN's YD is actually sending to the N2k bus.

Conclusions:
1- Although YD is working in bidirectional mode, it seems that the AC-12 does not have the information it needs. It may be a bug in the structure of the PGN 129285 Navigation — Route/WP information. Or in fact, anywhere else...

2- I'm wondering if it would not have been more effective to put a Simrad AT10 converter + a cheap USB<->RS232. The problem here is that since AT10 does not handle AIS data, and SIMRAD RS35 VHF is connected to NMEA2000, OpenCPN would not see those targets.

3- As Steve says, a couple of seconds capture is needed in NMEA2000 when YDNU is green, red, green, red. If you can use NGT-1 to do it, you can send it to me and I can analyze it myself.

- Although it is "offtopic", I think that for a 47´ catamaran an AC42 or NAC3 is more appropriate than an AC12. It's true?

J.L.

Tehani · 18-03-2022, 06:19

This was posted a long time ago:
https://opencpn.org/flyspray/index.p...s&task_id=2681

It was the analysis of the same problems that we deal with here, but with Raymarine Evolution pilots.
At that time, even using a Raymarine Seatalk/SeatalkNG converter it was not possible to navigate in NAV/TRACK mode using a plotter on the Seatalk side.
After quite a few user complaints, and some AP firmware updates, it was fixed.

In particular, I remember the case of a user who has a portable GPSMAP72 connected to the gateway (Not YD or Actisense or Ship Modul), and his AP works since then in NAV / TRACK mode without problems.

There is also a problem with PGN 127258 (Magnetic Variation).
In theory, that PGN is 6 bytes of data long, but Raymarine needs the entire frame of 8. Garmin sends 6 bytes, and they don't understand each other.
I solved it by reading 6 bytes and forwarding 8 to nmea2000.

I've been looking at a screenshot of an AC12 on a fully Simnet network, which I did about 3 years ago. In it appears the PGN 127258 with a length of 8 bytes of data.

Tehani · 18-03-2022, 09:54

Analyzing in depth that capture of AC12 that I have commented before, I obtain the following:

- The MDF stupidly repeats the speed (STW), wind, rudder angle, speed (STW) and heading PGNs that have previously been sent from the instruments.

- In waypoint navigation mode, the Simrad MFD adds 129284, (navigation data), 129283 (XTE), and 127237 (Heading/Track control) with only one valid field: "Heading to steer". That PGN 127237 is also sent by the pilot to the Simnet/N2k bus, which is normal, with more complete fields, but without the "heading to steer" field. No propietary PGNs are added.

I am sorry to tell you that your YDNU-02 does not interpret APB, nor any other sentence, such as 127237, but you can change your NGT-1 and YDNU for a simple NGW-1, as I told you at the beginning of the thread. Know that this one does translate APB -> PGN127237. I hope you can get money back...
So, you should put as output sentences for OpenCPN: RMB and APB.

J.L.

SirChaunchy · 18-03-2022, 12:54

Quote:

Originally Posted by Tehani

Analyzing in depth that capture of AC12 that I have commented before, I obtain the following:

- The MDF stupidly repeats the speed (STW), wind, rudder angle, speed (STW) and heading PGNs that have previously been sent from the instruments.

- In waypoint navigation mode, the Simrad MFD adds 129284, (navigation data), 129283 (XTE), and 127237 (Heading/Track control) with only one valid field: "Heading to steer". That PGN 127237 is also sent by the pilot to the Simnet/N2k bus, which is normal, with more complete fields, but without the "heading to steer" field. No propietary PGNs are added.

I am sorry to tell you that your YDNU-02 does not interpret APB, nor any other sentence, such as 127237, but you can change your NGT-1 and YDNU for a simple NGW-1, as I told you at the beginning of the thread. Know that this one does translate APB -> PGN127237. I hope you can get money back...
So, you should put as output sentences for OpenCPN: RMB and APB.

J.L.

J.L. and Steve,
Thank you both for taking the time to add your analyses to mine and helping me search for a solution to the problem.

J.L. I doubt if I can get any money back for the NGT-1 since I've had it since March of 2012 when I had the boat built in Valdivia, Chile and sailed it all the way from there to the Galapagos, then to Baja, and finally up here to California. I need to keep the YDNU-02 because it works with my newer generation Mac Computer with the M1 Chip and MacENCx64 as a backup navigation system to my preferred Open CPN. Actisense has not yet developed drivers for that computer so the NGT-1 doesn't work at all with that computer. I'm not sure about the NGW-1, but I'll look in to it. It may be that that's the cost of getting this last capability to work with Open CPN, or I may just have to use Open CPN without that capability—not what I was hoping for. Finally, J.L. regarding your comments about the AC43 or NAC3 I think those are valid comments, but on our way up here from Chile, we sometimes had 30 foot waves from behind the boat at all angles and we never had a bit of trouble with the AC-12. It always performed perfectly and it uses very little power. Power consumption was one of the main considerations we had when selecting all of our navigation equipment because we needed to go for long periods just on solar and wind power and we have two refrigerators, a water maker, and the autopilot is electric. That's why we went with Lithium Ion house batteries and mostly B&G instruments throughout. The AC-12 is also easy to maintain. So far I love it and I've had it for ten years and sailed in some pretty rough weather. I just wish I could get it to work with Open CPN.

CarCode · 19-03-2022, 00:53

Is it really needed to take the effort connecting the autopilot to OpenCPN?
When you are sailing great distances as you say and what I am doing also with sailing distances of 2-3 days I only adjust the autopilot to the wanted course and let him work. Even as singlehanded sailor I watch out from time to time and adjust the course of the autopilot if needed. That is all.

Tehani · 19-03-2022, 02:51

Quote:

Originally Posted by CarCode

Is it really needed to take the effort connecting the autopilot to OpenCPN?
When you are sailing great distances as you say and what I am doing also with sailing distances of 2-3 days I only adjust the autopilot to the wanted course and let him work. Even as singlehanded sailor I watch out from time to time and adjust the course of the autopilot if needed. That is all.

NAV/TRACK and NO DRIFT modes are very useful to compensate for drift and leeway. I also navigated as you say, but in legs of more than 30-40 miles, you save a lot of distance, and it is not necessary to monitor the course to the waypoint every hour.

I once did a short distance test near the coast and for sure on that day, there was a major lateral drift. It was amazing, I didn't notice that drift until I put the TRACK mode on. Added more than 20 degrees to starboard on the magnetic heading to keep the COG to the waypoint. TRACK mode did it perfectly, and in AUTO mode I would have had to constantly correct, drawing a perfect hyperbola.

In this other thread:
https://www.cruisersforum.com/forums...ts-225322.html

Douwe explains that the passages in the fjords where he navigates are narrow, and with a precise TRACK mode following a route, he has the necessary security.

J.L.

Tehani · 19-03-2022, 02:56

Quote:

Originally Posted by SirChaunchy

... I need to keep the YDNU-02 because it works with my newer generation Mac Computer with the M1 Chip and MacENCx64 as a backup navigation system to my preferred Open CPN. Actisense has not yet developed drivers for that computer so the NGT-1 doesn't work at all with that computer.

I don't get it, you started talking about a Raspberry and OpenCPN...

CarCode · 19-03-2022, 03:20

What do you trust more? Your eyes or some technics not knowing it works correct?
You will know the answer when going sailing.

Quote:

Originally Posted by Tehani

NAV/TRACK and NO DRIFT modes are very useful to compensate for drift and leeway. I also navigated as you say, but in legs of more than 30-40 miles, you save a lot of distance, and it is not necessary to monitor the course to the waypoint every hour.

I once did a short distance test near the coast and for sure on that day, there was a major lateral drift. It was amazing, I didn't notice that drift until I put the TRACK mode on. Added more than 20 degrees to starboard on the magnetic heading to keep the COG to the waypoint. TRACK mode did it perfectly, and in AUTO mode I would have had to constantly correct, drawing a perfect hyperbola.

In this other thread:
https://www.cruisersforum.com/forums...ts-225322.html

Douwe explains that the passages in the fjords where he navigates are narrow, and with a precise TRACK mode following a route, he has the necessary security.

J.L.