Garmin xHD Radar Overlay

[Hakan]

Hans..
A possible tip. Have you checked in BR24radar_pi how Kees is handling this. I can't say I've the knowledge to follow the code but BR24/3G/4G also use different ports.
See: https://github.com/canboat/BR24radar...24radar_pi.cpp start around row: 2241.
Håkan

[hasse_A]

Holy Moses!

I now seem to be getting radar scanner return data .
The interpretation is off course not correct since I have not
rayed out the pixels correct but something is getting through.

/Hans

[hasse_A]

The Display is now starting to resemble something that could be useful.

It looks very similar to what I see on the 721 display.

/Hans

[jonasaberg]

Well done!

[hasse_A]

Hi again!

I have created a GitHub repository here :
http://github.com/trudK45/gxradar_pi
if anyone is interested.

I did commit to get the work done up until now into a safe spot and as
a preparation for the future.

There are issues with this code.
1) It does not seem to work as released, but do work in VS2010.
2) The IP address of the interface on the PC is hard coded to 172.16.1.1
Haven't got it to work with INADDR_ANY yet. Some clue anyone ?
3) CMakelists.txt line 164; The LIB is linked from root.
This is as in Dave's repo and has been confirmed to be a bug by Pavel.
I don't know how to fix this. At least not yet.

I do not have the possibility at the moment to test the code in real action
as my boat is on the hard until May. It would be nice if
someone could have a try at it earlier than that. Not just yet though.
There are the issues 1 and 2 mentioned above that has to be fixed first.

/Hans

[hasse_A]

I am having trouble receiving status messages with the code in the repository.
It would be a great help if some one with better knowledge of network programming had a look at the code.

The code can be downloaded here:
http://github.com/trudK45/gxradar_pi

I am trying to fetch packets on port 50100.
In gxradar.cpp

Line 762
Line 3082
There about.


/Hans

[hasse_A]

Here's one for you!

Lately I have had trouble getting the scanner packets detected by the plugin. Started to investigate what's going on.

On the computer hooked up to the scanner there are 2 interfaces.
One named Internet and the other Radar Scanner.

It looks like the multicast group is bound to the wrong interface despite the fact that the Radar Scanner interface is on top.
I.e. multicast ip 239.254.2.0 is on the Internet interface and not the Radar Scanner i/f.

Does anyone understand this ?
Se attachment.

/Hans

[hasse_A]

Originally Posted by hasse_A

It looks like the multicast group is bound to the wrong interface despite the fact that the Radar Scanner interface is on top.
I.e. multicast ip 239.254.2.0 is on the Internet interface and not the Radar
/Hans

Problem solved :
It looks like it does not mater if the Ethernet i/f for the Radar Scanner is on top of the list.
I had to disable Automatic metric and set it manually to a low value (10).

Network and Internet -> Network Connections -> "Network Card" Properties -> Internet Protocol IPV4 -> Advanced.. -> IP Settings.
Unclick Automatic metric and set value = 10.

This should be applicable for the gradar_pi as well.

/Hans

[merrimac]

Hi Hasse,

If you want your code to be compatible with Linux and OS X, you should not listen on the ANY (127.0.0.1) address for multicast data, as those platforms don't support that. You have to use the IP address that is assigned to a particular card instead.

I just looked into what Dave does in the GRadar plugin does, which I think goes like:match addresses with the "well known" IP address of the scanner. If there is no ethernet card that has an address on the same network, it gives up.

In the BR24radar_pi we don't have that luxury since the Navico radar can have any IP address. So we solve the problem in a different way: the code just keeps scanning all ethernet cards in turn to see if it sees any data from the radar. If so, it remains bound to that ethernet device and all other threads also pick this up. Thus, there is nothing for users to configure -- it just works.

[hasse_A]

merrimac.....

I am not quite sure what you mean.
On line 3290 (gxradar_pi) I have "hard coded" 172.16.1.1 to the ethernet card for the radar scanner.
As described in my previous post I did not receive the scanner packets since
the multicast listened to the other of the 2 ethernet cards.
I fixed this as described by setting the metric priority to 10.
I was attempting to update the code and change line 3290 from
mreq.imr_interface.s_addr = inet_addr("172.16.1.1");
to
mreq.imr_interface.s_addr= INADDR_ANY;
which then will be the same as in Dave's gradar.

Is this what you are talking about ?

Now, if there is a better way I am willing to consider making a change.

What range of IP's do you test ?

/Hans

[oldmonk]

- nothing -

[oldmonk]

What is the latest news on this plugin? It looks promising to get basic radar functionality working with xhd scanners? Also do you think the new xhd2-scanners will require yet again more work on the plugin?

Just curious because I am just considering buying a new radar and new xhd2 open arrays seem pretty interesting - but maybe should just get a xhd radome to be sure.

[hasse_A]

Originally Posted by oldmonk

What is the latest news on this plugin?

At the moment nothing is happening with the code. As I mentioned earlier in the thread, I have no means to test the code live yet.
This will happen some time late April or beginning of May as the boat is still on the hard until then.
It is snowing outside right now.

Meantime there should be done some clean up of the code.
I am not particular fond of having >3500 lines of code in one file.
This is a legacy of gradar_pi and it has gotten worse by all the extra packet types for the xHD scanner.

I have not made a release and asked the opencpn gurus to make it official since it is not tested.

However i could push the plugin to GitHub or attach it here if someone is willing to test it.
I have built a release and plugged it into the latest OpenCPN release 4.0.0 and it appears to be ok.
It finds the scanner and all menus look and behave as they should as far as I can tell.

We are in the process of leaving home and go for blue water cruising so I may have trouble finding the time to do any extensive support before we leave in May.
But then I will have every incentive to get the plugin up to good standard as I will be using it myself.
Just a little warning.

/Hans

[oldmonk]

Originally Posted by hasse_A

Meantime there should be done some clean up of the code.
I am not particular fond of having >3500 lines of code in one file.
This is a legacy of gradar_pi and it has gotten worse by all the extra packet types for the xHD scanner.

Yes, it could use some modularity for sure - I took a peak into code you mentioned and it is indeed bit hard to follow due to sheer size. Base plugin for radar handling generic stuff and the smaller "driver" for each scanner subtype perhaps? I know, a big task to split it.

But you aim to have a new plugin for xhd or merged with old "legacy" garmin plugin? I would think new one would make more sense, but I am not familiar with the details so just a hunch.

[hasse_A]

Originally Posted by oldmonk

But you aim to have a new plugin for xhd or merged with old "legacy" garmin plugin? I would think new one would make more sense, but I am not familiar with the details so just a hunch.

I will for sure have a new plugin. The plugin for the xHD I belive is working today but structuring the code better will be a big help in the future.
I have been though the code while I was reverse engineering the xHD protocol so
I manage to find my way but for someone new it would be a pain in you know what to make any contribution.
I think that there is very little gained by merging the radar plugin codes into one because as soon as the protocol and/or the menus differ it's more of an obstacle to have generic code.

Anyone out there that's got a xHD2 scanner and can take a Wireshark pcap-file so I could determine if it is compatible with the gxradar plugin ?

/Hans