From the OpenCPN manual: If “Show Magnetic bearings and headings” is ticked OpenCPN will use magnetic courses and bearings. By default OpenCPN uses true courses and bearings etc. Note that OpenCPN knows nothing about deviation. All magnetic courses and bearings will have an (M) suffix to show they are magnetic. "
Though the M is displayed in other places, it is missing when using the measuring tool.
Thanks,
Bruce
Be great to have an setting or ini setting to change measurements by the measure tool to feet.
Thanks,
Bruce
OpenCPN logs information to the log file.
Sometimes people (including me)need to be pointed to it to discover an important error message.
I propose that when serious errors are logged, a wxMessageBox be displayed, either with the error descripion or just saying 'Look in the log!'
I know that wxMessageBox blocks OCPN until dismissed. I am thinking here only of errors sufficiently serious that you should not be proceeding to sea without at least dismissing the box.
Examples might be:
- Plugin load error and jailing
- File permssions problem on crucial file
- Invalid .ini options for core
Alerts could be added piecemeal as a developer reviews the relevant code.
With Grib PI enabled and Grib file selected, every 9th column ofwindbarbs is missing at certain zoom levels.
Sending NMEA0183 as UDP broadcast has become a tradition since the very first gateways came out. However, there are 2 drawbacks:
1.) firewall issues -- On many OSes an exception rule needs to be added to allow listening on an incoming port. Also, routers might drop broadcast traffic as it is frowned upon (there we have another tradition...).
2.) only one app per OS -- As soon as one app is listening on a particular port, it is blocked for other apps.
Of course there is the option of using TCP connections, however to be frank, sending realtime data over TCP is not wise (e.g. with a weak WiFi signal, retransmission of packets and long timeouts only cause more congestion, delays and hangs).
So, why not using unicast UDP "connections"? Those have none of the above drawbacks. Of course, the app has to initiate (or rather request) the data transfer, quite similar to opening a TCP connection, but by sending a first data packet to the server. There is no protocol (yet), but sending an empty packed would be fully enough (probably neater could be sending an NMEA0183 message. any, even proprietary would do). I saw some RaspberryPi projects that accept any packet, so does the Pitufino gateway.
If the data stream stops for whatever reason, the app has to send another packet to the server to resume the transfer (again, quite similar to reopening a TCP connection).
There is no need for an additional protocol for terminating the transfer as all OSes have implemented the ICMP: as soon as the app no longer reads from its ephemeral port, the OS sends a message to the server, notifying that no one is listening any more.
Cheers and thanks for your great work,
Chris
Warning when installing 5.2.8 on Samsung Galaxy Tab S4 #2562
https://github.com/OpenCPN/OpenCPN/issues/2562
Posted for Capt. Don see
https://www.cruisersforum.com/forums/f134/opencpn-5-6-0-released-258634-2.html#post3555333
The DSE Sentence may have 1 to 4 DSE Expansion Data fields. The current implementation assumes only one field and assumes it is a enhanced position report. While it may be correct 99% of the time, if the first DSE Expansion Field is something else (Speed Over Ground, Course Over Ground, Persons On Board, Station Information etc), then the current implementaion will generate an erroneous position (out by perhaps nine tenths (0.9) of a minute which mayhave serious consequences.
At a bare minimum the decoding should at least ensure that the DSE Expansion Data Symbol is "00". Even better is to at least parse COG, SOG, Station Information (Ship's Name) and append that to the existing DSC data.
These patches add this functionality to the current beta release 0f 5.5.0
Waypoint Visability
5.2.4+6b314e6
Certain waypoints remain visable on the chart even when marked "X" on the Route & Mark manager. (see VYC W2, VYC W 1 and Vallarta Start RC 52) in the screen shot.
These waypoints cannot now be selected when defining a route (no option to "use nearby waypoint) although they have been previously. Several routes exist in Route and Mark Manager which include these waypoints
Creating a route to that location results in a new waypoint (Routepoint?) which then becomes a duplicate of the existing waypoint. giving a name and making it visible does not result in a waypoint which can be reused.
Previously created routes using that waypoint can be displayed and display correctly and use that waypoint and can be exported. Exporting and reimporting these waypoints in a route does not result in duplicate waypoints and does not apparetnly change the behaviour of either the waypoint manager or the route.
Making invisible a previously created route with that waypoint and selecting "make shared waypoints...invisible" does not work, yes or no.
These issues have existed in previous versions of O
The following tracker reports seem to be related.
2208
2384
2436
2696
Version 1.2.0.2 of Nmea converter_pi do not support the functions anymore. Had to downgrade to version 1 to make it work again.
add, subtrack and multiply does work.
I used the apparent to true wind conversion. All nmea values were substituted and shown but no calculations were made. Sqr, sqrt, acos, cos. Failed
no task description
no task description
Two GPX files that are before and after the application hangs. v1.5a is a working copy exported at 6am, v1.5b is an exported copy made at 11am after restarting OpenCPN in safe mode. v1.5b reproduces.
REPRODUCE:
Import v1.5a GPX, Right click the Route and choose Properties... Displays diaolog as expected.
Import v1.5b GPX, Right click the Route and choose Properties... Hourglass spins forever, Taskmgr reports max CPU allotment. Have to kill the process. OpenCPN restarts with safe mode dialog. Reproduces in safe mode.
I am using a clean Win10 machine with an i7 processor and 16GB of RAM, onboard Intel Iris video controller. 5.2.4+6b314e6 with O-Chart CHS Canada Pacific Coast catalog are up to date.
REPRODUCE: Plotted 945 appends or insertions up and down the coast, However, modifying any waypoints position (click and drag) the drag following stalls window output, There is plenty of headroom accessing Window>Start bar icons or search while OpenCPN. will stall screen output and the program and cause a non responsive message. The CPU is maxed out within its constraints. I also have a couple routes populating that i did not test.
EXPECTATION: If performance is reproduced and found as expected, a feature request should follow to allow splitting routes up. Or worst case, create a limit for maximum number of waypoints are appended and inserted.
logfile.txt attached
For InterOperability (IO)
RTZ is an international standard and mandatory for ECDIS.
This format should be implemented in O as an alternative to GPS, selected by user choice.
"Rasbats" has a converter RTZ/GPX brewing here https://github.com/Rasbats/opencpn.rtz.assist
This is a bug report to do with the "Move boat here" command when a waypoint/mark is selected. Using the command, the boat moves to the exact spot of the mouse click, rather than to the coordinates of the selected waypoint.
This also affects the "Drop Mark" command in the same menu, and presumably any other commands that use the click coordinates.
I observed this in v5.2.0+4d956e1, on Mac OS 10.14, but it is reproducable on other systems as well.
Reproduction steps:
1) Right click near a waypoint
2) Waypoint becomes selected (yellow highlight) and context menu opens
3) In that menu, select Main Menu > Move Boat Here
4) Boat position is moved to the position of the click instead of the position of the waypoint.
See thread athttps://www.cruisersforum.com/forums/showthread.php?p=3208339for more details
Hello Team,
Monitors/Displays get bigger and cheaper and a standard Win10PC or RPI is able to handle multiple Displays. They could act as individual plotters utilizing the same data connection to N2K.
Would be nice if you could concider this. More and more commercial programs or Plotter go the same route.
Thank you!
Looking at Porto Cristo on the eastern side of the Spanish Island of Mallorca.
In the harbour there are a lot of the seabed that is marked 'unk' for unknown in oeSENC. In Cm93 these are correctly marked as 'sand,stone', 'mud,stone' or 'mud,sand' respectively. See screenshots below.
The problem is with interpeting the SBDARE->NATSUR containing two attributes with a "," in between.
There have been two cases recently on the forums where posters had equipment that transmitted incorrect NMEA checksums (equipment fault). Proper response is to get the equipment fixed, but O does have the facility, through connection settings, to ignore checksums. This function does not appear to work correctly. Even after users were able to remove the checksum flag from the connection configuration (notin itself a simple task) O appeared to continue checking the checksum, or at least it continued to ignore the data (even though the sentence, minus the checksum, was valid).
Solution in both cases was to use the NMEA plugin to read the bad sentences and recast them for use, but since the option is there in the connection dialog the program should properly ignore checksums and parse/accept all data when the connection configuration is set to ignore checksum.
Please review NMEA code to confirm that checksums can be/are ignored when requested.
OpenCPN_5.0.1+0266678,Weather_routing-Plugin-macOS-ov50_1.13.0, MacOS 10.14.6.
Route Position under View - I have just discovered that so long as the weather route remains in the Eastern Hemisphere (000E - 180E), then the Route Position window reports correctly. It does not work if the weather route is in the Western Hemisphere (000W - 180W). Ifthe weather route crosses the Anti-Meridian(180W/E), then the Route Position window reports the Eastern side correctly, but it does not report the Western side.
The Route Report is a great feature and it would be fabulous if it were working for the Western Hemisphere.
V5.0 introduced changes that alterthe behavior of Range Rings with Waypoints. V5.0 removed the Show Range Rings check box for waypoints and added the ability to set the default for range rings to all newly created waypoints. The removal of the Show Range Rings check box caused Range Rings to mysteriously start appearing around waypoints. Although the check box was removed the underlying identifier(Visible Flag) was still being used to determine if range wings should be displayed.
Background:
In prior versions of OpenCPN when a new waypoint was created the settings for range rings were taken from defaults in the opencpn.ini file that couldnot be updatedfrom within OpenCPN. In my case all previously created waypoints had the Show Range Rings(VisibleFlag) set to false, the Number of Range Rings set to 1 and the spacing set to 1nm and the color set to red.
Note:I am unsure how the original defaults in the opencpn.ini file were set. Many of my waypoints were created years ago so I assume the defaults were long ago. I would think everyone who upgrades to V5.0 would be experiencing these issues, but the number of people reporting seems to be very low.
Issue 1 - Range Rings Mysteriously Appearing Around Waypoints
V5.0 removed the Show Range Ring check boxto determine the value of the Visible Flag and instead used the Number of Range Rings to automatically set this flag. If Number of Range Rings is greater than 0, the Visible Flag is now set to true.
After the initial installation of V5.0 all waypoints appear normally without range rings due to the existing value of the Visible Flagbeing set to false. However, once a waypoint is in anyway updated, the program checks the Number of Range Rings and then sets the Visible Flag according. Since the prior default for Range Rings was set to 1, the program changes the Visible Flag to true and a range suddenly appears around the waypoint.
Possible Solutions:
The Show Range Rings check box could be added back to the Waypoint Properties so the Visible Flag is determined by the setting of the check box rather than the Number of Range Rings. This is probably the best option as it maintains prior functionality for anyone who wants to utilize that function and would also prevent any future installations of V5.0 from introducing this problem.
If a decision is made to eliminate the Show Range Ring check box, the V5.0 update routine could go through all waypoints and set the Number of Range Rings based on the value of the Visible Flag. If the Visible Flag is set to false, set the Number of Range Rings to 0. This prevent any future issues but would create an issue for any user that was setting range rings and then temporally turning them off with the check box. I would think this would be minimal.
Workarounds:
The easiest solution is to simply call up each waypoint and change the Number of Range Rings to 0. If you have hundreds of waypoints, this will not be an easy task.
For users with many waypoints it may be easier to export all of your waypoints to a GPX file and use a text editor to find/replace to correct the settings, then delete all of your existing waypoints and and import the corrected file. The line of code you need to correct in the GPX file looks like this:
<opencpn:waypoint_range_rings visible="false" number="1" step="1" units="0" colour="#FFFFFF" />Do a find and replace number="1" with number="0" and then find/replace step ="1" with step="0". This will prevent any future updates to waypoints from incorrectly setting the Visible Flag to true.
If you have already performed a number of updates on waypoints and have range rings being displayed you can also do find/replace on visible="true" and replace it with visible="false".
Issue 2 - Default Settings For Waypoint Range Rings in Setup Options
V5.0 added the ability to specify the default range rings that will be applied to all newly created waypoints. This new feature alsoeliminated the previous Show Range Rings check box and utilizes the Number of Range Rings to set the Visible Flag in all subsequently created waypoints. The defaults for this new feature utilized the defaults that existed at the time in the opencpn.ini file as described above.
I immediately updated this afterinstalling V5.0, so I am not certain,but think it may be possible after installing V5.0 to create waypoints without range rings appearing based on the default visible flag being set to false. Once any setting is changed in the setup the Visible Flag will be changed based on the value in the default Number of Range Rings.
Possible Solution:
Either the check box should be reintroduced to the new waypoint default or the update routine for V5.0 should change the defaults for the Visible Flag to false and the Number of Range Rings to 0 so the creation of waypoints functions as it did in prior releases.
Window colors and context menu not adapted for night mode
I mentioned this early when mbtiles was first time discussed on the opencpn cruisersforum, and Dave thought this to be a good idea for a Plugin:
http://www.cruisersforum.com/forums/f134/mbtiles-for-opencpn-197726-3.html#post2581576
Feature request:
Could this be expanded to read the chart/tiles cache from SAS.Планета directly, without the user needing to create MBTiles, when the cache is already there, in well structured folders?
Since quite a few users already seem to use SASPlanet to get their satellite, Navionics, CMap, etc charts as tiles, I would like to see this in the core OpenCPN. But I would be content with a plugin too.
Dirk
Hello,
the statement on the website that Tacktic is not available for Linux is now incorrect.
I have packaged it with ease for Linux OpenSUSE and it could be certainly be done for other distro as it does not require anything extra compare to other plugins.
Regards
Dominig
https://build.opensuse.org/package/show/Application:Geo:OpenCPN/OpenCPN-tactics_pi
would like to have a way to show a short analysisof the grib file like
- type of data
- grib dates
- coordinates covered etc-
see attached
In setting the parameters to add the metric system of measurement for distance and speed, only now knots and miles
Text does not rotate properly.see
http://www.cruisersforum.com/forums/f134/chart-rotation-plugin-oesenc-charts-text-wrong-place-207003.html#post2715251
Use RotationCtrl to test the plugin.
https://github.com/seandepagnier/rotationctrl_pi/issues/7
In the logbook preferences unde capacity / fuel it would be nice to set also default consumption per engine per hour.
Even with more than 1 engine (e.g. catamaran) they are usually of same type / and similar consumption.
This value could/should then be used to calculate approx consumption based on engine hours (except if ERRPM sentences are received)
When user had entered rpm manually and engine is still running it could be assumed for the next automatic logbook entry that this rpm is remained.
It is possible to have multiline title on Dashboard by using \n in title. Unfortunately the title just goes over data and does not extent title area for multiline. Dashboard could extend data title area higher in case of multiline title exist.
This is important on e.g. languages like Finnish, which has long words. Explanative titles becomes too long to fit to title area and using shorts makes them inpossible to understand.
Other option would be to have possibility to use shortcut and explanation. E.g. "AWA & AWS ..." By hint or pressing ... one could get explanation "Apparent wind angle and speed"
If there is no connection, Dashboard seem to use some 0-date for Sunrise/Sunset calculation. It could use in that case system date/time to get calculation right.
If a .gpx file is imported more than once, or if the sameroute or track is in the .gpx file that has already been imported, then a duplicate route or track ends up in the system. Waypoints are not however duplicated with the same process.
This was found when:-problem of waypoints (not route points) being hidden when hiding route that is using them. On hiding route in "route and mark manager", the option is given to also hide shared waypoints, selecting no, the waypoints are hidden anyway. The waypoints are visible on the waypoints tab and are not marked as hidden, toggling this on and off makes not difference, they will not show on thecharts.
I determined that this secondary bug was caused by having a duplicate route in the system. Deletiing the duplicates did not solve the problem.
See attached screenshot showing duplicate routes.
It could be useful to add to the plugin API to allow retrieval of PICREP as well as OBJNAM from S57 ENC.
Similar to:
virtual void SendVectorChartObjectInfo(wxString &chart, wxString &feature, wxString &objname, double lat, double lon, double scale, int nativescale);
Above from 'ocpn_plugin.h' API 112.
Both U.S. and European Inland ENC have useful .JPG images which add to pilotage information.
'Objsearch_pi' could be extended to add PICREP to the database and allow a link for displaying the .JPG.
AIS Summary - Display and Alarms http://www.cruisersforum.com/forums/f134/do-we-need-want-an-ais-filter-157030-2.html#post1974430
Alarm settings ideas
1. DONE Proximity FS#1881 - Establish a guard zone (distance) as in radar. Include a time element guard zone.-Done in Ocpn_Draw + WatchDog, Jon Gough (both proximity and boundary guard alarms).
2. Reduce nuisance alerts FS#807 - To allow users to acknowlege an AIS Alert from the AIS Target List after the Alert has come up and has then dropped off the screen. Thus giving the user more time to disable the alert! -Not implemented, please see FS#807 for more details.
3. AIS Alarm acknowledge shortcut FS#1260 Provide a shortcut key + left mouse to close one or all Acknowledge alerts that are outstanding. -Not implemented. --Does have Target Alert Acknowledge Timeout (min) -NOTE this will help stackup of Alert notices.
4. DONE Temporarily Disable Alarms FS#1573 - Provide an Icon Button toggle to temporary stop all acknowledge alerts. DONE --> Menubar > AIS > Checkbox-Sound CPS alert Checkbox-Show CPA alert, etc. Provide audible alarm instead (option) DONE -Now Menubar > AIS > Checkbox-audible alarm.
5. DONE The suggested filter for SOG max - is Implemented - DONE - Under Display, Hide moored/anchored targets, speed max (kn) .2 user defined. 6. Small AIS enhancements FS#668 - See #5 See http://www.cruisersforum.com/forums/f134/do-we-need-want-an-ais-filter-157030-2.html#post1974430
Alarm Clutter ideas
1. DONE Suppress CPA calc for boats at anchor FS #1826 -DONE- Implemented - Menubar > AIS > Checkbox-Hide Moored Targets, Under CPA/TCPA Alerts -Checkbox - Suppress alerts for Anchored/Moored Targets (reduces load & clutter, but what happens in fog? hit boat at anchor? or depend on radar?)
2. DONE Make Make targets user definable FS#668 - not implemented, but RooieDirk's idea is more logical and ordered in the way it adjusts the size of the AIS. - Working.
Friends/Follower Features
Permanent Disable for certain types DONE FS#1884 AIS Remember "white" list - fleet, friends, disable alarm, proximity - Similar to Vesper. Hakan implemented "Follower" class which disables alarms, Vesper has some additional nuances.
FS#1929 - AIS Remember List - Friends Extend capability of friends so that Friends can be sorted and kept together, etc
after using OCPN further and gaining more experience with the chart displays, i believe the switch from km to sm should not be user selected as it's independent of which units a user prefers to use - metric, sm, nm.
all USACE inland river charts and all NOAA costal charts of the Intracoastal Waterways use sm astheir distance marks. so if a user prefers to see knots and nm on screen, they still need to see sm on the chart since that's what the chart is measuring and showing.
perhaps the best solution (not knowing the code and programming issues) wouldbe for O to recognize USACE and NOAA charts and automatically label a distance mark as sm instead of km.
the distance marks are a chart feature and appear 1 sm apart on USACE charts and usually every 5 sm on NOAA charts. and the numbers that currently appear by each distance mark are correct statute mile numbers. so nothing needs to be done to correct the distance, it's just the label (now km) that O applies to them that should change to sm.
related to this, O overlays part of the mile number on top of the "km" making things even harder to read. and the magenta color is amazingly hard to read on screens, particularly in daylight. i've attached a screen capture shoing this to save you the trouble of loading a USACE chart. (OCPN for Android has changed this to show the mile number in black. huge improvement in readability!)
BTW, everything here except the mile number color needs changing in O for Android. is that adressed in this place as well, or does the Android version have its own request/change platform?
thanks
--------------------------
when using inland waterways ENCs from the USACE (for example the Illinois Waterway and the great loop inland rivers) the dot indicating each mile marker is labeled "km" stemming from the European IENC spec. this request is to automatically (or perhaps manually) be able to show the correct label "mi". or perhaps "sm" for statute mile would be better since those are the specific units used? thanks guys.
- New Clock for local time
- Existing Clock for UTC
It would be nice if the user can select the way the time clock is displayed (UTC or Local time). This can be quite confusing, in the clock is displayed is in UTC while orther plugins (gribs) can displayed it in UTC or local zone (choice given to the user). Serge
Fleur de Sel (belle-isle) - Thursday, 11 June 2015, 07:19 GMT-5 wrote: As of present, Clock and Sunrise/Sunset widgets in the Dashboard plugin are only in UTC. I would request a way to have this information in Local Time as well.
I can see the following possibilities :
In Dashboard Preferences > Appearance > Units, Ranges, Formats , add radio buttons or a dropbox to select between :
- UTC, Local or both.
- In Dashboard Preferences > Dashboard > Instruments ,
Rename the current instrument widgets to Clock UTC and Sunrise/Sunset UTC, and
then add
- Clock Local,
- Sunrise/Sunset Local,
- Sunrise/Sunset Both,
- Sunrise/Sunset Local, and Sunrise/Sunset Both
Finalization of the play mode
- Display the date and time playback. Much better controls.
- Speed Up/Dwn-Speed up bar. Checks for 0x, 10x and 100x speedup.
- Buttons for Play, Pause, Speed up the playback button, a Play Next File or previous file. (similar to grib_pi, ability to backup, restart, click on a location on the timeline to restart, move forward or whatever.
- Play what you want - Ability to select where to start on the timeline. Click on timeline to restart playing at that location. -Yes!
- Checkbox for play continuous loop single file, or play a series of predefined files in a loop.
- Ability to filter out AIS sentences or to include them... (two lines, using comma separate terms)
- Means of filtering other NMEA sentences.
- Means of selecting/highlighting only certain NMEA sentences or just one sentence, and sending those to Opencpn.
- VDR player needs to have a window, where you can paste a nmea sentence in and then push a button to send the sentence! (of course when the Player is stopped).
- A nmea debug window like opencpn, scrolling what it is reading in.
- Nmea debug window -Ability to highlight and copy the nmea data.
- We need to be able to pause or stop the reading of the file, then be abble select/highlight a sentence in the nmea debug window and then be able to send it directly to OpenCPN to test the sentence and see what happens.
- Even copy an section of nmea that has been isolated as the culprit area from the Nmea Debug window.
- Join these features with the Opencpn debugger?
- Have a checksum calculator that checks every sentence and highlights bad checksum and proposes new checksum if wrong. http://www.hhhh.org/wiml/proj/nmeaxor.html I have a spreadsheet checksum calculator which might help with this because the formulas would be there.
- Recording settings - Automatic recording when you start openCPN, create a new file every 24 hours, path to the file folder records.
- We need a good shortcut key to pop up the Nmea Debug Tool How about "N" which is open? Mike Rasbats has done a fair amount of work on an updated VDRplus which is much better than the Current VDR. https://github.com/Rasbats/vdrPlus
Integrate ability to initiate a DSC VHF Call to an AIS target from the AIS Context Menu. A number of current DSC VHF radios enable another device (such as AIS transponder) to initiate the DSC call via a NMEA sentence
For example: I have an Icom 502 VHF radio that supports the NMEA 0183 DSC Initiate sentence which is of the format:
$AIDSC,DSC Message Type,MMSI Number,Category,First Telecommand,Second Telecommand,VHF Channel,Time ,MMSI of Ship in Distress ,Nature of Distress ,Acknowledge Flag,Expansion Indicator*25
Where
- DSC Message = Individual Call (encoded as 20)
- Category = Routine (encoded as 00)
- First Telecommand = F3E/3GE All Modes (encoded as 00)
- Second telecommand = No additional Information (encoded as 26)
- VHF Channel is encoded as per Paragraph.3.2.2.2 of the Standard.
for example to request Channel 8, it is encoded as 900008900008 Time,MMSI Number of Ship in Distress, Nature of Distress and Expansion Indicator are null
The relevant standard is ITU-R M.493-13
Other VHF radios may use different sentences, for example Garmin uses NMEA 2000 and therefore a different sentence, Standard Horizon reputedly uses a proprietary sentence format.
Make the possibility of a global setting Units of measurement in OpenCPN. someone accustomed to use the metric system of measurement -
- Distance: kilometers and meters, feet, yards, nautical miles nautical miles and feet, nautical miles and yards.
- Spot soundings: feet, meters, fathoms.
- Mast Height: meters, feet.
- Speed: knots, kilometers per hour, miles per hour.
- Bearing: Magnetic, true
- Fuel: Gallons, Liters
- Position: degrees minutes seconds, degrees and minutes, degrees.
- Time: 12 hours, 24 hours
- Date Format: YYYY-MM-DD or mm-dd-yyyy
- Temperature: Fahrenheit, Celsius.
- Wind speed: knots, kilometers per hour, meters per second.
- Pressure: mBar, mmHg, Pa.
- Current Velocity: knots, kilometers per hour, miles per hour.
Also NOTE: Related but separate OwnShip Settings FS#1102
Consider this note requesting Small distance units FS#2407
