keesverruijt / br24radar_pi Goto Github PK

The code is littered with constants, most of which can be converted to sizeof() etc.

A correct overlay and some pointers will clean up the code, and speed it up slightly.

Also, the values seem off in the dialog.

It should work, but hasn't been tested.

On OCPN 3.3.1713 & .1715
The command; topSizer->Show(controlBox); is not always working, only the topSizer frame is shown when returning from any of the other control "collections".
The "bug" seems to be at row 603 br24radarcontrol.cpp
if (!fromBox) {
fromBox = controlBox;
}
The "fromBox" is obvious sometimes not Null and is not "controlBox" when it should be. I haven't found where it's not set so meanwhile I solved it by this "work around":
if (fromBox != advancedBox) {
fromBox = controlBox;
}
I'll not call this a final solution so that's why I not made a push. I've a feeling you have better way to solve it? The controls switching in the topSizer frame is really smart and efficient coding. See my obeisance!
Håkan

On some Windows machines, but not all, is the preferences menu nor the right click menu not functional. See http://www.cruisersforum.com/forums/f134/opencpn-simrad-lowrance-radar-overlay-plugin-123167-5.html#post1586719 for more info.
Some tests:
I've tested some different BR24radar_pi versions against different OCPN versions. The conclusion will be that something happened with the BR24 code before 140408 that make it incompatible with some, but not all, Windows machines. The tests are performed on my XP-PC and I will not touch my W7-PC because it's working and that's the one I'm using for navigation.
I don't have the code for the old br24 in my repository so I can't compare them. Let's hope Kees will return. I'll make an issue on https://github.com/canboat/BR24radar_pi/issues
Test results:
BR24RADAR_pi OCPN
140402 3.3.1419 menu items - Yes Radar functional - Yes
140408 3.3.1606 menu items - Yes Radar functional - Yes
140622 3.3.1606 menu items - No Radar functional - No
140413 3.3.1713 menu items - No Radar functional - No
140622 3.3.1911 menu items - No Radar functional - No
140408 3.3.1911 menu items - Yes Radar functional - Yes
140622 3.3.1606 menu items - No Radar functional - No
Note: The version numbers in this test can be different from yours due to my local changes. All those are however based on the last official version before mine, and the other users don't have my versions.

When modifying guard zone start bearing or end bearing, the changes are are immediately displayed but not reflected in the monitored guard zone. When modifying these bearings again, the previous changes will be monitored and the most recent ones displayed.
Try following:
Start OCPN. Activate guard zone 1 Arc. Choose suitable inner and outer range. Make both start bearing and end bearing 0. Close OCPN and re-open. Modify end bearing to suitable value for alarm. No alarm is given. Only after a second change you will get the alarm of the first value.
This issue is caused by the fact that the GuardZoneAngles are not re-computed after modification.

Solution: (in GuardZoneControls.cpp)

@@ -287,6 +287,7 @@ void GuardZoneDialog::OnStart_Bearing_Value(wxCommandEvent &event)
     wxString temp = pStart_Bearing_Value->GetValue();

     temp.ToDouble(&pPlugIn->guardZones[pPlugIn->settings.guard_zone].start_bearing);
+   pPlugIn->ComputeGuardZoneAngles();
 }

 void GuardZoneDialog::OnEnd_Bearing_Value(wxCommandEvent &event)
@@ -294,6 +295,7 @@ void GuardZoneDialog::OnEnd_Bearing_Value(wxCommandEvent &event)
     wxString temp = pEnd_Bearing_Value->GetValue();

     temp.ToDouble(&pPlugIn->guardZones[pPlugIn->settings.guard_zone].end_bearing);
+   pPlugIn->ComputeGuardZoneAngles();
 }

 void GuardZoneDialog::OnClose(wxCloseEvent &event)

In Beta 2330 the two rows buttons are not working. I've only tested in Windows, XP & 7. Neither Linux nor Mac is tested.
Dave C has suggested a fix:
http://www.cruisersforum.com/forums/f134/opencpn-beta-version-3-3-2330-released-137342-8.html#post1691522

