Performance during anchor watch alarm

[ameoba]

Hi All,


I've found a possible bug while using the anchor watch feature in OpenCPN version 5 that I'd like to ask the community if it can be replicated and shown as a software error, or if not assist me in determining why my two PCs behave this way.


Scenario:
I drop a mark on the anchor and name it with the distance of chain layed out + distance to my GPS antenna. E.g. 50m. I then right click the mark and select "Set Anchor Watch" to create a green circle around the mark.
When the boat leaves this circle, the audible alarm sounds and a red jagged line flashes around the mark.


The issue is that while the alarm is sounding, the app responds terribly slow. As an example, right clicking on the mark and selecting "Remove Anchor Watch" while normally instantaneous, takes 5 seconds. all menu navigation is hindered as long as the alarm is active.

Once the alarm is over, all functionality is restored and performance is great.


I have 2 PCs loaded with OpenCPN that I have been able to replicate this on. Wondering if there are others that could confirm this behavior and if there is somewhere to log a bug report or the like.


Regards,

[Nicholson58]

Possibly the alarm draws too much current so maybe a voltage drop and operation is inhibited? Just a guess.

Personally, I prefer a separate non-interdependent, dedicated anchor watch. We have a Watchmate 850 AIS that is an excellent stand alone anchor watch. It uses about 7 watts. At anchor everything else is off except the also independent depth. The 850 fires a relay that enables the Wake The Dead alarm.

[ameoba]

Thank you for your reply.



Power draw is not the issue here. On the two PCs I've found this issue, one is a small form factor PC connected to 240V supplied from a diesel generator. This is the same generator that powers the anchor winch, so if it can't handle a set of PC speakers beeping I'd be concerned.
The other PC is may laptop. Again if power draw from operating the speakers is the issue I'd be concerned.


Both PCs run full Windows 10. This is not a raspberry pi setup.


Regards,

[Nicholson58]

The generator is of no concern. If the PC must drive an external load that may pull down the internal voltage within the PC. I am unaware of the architecture of your devices. Good hunting.

[CarCode]

Originally Posted by ameoba

Power draw is not the issue here. On the two PCs I've found this issue, one is a small form factor PC connected to 240V supplied from a diesel generator. This is the same generator that powers the anchor winch, so if it can't handle a set of PC speakers beeping I'd be concerned.
The other PC is may laptop. Again if power draw from operating the speakers is the issue I'd be concerned.


Both PCs run full Windows 10. This is not a raspberry pi setup.

I don't guess the CPU of your PC is powered with 240V. But even Windows should have a taskmanager which can show the CPU load of the running tasks. Start the taskmanager and regard if the OpenCPN task load changes much when an alarm occurs.

[ameoba]

The external load of a PC speaker does not take much power. I'm not powering a large sound system here, nor am I running a Pi powered by a sub par USB supply. That's all I was getting at with the 240V.


I've tried it again with the task manager open and while there a few small spikes in the CPU activity, it does not reach the peak, nor does it flat line (which would indicate a bottle neck).
While leaving the alarm sounding I was able to navigate around other applications on the laptop without any issue. The slow down is only affecting the opencpn software. Indicating to me that this is not a system resources issue.


FYI, laptop has an Intel i7-8550 CPU with 16GB RAM.

[ameoba]

The attached image is of my CPU while the alarm is on. Approximately one third of the progress through this graph i activated the alarm.


As you can see there is no significant load on this PC, maxing out around 10% CPU near the end there for a split second.

[Hakan]

Originally Posted by ameoba

Hi All,
I've found a possible bug while using the anchor watch feature in OpenCPN version 5 that I'd like to ask the community if it can be replicated and shown as a software error, or if not assist me in determining why my two PCs behave this way
.................
I have 2 PCs loaded with OpenCPN that I have been able to replicate this on. Wondering if there are others that could confirm this behavior and if there is somewhere to log a bug report or the like.

ameoba...
I'm on Win10 and a dated slow PC and can not reproduce your observations. While the anchor watch is alerting no other functions are disturbed in a noticeable way. "Show CPA..", Dashboard and other live data are updated as usual and I can wo delay set the anchor watch off again.

On my Androids an alerting anchor watch does crash OCPN though.

Håkan

[AedanC]

I have seen this behaviour too, but did not try and reproduce it yet. It was on a very low end Atom based Win 10 tablet. When I get back to base I’ll see if I can make it happen again, that could be ten days or so.

Aedan

[CatNewBee]

I guess the alarm loop has high priority in the task manager hierarchy, it simply blocks the message queue acquiring rapidly new gps positions to show the drift on the screen.

It is a programming issue, you have to call the yeld method to suspend the current thread to background after starting the alarm thread while waiting for new gps data. Also the alarm thread must yeld after rununning the buzzer.

[NahanniV]

I have exactly the same issue on:

Win10 64 Atom x5-z8350 (OpenCPN 5.0.604)

and

RaspBerryPi 3B+ (OpenCPN 5.0.0)

It happens with or without OpenGL.

[Stu Jackson]

What the heck else would one be doing with the app between the time one picked the device up or got out of bed to get to the laptop, and turning the alarm off? 5 seconds... not really that long.

[NahanniV]

Originally Posted by Stu Jackson

What the heck else would one be doing with the app between the time one picked the device up or got out of bed to get to the laptop, and turning the alarm off? 5 seconds... not really that long.

If you are dragging 5 (or more) seconds can seem like a long time.

This has also happened several times when we were getting underway if the alarm is left on by accident. So, just as you are navigating out of an anchorage or harbour OpenCPN becomes unresponsive, not good.

[Moo]

I knew I had seen this in previous versions. I put an anchor watch on and waited for an alarm and yep I struggled to pan to the boat, right click on the anchor WP and cancel the alarm. I think the same happens with other alarms, such as AIS too.

No memory increase or CPU load issue that I could see.

W10 on an ASUS Zenbook i5 2.5GHz

[Dsanduril]

I have had the same issues on a PI3 install of OpenCPN. When on anchor watch I tend to be zoomed in quite far. I've found that if I zoom back out to a more 'normal' zoom level I don't have the same problems. Curious if you see a difference in behavior when zoomed way in vs. way out?