Here are some notes that I have made whilst experiences on my latest trip are still fresh in my mind.
Openplotter - Version 0.14.3
Sensors -
IMU - MPU9150
Temp pressure humidity - BME280
Temperature - 1W
GPS Hat with external antenna
AIS and wind data were shared from my boat PC via UDP over Wifi. AIS I used but never used wind data on the plotter as the screen real-estate is too limited. I have a wind instrument, a windex, and wet finger anyway!
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.
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).
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.
Could the above two issues be related to memory allocated to the track etc. filling up?
Anybody got the official RPi touch screen to actually work as a touch screen.. i.e. at least get right click to work?
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 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.
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.
(2017-09-02, 09:43 PM)Littlechay Wrote: Here are some notes that I have made whilst experiences on my latest trip are still fresh in my mind.
Openplotter - Version 0.14.3
Sensors -
IMU - MPU9150
Temp pressure humidity - BME280
Temperature - 1W
GPS Hat with external antenna
AIS and wind data were shared from my boat PC via UDP over Wifi. AIS I used but never used wind data on the plotter as the screen real-estate is too limited. I have a wind instrument, a windex, and wet finger anyway!
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.
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).
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.
Could the above two issues be related to memory allocated to the track etc. filling up?
Anybody got the official RPi touch screen to actually work as a touch screen.. i.e. at least get right click to work?
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 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.
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
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 %.
I'm currently moored in a creek and therefore the track file is not building up in memory, but that is the only difference.
(2017-09-02, 09:43 PM)Littlechay Wrote: 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
(2017-09-02, 09:43 PM)Littlechay Wrote: 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.
(2017-09-02, 09:43 PM)Littlechay Wrote: 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.
Quote: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?
(2017-09-02, 09:43 PM)Littlechay Wrote: 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.
Quote: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.
Quote: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.
Quote: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.
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?
2017-09-17, 12:58 AM (This post was last modified: 2017-09-17, 01:06 AM by Littlechay.)
Please note that all of this was on version 0.14.? which was the latest version available when I last had internet access before starting my last trip. The CPU usage has dropped considerably on 0.15.x I am not currently on the boat but have my plotter with me. The only thing I need to do to replicate the boat environment is to buy another perssure/temp/humidity sensor .. oh and to arrange to move the house erratically along at between 3 and 8 knots and to make it roll and pitch... I'm in Christchurch better be careful what I wish for !
(2017-09-16, 04:27 PM)seandepagnier Wrote:
(2017-09-02, 09:43 PM)Littlechay Wrote: 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.
(2017-09-16, 04:27 PM)seandepagnier Wrote: Yes, this should probably be reported to opencpn directly as this is a wider issue than openplotter
OK I'll start a small screen thread on the OCPN forum
(2017-09-02, 09:43 PM)Littlechay Wrote: 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).
(2017-09-16, 04:27 PM)seandepagnier Wrote: 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.
I'm using mpu9150
(2017-09-02, 09:43 PM)Littlechay Wrote: 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.
(2017-09-16, 04:27 PM)seandepagnier Wrote: 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.
I can't reproduce it in the house, but have now updated to v0.15.x anyway. As mentioned above I'll pick up another P/T/H sensor and that will fully replicate the hardware that I was using at sea.
Should I raise the tracks issue again on OCPN forum?
(2017-09-02, 09:43 PM)Littlechay Wrote: Could the above two issues be related to memory allocated to the track etc. filling up?
(2017-09-16, 04:27 PM)seandepagnier Wrote: 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?
I find that OCPN is fine with it's own tracks but if you import GPX files from other sources then it slows right down. You have to go through the tracks and condense each segment and it slowly speeds up. Often when revisiting a destination I want to import my old tracks and this is an issues. I slowly getting a set of OCPN edited tracks built. Not sure how long my track collection is or how many points but in terms of miles since I have been recording tracks but well in excess of 50k NM
(2017-09-02, 09:43 PM)Littlechay Wrote: Anybody got the official RPi touch screen to actually work as a touch screen.. i.e. at least get right click to work?
(2017-09-16, 04:27 PM)seandepagnier Wrote: Doesn't touch screen mode work? I think you tap then hold.
Internet searches indicate that nobody can get it to work in current releases of Raspberry Pi/Ubuntu - grrrr
(2017-09-02, 09:43 PM)Littlechay Wrote: 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
(2017-09-16, 04:27 PM)seandepagnier Wrote: Someone told me you can just wipe the water off and it works again. I don't use touch screens.
Salesmen will tell you that. Doesn't work if there is any spray, raindrops, or drips (off the end of your nose, off your foulies, etc..). If it is rough enough or wet enough then your fingers become sodden and skin all white and wrinkly and the touch screen gives up.. all of them; no exceptions. I put one of my project because I wanted to replicate the functionality of a commercial plotter; which I think I succeeded in doing for the grand sum of something less than 350 NZD. the most expensive items were probably the waterproof enclosure, switches and buttons and connectors for the peripherals.
(2017-09-02, 09:43 PM)Littlechay Wrote: 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.
(2017-09-16, 04:27 PM)seandepagnier Wrote: 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.
Will have look at that, thanks. I have been post processing data using a SED/AWK script and GNUPlot - you may have seen it over on the OCPN forum - image attached
(2017-09-02, 09:43 PM)Littlechay Wrote: 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
(2017-09-02, 09:43 PM)Littlechay Wrote: 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 %.
(2017-09-16, 04:27 PM)seandepagnier Wrote: Is it using mpu9150 or mpu9255?? Is there a log output from rtimulib2?
mpu9150 I can't find a log output from rtimulib2. Where would I find it? and how would I recognise it?
2017-09-17, 02:55 AM (This post was last modified: 2017-09-17, 03:00 AM by seandepagnier.)
I just did a simple but very effective optimization to opencpn tracks today... It uses a lot less memory and loads tracks much faster. I haven't pushed any code yet.
Maybe you can upload all of your gpx tracks for testing.
If you use the mpu9150 you will get much inferior data, also using much more cpu compared to mpu9255.
2017-09-17, 04:48 AM (This post was last modified: 2017-09-17, 04:51 AM by Littlechay.)
(2017-09-17, 02:55 AM)seandepagnier Wrote: I just did a simple but very effective optimization to opencpn tracks today... It uses a lot less memory and loads tracks much faster. I haven't pushed any code yet.
Maybe you can upload all of your gpx tracks for testing.
If you use the mpu9150 you will get much inferior data, also using much more cpu compared to mpu9255.
I've PM'ed you regarding GPX files.
Do you have a source for the mpu-9255 .. Ideally in NZ or one that will ship this way?
sailoog might have a different solution keeping the sensors further away from the raspberry, but this seems to work fine. The problem is when the sensors are near magnetic interference like wires carrying a lot of current.