I've tried to solve it but the result is not the best. The centring of the second row was destroyed so there is probably a better way to do it.
This is my diff:

------------------------------ src/br24radar_pi.h ------------------------------
index 80944ca..ce42e28 100644
@@ -572,7 +572,7 @@ public:
int newValue
)
{

•    Create(parent, id, label, wxDefaultPosition, g_buttonSize, 0, wxDefaultValidator, label);
  

•    Create(parent, id, label + _T("\n"), wxDefaultPosition, g_buttonSize, 0, wxDefaultValidator, label);  
   minValue = 0;
   maxValue = 100;
   value = 0;
  

  @@ -618,7 +618,7 @@ public:
  br24radar_pi *ppi
  )
  {

•    Create(parent, id, label, wxDefaultPosition, g_buttonSize, 0, wxDefaultValidator, label);
  

•    Create(parent, id, label + _T("\n"), wxDefaultPosition, g_buttonSize, 0, wxDefaultValidator, label);
   minValue = 0;
   maxValue = 0;
   auto_range_index = 0;
  

--------------------------- src/br24radarcontrol.cpp ---------------------------

@@ -658,12 +658,12 @@ void BR24ControlsDialog::CreateControls()
bAdvanced->SetFont(g_font);

 // The GUARD ZONE 1 button

• bGuard1 = new wxButton(this, ID_ZONE1, _("Guard zone 1"), wxDefaultPosition, g_buttonSize, 0);
• bGuard1 = new wxButton(this, ID_ZONE1, _("Guard zone 1\n"), wxDefaultPosition, g_buttonSize, 0);
  controlBox->Add(bGuard1, 0, wxALIGN_CENTER_VERTICAL | wxALL, BORDER);
  bGuard1->SetFont(g_font);

// The GUARD ZONE 2 button

• bGuard2 = new wxButton(this, ID_ZONE2, _("Guard zone 2"), wxDefaultPosition, g_buttonSize, 0);
• bGuard2 = new wxButton(this, ID_ZONE2, _("Guard zone 2\n"), wxDefaultPosition, g_buttonSize, 0);
  controlBox->Add(bGuard2, 0, wxALIGN_CENTER_VERTICAL | wxALL, BORDER);
  bGuard2->SetFont(g_font);

My tablet has scaling set at 150% and it shows the right mouse menu item at the wrong size.

A slice of an older image remains but is misplaced and combined with the current image after changing range following zooming in or out.
The ghost image is realigned to north following compass updates but does not change otherwise. The current image is realigned to north and changes its content. The ghost image, overlaid on top of the current image, is realigned to north but does not change its content.
The ghost image may be about 70° of arc.
Depending on whether the ghost image appeared after zooming in or out, it is placed inward of the actual returns or outward. At one point I had the ghost image at the same distance than the current image, so, because the boat had moved, it was obscuring the actual returns just in the area of interest, making the radar image pretty useless.
If playing with zooming in and out, it is possible to get rid of the ghost image but it is hard. It never goes away by itself, however long I wait. When finally having gotten rid of it after playing with zoom for a while, after the next zoom it comes back.
This can be quickly reproduced.

If the emulator is not enabled then the warning dialog that something is wrong should be shown.

Instead of 2 items we could show four items:

[ ] Boat position
[ ] Heading
[ ] Radar presence
[ ] Radar image

Increase the number of turns a target is drawn before deletion. Now we check if a target echo is present the last three scanner turns before deletion. I've tried six turns with very good result especially for weak targets. Possible the number of turns could be adjustable.

Please consider to exclude the function when scanner range is changed, otherwise the redrawing will take longer time.

At the moment any packet coming in is assumed to be a complete radar packet. This might not be true.

The definition of: wxString GuardZoneNames[3] = { wxT("Off"), wxT("Arc"), wxT("Circle") }; is made to early to be covered by the localization function and are therefore not listed in the pot-file.

See Pavel's hint copied from a mail: (The referred "diff" is pasted further down)
//Mail copy
Hi Hakan...
Simple one... The way you are initializing the variable, the values are set before AddLocaleCatalog is called in br24radar_pi::Init, thus no localization can be performed.

Attached diff (against the github master) contains one of the possible solutions (There are sure more elegant ways to fix it, I just used the one meaning least reading of the code and using the brain). It also fixes the build on Linux (there is no implicit conversion from wxString to C string possible there)

Two more observations from a Linux machine:

• When I run OpenCPN with the plugin, I get an empty message box when the plugin gets initialized
• Once I open the plugin preferences, The window can't be closed

Cheers

Pavel

On 06/05/2014 04:02 PM, S/Y Momo wrote:

Hi Pavel

If you would have the time for a hint why the translation is not working for this I’ll be most grateful:

GuardZoneControls.cpp, row 66: wxString GuardZoneNames[3] = { _("Off"), _("Arc"), _("Circle") };
The pot file as well as the po files are well updated but the translations in the po file are not carried out during runtime. All other strings in the same file marked for translation are carried out.
//End mail copy

diff --git a/src/GuardZoneControls.cpp b/src/GuardZoneControls.cpp
index fe6f7ae..4491e41 100644
--- a/src/GuardZoneControls.cpp
+++ b/src/GuardZoneControls.cpp
@@ -63,8 +63,6 @@ enum { // process ID's
ID_ALARMZONES
};

-wxString GuardZoneNames[3] = { wxT("Off"), wxT("Arc"), wxT("Circle") };

bool outer_set;

//---------------------------------------------------------------------------------------
diff --git a/src/br24radar_pi.cpp b/src/br24radar_pi.cpp
index a6a76a9..28b172a 100644
--- a/src/br24radar_pi.cpp
+++ b/src/br24radar_pi.cpp
@@ -130,6 +130,8 @@ wxString RadarAlertAudioFile;
bool guard_bogey_confirmed = false;
wxDateTime alarm_sound_last;

+wxString GuardZoneNames[3];
+
// the class factories, used to create and destroy instances of the PlugIn

extern "C" DECL_EXP opencpn_plugin* create_pi(void *ppimgr)
@@ -360,6 +362,10 @@ int br24radar_pi::Init(void)
{
AddLocaleCatalog( _T("opencpn-br24radar_pi") );

• GuardZoneNames[0] = _("Off");
• GuardZoneNames[1] = _("Arc");
• GuardZoneNames[2] = _("Circle");

m_pControlDialog = NULL;

br_radar_state = RADAR_OFF;
diff --git a/src/br24radarcontrol.cpp b/src/br24radarcontrol.cpp
index 71694c0..a1bb961 100644
--- a/src/br24radarcontrol.cpp
+++ b/src/br24radarcontrol.cpp
@@ -245,9 +245,9 @@ void RadarControlButton::SetValue(int newValue)
wxString label;

if (names) {

•    label.Printf(wxT("%s\n%s"), firstLine, names[value]);
  

•    label.Printf(wxT("%s\n%s"), firstLine.c_str(), names[value].c_str());
  

  } else {

•    label.Printf(wxT("%s\n%d"), firstLine, value);
  

•    label.Printf(wxT("%s\n%d"), firstLine.c_str(), value);
  

  }

  this->SetLabel(label);
  @@ -260,7 +260,7 @@ void RadarControlButton::SetAuto()
  {
  wxString label;

• label.Printf(wxT("%s\nAUTO"), firstLine);

• label.Printf(wxT("%s\nAUTO"), firstLine.c_str());
  this->SetLabel(label);

isAuto = true;
@@ -286,13 +286,13 @@ int RadarRangeControlButton::SetValueInt(int newValue)
wxString rangeText = value < 0 ? wxT("?") : g_range_names[units][value];

if (pPlugIn->settings.auto_range_mode) {

•    label.Printf(wxT("%s\nAUTO (%s)"), firstLine, rangeText);
  

•    label.Printf(wxT("%s\nAUTO (%s)"), firstLine.c_str(), rangeText.c_str());
  

  }
  else{

•    label.Printf(wxT("%s\n%s"), firstLine, rangeText);
  

•    label.Printf(wxT("%s\n%s"), firstLine.c_str(), rangeText.c_str());
  

  }
  this->SetLabel(label);
• wxLogMessage(wxT("Range label '%s' auto=%d unit=%d max=%d new=%d val=%d"), rangeText, pPlugIn->settings.auto_range_mode, units, maxValue, newValue, value);
• wxLogMessage(wxT("Range label '%s' auto=%d unit=%d max=%d new=%d val=%d"), rangeText.c_str(), pPlugIn->settings.auto_range_mode, units, maxValue, newValue, value);

return meters;
}
@@ -495,10 +495,10 @@ void BR24ControlsDialog::UpdateGuardZoneState()
{
wxString label;

• label.Printf(wxT("Guard Zone 1\n%s"), GuardZoneNames[pPlugIn->guardZones[0].type]);
• label.Printf(wxT("Guard Zone 1\n%s"), GuardZoneNames[pPlugIn->guardZones[0].type].c_str());
  bGuard1->SetLabel(label);
• label.Printf(wxT("Guard Zone 2\n%s"), GuardZoneNames[pPlugIn->guardZones[1].type]);
• label.Printf(wxT("Guard Zone 2\n%s"), GuardZoneNames[pPlugIn->guardZones[1].type].c_str());
  bGuard2->SetLabel(label);
  }

Method to debug:
Create an arc zone and close the dialogue to activate the guard zone.
Await a bogey and the zone alarm. (Perform acknowledge or not) Inactivate the arc zone. Now the guard zone image disappears but the zone alarm will still be activated if a bogey is detected in the previous used arc.
On the first picture the alarm for the newly created guard zone is active. The second shows that the guard zone is set to OFF (Av) but the alarm has returned.
The bug is newly introduced. This has been working before.

The label of BR24ControlsDialog(); could contain the radar type when detected. Something like:
_("%s Radar"), br_radar_type;

Change the radar control dialog such that is much more compact, uses control concepts that are similar to the MFDs, and work well with both touch screen displays as well as mouse control with a scroll wheel.

Triangles of AIS targets are layered over the radar image. This makes it hard or impossible to verify the AIS target is also a radar contact - which is important, I think.
Given the fact that the radar image can be made partly transparent and the AIS triangles cannot, I propose to put the radar image as the topmost layer with chart lowest, then AIS, then radar.
Making AIS triangles partly transparent would start a competition in "translucentness" between radar blips and AIS triangles which likely results in both being invisible.

The range appears off by 4% (my best guess). With range calibration factor 1.0 the targets appear closer than they are. With 1.04 they appear correct.
I do not propose to hard-code this or any other correction factor into the plugin.
This issue is primarily a reminder that there is (appears to be) an issue with range that should eventually be resolved by finding the real cause, not by a quick and dirty fix.
I consider this an issue because the radar image should be true to the chart and/or reality.
Should a range calibration factor continue to be needed in the production version, I suggest to place it in the .ini file and not as a control in the GUI.

Range with 1.00 calibration factor:

Range with 1.04 calibration factor:

The 1.0 release .pkg file doesn't actually install anything.

In, Widows at least, double plugin icons can sometimes appear.
Debug method to create it:
1 Have the plugin activated.

2 In Tools>Plugins: Deactivate the BR24Radar_pi plugin. Use > Ok.
3 In Tools>Plugins: Activate the BR24Radar_pi plugin. Use > Ok.
Result:

The extra icon disappears at next OCPN restart.
There are actually two places in the code where an icon is created. The latter for some "security" reason which I can't verify or understand. Please investigate to next plugin version.
(Sorry for being late issuing this "old" note.)

Currently the radar interface must be present when OpenCPN starts. If you use an USB or WiFi the ethernet card may appear during the run.

1. 4G radar has a range setting of 1/8nm between 1/4nm and 200yds (which my NSS "calls" 100meter). OCPN does not have this. Is this a 4G specific setting?
2. Ranges below 1/4nm (or 1/8nm, see 1.) can be configured to be expressed in meters on Simrad NSS (setting "distance small" under Settings|Units having values of "ft", "m", "yd"). OCPN shows yards and cannot be changed. Using yds, OCPN has 200yds and 75yds below 1/4nm. NSS has 100m, 75m, 50m. So there is a mismatch in the unit but also a mismatch in the number of ranges.
   I suspect the control of ranges on the radar works with +1, -1 and not by requesting a specific range. As a result, there is confusion between OCPN and the NSS.

Though the pi comes up with autogain, the actual state of the radar is the state in which it was left at last usage. But pressing autogain does not bring the radar in autogain state. If for example the radar was in gain = 0, gain should be adjusted manually to +40 to get an image. Pressing autogain there after will show autogain, but it seems to me that the radar remains in the manually adjusted +40.
It might be better (but more complicated) to show in the buttons the register values of the radar variables. This means that after starting up and after each adjustment of a variable, the relevant radar register should be read out, and the resulting value displayed.

You cannot access it until the (modal) main settings dialog is closed.

I find that the transparency slider is adjusted poorly in that I get useful transparency only at the very high end of the slider and then I only get to choose from too low or too high.

Hi

Compiling today Aug 6 against current version of OpenCPN throws this error:

[ 67%] Building CXX object plugins/BR24radar_pi/CMakeFiles/br24radar_pi.dir/src/br24radar_pi.cpp.o
/BR24radar_pi/src/br24radar_pi.cpp: In function ‘double radar_distance(double, double, double, double, char)’:
/BR24radar_pi/src/br24radar_pi.cpp:124:91: error: ‘double radar_distance(double, double, double, double, char)’ was declared ‘extern’ and later ‘static’ [-fpermissive]
static double radar_distance(double lat1, double lon1, double lat2, double lon2, char unit)
^
In file included from /BR24radar_pi/src/br24radar_pi.cpp:58:0:
/BR24radar_pi/src/br24radar_pi.h:73:8: error: previous declaration of ‘double radar_distance(double, double, double, double, char)’ [-fpermissive]
double radar_distance(double lat1, double lon1, double lat2, double lon2, char unit);
^
make[2]: *** [plugins/BR24radar_pi/CMakeFiles/br24radar_pi.dir/src/br24radar_pi.cpp.o] Error 1
make[1]: *** [plugins/BR24radar_pi/CMakeFiles/br24radar_pi.dir/all] Error 2
make: *** [all] Error 2

Best [and thank you for working on the BR24 - really helpful plugin]

Peter

1. The guard zone system creates hundreds of sound play requests if there are many echoes in the guard zone.
2. The alarm does not reset when a bogey leaves and then re-enters, according to reports by testers. Not sure what the exact setup is.
3. There is no threshold for bogey size.

Specially after zooming echos from the previous zoom level tend to remain on the display in their original (before zoom) position. These echos can survive many zooms and also remain visible when gain is reduced to 0 (and all real echos disappear). Sometimes these echos disappear after some extra zooming in and out. They disappear when switching radar to standby, but often return when radar is activated again (even with gain = 0). Closing and restarting OCPN makes them disappear.
These persistent echos were also noticed without zooming but with a unstable (slowly turning) compass, making the radar image rotate. Screenshots: Lower one is after turning on, all OK. Upper image is after zooming, double echo's. Middle one shows persistent (false) echo with gain = 0, real echos are all hidden

And there is no way to access the close button either.

We ought to have a real separate radar display, without any charting underneath.

This allows side-by-side windows of pure radar and charting (possibly with radar overlay.) It also allows pure heads-up mode.

AIS on the radar only screen is nice to have, but not crucial. It should have nice range rings and heading information.

The transparency increases towards the edge of the radar image (it is more translucent farther away from the boat). I don't understand the reasoning behind this (if there is any) and propose to use the same transparency across the entire radar image.

The send socket is bound to port 6680, but on OS X we cannot then also create a multicast UDP socket that listens to port 6680 as well.

Haven't tested it but the controls apparently do not adjust to night mode.

In the "preferences" dialog, the red X in the top right corner does not work. It does work in the radar control dialog.

By embedding a guard zone alarm sound into the DLL we simplify delivery of the plugin.

I was recently navigating in a very heavy squall and found that there were no radar returns near my vessel The problem was most pronounced at ranges greater than 1nm and quite sever at 8nm. I made every possible settings adjustment, but the problem persisted. This issue is best described by the attached screen shots.

OpenCPN 3.3.1606
Kees Plugin v 0.40511

For 0.40513:
The rendering of the alarm zone limits are still not correct, they are 1.3 times to big.
If I in RenderAlarmZone() change the value to:
ppNM = v_scale_ppm * 1852.0 * 0.77 ; the drawn limits are correct. There would be a systematic error somewhere but I cant find it. It's strange since v_scale_ppm is used to render the blobs and they are correct???

The alert limits are still correct and nothing else found so far.
Håkan

I've been able to test the alert function for a couple of days now and it's not very reliable. The alert is far too sensitive. If I use a sector in front of the boat the alert is activated all the time without any visible "blobs". Probably by a small sea echo. I think we have to change the alert function to react only on a more stable blob.
Could the "m_scan_range[angle][0]" be used and only alert when we have received the same echo two or three times?

The Linux TCP stack needs an explicit IP address in order to add the multicast listen. Currently you have to edit opencpn.conf to set its IP address if there are multiple ethernet cards.

See attached photo where Guard Zones shading density could obscures targets. I would prefer guard zones be delineated by a simple light weight line and no shading.

David Kane
[email protected]
s/v LightSpeed
www.dksail.com

Testing with the 1.1 version of the plug-in:
Shared library object should install with 0644, currently installs with 0770
LC Message files may also need different permissions, currently as 0770. Linitian error output suggests 0755

See Lintian output:
W: br24radar_pi: hardening-no-relro usr/lib/opencpn/libbr24radar_pi.so
E: br24radar_pi: missing-dependency-on-libc needed by usr/lib/opencpn/libbr24radar_pi.so
E: br24radar_pi: changelog-file-missing-in-native-package
E: br24radar_pi: control-file-has-bad-permissions md5sums 0770 != 0644
E: br24radar_pi: no-copyright-file
E: br24radar_pi: description-starts-with-package-name
E: br24radar_pi: extended-description-is-empty
E: br24radar_pi: bad-package-name
E: br24radar_pi: maintainer-address-missing BR24 Radar Plugin authors
E: br24radar_pi: depends-on-essential-package-without-using-version depends: gzip
W: br24radar_pi: non-standard-dir-perm usr/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/lib/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/lib/opencpn/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/lib/opencpn/libbr24radar_pi.so 0770
W: br24radar_pi: non-standard-dir-perm usr/share/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/ca/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/ca/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/ca/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/cs/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/cs/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/cs/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/da/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/da/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/da/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/de/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/de/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/de/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/el/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/el/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/el/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/es/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/es/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/es/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/et/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/et/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/et/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/fi/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/fi/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/fi/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/fr/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/fr/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/fr/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/gl/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/gl/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/gl/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/hu/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/hu/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/hu/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/it/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/it/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/it/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/nb/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/nb/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/nb/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/nl/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/nl/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/nl/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/pl/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/pl/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/pl/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/pt/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/pt/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/pt/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/ru/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/ru/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/ru/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/sv/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/sv/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/sv/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/tr/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/tr/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/tr/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: non-standard-dir-perm usr/share/locale/zh/ 0770 != 0755
W: br24radar_pi: non-standard-dir-perm usr/share/locale/zh/LC_MESSAGES/ 0770 != 0755
W: br24radar_pi: executable-is-not-world-readable usr/share/locale/zh/LC_MESSAGES/opencpn-br24radar_pi.mo 0770
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/gl/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/tr/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/fr/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/et/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/el/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/cs/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/fi/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/zh/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/pt/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/nb/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/de/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/it/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/es/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/hu/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/ca/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/nl/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/da/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/ru/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/sv/LC_MESSAGES/opencpn-br24radar_pi.mo
W: br24radar_pi: executable-not-elf-or-script usr/share/locale/pl/LC_MESSAGES/opencpn-br24radar_pi.mo
E: br24radar_pi: shlib-with-executable-bit usr/lib/opencpn/libbr24radar_pi.so 0770

Hi!

It would be very usefull to have tagged releases, so the source for a specific version of th eplugin can be downloaded. Please add a release/tag for your released versions. This makes packaging a lot easier.

I'd like to package this plugin for Gentoo Linux and for that it requires a reliable specific download URL for the releases.

Thanks in advance!

Even when the radar range is in kilometers the values that must be set in the guard zone dialogs are always in nautical miles.

Two issuses:

First.
I think we need some kind of automatic alert audio file load into the config file. It could be done in the same way as for example the AIS Alert Audio file but I’m not sure that elegance is needed? As long the setting is present and saved in the config file I think it’s enough to instruct users how to change the file if desired.
I did it this way to half automate the config file launch to my own test machines running both Win and Linux.

diff --git a/src/br24radar_pi.cpp b/src/br24radar_pi.cpp
index ed1ac50..ea5884d 100644
--- a/src/br24radar_pi.cpp
+++ b/src/br24radar_pi.cpp
@@ -1686,8 +1686,15 @@ bool br24radar_pi::LoadConfig(void)
             }
             pConf->Read(wxT("Zone2ArcCirc"), &guardZones[1].type, 0);

            pConf->Read(wxT("RadarAlertAudioFile") , &RadarAlertAudioFile) ; 
+            if(RadarAlertAudioFile == wxEmptyString ) { //For first time launch, copy AIS Alert audio file
+                pConf->SetPath(wxT("/Settings/AIS"));
+                pConf->Read(wxT("AISAlertAudioFile"), &RadarAlertAudioFile);
+                if(RadarAlertAudioFile != wxEmptyString) {
+                    pConf->SetPath(wxT("/Plugins/BR24Radar"));
+                    pConf->Write(wxT("RadarAlertAudioFile"), RadarAlertAudioFile); 
+                }
+            }
             SaveConfig();
             return true;
         }

