Gradar Plugin stops NMEA feed

[coupdemistral]

Running the gradar_pi plugin. Everything's well for the first few minutes, then my NMEA feed dies (NMEA debug window stops, own boat icon turns gray). Simultaneously, the log shows message: "***GPS Watchdog timeout at Lat:37.8596 ...."

Running:
Ubuntu 14.05
gradar_pi v 1.5
OCPN 4.6.1

Perhaps a timeout setting somewhere? Thank you for any leads you can offer...

[coupdemistral]

still at a loss over this issue. To provide a bit more context:

- everything runs fine without the radar plugin: I get my NMEA datastream from an AIS transponder over UDP
- when I fire up the radar plugin, everything continues to run fine for the first 10-12 minutes. The radar overlay displays fine etc
- suddenly, CPU utilization shoots from a normal 10-15% or so to 100%
- a few seconds later, the NMEA stream stops, and the log file records "GPS Watchdog timeout" message
- restarting OpenCPN resets the cycle from the beginning

I don't want to give up on gradar_pi as it's a really neat tool (....and I don't have a radar plotter nor do I intend to buy one).

Hopefully some enlightened soul out there can point me in the right direction? That would be sincerely appreciated!

[coupdemistral]

I may finally have a breakthrough on this issue (posting in case anyone runs into the same trouble in the hope I can save the unfortunate soul hours of misery).

I am now reading the AIS NMEA feed directly from the serial interface (instead of a UDP network connection) and the plugin works fine. I tested it last night for about 30 mins, and the NMEA stream worked uninterruptedly.

So something points to the possibility that UDP stream from the radar that the plugin reads may somehow interfere with the UDP stream from my NMEA multiplexer. Perhaps a buffer overflow or something of that nature....Beats me!

[svcattales]

I have had similar experience, but was not able to analyze as well as you have. OCPN get very sluggish and the slowness of zoom function is frustrating.

[rgleason]

Coupdemistral,
Good sleuthing. I hope someone else with Garmin Radar will test as well and take the time to report here too, because this needs to be verified.

Additionally, I hope that you will add a task to Tracker starting with "AIS - your title" with a specific request, and vote for it!
https://opencpn.org/flyspray/index.p...edto=&do=index

You will need to register for Tracker https://opencpn.org/flyspray/index.php?do=register

The person who verifies should also vote for the tracker item. Also in the description text include a link to this thread.

Also it would not hurt to add a link to your Tracker item in this thread too and ask people to vote.

[merrimac]

@coupdemistral

Does the UDP NMEA stream cause issues without the radar plugin? Or is it only with the radar plugin enabled that it slows down?

The "GPS timeout" is probably just an effect of the main thread becoming slow.

[coupdemistral]

@merrimac
You are correct. As it turns out after more sleuthing, the GPS Timeout is just a symptom of the CPU being overloaded by the plugin.

After moving to a new Ubuntu 16.04 laptop (64-bit Dell Latitude 6400), I have been able to identify the main issue as such: after turning on the radar in the plugin (with or *without* an NMEA stream, as I have noticed after my original post), the CPU shoots up to 100-110% and stays there as long as the radar is running.

It may take it 2-3 minutes after turning the radar on, but it gets there inevitably. On my old machine (32 bit Dell Latitude, Ubuntu 14), this caused the NMEA stream to die. On my new one, it just causes the system to become sluggish or even unresponsive.

Turning the radar off will bring the CPU util down in the mid 30s , but turning it back on causes it to jump right back at 100%+. I need to exit Opencpn to reset things back to normal.

So my initial assessment of this being a UDP-related problem was incorrect. Sorry about sending folks on a wild-goose chase.

I have not filed a bug report on Flyspry as I was waiting to get more data on the issue, but I think this pretty much describes the problem, so I'll do just that.

I'll be sailing down the California coast soon (where fog may be a problem) and the only solution will be to turn Opencpn on for a few mins, get a "lay of the land", so to speak, then turn if off. The price you pay for your resistance to buying more dedicated, proprietary hardware!
Thanks for everyone's help!

[bdbcat]

coupdemistral....

Lets try to isolate this UDP performance problem with gradar.

I am currently running gradar_pi on Kubuntu 12.04, medium spec machine. Radar connected to ships network through a switch/router. In operation, I see only minimal evidence of GUI sluggishness. With the radar operational, the UDP data stream is steady at about 55 kbps. The CPU load is about 10-12%. It will run indefinitely with this configuration, and never bogs down or loses a TCP NMEA data stream connection. It is certainly usable for real navigation, and I do use it.

What can you tell us about your configuration that may relate?

Greg on SV cattales:
Can you tell us more about your Windows configuration that might let us debug zoom/pan sluggishness when using gradar?

Thanks
Dave

[coupdemistral]

@Bdcat

Thanks for taking the time to look into this:

"the UDP data stream is steady at about 55 kbps."

That may be a clue: mine is steady at about 700kbps!

I am using a standard Garmin HD 18. What could explain the difference?

[coupdemistral]

the 700kbps was bogus. My bad, sorry! I had an app syncing files in the background when I looked at network traffic. The actual network traffic caused by the radar at steady state is 56Kbps.

So I am back to square one, with my laptop huffin' and puffin' at 109% within a couple of minutes of turning the radar on...

I can think of nothing unusual about the configuration, other than the data I provided: Ubuntu 16.04 , Dell Latitude 6400, Xorg graphics driver (though I tried with the Nvidia drivers as well with no measurable improvement). Default opencpn.conf with no modifications, standard gradar_pi settings (operating as master, swept scan, default range, noise etc). Only one active connection: UDP listening on localhost, port 10110).

Not sure what other clues I can provide, but ask away!

[bdbcat]

coupdemistral...

Success here, of a sort.

Sure enough, if I start OCPN, activate GRadar, and wait long enough, I can see 100% CPU on my linux box, too. Variable time, from 5-10 minutes. If I start from console, I get a bunch of warnings on screen when the CPU load goes up, like "Warning: poll(2) invalid arguments" That is a sure clue.

So, I should be able to track this down. Give me a couple of days to work it.

Progress!

Dave

[coupdemistral]

@bdcat
that sure sounds like progress! Glad to know I am not the only one experiencing the issue.

FYI - here's the bug I created on Flyspray.

Crossing my fingers for a quick resolution :-) and thanks again for looking into this.

[coupdemistral]

@bdcat
to add a new twist on the mystery saga, I have installed Opencpn and the gradar plugin on what was meant to be a backup laptop for the boat. It's just an old Latitude I bought on Ebay, which came with Lubuntu 17.04 (Zesty Zapus) preinstalled. Lo and behold, everything works fine, and the Opencpn CPU usage never exceeds 15% even after 30 minutes of running!

So for now my backup becomes my primary, and in the meantime I will upgrade the other one to 17.04 as well. More importantly, I can sail off knowing my radar works!

The issue of course is still there (as you have been able to reproduce) but at least we know it must be tied to either the version of the OS (both 14.04 and 16.04 seem to be affected), or the underling hardware.

Cheers and thanks again