Observations on OP at sea

[seandepagnier]

OCPN - impossible to perform some actions on the small RPi touch screen. Edit a waypoint for example as its impossible to get to the OK button. This is an OCPN scree realestate management issue. 

Yes, this should probably be reported to opencpn directly as this is a wider issue than openplotter

Compass stops working after 8 hours or so. Restarting sensors sometimes works but on many occasions restarting sensors, signal K and NMEA has no effect and the only way to get it running again is to perform a power off reboot (Normal soft reboot doesn't work). No error messages when running OP from the command line. Processor usage usually runs at about 30% but rises to 50% when this occurs. There may or maynot be some interaction with a bug that I reported in OCPN where if auto-follow is active the heading indicator on screen becomes inactive (COG continues to work).

Please use mpu9255, not mpu9250 or mpu9150. I significantly optimized it making it have much lower noise from the sensor while greatly reducing cpu. It should use 1-2% of cpu. I have run it for more than 1 month at a time without problem. In theory you can backport the mpu9255 driver to support mpu9250 or mpu9150 but I didn't bother.

Maybe connected with the above is that sometimes OCPN slows to a crawl or locks up completely and will not shutdown. Unfortunately in versions of OCPN since 3.something the track is not recorded to the drive in realtime resulting in lost tracks in the event of a crash or forced shutdown (for this reason I know of a few people who are still using ancient versions of OCPN). Hence the track recorded on the Pi plotter for this voyage has huge gaps in it. 

Why is ocpn slowing to a crawl?? Can you reproduce it or stop in a debugger to find what is taking so long?

Since version 3, the tracks are not rewritten is not recorded, doing so was inefficient and cause the program to lock for several seconds depending on track size. every 5 minutes. It instead records the "changes" Unfortunately it doesn't correctly re-apply them, because it doesn't store the guid of the track in the changes file, so it doesn't match the existing track and the trackpoints are discarded. This logic is broken and so, the tracks are lost. It is not really difficult to fix, I didn't because I didn't write this part of opencpn.

Could the above two issues be related to memory allocated to the track etc. filling up? 

I had a track that went halfway around the world without issues of performance or memory. This is since changes in 4.6.0. Before that, long tracks were slow. It had something around 180,000 points. How much ram does opencpn use?

Anybody got the official RPi touch screen to actually work as a touch screen.. i.e. at least get right click to work?

Doesn't touch screen mode work? I think you tap then hold.

Anybody used something like a game controller as a mouse/button pad? I have never found a touch screen that is really usable at sea on any equipment so for me touch screens on boat nav equipment are only for in port use and planning (quite a few 10 of ks of miles at sea testing new stuff for one of the major manufacturers - they understand but touchscreens sell plotters at the boatshows). When things get tough

Someone told me you can just wipe the water off and it works again. I don't use touch screens.

something else is required, preferably a one handed thing. Maybe one of those presentation handsets? Most people that I know that sail in bouncy stuff regularly use a trackball as their pointer input and that is what I use at the nav desk (Logitech M570 being the usual preferred device). However for the cockpit and watchkeeping station under the hard dodger something else is needed. Ideas please?

Has anybody scripted screen brightness controls to buttons yet? As actions perhaps? I'm thinking of adding two buttons with actions to increment/decrement the brightness setting by 10 at each push? I've been using this from a terminal to adjust screen brightness "echo 255 > /sys/class/backlight/rpi_backlight/brightness"; replacing 255 with anything from 25 to 255 as required. 

Anybody got a better way of doing this or perhaps has done something with Node Red (I haven't got my head around this yet any tutorials out there?). The problem with software brightness is that say you have the brightness turned right down at night and are doing a sail change at sunrise. You come back the plotter and can't see anything on screen therefore it is impossible to navigate to software controls. Hardware wins in this case I think.

Has anybody made any graphic devices in NodeRed or similar for a barograph and a TWS/TWD ribbon similar to those in OCPN? They are crippled in real life use by the fact that the history is limited to the last 20 minutes in the case of the wind graph and that the it is impossible to set the y axis in the case of the OCPN barograph. 

The tools in pypilot (now included in openplotter) contain a scope which is efficient and configurable to display many parameters including wind speed and direction. Openploter currently only uses the imu part, but if you ran a full autopilot, or just the nmea.py script, you would be able to plot wind speed and direction.

So in summary. The combination of my hardware and OP worked fairly well. Some ergonomics need to be addressed; touchscreen and other I/O issue. But Openplotter and OCPN were a great combination.

Stability and lost data when OCPN fails is a major issue. For the whole trip I also ran OCPN and Nobeltec TZ on W10 on my downstairs boat computer neither of which missed a beat so the issues reported are Openplotter/Pi/Linux specific. 

Cheers
Chris

[quote='Littlechay' pid='2852' dateline='1504384995']

On the subject of the compass sensor hanging and OCPN slowing to a crawl. - I've updated to the latest version as of yesterday evening and have had it running for 24 hours now with no issues so far. Processor load is much lower in this version running at about 7 - 8 %.
[/quote[

Is it using mpu9150 or mpu9255?? Is there a log output from rtimulib2?