Garmin xHD Radar Overlay

[hasse_A]

As promised!
Here is a screen plot of the menus.

Changes made are

Radar Control --
No Xmit Zone button added.

Noise Control --
On/Off button for Sea Clutter added.
High changed to Rough.
FTC removed.

Range --
There are now 2 Auto buttons instead of one.

Dome Control --
24 changed to Normal.
30 changed to High.
On the xHD the rotation speeds are 24 and 48 rpm.

Sentry Control -- No change

No Xmit Zone --
Menu added. Controlling the no transmit sector is similar to Sentry Control.

The gray sector aft of the boat is illustrates the area where the radar is quiet.

There is no FTC on the xHD so that is removed

On the Garmin plotter the sector is stretched out to the edge of the display. Should it, or will that only interfere with the chart in that area ?

All the menus displayed are working with the scanner. A change in the setting will pop up on the Garmin plotter.

/Hans

[jonasaberg]

Hasse,
I think this looks excellent. Well done!

A small thing: For consistency, maybe the window name for the "Range" window should be "Range control" since all the others have "control" in the name?

Are all the concepts and definitions exactly defined as in the original Garmin xHD manual? Are there stuff not in the Garmin manual that needs to be explained?

I dont have a scanner so I don't know exactly which features it have. Is there anything remaining?

Regarding the no transmit grey zone. As it is there only as a reminder of this setting, I think it is reasonable to let the grey zone extend as far as the range setting. This way you also get a "reminder" about how far the radar is set to detect reflections.

/Jonas

[jonasaberg]

Hasse,
How does the collision work. Is it if a taret is within the set radius or is there some type of target tracking implementet?

What would it take to make mini arpa work?

Is it really necessary with a rategyro sensor?
I think it probably is ... but always worth questioning conventinal truth....

Hasse, if you had a rate gyro, would your display be able to handle it? It seems marpa is specified in the radome specs and not the display specs but maybe I am reading in the wrong place - or a different display is needed to get marpa functionality when you have a rategyro installed.

/J

[hasse_A]

Originally Posted by jonasaberg

A small thing: For consistency, maybe the window name for the "Range" window should be "Range control" since all the others have "control" in the name?

Yeah, I agree. This was inherited from gradar. Maybe Dave should change as well.

Originally Posted by jonasaberg

Are all the concepts and definitions exactly defined as in the original Garmin xHD manual? Are there stuff not in the Garmin manual that needs to be explained?

No I don't think so. Menus are not laid out the same way.
This is anyhow not a priority right now. My view is that the menus made
"our" way are much easier to handle. Clicking through the Garmin menus ar much more tedious.

Originally Posted by jonasaberg

I dont have a scanner so I don't know exactly which features it have. Is there anything remaining?

Yes there are more features in the scanner than is incorporated in the menus. For instance VRM/EBL. One might ask how useful those are when you have a chart beneath.

Originally Posted by jonasaberg

Regarding the no transmit grey zone. As it is there only as a reminder of this setting, I think it is reasonable to let the grey zone extend as far as the range setting. This way you also get a "reminder" about how far the radar is set to detect reflections.

I think I will go that path.

/Hans

[hasse_A]

Originally Posted by jonasaberg

How does the collision work. Is it if a taret is within the set radius or is there some type of target tracking implementet?

There is no target tracking. I would expect that if a target hits the yellow arc the alarm will go off. You might better ask Dave about that.

Originally Posted by jonasaberg

What would it take to make mini arpa work?

Hold your horses!
I am trying to get the xHD scanner working with OpenCPN. As of now this is a one man's job. For the time being I am focusing on getting the same functionality as there is in the gradar plugin.
To get marpa or even mina arpa working a couple of things must be in place.
I would need a high end plotter. The 721 I got does not support it and without I would have no way of R/E the thing. I have never used a radar with marpa so there would be a steep learning curve. If I were to do it, a simulator may be needed.

Originally Posted by jonasaberg

Is it really necessary with a rategyro sensor?
I think it probably is ... but always worth questioning conventinal truth....

I've got a 10Hz fluxgate compass. I think that would be good enough but I'm not sure. Would you really need turn rate info ?

Originally Posted by jonasaberg

