Getting Lowrance/Navico Radar plugin to work

[jfhspike]

I can't seem to make the 3G radar plugin work. My setup is this:

Radar <== ethernet ==> Netgear FS105 Switch <== ethernet ==> windows 10 laptop

I know that the router is likely to be overwhelmed by the traffic, but this is a first draft -- I want to see that the radar dome itself is working at least.

When I connect power (and B+ to the yellow wire), the green light on the radar connection at the switch lights up; it blinks for a moment or two, then goes steady, and then flickers a bit once every second or so; the green light for the laptop flickers in sync with it, suggesting that some basic handshaking-like info is getting from the radar to the laptop, or at least is leaving the internet switch.

On the laptop, OpenCPN reports that it's using the Ethernet card 169.254.68.248, and greyed out beneath that is "Radar IP: 169.254.82.89".

I've tried

% ping 169.254.82.89

and gotten 1 or 2ms turnaround time with no losses; that suggests to me that the radar is functioning.

But up at the top of the Radar dialog is the dreaded "Cannot switch radar on as it is not connected or off."

My dream was to have a connection like this:

Radar <== ethernet ==> Netgear wireless router <...> Macbook with wifi enabled

but for now, I'd be happy with anything at all. Any suggestions out there?

[By the way: Lowrance 3G radar]

[Douwe Fokkema]

This is something that just should work. Can't see why it doesn't. Further it is hard to debug anything on the old br24_radar_pi as I am busy on the new one, using an adapted development environment (as required for OCPN 4.99 / 5). I suggest:
- first try to directly connect the radar to the Ethernet port of the computer. Should not make any difference, but just try.


Other step could be to use our new radar_pi plugin. This one is made to function with several different radars, works fine now with 3G and 4G. In the preferences screen you should select the radar(s) used, that is 3G in your case. I still have this radar_pi.dll for the current versions of OpenCPN (4.8). I attach it with this post. Remove the .pdf from the filename and copy it to the plugins directory of your OpenCPN installation. Don't forget to enable it in the Tools/plugins menu of OCPN and disable the previous br24radar_pi.

[jfhspike]

Thanks, Douwe.

It turns out that the magic missing piece was....OpenGL. You have to have openGL turned on to make the thing work. The instructions say that your computer has to have OpenGL, and that it has to be enabled, and the dialog shows when it's NOT enabled, but by the time I got there, I'd forgotten that it was required, and just thought "Oh, that shows me which mode it'll use for rendering" rather than "that's an option which, if I don't opt for it, breaks everything."

You folks have done a great job with this, but I'd like to recommend two possible changes:

(1) If I were writing that dialog, it'd say

[] Accelerated Graphics (OpenGL) [must be checked!]

and I might even add a button to the right to pop up the relevant part of the Tools...Display...Advanced menu where the user can actually do the checking.

(2) Also, the sentence at the top of the dialog is

"Cannot switch radar on as it is not connected or off"

which is ambiguous: the "not" may or may not apply to the word "off". I'd rewrite as something like

"Cannot switch radar on as it is either not connected or is not off."

(if that's actually what you mean!)

Thanks again for the work you've done on this, and for the quick response to my clueless question. As a computer scientist, I should know to RTFM.

[merrimac]

Your suggestions are interesting, but there is a trade off between how much time and effort we can put into this. Also plugins cannot easily open a dialog in the main O code, there is no API support for that.


The wording has already changed in the new plugin, so that is already taken care of.


What we could maybe do is just set the OpenGL flag in the OpenCPN settings, and if necessary tell the user to restart OpenCPN.


Here is a screenshot of the new plugin with 3 radars (that I don't have) enabled. We cannot make the texts black, as then you are allowed to click in the check box, and we want this to be read only.


One thing we could do is do away with the check boxes completely and change it to 'plain text' fields. This would then allow us to say


"Please enable OpenGL mode"
"OpenGL mode is enabled"



and



"Heading OK (true heading received)"
"Heading OK (magnetic heading received and variation available)"
"Heading not OK (no heading source detected)"
"Heading not OK (magnetic heading received but no variation available)"

[jfhspike]

Thanks, Merrimac.

I had guessed that the "open the dialog in the parent program" thing wasn't really an option...but it would make a better interface if it were.

The other edits all look like good ideas to me. In general, I'd say that you shouldn't have "options" that aren't options, and that informational or status things should be distinguished (when possible) from their descriptors. So

Status: Scanning

is better than

Scanning

because it's clear that the word after the colon can change. The status reports for the three radars in the new dialog does this nicely.

====

This displayed dialog is great as far as information content goes, but the bottom bit is bad from a UI point of view: I believe that you shouldn't have check-boxes that a user cannot check. Better would be either your four-sentence alternative list, or something like this:

Radar overlay requires either 1 and 2, or 3 (with 4 as an option).

1. Boat position X
2. True heading C
3. Magnetic heading C
4. Variation X

where the "X" and "C" are red "X" or green check-marks, not inside little squares that give the appearance of being check-able.

======
I totally understand that making things like this right sucks up time and effort that you'd like to devote elsewhere, and offer my suggestions merely as suggestions; if you want to spend your time/effort on other stuff, I certainly have no reason to complain!

[rgleason]

Added an FAQ for enable opengl