Second.
The Radar Alert Audio file playing is working fine in Windows.
But I can’t get it playing in Linux-Ubuntu 12.04 and this is not due the general Linux sound problem since the AIS Alert sound is working fine in the same OCPN instance, and the same audio file is used for the Radar Alert. My Linux experiences are though very limited so please make an own test if possible.

When a chart plotter is used as the master the radar picture reflects the commands sent by the chart plotter, but the radar controls on screen do not.

The window is a lot higher than needed. Below the "Close" button there is lots of grey area. On my 1024x786 screen I can't even see the lower margin.

OpenCPN 3.3.1606
BR24radar_pi.dll v 0.40510 for Microsoft Windows.
Navico 3G

Standalone mode should orient everything on screen relative to 'Heading Up'. Heading (HDG) = direction that the bow is pointing towards, not Course Over Ground (COG). So, ticking the box Options/ Dispaly/Course Up is of no help as it's based on COG not HDG.

Currently, In Standalone Radar mode the radar image appears to be shifted to heading up, however everything else stays the same, creating a mash up of reality. See examples below:

Mashup

Overlay illustrates actual heading with a dashed line.

Is a 3G/4G feature only.

In Linux Ubuntu:
1)
Screen position of the BR24RadarControl.
The radar control can be placed for example to the right on screen. But as soon I enter the Alarm Zone settings that box is centred. When returning to RadarControl that box is opened in the same centred position. If I move the radar control and later enter Zone settings the radar control is again centred.
Any Alarm Alert is also, correct, located in centre.

In Win there’s a nice radar type indication in the RadarControl box header. That label is not visible in my Ubuntu 12.04.

As said, both notes are valid for Linux, in Windows it's working as expected.