Hasse, if you had a rate gyro, would your display be able to handle it? It seems marpa is specified in the radome specs and not the display specs but maybe I am reading in the wrong place - or a different display is needed to get marpa functionality when you have a rategyro installed.
/J

This page might give you the answer.
https://support.garmin.com/support/s...-000000000000}

/Hans

[jonasaberg]

Originally Posted by hasse_A

Hold your horses!
...To get marpa or even mina arpa working a couple of things must be in place.
I would need a high end plotter. The 721 I got does not support it and without I would have no way of R/E the thing. I have never used a radar with marpa so there would be a steep learning curve. If I were to do it, a simulator may be needed.

I've got a 10Hz fluxgate compass. I think that would be good enough but I'm not sure. Would you really need turn rate info ?

This page might give you the answer.
https://support.garmin.com/support/s...-000000000000}

/Hans

Horses held!

Your doing a great job, and that of course goes for Dave et al aswell.

I was just considering how it could work with marpa, I am not saying you or anyone in particular should do it. It is still interesting to explore the possibility.

Anyway, there seem to me there could be two ways. Either the target tracking is made by the hardware in the scanner or by the control display.
If it is done by the scanner it would probably make sense to reverse engineer it by getting a display with marpa support. That would probably be most economical in term of calculation economy and possibly also programming effort. I can't really judge whether reverse engineering or programming marpa from start is easiest, I would guess that reverse engineering it is easier for you guys that know how to do it.

But, if marpa is done by the control display I see no real reason it could not be made in a software plug-in. It seem to me that this is (just) plane geometry. We are only talking about a 50 NM radius, so we can discard the curvature of the earth.

Marpa is about manually marking a target and let the system track it and record its position over time. When this is done it is trivial to calculate its speed and course.

I dont think this is a very hard problem in principle even if it would take a bit of an effort to program it. It would be something like:
1. Mark target. Calculate its position.
2. Wait a sensible amount of time (1/48th of a second or longer...).
3. Check a circle around the targets position for the target. (The radius being determined by the expected speed of the target)
4. Calculate target position and log it.

The problem may be the accuracy of the target positioning. It will be greatly influenced by how much your ownship is moving and how well you can detect it. This is where a fast compass and/or rategyro is helpful.

We could make an estimate if we new the specs for your compass and compared it with the specs for Garmins rategyro. It seems it is manufactured by a subsupplier.
Airmar H2183 Heading Sensor

I have an old Silva=Nexus compass transducer, it is still very good, but quite slow since it is in essence a magnet floating in a liquid that is monitored by sensors on the outside of the glass bulb.

What is the model of your fluxgate? Specs?

/J

I think the below specs are valid for the Garmin rategyro.

Airmar H2183 Heading Sensor - Solid State - 10 Hz

Static Compass Accuracy: 1°       RMS when level
      Dynamic Compass Accuracy: 2° RMS (Best-in-Class)
      Heading Display Resolution: 0.1°
      Settling Time: 1 second (adjustable)
      Heading Data Output Update Rate:—10 Hz—NMEA 0183—Adjustable up to 20       Hz—NMEA 2000®
      Rate-of-Turn Range: 0° to 70° per second
      Rate-of-Turn Accuracy: 1° per second
      Rate-of-Turn Data Output Update Rate:—2 Hz—NMEA 0183 (Adjustable up to       10 Hz)—Adjustable up to 20 Hz—NMEA 2000®
      Pitch and Roll Range: ±50°
      Static Pitch and Roll Accuracy: <1°
      Dynamic Pitch and Roll Accuracy: <3°
      Pitch and Roll Display Resolution: 0.1°
      Pitch and Roll Boat Alignment: Yes with software
      Pitch and Roll Data Output Update Rate:—2 Hz—NMEA 0183 (Adjustable up       to 10 Hz)—Adjustable up to 20 Hz—NMEA 2000®
      Supply Voltage: 9 VDC to 16 VDC
      Supply Current: <140 mA
      NMEA 2000® Load Equivalency Number (LEN): 3
      Certifications and Standards: CE, IPX6, RoHS, IEC60945
                                        NMEA 0183 Sentence             Structure
             $HCHDG ............             Heading, Deviation, and Variation
            $HCHDT ............ Heading Relative to True North
            $TIROT ............... Rate of Turn
            $YXXDR ............. Transducer Measurements: Vessel Attitude
             NMEA 2000® Supported             PGNs
             127250 .......Vessel             Heading
            127251 ....... Rate of Turn
            127257 ....... Attitude

