AIS SART/DSC tracking - not only Beta 3.3.1731

[PjotrC]

I know there are many priorities, but sometimes it is useful to revisit seldom-used functions, especially if safety-related.

So, just for the record and review.

Re: DSC distress and position report

1. In 3.3.1731 Beta this does not work at all - some Alert tries to pop up, but with empty contents and null effect. It was correctly implemented before up to 3.2.2.

I think an alarm is NOT needed on reception of a DSC Distress in the chartplotter. The Distress could have been received only by an approved radio, which already did produce an alarm, and it had to be acknowledged by the operator. There are legal issues around receiving radio distress, requiring the operator to note down all the message details (from the radio panel) in the hardcopy log. Repeating the alarm on the chartplotter is not necessary... A helping dialog is OK, but no alarm requiring an action ... Please note, that OCPN takes just the position data from the DSC message, all other particulars anyway must be viewed on the radio...

2. In 3.2.2 the feature does work, but for future versions it would be essential to also have the "Create Waypoint" button on the Alert panel to help in recording the spot.

3. I think the DSC Distress target should not be removed from chart and Target List with normal target ageing. It should be kept much longer.

4. The track drawn for a DSC target is a little buggy: since the position comes in two parts, first the degrees and whole minutes position is assumed from the first message, then it moves to the fine specification of minute fractionals from the second message. I did this, because I wanted a position assumed even if the second part is lost, but a proper implementation should include a small timeout to wait for the second message, before displaying the target.

Re: GPSGate Buddy

1. In the Target Query panel the report date shows only UTC time. Sometimes the calendar date may be relevant as well, since reports may be coming even less often than daily...

2. In principle, the report should be kept even across OCPN sessions, as it represents "the last trace of the buddy", but this is done in the Server. The "Create Waypoint" button in the Target Query nicely helps to record this, but it would be better, if the target identification and timestamp would be automatically included in the WP name. The same remark applies to all other Target_Query-created Waypoints.

3. There seems to be a bug, making all buddy positions show in the NE quadrant, ignoring the N-S-E-W indicators. The fix is to replace the "Ss" and "Ww" in the respective tests by just "S" and "W". I do not have the current source, but the faulty code in file ais.cpp still probably looks like this:

            token = tkz.GetNextToken();            //  hemisphere N or S
            if (token.Mid(1,1).Contains(_T("Ss")))  gpsg_lat = 0 - gpsg_lat;

            token = tkz.GetNextToken();            // hemisphere E or W
            if (token.Mid(1,1).Contains(_T("Ww")))  gpsg_lon = 0 - gpsg_lon;

Re: AIS SART

The documentation states that, once acknowledged, an AIS SART/MOB/EPIRB target behaves like a regular ship.
This is generally a good idea.

But

1. SART seems to be excluded from collision warnings etc. This is probably not correct, since a SART in active or testing mode is still a physical object, located at the advertised position. The testing mode just indicates it is not a Mayday, but still we do not want to run over it.

2. SART targets do not have their COG and SOG shown in the AIS Target Query panel, even if this data is correctly received and shown in the Target List and mouse rollover. I think The Target List and Target Query should show the same info, if available, with the Target Query showing the most complete data.

3. SART targets are subject to ageing, lasting somewhat longer than ships. This is OK for active ones, but the position data should be kept as long as the corresponding entries appear in the Target List.

4. In spite of acknowledging an AIS SART, reception of every message from it results in an alert again. In the specification ITU-R M.1371-4 I did not find, what is the transmissions interval, Resolution MSC.246(83) suggests that it may be 1 minute or less. We do not want an alert every minute... SART is a small, low power transmitter, so if received on a boat, it must be quite close, requiring immediate attention. It is unlikely that someone will forget about such an alert... Acknowledging once should be enough for the rest of the session.

Just some impressions from a test flight...

Attached are some NMEA scenarios, one with with SARTs, other with DSC and a Buddy.

[PjotrC]

One more thing: the Distress Targets (SART and DSC) should not be subject to filtering by distance in the Target List. Especially the DSC Distress can be very distant, and finding it quickly is the main purpose of this function.

Putting these targets on top of the list is an excellent thing, but they should be always visible there.

[PjotrC]

More testing, another issue...

I prepared a more realistic scenario, involving a (natural) case, where the DSC Distress is co-located with a regular AIS target, sharing not only the coordinates, but also the MMSI.

The icons are correctly positioned, with the Distress diamond on top, but in 3.3.1731 the $CDDSE sentence following the $CDDSC seems to be ignored, so the precision reported and shown on chart is just whole minutes. The fractionals are thus lost.

In 3.2.2 this is still handled correctly (albeit with the tracking zig-zag issue as mentioned in the first post).

The NMEA transcript of the scenario is attached. For correct timing, one should view it in VDR at 30% of the maximum replay speed.

In addition to some usual traffic, the scenario shows a fishing vessel 30 nm East of Gibraltar. She transmits AIS, then DSC Distress, which is repeated in 5 minutes, then no more transmissions from the ship.

A plane (own ship here) takes off from LXGB (Gibraltar), locates visually a liferaft in vicinity of the second Distress, and drops an AIS-EPIRB-enabled buoy, which then starts transmitting... Please note, that the EPIRB starts transmitting on being released, so there is quite some distance between the release point and its final position (ballistic flight), where it hits the water. Normally this path would be much shorter, but I am just learning how to build models (and how to fly), so I have used a readily available drop-tank feature (and too fast a plane), which I equipped with an AIS SART transmitter.

One can now experiment with various settings for OCPN AIS Ships panel.

I am still not quite sure why the collision warnings are not signalled, but I think this is because of the high speed of own ship (300 kts), so the CPA is always very distant,

[rgleason]

Very interesting. Don't have time to view it using Opencpn 3.3.18824 with VDR or NavMonPC, but with this kind of testing, there are likely to be some good operational suggestions and changes to the AIS, SAR, DSC tools. With these changes and the the search plugin Opencpn could become a really good search and rescue tool.

[PjotrC]

rgleason...

Thank you for looking at this. The tool seems very powerful indeed.

As an axample of how scenarios are described, I attach the abovementioned demo. If there are suggestions for what scenarios to model, I would be happy to help.

[bcn]

Pjotr,

for playing: the attached file is a data stream from a rescue simulation run in front of our port. Helimer.
Bit lengthy, but if you want to try...

Hubert

[bdbcat]

Folks...

I've been working on this a bit. Some updates in github now:

1. Correct DSC alert and tracking algorithm, works now.
2. Improve GPSGate Buddy formatting to include date of message and correct quadrant decode.

More to come later with improved SART processing.

Thanks for the test cases and reports.
Dave

[PjotrC]

It's sure great fun to test...

For example, this is how dropping the tanks-epirbs looks like...