OpenCPN SIMRAD/LOWRANCE Radar Overlay PlugIn

[Hakan]

Dave777...
I suppose you've a heading line in OCPN? In the case you describe that line should also then be false.
BR24 radar picture is an overlay on the chart and it's directed by the boat's true heading, not the chart.
What about your setting for shewed charts in OCPN, is "Show shewed raster charts as north-up" in <Tools-display-advanced> checked?
Håkan

[merrimac]

Originally Posted by dave777

I can confirm that there seems to be a bug with Navico radar plug-in: skewed charts display "un-skewed" radar return data.

Please head to https://github.com/canboat/BR24radar_pi/issues and log this as an issue.

This could be a safety issue for people who don't normally use a skewed chart if a skewed chart is swapped in on a voyage, the return of another ship would be shifted.

Yeah, right. That's why this is not an ECDIS and there are warnings all over the place.

O (+ the plugin) are certainly fun to develop and quite often very useful, but if you use it as your only means of navigation, certainly with skewed (and quite likely, outdated) charts, then maybe you deserve a Darwin award?

[NahanniV]

I'm trying to install the latest br24radar_pi code on a laptop running Ubuntu 14.04.1 LTS. and OpenCPN 4.0

But OpenCPN keeps crashing.

I don't have a Radar connected at the moment.

The plugin compiled with one minor warning.

I enable the plugin in OpenCPN config menu.
Then I start the VDR plugin to supply heading and position.
OpenCPN crashes approximately when HDT is received for the second time.

VDR data:

$AIHDT,045.0,T
$GPGGA,174708.000,4311.8478,N,07934.4941,W,1,07,1.5,82.4,M,-34.7,M,,0000*56
$GPGSA,M,3,26,15,29,13,21,05,18,,,,,,3.6,1.5,3.3*39
$GPRMC,174708.000,A,4311.8478,N,07934.4941,W,0.00,045.00,151214,,,A*7B

Crash:

*** opencpn (wxWidgets 2.8.12) crashed ***, see backtrace!
0x83577f6 in wxCrashPrint::Report() at ??:?
0x8142324 in MyApp::OnFatalException() at ??:?
0xb76679f3 in wxFatalSignalHandler at ??:0
0xb76f7400 in [0xb76f7400] at ??:0
0xb7629727 in wxStringBase::operator=(wxStringBase const&) at ??:0
0x8162062 in wxString::operator=(wxString const&) at ??:?
0x836e544 in NMEA0183::PreParse() at ??:?
0xb2feb134 in NMEA0183::Parse() at ??:0
0xb2fdcbbe in br24radar_pi::SetNMEASentence(wxString&) at ??:0
0x82e5032 in PlugInManager::SendNMEASentenceToAllPlugIns(wxString const&) at ??:?
0x8323868 in Multiplexer::OnEvtStream(OCPN_DataStreamEvent&) at ??:?
0xb75d3df6 in wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const at ??:0
0xb76646ae in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) at ??:0
0xb7664a49 in wxEvtHandler::SearchDynamicEventTable(wxEvent&) at ??:0
0xb7664b0b in wxEvtHandler::ProcessEvent(wxEvent&) at ??:0
0xb76645f8 in wxEvtHandler::ProcessPendingEvents() at ??:0
0xb75d41a9 in wxAppConsole::ProcessPendingEvents() at ??:0
0xb740b340 in wxAppBase::ProcessIdle() at ??:0
0xb7376022 in  at ??:0
0xb6579c50 in  at ??:0
0xb657d0a7 in g_main_context_dispatch at ??:0
0xb657d468 in  at ??:0
0xb657d76b in g_main_loop_run at ??:0
0xb68df450 in gtk_main at ??:0
0xb738c17e in wxEventLoop::Run() at ??:0
0xb740b14f in wxAppBase::MainLoop() at ??:0
0xb740ac4f in wxAppBase::OnRun() at ??:0
0xb7608d16 in wxEntry(int&, wchar_t**) at ??:0
0xb7608db6 in wxEntry(int&, char**) at ??:0
0x813d0c4 in main at ??:?
Aborted

I tried running the VDR plugin without the radar plugin enaled and it did not crash until just after I enabled the RADAR plugin.