[hasse_A]

Originally Posted by jonasaberg

Horses held!

I don't think I am the right person to discuss the marpa thing with.
At least not at the moment. I just don't have the knowledge it takes.
If someone else want's to get in on the subject, feel free to participate.

Here's a reply from Dave in the HD thread concerning marpa.
http://www.cruisersforum.com/forums/...ml#post1294556

Originally Posted by jonasaberg

What is the model of your fluxgate? Specs?

It's this one
http://http://digitalyacht.co.uk/fil...hure%20Eng.pdf

/Hans

[hasse_A]

A short report!

I can now operate the scanner from the gxradar plugin.
The radar icon is clickable and changes colors as the state of the scanner changes.

I am now focusing on the video. If I understand the code for the HD scanner it's got 180 angles to a full circle. The xHD has got 1440.
Thats 8 times as many and it's a color scanner. The video is also sent on a different port.

I might want to come back to you Dave for a description of the way you handle angles and data storage.

/Hans

[ChuckSK]

Hans

The HD scanner sends 180 packets per scan. Each packet contains 4 radials for a total of 720 radials.

Chuck

[hasse_A]

I need some info.
The xHD has 1440 radials/scan compared to 720 for the HD scanner.
Number of bytes/radial for the xHD scanners is between 547 and 733.
There is one packet sent for every radial instead of 4/packet.
What I would like to know is how many bytes there are per packet for the Garmin HD scanner. That would give me a hunch of what I could expect the sample rate of the xHD to be.
The radar scan data for the HD scanner seem to pure binary, echo/no echo.
Obviously the data rate from the xHD scanner is a lot higher since it's a color scanner. I have to figure out how the color info is presented. I might have to build a simulator to be able to R/E this. Thanks in advance to anyone answering this question.

[hasse_A]

Ok, back in saddle again after 2 weeks of holiday in the Canary Islands.

The scan data is represented as 1 byte/pixel. So it's an 8 bit color coding but not standard RRRGGGBB.

Values I have seen are 0 and between and including 27(hex) and ff(hex).
Values between and including 1 and 26 are not.

0 = black i.e no return.
27 = lowest amplitude (dark blue color on the 721 display)
ff = max amplitude (dark red color on the 721 display)

Colors go from dark blue to light blue, light yellow, dark yellow, light red and for the highest amplitude to dark red when the values from scanner go from 27 to ff.

There must be some kind of remapping done here.
How should we handle this best ?

Any ideas Dave, Chuck or anyone ?

/Hans

[dacust]

First, there is not actually any such thing as a color scanner. It is a display that has a false color display generated so the colors can show the intensity of the returns. My guess is there is more data because it is HD and maybe can return a greater resolution of intensity as well as separation?

There is no real reason to use the colors they used except that they probably did some research to show that the colors they used are intuitive for users to judge what they mean.

I think you can just use the lowest and highest colors on each end of the scale and then evenly distribute the fades in the middle.

But you might want to wait until some more people weigh in before coding...

-dan

[jonasaberg]

I am not sure it makes sense to have more than 8 bit resolution for the signal strength representation. It seems to be plenty of levels to me.

So, if I got it right, you found 26 to ff (hex), that's 38-256 in decimal or 228 levels of intensity.
Could the missing range (1-37) be due to some level setting, that low intensity returns where filtered out?

I would suggest that you try to follow the Garmin colour scheme just because it makes it easier for those that choose to acquire a Garmin plotter as backup/complement for OpenCPN. It makes sense to have the same colour scheme on the plotter and in OpenCPN.

[hasse_A]

Thanks for the feedback!

For the time being I think I will just let the values control the intensity of the chosen color. This is by far the easiest.
Later when I got this working I can upgrade and let the user choose method.

[hasse_A]

Hi all!

I think I need some guidance here.

On the original Garmin HD the scanner sends data on just one port, 50100.
On the xHD control and status are sent on that port. However scan data is sent on port 50102.

What would be the correct approach fetching that scan data ?
Is it possible to set up the existing "MulticastRXThread" to listen to also the 50102 port or should I make a second thread handling the scan data ?

/Hans