Raymarine Quantum 2 Q24D Radar & OpenCPN 5.8.2 + radar_pi

[SoggyPaws]

We are on the verge of buying a new radar, as our old one is failing. A friend demoed his Halo 20+ and OpenCPN and I was impressed. We are intrigued with the idea that we don't need to also buy ~$1000 chartplotter/mfd to take advantage of the new technology.
But where we are now, Raymarine is the simplest to buy. There is a Raymarine dealer nearby who has the Quantum 2 Q24D in stock. Shipping stuff in to Malaysia from elsewhere can be difficult and expensive, but not impossible.
The official docs on Radar_Pi on OpenCPN.org indicate the newer Raymarine radars are not supported. However, I think this info is obsolete. I see on the radar_pi Github Wiki, the Quantum 2 Q24D should work.

So, I wanted to
(1) Confirm that there are no major issues with the latest rev of OpenCPN and the radar_pi for the Quantum 2. All our other Ray equipment is circa 2004, and already being piped in to the OpenCPN (Windows) computer via a Seatalk/NMEA USB connection.
(2) Ask other new-technology radar users if there are technical/quality reasons why we SHOULDN'T go with the Quantum 2. (Display quality/features, etc).

We've recently upgraded to a faster W11 computer with more memory and a 22" screen. I understand we'll want to use a wired connection for the radar/computer connection, and we'll have to buy an expensive Raymarine cable to make that work without a Raymarine chartplotter/mfd.

I am fairly technical and proficient with OpenCPN.

Thanks in advance for your inputs.

[Douwe Fokkema]

The Quantum 2 radar is supposed to function with radar_pi. But as the core development team has no access to this radar, we do not actively support it. In case you have problems getting it working, there may be others on the forum to help you, or not. We do not correct any bugs for these radars as we have no test environment. But if you are technical and know the basics of C++, all software is public and can be adapted as needed. We will be happy to accept any corrections and get them in the code base.

[Douwe Fokkema]

I would plan a shopping trip to Singapore.

[SoggyPaws]

