Quote:
|
I'm thinking the 'push_back' and/or 0xFF bits may be where I'm going wrong. It could easily be that canboat's pgn.h is incorrect.
|
If canboat defines a value as occupying 4 bytes, it & signalk both encode the value using the correct endianess. Don't worry about the "push_back" stuff, that is just the C++ method used to push values onto a vector.
Code:
byte sid = 0xA0;
payload->push_back(sid);
unsigned int emitterId = 0xFAB12;
payload->push_back(emitterId & 0xFF);
payload->push_back((emitterId >> 8) & 0xFF);
payload->push_back((emitterId >> 16) & 0xFF);
payload->push_back((emitterId >> 24) & 0xFF);
~snip~
is little different to
Code:
byte sid = 0xA0;
payload[0]= sid;
unsigned int emitterId = 0xFAB12;
payload[1] = emitterId & 0xFF;
payload[2] = (emitterId >> 8) & 0xFF;
payload[3] = (emitterId >> 16) & 0xFF;
payload[4] = (emitterId >> 24) & 0xFF;
~snip~
I don't think I've pushed my latest commits (DSC, MOB, Waypoints) to github, waiting for the OpenCPN 5.5 fuss to die down. Other than creating the CAN Id (pgn, source,
destination & priority) and fragmenting the fast message all you need is in the snippet.
Re the MMSI number, that's an interesting point. First of all I don't
recall that I ever tested PGN127233 using a "normal" MMSI number. So it may have worked, I don't know.
However I think the intent for the PGN 127233 message (and for that matter the NMEA 183 MOB sentence) is that they are generated by an AIS transceiver/receiver when an AIS MOB signal is received from an AIS MOB device such as a McMurdo Smartfind or Ocean Signal RescueME.
The MMSI prefix is used to clearly indicate that the AIS signal is transmitted by a SART, EPIRB or MOB device. Consequently and not surprisingly MFD vendors seem to only parse PGN 127233 messages or NMEA 182 MOB sentences that have the appropriate prefix.
I don't think the other kind of MOB devices (eg. the wireless wristband devices such as the ACR OLAS) and certainly not the Chipolo thing your are playing with, have any
concept of an MMSI number, nor communicate to the outside world using NMEA 183 or
NMEA 2000. Therefore easy to understand why NMEA and the
chartplotter vendors chose not to accept just any MMSI number in their AIS MOB/SART/EPIRB alerts.
From your perspective, a bit of a Catch22 situation In SignalK, users can configure their vessel's MMSI number and presumably/hopefully your SignalK plugin will retrieve the MMSI number from the SignalK config. However it will likely be a valid MMSI number that the user would have also used to configure their AIS and
VHF DSC transceivers. It should be a proper number issued by the responsible authority for the vessel's country of
registration. It won't be a number that has the 97x prefix. So if the users have other MFD's on-board, unlikely that the PGN 127233 message that you generate will ever be displayed. A conundrum no doubt.
Which then begs the question. Yacht Devices have a MOB button/device that they claim will generate alerts on chartplotters. Without reading the
documentation, I don't know whether users have to "create" a MMSI number with a valid prefix, or if they just enter their existing MMSI number and instead of transmitting PGN 127233, the Yacht Devices button just generates PGN 129802, an AIS
Safety Message. Or what brand & model of chartplotters will display the alert.
Assuming that the other
chartplotter vendors behave similarly to B&G, if you want to ensure that those chartplotters display something meaningful, you may want to contemplate either generating PGN 129802, the AIS
Safety Message, or PGN 126985 an Alert Text message.
Interested in smart boat technology, networking and all things tech
Now I'll need to some of the same things like cycling through MMSIs as the YachtDevice does, but that's all doable.
Linear Mode
Recent Discussions