I also ran the radar plugin without the vdr and it did not crash.
I could click the radar icon and get the first screen and it did not crash until the vdr was started.

[merrimac]

Originally Posted by NahanniV

I'm trying to install the latest br24radar_pi code on a laptop running Ubuntu 14.04.1 LTS. and OpenCPN 4.0

But OpenCPN keeps crashing.

I don't have a Radar connected at the moment.

The plugin compiled with one minor warning.

I enable the plugin in OpenCPN config menu.
Then I start the VDR plugin to supply heading and position.
OpenCPN crashes approximately when HDT is received for the second time.

Better to report this on Github. It is more conducive to tracking progress. See https://github.com/canboat/BR24radar_pi/issues/69

[merrimac]

Originally Posted by dave777

Thinking out loud: the chart I use 90% of the time is "skewed", a red slash displayed on it. Does the plug in account for using a skewed chart?

I've created https://github.com/canboat/BR24radar_pi/issues/70 for your issue. Any followup on github.

[NahanniV]

Originally Posted by merrimac

Better to report this on Github. It is more conducive to tracking progress. See https://github.com/canboat/BR24radar_pi/issues/69

OK, thought I would try here first incase it was just a simple error on my part.

Thanks,
JM.

[dave777]

Originally Posted by Hakan

Dave777...
I suppose you've a heading line in OCPN? In the case you describe that line should also then be false.
BR24 radar picture is an overlay on the chart and it's directed by the boat's true heading, not the chart.
What about your setting for shewed charts in OCPN, is "Show shewed raster charts as north-up" in <Tools-display-advanced> checked?
Håkan

Yes, the heading line works with or without the radar plug in. I've not noticed that the heading line is wrong.

I understand that heading is used to overlay a radar on the chart. However, if the chart is skewed then the radar image needs to be skewed as well.

I'll have to check the settings after I get back on the boat, but I believe its set up so that all charts are always shown North Up.

[dave777]

Originally Posted by merrimac

I've created https://github.com/canboat/BR24radar_pi/issues/70 for your issue. Any followup on github.

Thanks merrimac, I've just joined there and will do what I can in testing to help the developers.

[merrimac]

Binary releases have been made for v1.2 beta, with all of Douwes update fixes and Håkans timed transmit changes.

Download them at opencpn-navico-radar-plugin.github.io

It also contains a tentative fix for the skewing issue: https://github.com/canboat/BR24radar_pi/issues/70

Please test. Any issues or bugs should be reported on https://github.com/canboat/BR24radar_pi/issues .

[Neptune's Gear]

Windows 7. OCPN 4.0, radar plugin 1.1.
My install is getting more complex. My PC has 3 NICs, one is a Zyxel and works as an boat intranet access point, one is a long range wifi antenna shared for internet access, and the final one is is built in Ethernet to which the radar is connected.
If the shared connection to the long range antenna and Zyxel is working, (like not disabled!) then the radar does not work. Sorry I'm not strong on UDP, but if it was all IP I'd say it's a routing issue.
Can I tell the plugin that the radar is on a specific interface? I see that the opencpn.ini has interface=0.0.0.0 - should I allocate the radar nic an IP address, or will that have no effect on UDP broadcasts?
Oh yeah, OCPN also broadcasts NMEA data over the Zyxel NIC, for tablets etc... So can I tell OCPN which NIC to send this on as well?
Any suggestions?
Matt

[muttnik]

Originally Posted by Neptune's Gear

Can I tell the plugin that the radar is on a specific interface? I see that the opencpn.ini has interface=0.0.0.0 - should I allocate the radar nic an IP address, or will that have no effect on UDP broadcasts?
Oh yeah, OCPN also broadcasts NMEA data over the Zyxel NIC, for tablets etc... So can I tell OCPN which NIC to send this on as well?
Any suggestions?

The guys who wrote this will be able to tell you authoritatively but I just took a look at an old version of the code (sorry, on super-restricted download austerity as month end approaches...). Actually this is all UDP multicast rather than broadcast. Have a go at setting Interface=x.x.x.x where x.x.x.x is the IPv4 address of the wired interface your radar should be contactable on. The plugin will the add membership of the appropriate multicast group on that interface.

Unfortunately you then have a second issue which is routing commands the plugin sends to your radar. Specifying which interface is used for multicast output bypassing the routing table is all a bit platform specific and wxWidgets is a bit of a blunt tool so it's best just to tell the OS to sort it out. You need to add a route to 236.6.7.10 (or possibly the whole range of multicast addresses if that's easier/more appropriate) via your wired interface. I can help you with that if you're running Linux (or possibly OS X) but I'm not so hot with Windows.