We had the Raymarine guys bring a Quantum radar to the marina today. A sales guy and his IT guy helper. We set up cabled to the computer with an old router I had laying around (that I wasn't very familiar with). I had to change the IP address range of the router to talk to the Quantum--this took a little doing because I didn't know what I was doing and the IT guy didn't want to jump in and possibly bugger up my system permanently.

But once we got the IP address range right (192.168.0.x) The Radar PI (5.8.2 + 5.5.0) did appear to find the radar eventually. (see screenshot). At least it picked up model number and serial number. When I google the part number it says this:

Raymarine E70210 Quantum Q24C Radome w/Wi-Fi & Ethernet

The tech guy confirmed that the s/n of the unit matched their radome, so it was definitely coming from that radar. But I could never get anything else to happen. Clicking on the Standby/Transmit never did anything. Here is a sample of the log when it actually declared success, at least in the initial "where is the radar" effort. (When we finally got things set up correctly, my IP was :101, and the radome's IP was :103)

13:29:13.020 MESSAGE RaymarineLocate.cpp:257 Located raymarine radar IP 192.168.0.103 port 1, interface 192.168.0.101 [ /232.1.181.1:2574/232.1.181.1:2574/192.168.0.103:2575]
13:29:13.020 MESSAGE RaymarineLocate.cpp:191 Raymarine locate stopped after success
13:29:13.020 MESSAGE RaymarineReceive.cpp:274 Raymarine Quantum RaymarineReceive receive timeout 5
13:29:13.020 MESSAGE RaymarineReceive.cpp:300 Raymarine Quantum RaymarineReceive updating radar location  /232.1.181.1:2574/232.1.181.1:2574/192.168.0.103:2575 socket -1
13:29:13.020   ERROR RMQuantumControl.cpp:55 Raymarine Quantum INVALID_SOCKET, Unable to transmit command to unknown radar
13:29:13.020   ERROR RMQuantumControl.cpp:55 Raymarine Quantum INVALID_SOCKET, Unable to transmit command to unknown radar
13:29:13.020 MESSAGE RaymarineReceive.cpp:112 Raymarine Quantum Creating multicast socket for radar at IP 192.168.0.103 port 1 [ /232.1.181.1:2574/232.1.181.1:2574/192.168.0.103:2575] - 1296
13:29:13.020 MESSAGE RaymarineReceive.cpp:274 Raymarine Quantum RaymarineReceive receive timeout 0
13:29:13.020 MESSAGE RaymarineReceive.cpp:300 Raymarine Quantum RaymarineReceive updating radar location 0720229/232.1.181.1:2574/232.1.181.1:2574/192.168.0.103:2575 socket 1296
13:29:13.020 MESSAGE RaymarineReceive.cpp:112 Raymarine Quantum Creating multicast socket for radar at IP 192.168.0.103 port 2574 [0720229/232.1.181.1:2574/232.1.181.1:2574/192.168.0.103:2575] - 1296
13:29:13.020 MESSAGE RaymarineReceive.cpp:274 Raymarine Quantum RaymarineReceive receive timeout -60
13:29:13.021 MESSAGE RaymarineReceive.cpp:274 Raymarine Quantum RaymarineReceive receive timeout -59
13:29:13.021 MESSAGE RaymarineReceive.cpp:274 Raymarine Quantum RaymarineReceive receive timeout -60

The log file just indicates timeout over and over. I didn't find out how to turn on Verbose until after they'd put everything away, so not a verbose log file, sorry. I did capture some random Ethernet comms via Wireshark later, but I've never used Wireshark before, so I didn't really know what I was doing.

In these log files, search for the S/N, as any logs before that, maybe we were trying to talk on the wrong IP address, because I'd buggered up changing the IP range on the router.

We also tried to directly connect the radar to my computer (without changing the cable... should we have had a cross-over cable?). And that didn't produce anything useful either.

Have attached the logfile and wireshark files (zipped and renamed .PDF), and the screenshot.

In theory, the tech guy, Promoth, is supposed to go back to the Raymarine office here in Malaysia and try to get OpenCPN 5.8.2 + 5.5.0 plugin working, as we told them we would buy one if they do. But I'm not sure if he has the time or what his skill set is, though he seemed pretty sharp and interested.

We told the salesman that they should contact you guys via this forum and offer a loan of a radome to one of you (convenient to a Raymarine dealer wherever you are) to get the RadarPi working well for the Quantum. They are definitely losing sales over this.

Sorry this is not more helpful.

[ews]

Did you do this and how did it turn out ? I just acquired a Quantum Radome and understand I'll need a Ray MFD to get it to pair (no DHCP int he Quantum). But before I get an Axiom I need to know if its working well on OpenCpn.

let me know ....

cheerio

Ernie SV Patience

Originally Posted by SoggyPaws

We are on the verge of buying a new radar, as our old one is failing. A friend demoed his Halo 20+ and OpenCPN and I was impressed. We are intrigued with the idea that we don't need to also buy ~$1000 chartplotter/mfd to take advantage of the new technology.
But where we are now, Raymarine is the simplest to buy. There is a Raymarine dealer nearby who has the Quantum 2 Q24D in stock. Shipping stuff in to Malaysia from elsewhere can be difficult and expensive, but not impossible.
The official docs on Radar_Pi on OpenCPN.org indicate the newer Raymarine radars are not supported. However, I think this info is obsolete. I see on the radar_pi Github Wiki, the Quantum 2 Q24D should work.

So, I wanted to
(1) Confirm that there are no major issues with the latest rev of OpenCPN and the radar_pi for the Quantum 2. All our other Ray equipment is circa 2004, and already being piped in to the OpenCPN (Windows) computer via a Seatalk/NMEA USB connection.
(2) Ask other new-technology radar users if there are technical/quality reasons why we SHOULDN'T go with the Quantum 2. (Display quality/features, etc).

We've recently upgraded to a faster W11 computer with more memory and a 22" screen. I understand we'll want to use a wired connection for the radar/computer connection, and we'll have to buy an expensive Raymarine cable to make that work without a Raymarine chartplotter/mfd.

I am fairly technical and proficient with OpenCPN.

Thanks in advance for your inputs.

[SoggyPaws]

Ernie,
After
(a) lackluster response from the Raymarine dealer (his tech guy never returned another call).
(b) being told by the plugin developers that I should buy a Navico type
(c) being PM'd privately by a guy who had a Raymarine who told me he thought the Navico was a slightly better radar
(d) finding the bolt pattern on the B&G exactly matched our Raymarine Radome mount on the mast

We bought a B&G (Navico with a B&G sticker) and have not been happier.

However, if you already HAVE the Raymarine Quantum you might get it to work, especially if you have the MFD. I think (being fairly techie) that I could have gotten the Quantum to work with just a little assistance from the plugin guys, but they were not really interested.

At least one guy has gotten the Quantum working with OpenCPN.

Sorry I can't be more reassuring. Maybe someday Raymarine will get off their high horse and try to work with OpenCPN.

Sherry

[molly21]

We have a Quantum 2 and it works with OpenCPN. It is connected by wire using a Raymarine Raynet switch.
BUT the radar picture in OpenCPN is very pixelated.

[CaptainRivet]

Originally Posted by molly21

We have a Quantum 2 and it works with OpenCPN. It is connected by wire using a Raymarine Raynet switch.
BUT the radar picture in OpenCPN is very pixelated.

Thats because the radar needed to reduce data volume via wifi to work and raymarine solved that by first sending one half of the picture and then the other half and the axiom plotter then joins the two halves and smoothens the picture.
In OpenCPN you just see the half picture, means half resolution of the actual picture and smoothening is missing too. Thats why its very pixelated.

Orca navigation had the same issues and managed to solve it. I am one of Orca's beta tester thats why i know the details...sadly no developer that can help fixing it and not familiar with OpenCPN as the radar doesn't work...now at least partly...OpenCPN makes no sense for me unless it does.
I have Quantum2, Axiom 7+, orca core, cerbo GX and a NUC mini PC running windows 10 all connected via ethernet to a switch and also YachtDevices NMEA dongle broadcasting NMEA2000 and NMEA0183 so i assume having all necessary hardware already so can setup OpenCPN and test/do&send logfiles if some developer or the plugin team wanna tackle and fix it. Happy to support.
Correct the navico is the slightly better radar, the furuno doppler the best (and sadly unsupported too) and send full data so its much easier to get that to work.
Well i got my Quantum 2 new for 1500Euro and Orca supported that first so it was a nobrainer to get it, the navico would have been 1000Euro more. B&G blocking their autopilot to be remotly steered by tablets and also apple watch so a NoGO for me, had a zeus 3/halo combo on my previous vessel and that was the first time in my life i needed to read manual to be able to operate it. Sail steer the only really advantage but not user friendly.

[Douwe Fokkema]

Originally Posted by CaptainRivet

Thats because the radar needed to reduce data volume via wifi to work and raymarine solved that by first sending one half of the picture and then the other half and the axiom plotter then joins the two halves and smoothens the picture.

I have analyzed al lot of data from the Raymarine Quantum2 radar. Spoke length is 250 pixels and the number of spokes is 250. This explains why the image is very "pixelated". Compare this with a Halo radar, these have 1024 pixels per spoke and count 2048 spokes per revolution.
I have not seen that the Quantum radar writes the image in two parts that are joined in the display as CaptainRivet describes. This would be difficult anyhow, as the radar is a moving image that is refreshed continuously at the beam. I assume that Raymarine is just smoothing the corners of the blocks they write. I looked at applying smoothing as well, but that was not straightforward with the OpenGL that we use.

Please understand that the support of the radar_pi developers for the Raymarine radars is limited. We do not have direct access to any of these radars. All work has been done remotely with help of Raymarine radar owners. This is a difficult and slow process. When you have direct access to a radar the turnaround time of a test is measured in seconds, doing it remotely in days.

[CaptainRivet]

Originally Posted by Douwe Fokkema

I have analyzed al lot of data from the Raymarine Quantum2 radar. Spoke length is 250 pixels and the number of spokes is 250. This explains why the image is very "pixelated". Compare this with a Halo radar, these have 1024 pixels per spoke and count 2048 spokes per revolution.
I have not seen that the Quantum radar writes the image in two parts that are joined in the display as CaptainRivet describes. This would be difficult anyhow, as the radar is a moving image that is refreshed continuously at the beam. I assume that Raymarine is just smoothing the corners of the blocks they write. I looked at applying smoothing as well, but that was not straightforward with the OpenGL that we use.

Please understand that the support of the radar_pi developers for the Raymarine radars is limited. We do not have direct access to any of these radars. All work has been done remotely with help of Raymarine radar owners. This is a difficult and slow process. When you have direct access to a radar the turnaround time of a test is measured in seconds, doing it remotely in days.

Its definitely not 250x 250. As said thats half of the resolution. To be able to do wifi they had to cut down on data.
With the update frequency of the radardata is high enough you won't relaize you are moving...the same with screen frequency or pixtures per second in a movie...or 3D with one protector....you just send the same picture twice and overlay plus then interpolate between the same 2 datapoints to create more.