OpenCPN Version 5.7 Alpha Test

[stevead]

Hi Hakan,

To the best of my knowledge most speed sensors transmit PGN 128259 whereas I think PGN130577 is synthesised/generated by chart plotters as it includes COG, SOG, Heading and also calculates Set & Drift. PossIbly more akin to VMG calculations?

I haven't heard any TwoCan users mentioning that their speed sendors emit anything but PGN 128259.

Are you going to help with the DSC parsing?

Regards.

[Hakan]

Steven..
Sounds fair with MFD. So we better change to 128259 speed through water.


DSC: Would that be a part of N2K handling?

[Hakan]

Does anyone happens to have a candump -L for a moving ship including speed trough water and if possible distance log data?
Thanks
Håkan

[merrimac]

Originally Posted by Hakan

Does anyone happens to have a candump -L for a moving ship including speed trough water and if possible distance log data?
Thanks
Håkan

Is this what you are looking for?

https://github.com/canboat/canboat/b...umpSample3.txt

[wholybee]

Originally Posted by bdbcat

wholybee..
As far as we can tell, there are no "standard" definitions for this function. There are some proprietary product out there, with various functions.


Someday, there will be NMEA OneNET, which seems to be something like N2K over ipv6 network. We do not plan to implement this in O58


But maybe we are missing something. Do you have any more info? Any particular hardware solution interests you?



Thanks
Dave

I currently use a Yacht Devices YDWG-02 which supports n2k and also will convert to NMEA0183. I experimented with its n2k output with SignalK, but didn't like the SignalK solution.

Antisense also supports n2k. And both also support a "RAW" mode. They might both be proprietary formats, but both are supported by SignalK, and canboatjs.

Of course, there might not be anything proprietary at all. It might be the same serial stream just sent via IP socket instead of a com port. If that is easy to "hook up" I would be happy to test it for you. Or, I could mail someone my YDWG-02 for a couple weeks to test with.

I am certainly not going to go backwards and connect a wire again. For now 0183 works fine, but I would like to look forward to more functionally in the (not immediate) future.

[bdbcat]

Wholybee...
Not clear from the documentation what is the format of the data on the wire, exactly.
Anyone else using or contemplating the YDWG-02 device?


Thanks
Dave

[merrimac]

Originally Posted by bdbcat

Wholybee...
Not clear from the documentation what is the format of the data on the wire, exactly.
Anyone else using or contemplating the YDWG-02 device?


Thanks
Dave

I tried it for a while but it was unreliable for me, dropping the TCP/UDP connection to such a point that it did not come back up. I had to power cycle the device to get it back up. So out with the YDWG-02 and back to something with a wire (which is OK in my use). I switched to an iKonvert which is easier on the open source programmer as DY have an open API description on GitHub.

The canboat samples directory contains many different format examples, there is a sample-YDWG02.txt file there which is what you get when you connect to the N2K stream. It is pretty simple:

21:55:37.922 R 0DF50B23 FF FF FF FF FF 00 00 FF
21:55:37.932 R 09F50323 FF 00 00 FF FF 00 FF FF
21:55:37.934 R 19F51323 60 0E FF FF FF FF FF FF
21:55:37.936 R 15FD0723 FF C0 D9 6F FF 7F FF FF
21:55:37.937 R 19F51323 61 F6 94 07 00 F6 94 07
21:55:37.940 R 19F51323 62 00 FF FF FF FF FF FF
21:55:38.439 R 15FD0723 FF C0 D9 6F FF 7F FF FF
21:55:38.927 R 0DF50B23 FF FF FF FF FF 00 00 FF
21:55:38.937 R 09F50323 FF 00 00 FF FF 00 FF FF
21:55:38.939 R 19F51323 80 0E FF FF FF FF FF FF
21:55:38.941 R 15FD0723 FF C0 D9 6F FF 7F FF FF
21:55:38.942 R 19F51323 81 F6 94 07 00 F6 94 07
21:55:38.945 R 19F51323 82 00 FF FF FF FF FF FF

CANboat analyzer knows how to parse this, so feel free to learn from there.

[Hakan]

Originally Posted by merrimac

Is this what you are looking for?

https://github.com/canboat/canboat/b...umpSample3.txt

Yes both STW and logs are there.

Thanks
Håkan

[verkerkbr]

Did the first test with the small and cheap Canable board at 250000.

Use the inialisation string to get canO. System is an AM64 Linux Mint.

I can report it works here at home with my NMEA2K Garmin GPS.

Tomorow will test the NGT-1.


Bram

[wholybee]

