Looking for working MOB PGN (127233) example

[hanst]

Hi all,

For SignalK I'm working on a MOB plugin. The idea is to watch Bluetooth beacons (like Chipolo) for presence and when not there alert the crew by having the beacons emit sound as well as raising an MOB alert through pgn 127233.

I've got some initial code here: https://github.com/htool/signalk-beacon-mob-plugin
It creates a MOB pgn like:
2021-11-16-09:30:26.573 3 30 255 127233 Man Overboard Notification: SID = 0; MOB Emitter ID = 1234567; Man Overboard Status = Test Mode; Activation Time = 16:57:25; Position Source = Position estimated by the Vessel; Position Date = 2021.11.14; Position Time = 16:57:25; Latitude = 52.4601967; Longitude = 5.0446193; COG Reference = True; COG = 0.0 deg; SOG = 0.00 m/s; MMSI of vessel of origin = 244670524; MOB Emitter Battery Status = Good

But my B&G Vulcan doesn't show the Man Overboard alert. It should according to:


https://www.yachtd.com/news/new_nmea...ndard_411.html


Does someone here have the capability to raise a MOB pgn (127233) and capture it on the n2k bus?

Thanks in advance,

hans

[goboatingnow]

https://www.nmea.org/Assets/20130906...tification.pdf

[hanst]

Originally Posted by goboatingnow

https://www.nmea.org/Assets/20130906...tification.pdf

Yes, I'm aware of the document. And I even changed the canboat pgn.h to have the 'reserved' bits set to 1, but so far I'm not getting my Vulcan to show a message.
That's why an MOB message captured from the network would be useful to compare with.

[stevead]

The two obvious problems with your example are that you are not using a valid MOB Emitter ID nor a valid MMSI number.
The emitter ID is a 5-digit fixed length field of hexadecimal characters.
And the following MMSI prefixes are used for different devices:
AIS SART: 970
AIS EPIRB: 974
AIS MOB: 972

And don't think that B&G displays are immune from bugs. The dialog title should say MOB Active, rather than SART Active, they don't differentiate between Navigation Status 14 (Active) and Navigation Status 15 (Test) etc.

This is a bastardised sample of code from my plugin that encodes PGN 127233.

void SendMOBMessage(std::vector<byte> *payload) {
	payload->clear();
	
	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);

	byte mobStatus = 0;
	payload->push_back((mobStatus & 0x07) | 0xF8);

	unsigned int timeOfDay = 50415 * 1e4; //2:15pm
	payload->push_back(timeOfDay & 0xFF);
	payload->push_back((timeOfDay >> 8) & 0xFF);
	payload->push_back((timeOfDay >> 16) & 0xFF);
	payload->push_back((timeOfDay >> 24) & 0xFF);

	byte positionSource = 1;
	payload->push_back((positionSource & 0x07) | 0xFE);

	wxDateTime now;
	now = wxDateTime::Now();
	wxDateTime epoch;
	epoch.ParseDateTime("00:00:00 01-01-1970");
	wxTimeSpan diff = now - epoch;

	unsigned short daysSinceEpoch = diff.GetDays();
	unsigned int secondsSinceMidnight = (unsigned int)(diff.GetSeconds().ToLong() - (diff.GetDays() * 24 * 60 * 60)) * 10000;

	payload->push_back(daysSinceEpoch & 0xFF);
	payload->push_back((daysSinceEpoch >> 8) & 0xFF);

	payload->push_back(secondsSinceMidnight & 0xFF);
	payload->push_back((secondsSinceMidnight >> 8) & 0xFF);
	payload->push_back((secondsSinceMidnight >> 16) & 0xFF);
	payload->push_back((secondsSinceMidnight >> 24) & 0xFF);

	int latitude = static_cast<int>(41.158 * 1e7);
	payload->push_back(latitude & 0xFF);
	payload->push_back((latitude >> 8) & 0xFF);
	payload->push_back((latitude >> 16) & 0xFF);
	payload->push_back((latitude >> 24) & 0xFF);

	// Field 10
	int longitude = static_cast<int>(1.5 * 1e7);
	payload->push_back(longitude & 0xFF);
	payload->push_back((longitude >> 8) & 0xFF);
	payload->push_back((longitude >> 16) & 0xFF);
	payload->push_back((longitude >> 24) & 0xFF);

	byte cogReference = 0;
	payload->push_back((cogReference & 0x02) | 0xFC);

	unsigned short courseOverGround = 45;
	courseOverGround = DEGREES_TO_RADIANS(courseOverGround) * 10000;
	payload->push_back(courseOverGround & 0xFF);
	payload->push_back((courseOverGround >> 8) & 0xFF);

	unsigned short speedOverGround = 1.7;
	speedOverGround = (speedOverGround / CONVERT_MS_KNOTS) * 100;
	payload->push_back(speedOverGround & 0xFF);
	payload->push_back((speedOverGround >> 8) & 0xFF);

	unsigned int mmsiNumber = 972201234;
	payload->push_back(mmsiNumber & 0xFF);
	payload->push_back((mmsiNumber >> 8) & 0xFF);
	payload->push_back((mmsiNumber >> 16) & 0xFF);
	payload->push_back((mmsiNumber >> 24) & 0xFF);

	byte batteryStatus = 0;
	payload->push_back((batteryStatus & 0x07) | 0xF8);

}

