OpenCPN and CAN Bus PGN's

[bcn]

Originally Posted by hoolie

CANBUS relies on distributed processing - a concept that at present doesn't get much coverage in boats. Certainly it's worth pursuing but I think it's for the long term.

Distributed processing is a benefit you get from a bus concept - but there can be just one master as well.
Being just a listener to the bus is as too much easier in N2K than in a multiple NMEA0183 environment.

The other CAN world:
CAN on (passenger) cars or motorcycles is different: there is no common (application) protocol.
Every manufacturer plays with own data and protocols. They have sufficient _volume_ to do their private plays.

Industrial vehicles are a second field. Standards do exists, even on the application level and from there NMEA took the basis of the standard (industrial buses as well).

bcn

[goboatingnow]

Originally Posted by hoolie

CANBUS relies on distributed processing - a concept that at present doesn't get much coverage in boats. Certainly it's worth pursuing but I think it's for the long term.

Jeepers there's lot of CAN. Nonsense here. Firstly CAN BUS as in the 2.0 standard is merely the underlying protocol . This is an open standard. Unfortunately more sophisticated protocols are overlaid on it, like J1939 in trucks etc.
in the sailing world NMEA defined in effect a closed protocol. So for an open source project this will fundamentally be at odds with 2k and the only way is the gateway option. That's its folks.

By the way there is loads of " distributed " processing on boats. A seperate wind and depth display is " distributed processing "

Secondly 0183 is close to dead. All new installations in new production boats are 2k, even of its just to hook the wind and depth displays.

and there are issues with multiple identical sensors. 2k never defined what to do with the " source select " issue and its remains a problem with many installations/ system software. Three are other issues with 2k , like gateway bridging etc

Dave

[bcn]

Originally Posted by goboatingnow

By the way there is loads of " distributed " processing on boats. A seperate wind and depth display is " distributed processing "

That seems to be just multiple receive - no data sent back on the same communication channel

and there are issues with multiple identical sensors. 2k never defined what to do with the " source select " issue and its remains a problem with many installations/ system software. Three are other issues with 2k , like gateway bridging etc

Dave, do you have details about that issues - I'm interested to learn more.

bcn

[JesperWe]

From the point of OpenCPN of course it would be nice to accept N2K messages straight away. Only problem is no general purpose computers have an N2K port.

So we need an interface. But there is no standard for that. Most interfaces comes with a closed source driver, the drivers from different vendors all have different API's, and none I am aware of are cross platform. (CANUSB seems to work on Linux but without real support from the vendor)

The closed NMEA standard is no issue, it has been reverse engineered and all the needed information is available for making OpenCPN understand the navigational related PGN's. And it would fit nicely with the new datastream bus concept launched in the latest beta.

But until we have a standard way of interfacing with the physical cable across our supported platforms I don't see this finding it's way into the core OpenCPN.

On the other hand, building a platform and driver API specific plugin for one vendors interface hardware is already possible and not difficult.

(Maybe I should add that I already have two different N2K buses with different PC adapters installed on my boat (One CANUSB + one Airmar, but I still use 0183 to feed OpenCPN and that feels just fine...)