Originally Posted by merrimac

I tried it for a while but it was unreliable for me, dropping the TCP/UDP connection to such a point that it did not come back up. I had to power cycle the device to get it back up. So out with the YDWG-02 and back to something with a wire (which is OK in my use). I switched to an iKonvert which is easier on the open source programmer as DY have an open API description on GitHub.

The canboat samples directory contains many different format examples, there is a sample-YDWG02.txt file there which is what you get when you connect to the N2K stream. It is pretty simple:

21:55:37.922 R 0DF50B23 FF FF FF FF FF 00 00 FF
21:55:37.932 R 09F50323 FF 00 00 FF FF 00 FF FF
21:55:37.934 R 19F51323 60 0E FF FF FF FF FF FF
21:55:37.936 R 15FD0723 FF C0 D9 6F FF 7F FF FF
21:55:37.937 R 19F51323 61 F6 94 07 00 F6 94 07
21:55:37.940 R 19F51323 62 00 FF FF FF FF FF FF
21:55:38.439 R 15FD0723 FF C0 D9 6F FF 7F FF FF
21:55:38.927 R 0DF50B23 FF FF FF FF FF 00 00 FF
21:55:38.937 R 09F50323 FF 00 00 FF FF 00 FF FF
21:55:38.939 R 19F51323 80 0E FF FF FF FF FF FF
21:55:38.941 R 15FD0723 FF C0 D9 6F FF 7F FF FF
21:55:38.942 R 19F51323 81 F6 94 07 00 F6 94 07
21:55:38.945 R 19F51323 82 00 FF FF FF FF FF FF

CANboat analyzer knows how to parse this, so feel free to learn from there.

I expect (without looking) that the above capture is very close to what would be read directly from the CANBUS. Perhaps just with a timestamp and some whitespace added.

My wire is still there as a backup. Interesting that you have that problem with it needing an occasional power cycle. I actually had that issue also, but with some fiddling managed to get it stable. But I still can't deal with a wire. To me that's a reason to switch to an antisense, not a wire. All of the USB ports on my laptop quickly rusted, as did the plug on my converter. So I bought the YDWG to fix that problem. Plus the wire doesn't let me connect from the cockpit, or anywhere other than the desk.

[verkerkbr]

Originally Posted by verkerkbr

Did the first test with the small and cheap Canable board at 250000.

Use the inialisation string to get canO. System is an AM64 Linux Mint.

I can report it works here at home with my NMEA2K Garmin GPS.

Tomorow will test the NGT-1.


Bram

The NGT-1 on 115 and the on at 250 do not yet work. Perhaps is a configuration needed.


Tte Canable (lighthouse firmware) also need a configuration string to get can0.

[verkerkbr]

Originally Posted by verkerkbr

The NGT-1 on 115 and the on at 250 do not yet work. Perhaps is a configuration needed.

Tte Canable (lighthouse firmware) also need a configuration string to get can0.

I was looking for CanX input. But the NGT-1 uses serial input.

After setting the right parameters, now the Actisense NGT-1 also works with direct input in version 5.7.1.

However the Canable uses can0 as input.

Bram

[stevead]

However the Canable uses can0 as input.

With the Candlelight firmware, the Canable should appear as a native interface can0.
If the Canable has not been flashed with the Candlelight firmware, it should appear as a Serial Line CAN interface slcan0

Depending on the platform, as long as udev rules, etc/network/interfaces or /etc/systemd/system have been configured correctly, there should be no need for additional commands to bring up the interface.

But I digress.
Dave, Alec,you may want to double check with Timo and your N2K libraries, in particular the N2KIsNA functions.
To the best of my knowledge if a value is set to:
max value, it means data not available
max value -1, it means error (or out of range ?)
max value -2, it is NMEA reserved

That means for something like PGN 129025, Position Rapid Update, where latitude & longitude are transmitted as a signed integer, invalid values are INT_MAX, INT_MAX-1, INT_MAX-2.

The following screenshots illustrate the problem.

[bdbcat]

Steve...
In the "error-max" image, I assume you are referring to the Hdg value of 374 degrees (true). Bogus, for sure.
In certain cases, OCPN calculates HDT from HDM and MagVariation. This could be happening here, with some logic error. Or it could be a legitimate N2K error-max detection problem.

Can you produce a candump -L record of this situation for analysis?


Thanks
Dave

[bdbcat]

Note to interested devs and source builders:
OpenCPN github branch "comm" has been merged to branch "master". All local building should migrate to "master" now, as will the ongoing dev activities.


Thanks
Dave