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
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;
states that, once acknowledged, an AIS SART/MOB/EPIRB target behaves like a regular ship.
This is generally a good idea.
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.