EDIT...Actually thinking about it, just sticking in a route to 236.6.7.0/24 or some range which encompasses that via the wired interface might sort everything out without touching the Interface setting...

For the final question if you're *broadcasting* data you just need to specify the broadcast address of the NIC you want to send it out and the system's routing table will sort it out for you.

...with disclaimer that I have an old version of the plugin code here, I don't have radar myself and my familiarity with is is only cursory so I could be completely wrong but it might be worth a try until someone who knows what they're talking about comes along...

[NahanniV]

Latest Plugin is working very well!

I don't have to use any downsampling now, and the faster updates are impressive. I am very happy with the plugin and the 4G RADAR so far.

One small problem: I had not intended to use the RI-10 initially, but then Douwe added the heading functionality and I changed my mind.
I added the RI-10 today, but could not get it to work.

When I connect the ethernet cable from the scanner directly to my laptop I get a message "wired ethernet connected" and it works, but when connected through the RI-10 I get no message and the plugin never sees the radar.

I think it's a problem with the cable I made from the Navico Ethernet cable. First I tried strait through same as the cable from the scanner, then with the other half of the cable I tried to make a crossover, neither worked.

Any Ideas ?

Cheers,
JM.

[RobbieW]

Originally Posted by NahanniV

...
One small problem: I had not intended to use the RI-10 initially, but then Douwe added the heading functionality and I changed my mind.
I added the RI-10 today, but could not get it to work.

When I connect the ethernet cable from the scanner directly to my laptop I get a message "wired ethernet connected" and it works, but when connected through the RI-10 I get no message and the plugin never sees the radar.

I think it's a problem with the cable I made from the Navico Ethernet cable. First I tried strait through same as the cable from the scanner, then with the other half of the cable I tried to make a crossover, neither worked.
...

JM, I have an RI-10 as I also have a Simrad MFD. I have teed the radar ethernet connection before the RI-10 using a powered ethernet hub, one leg goes to the RI-10 the other to my onboard router and then on to the laptop.

From my experimenting, plugging an HDM/HDT signal into the RI-10 will not pass that through to the radar head and thence to OCPN. I believe the Simrad set up uses two levels of data, the RI-10 doesnt seem to mix HDM/HDT with the ethernet data out to the scanner and then back to whatever is recieving the data - that seems to be done by the MFD. I'm now feeding OCPN with HDM/HDT data direct which enables the plugin to operate. HDG data alone is not sufficient to switch on the plugin so far as I've seen.

[NahanniV]

I didn't have internet at the boat today, think I found the answer:

Yacht Electronics: Lowrance yellow Ethernet cabling

I think I was confused by the non standard colors. Will try again tomorrow.

Cheers,
JM.

[NahanniV]

Originally Posted by RobbieW

JM, I have an RI-10 as I also have a Simrad MFD. I have teed the radar ethernet connection before the RI-10 using a powered ethernet hub, one leg goes to the RI-10 the other to my onboard router and then on to the laptop.

From my experimenting, plugging an HDM/HDT signal into the RI-10 will not pass that through to the radar head and thence to OCPN. I believe the Simrad set up uses two levels of data, the RI-10 doesnt seem to mix HDM/HDT with the ethernet data out to the scanner and then back to whatever is recieving the data - that seems to be done by the MFD. I'm now feeding OCPN with HDM/HDT data direct which enables the plugin to operate. HDG data alone is not sufficient to switch on the plugin so far as I've seen.

Did you try it since Douwe implemented reading the heading data from the scan packets ?

My understanding is that the RI-10 reads the heading data from NMEA2000(Simnet) and sends it to the scanner over the Ethernet cable but not as Ethernet data (on a normally unused pair), the scanner receives it and adds the heading data to each scan packet.