SAR Plugin

[capt.geoff]

My name is Geoff Sanders. I was in the Canadian Coast Guard for almost 36 years, and was a captain for about 25 of those years. I did aids to navigation tending and icebreaking, but my main area was search and rescue. I wanted to give you some of my thoughts on this plugin. As you note in the online manual, you will probably receive instructions on where and how to search from shore authorities, but you may need to do this by yourself.


Track Spacing - this is normally the same as Sweep Width, which can be obtained from tables. IAMSAR has tables for searching from a Merchant ship, with an elevated height of eye and a more stable motion. The USCG Addendum and Canadian Coast Guard manual have sweep widths for smaller vessels. They also have sweep widths for detection aids such as flares, signal mirrors, lifejacket lights, etc. If copyright permits, it would be very useful to have those figures available in your plugin.


The USCG has a “Guide for Coxswains” (original 2007, updated 2020) that can be found online. For a person in the water (PIW), the US and Canadian Coast Guard manuals have a small vessel (41’) sweep width of 0.3 Nautical Miles (NM) in 20 NM visibility and good weather. However the Guide for Coxswains always uses 0.1 NM. For a Sector search it uses a radius equal to sweep width, whereas their Addendum uses twice the sweep width (3.4.2.1 c)


A Youtube, done by SmarterEveryDay in January (find by Googling “Zig Zag Search”) goes with a US Coast Guard Fast Boat as they do a sector search exercise using the above sweep width. The video also explains why they do the search by time (as opposed to GPS) and has an animation showing the shape of the pattern over ground when current is present. Their search speed of six knots creates larger offsets than if you were searching at 10 knots, but shows the drift issue very clearly.


Drift - the USCG Addendum and Canadian Coast Guard CAMSAR manual both have formulas that can determine whether you should be drift compensating your search. They both use the same formulas, but the USCG has a better explanation of how it works (H.7.3.9). You can first test whether you need to take further steps by entering the formula with the “length” of the pattern perpendicular to the drift value. If the result is greater than 0.1, you change the orientation to have the smaller “width” perpendicular to the current and recalculate. It isn’t meant for a sector search, but if you substitute either a CS or PS with the same dimensions as the diameter of the sector (plus half a sweep width on either side), it will give a good approximation. (In fact a sector search for the same area would give a worse measurement, as that search takes longer, and so would distort the pattern even more.)


Your plugin should warn when the pattern dimensions, with drift factored in, exceeds the formula’s 0.1 threshold. Even in as little as one knot of drift (primarily current for a PIW), the formula will likely indicate that the pattern should be drift compensated.


If it does, users should switch to a timed search. As mentioned earlier in the thread, Weems and Plath sell a plastic calculator, which makes figuring out courses easier (although this is just a matter of adding 120 to each leg of a sector, or 90 to each leg of a expanding square or parallel search). Then it is a simple matter to determine how long you need to run on each leg using leg distance and search speed.


I’d be happy to go into detail on these points, but wanted to make this relatively short.

[Rasbats]

Geoff ...

Appreciate your input. A lot of help with this version of the plugin came from an Australian SAR coordinator. There was a lot of discussion on the merits of IAMSAR v USCG, which is why the two options for a sector search were included.

Coding time is always the problem. Drift does need factoring in to any update of the plugin. A warning to use a timed search could be added, based on the CG formula. The GPX courses could assist with this, avoiding the arithmetic.

Mike

[capt.geoff]

Hello Mike,


The USCG Supplement actually uses IAMSAR as its basis (as does the Canadian), but expands on a number of areas, such as Sweep Width for smaller vessels and leeway for more targets. For manual solutions the USCG Supplement details the differences in section H.2.2 “ Modifications to the IAMSAR Manual Method”.


As to why IAMSAR starts their sector search at the edge rather than the middle, I can only suppose they do that to start the search as quick as possible. But if they use the intersect from their position to datum, they would have to reorient the pattern based on their inbound course, or go to a point offset from their direct course, which will add to the time before they can start the search. And at the end of the pattern they then have to either re-cover that first leg or do part of the outside leg of the 30 degree offset second search before heading back to the centre.


On the YouTube, the crew talk about sending current info ashore at the end of the search, to update the shore computer model. Doing the search by time enables an accurate search before you know the actual drift. The current models held ashore have improved, but they are still mainly based on predictive data (unless they have local current meter data available). Even a small current error, particularly when looking for a person in the water (with the tight track spacing), will likely result in a fail. A complication in tidal waters is that the current is always changing, and can have different vectors in close proximity when searching around islands and reefs. Working with a data marker buoy is really the only way to get accuracy on this small a scale.


As often we won’t know the actual current until after the search, I can’t see a way to write something that could make a GPX track conform to current.


Back in the 90s, I wrote a couple of programs for Canadian Coast Guard. The search and rescue one started out as a way for ships to record SAR incident details, rather than trying to type the information into a paper form. The data is emailed to RCC in zip files where it is imported into their copy of the program. Along with reviewing narrative comments, they could filter incidents by critical factors, vessel type, activity, etc.


Over the years, I added a number of other modules, including timed searches for sector and expanding square searches. The program calculates courses and steaming time, warning of when your next alteration was due, etc. It never became a National program, as that would require it to be Bilingual, and my French is terrible. However the program is Nationally Approved, and can be installed by any CCG user.