One important thing to note is that OpenCPN does not display MOB alerts generated from outside of OpenCPN. So it is an academic exercise if you generate a SignalK alert, or convert PGN 127233 into the NMEA 183 MOB sentence as OpenCPN isn't going to do anything with it.

[hanst]

Originally Posted by stevead

The two obvious problems with your example are that you are not using a valid MOB Emitter ID nor a valid MMSI number.
The emitter ID is a 5-digit fixed length field of hexadecimal characters.
And the following MMSI prefixes are used for different devices:
AIS SART: 970
AIS EPIRB: 974
AIS MOB: 972

Thanks for your elaborative answer Steve!
For the MMSI, according to canboat's pgn.h the MMSI can also be from the reporting vessel. That's why I tried that. I'll use the one in the screenshot to test further first.
According to the technical docs the emitter id can be any 'int'. It all ends up as hex in the end ofcourse.

Originally Posted by stevead

And don't think that B&G displays are immune from bugs. The dialog title should say MOB Active, rather than SART Active, they don't differentiate between Navigation Status 14 (Active) and Navigation Status 15 (Test) etc.

This is a bastardised sample of code from my plugin that encodes PGN 127233.

void SendMOBMessage(std::vector<byte> *payload) {
	payload->clear();
	
	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-
}

One important thing to note is that OpenCPN does not display MOB alerts generated from outside of OpenCPN. So it is an academic exercise if you generate a SignalK alert, or convert PGN 127233 into the NMEA 183 MOB sentence as OpenCPN isn't going to do anything with it.

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.

Is your full code available anywhere?

Thanks,

hans

[stevead]

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.

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

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.

[hanst]

Originally Posted by stevead

-snip-
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.

Correct, these are Bluetooth LE devices. The intention is to track them using a Raspberry Pi and when one is lost, create a MOB alert.

Originally Posted by stevead

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.

I took at the Yacht Devices manual and you're right:

In this mode (factory default), pressing the connected button for two seconds (can be changed in settings)
causes the sending of NMEA 2000 MOB messages (PGN 129038 and 129802), using the GPS position
data from NMEA 2000 network. Multifunction displays (chart plotters) will place the mark on the screen.
In addition to that, the Device produces a sound alarm and the external LED start "S" flashing, confirming
that the MOB alert is activated. The next 2-second press to the button cancels the MOB signal.
For the MOB mark, the Device uses MMSI number 972777XXX, where XXX is an incremental number from
000 to 999. This allows setting the mark next time when the previous MOB alert from the Device has been
canceled or suppressed by the MFD user

So the MFD probably doesn't support pgn 127233 at all afterall. I'll give the above a shot and see where that leads me. Thanks for the input Steve!

Cheers,

hans

[hanst]

And that works Now I'll need to some of the same things like cycling through MMSIs as the YachtDevice does, but that's all doable.