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:
Code:
token = tkz.GetNextToken(); // hemisphere N or S
if (token.Mid(1,1).Contains(_T("Ss"))) gpsg_lat = 0 - gpsg_lat;
Code:
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.