I support the program, and often got the same queries on using it from new users; setup questions, revising incidents that have been sent to RCC, etc. I made a number of short video clips to answer these questions, and in the end I created some longer videos for new users and those new to Search and Rescue. The introduction to SAR video covers drift issues, based on a separate computer model I built. If you are interested, the video can be found in Google Drive (link below). Note that the video has not been updated to show the newer leeway factors.


Geoff


https://drive.google.com/file/d/1ZQL...usp=share_link

[Rasbats]

sar_pi has been updated for OpenCPN 5.7.1-beta/5.8.

Now in the master catalog.

Please test and post comments here.

Still needs work.

Mike

[Gilletarom]

Originally Posted by Rasbats

sar_pi has been updated for OpenCPN 5.7.1-beta/5.8.

Now in the master catalog.

Please test and post comments here.

Still needs work.

Mike

Hello Mike,

Test with version 5.7.1 + d9d2f22 (uploaded on the cloudsmith).But this version of O 5.7.1 is not the "official" version of O 5.7.1.

That said, OpenCPN crashes. In particular, before this crash, SAR was asking me for a date and I couldn't find any way to enter that date. I took into account the position of the boat and it is by validating this that the crash took place.

[Gilletarom]

Originally Posted by Gilletarom

Hello Mike,

Test with version 5.7.1 + d9d2f22 (uploaded on the cloudsmith).But this version of O 5.7.1 is not the "official" version of O 5.7.1.

That said, OpenCPN crashes. In particular, before this crash, SAR was asking me for a date and I couldn't find any way to enter that date. I took into account the position of the boat and it is by validating this that the crash took place.

New test without crash. Here are successive screenshots (with the first tab).
I also did a test by entering numerical data which went well.

[Rasbats]

sar_pi UPDATED

This plugin has now been updated to work with OpenCPN 5.8.4 and the upcoming 5.10.0.

Input is now validated to prevent input of non-numeric characters. Some minor bugs were fixed.

The plugin uses TinyXML2 instead of TinyXML. The latter is no longer maintained.

A .pot file has been uploaded to Crowdin for translation. Only 4 changes seen. Help with translation would be appreciated.

Not yet in the catalog but Alpha packages for testing are here:

https://cloudsmith.io/~opencpn/repos...ckages/?page=1

Mike

[bcn]

Mike...


can you please add context or some explanation for the items on the screen shot? Datum? CSP? CPU in that context?


The other entries are clear for translation and are done.


Thanks


Hubert

[Gilletarom]

Originally Posted by Rasbats

sar_pi UPDATED

This plugin has now been updated to work with OpenCPN 5.8.4 and the upcoming 5.10.0.

Input is now validated to prevent input of non-numeric characters. Some minor bugs were fixed.

The plugin uses TinyXML2 instead of TinyXML. The latter is no longer maintained.

A .pot file has been uploaded to Crowdin for translation. Only 4 changes seen. Help with translation would be appreciated.

Not yet in the catalog but Alpha packages for testing are here:

https://cloudsmith.io/~opencpn/repos...ckages/?page=1

Mike

OIL RIG, although present and translated in the current crowdin, is not translated in practice with your new version of the plugin.( With OpenCPN 5.9.0 + 5316bc4 version)

[Rasbats]

G ...

Have not yet compiled with the new translations. OIL RIG should then appear correctly.

Bcn ...

Perhaps ...

"Casualty Location (Datum)"
"Commence Search Point(CSP)"

Which makes: Casualty Location (Datum)/Commence Search Point(CSP).
The images in the plugin clarify the meanings a little.

Mike

[bcn]

Mike,


thanks - the last one: "CPU saving settings" ?


Hubert

[Rasbats]

bcn ...
"CPU saving settings" = "Settings for Capture"

Don't know where CPU came from??? These settings do not seem to be applied. bug???

Mike

[Gilletarom]

Originally Posted by Rasbats

bcn ...
"CPU saving settings" = "Settings for Capture"

Don't know where CPU came from??? These settings do not seem to be applied. bug???

Mike

The first translation of this item in french dates from 10 years ago, and it was Pavel who did it. I have never modified its translation which is "Sauvegarde des réglages", that is to say "Save settings". So, unrelated to the PC's CPU

[Rasbats]

v4.2.0-Alpha is now in Cloudsmith:
https://cloudsmith.io/~opencpn/repos...lpha/packages/

Preferences has been removed to avoid confusion. These options were not used in recent versions of the plugin.

To avoid having to import the .gpx to display the pattern there is now an option to chart the route at the same time as creating the .gpx. The API does not allow a choice of colour for the route so they are shown in blue. Importing the .gpx would retain the colour.

There may be interest in providing an RTZ file for use in an ECDIS. For this reason an option for creating these files is now provided. The .gpx is saved as a backup during this process. The RTZ files have been validated and should have the minimum detail necessary for use with an ECDIS.

Mike

[Gilletarom]

Originally Posted by Rasbats

v4.2.0-Alpha is now in Cloudsmith:
https://cloudsmith.io/~opencpn/repos...lpha/packages/

Preferences has been removed to avoid confusion. These options were not used in recent versions of the plugin.

To avoid having to import the .gpx to display the pattern there is now an option to chart the route at the same time as creating the .gpx. The API does not allow a choice of colour for the route so they are shown in blue. Importing the .gpx would retain the colour.

There may be interest in providing an RTZ file for use in an ECDIS. For this reason an option for creating these files is now provided. The .gpx is saved as a backup during this process. The RTZ files have been validated and should have the minimum detail necessary for use with an ECDIS.

Mike

Mike,

Quick test.
1° : Crowdin updated
2° : For now, the item "OIL RIG" stay in french.