Feature Requests

[petermoree]

A similar request is listed with the *features requested* list for the dashboard plugin.
Lots of ships have their GPS signal separate from the other NMEA data. Therefore a separate port selection option is desirable for the plugin.

Peter

[svpresent]

Originally Posted by bdbcat

(...)
In fact, the Route->SendToGPS function needs to be extended to support various non-compatible "NMEA compatible" GPS units we have found. We need more real time data, and lots of different GPS unit tests to develop these extensions. This is on the "someday" list.
(...)

Dave,

The new Furuno GP33 differs from the GP32 where the RTE/WPT exchange file is concerned. Via manual entering of waypoints, adding them to a route and some down and uploading using hyperterminal I found out the following files works flawlessly.


$PFEC,GPwpl,1302.2565,N,06145.4622,W,WP0001,3,@q12 :57 14DEC10,A,,,,
$PFEC,GPwpl,1402.2570,N,06145.4617,W,WP0002,3,@q12 :57 14DEC10,A,,,,
$PFEC,GPwpl,1502.2569,N,06145.4618,W,WP0003,3,@q12 :57 14DEC10,A,,,,
$PFEC,GPwpl,1602.2568,N,06145.4618,W,WP0004,3,@q12 :58 14DEC10,A,,,,
$PFEC,GPwpl,1702.2565,N,06145.4622,W,WP0005,3,@q12 :57 14DEC10,A,,,,
$PFEC,GPwpl,1802.2570,N,06145.4617,W,WP0006,3,@q12 :57 14DEC10,A,,,,
$PFEC,GPwpl,1902.2569,N,06145.4618,W,WP0007,3,@q12 :57 14DEC10,A,,,,
$PFEC,GPwpl,2002.2568,N,06145.4618,W,WP0008,3,@q12 :58 14DEC10,A,,,,
$PFEC,GPwpl,2102.2565,N,06145.4622,W,WP0009,3,@q12 :57 14DEC10,A,,,,
$PFEC,GPwpl,2202.2570,N,06145.4617,W,WP0010,3,@q12 :57 14DEC10,A,,,,
$PFEC,GPwpl,2302.2569,N,06145.4618,W,WP0011,3,@q12 :57 14DEC10,A,,,,
$PFEC,GPwpl,2402.2568,N,06145.4618,W,WP0012,3,@q12 :58 14DEC10,A,,,,
$PFEC,GPwpl,2502.2565,N,06145.4622,W,WP0013,3,@q12 :57 14DEC10,A,,,,
$PFEC,GPwpl,2602.2570,N,06145.4617,W,WP0014,3,@q12 :57 14DEC10,A,,,,
$PFEC,GPwpl,2702.2569,N,06145.4618,W,WP0015,3,@q12 :57 14DEC10,A,,,,
$PFEC,GPwpl,2802.2568,N,06145.4618,W,WP0016,3,@q12 :58 14DEC10,A,,,,
$GPRTE,3,1,C,1, WP0001, WP0002, WP0003, WP0004, WP0005, WP0006, WP0007
$GPRTE,3,2,C,1, WP0008, WP0009, WP0010, WP0011, WP0012, WP0013, WP0014
$GPRTE,3,3,C,1, WP0015, WP0016
$PFEC,GPrtc,1,WP0001 ->WP0016,RT0001
$PFEC,GPxfr,CTL,E

From Furuno tech support, I understand PFEC stands for "Propriatery Furuno Electronic Communication". If you need more info, just let me know.

Thanks for your great program,
Len.

[xuraax]

Originally Posted by jonasaberg

Hi Xuurax,

Welcome as a OpenCPN and forum user.

This is strictly not a OpenCPN thing, it is related to your operating system and its screen saver and power saving options.

You do not mention which operating system you use. If it is windowsXP you set this like this:
Right click on the desktop, choose "properties". The "Display properties" window will open. Chose the "Screen saver" tab at the top of the window.

Check if you have a defined screen saver and how long it will take until it turns on and choose a suitable time or disable it.
Then, click on "Power" in the bottom this will open the "Power options properties" window.

In this window you set how long time it should take before the monitor turns off depending on if you run on mains power or battery.

Hope this helps
J

thanks for your speedy reply.

I know about those options but this is not exactly my request.

Using the standard windows setups will result in ALL programs remaining on and not just Opencpn. This may not be what you want especially if you use the PC for normal functions besides navigations.

I believe windows has an api which when invoked from within a program it disables the screen from going to standby. This would work for that program only.

Regards

[champ8242]

What xuraax means,

case WM_POWERBROADCAST:
if (wParam==PBT_APMQUERYSUSPEND)
{
return (BROADCAST_QUERY_DENY);
}

This Windows message will abort the the Sleep, Stand-by or Hibernate call made by the system. The system will broadcast the PBT_APMQUERYSUSPENDFAILED event and tell applications keep on running.

[SethDart]

Originally Posted by petermoree

A similar request is listed with the *features requested* list for the dashboard plugin.
Lots of ships have their GPS signal separate from the other NMEA data. Therefore a separate port selection option is desirable for the plugin

Hi Peter,

This may be part of future development but IMHO inside core OpenCPN, not the plugin. Managing COM port, NMEA routing inside a plugin is not possible (yet) with current API. It's a huge task, further more with such multi-platform software.

I had a request a few month ago about ability to receive NMEA data from the autopilot port (rudder angle for example). For now it's write only: waypoint & route data is sent but nothing is read from this port in OpenCPN. There's a feature request open

I'd like to create (or maybe someone else if interested) a VDR plugin: Voyage Data Recorder with options to replace the current (basic) logbook. This plugin may also have the ability to replay NMEA sentences previously recorded. It would require API change to read NMEA stream from plugin and use it inside whole OpenCPN & plugins (boat moving on the chart, dashboard displaying data...)

So this is part of a major enhancement in OpenCPN: to be able to receive NMEA data from multiple sources (one or many, mix of COM / USB / ethernet / plugin) then route it appropriately everywhere: we may receive the same sentence from multiple sources, user shall be able to select the one he wants to use for each application.

This is pure imagination, it may be done this way or just another way or maybe not done at all. We'll see where next beta development takes us Dave may have a roadmap and probably a huge list of feature requests stacked somewhere This may not stick to the KISS principle

[jonasaberg]

Originally Posted by champ8242

What xuraax means,

case WM_POWERBROADCAST:
if (wParam==PBT_APMQUERYSUSPEND)
{
return (BROADCAST_QUERY_DENY);
}

This Windows message will abort the the Sleep, Stand-by or Hibernate call made by the system. The system will broadcast the PBT_APMQUERYSUSPENDFAILED event and tell applications keep on running.

Xuurax, Champ...

Cool, This is quite good.

However, if implemented it should be user configurable.

We have the display under deck. When no one is watching the screen I like it to be turned off to save energy. We go under sail, and power is scarce...

/J

[decjd]

SethDart, Peter, et al

My original question was to determine if there is a preexisting way of getting more than one source of NMEA data into OpenCPN. The reason I asked is because I'm interested in purchasing a depth transducer that outputs NMEA data but there seems to be no way to get it into OpenCPN and I was wondering if it has already been solved.

If it hasn't been solved, then I would like to respectfully recommend that we add a network socket (either TCP/IP or UDP) so that another external piece of software can collect all the NMEA sentences and send them to this socket (BTW a socket is already being used for libGPS data, but it doesn't read NMEA sentences). The current input interfaces can remain as they are since most people are using a single GPS or AIS unit.

I would add it myself but I would like input from Dave and others who are more familiar with the input side, so that I don't screw up any critical timing (if this is even a problem). So any comments on this would be appreciated.

Regards,
Jim

[SethDart]

Originally Posted by decjd

My original question was to determine if there is a preexisting way of getting more than one source of NMEA data into OpenCPN.

For now, the easiest way is to use a multiplexer, either hardware or software so you can receive multiple NMEA sources in one COM/USB port.
You can use software such as VSPE (Virtual Serial Port Emulator), NavMonPC can also do the job. There are probably many more solutions around.

The TCP input/multiple NMEA source will probably be discussed part of the future development, stay tuned!

Regards,
Jean-Eudes

[HotRod]

The NMEA issue should be rewritten as suggested.
The ability to have several NMEA inputs, without having any software or hardware multiplexer is a must. I was not aware of this problem yet, but I can see that this will be a problem.
I have many NMEA sources today (GPS, Echo sounder, AIS, MARPA, Wind and Navtex) and I would like to use most of them at a point when I replace MaxSea with OCPN.

There should be a tab containing I/O settings for all comports and devices.

The option to use network should be there to share gathered NMEA data, not for receiving NMEA.. as you need a serial to network adapter for this...
Keep it simple...

[Sailing Hanse37]

Hi some months ago i posted my at that moment starting project:

• making a good instrument panel for displaying sail polars. Polarcom is a good example for an instrument panel approach, but lacking sail polars
• Better storing of panel positions (sometimes polarcom is weird for this)
• getting a full polar database and auto-correct possibility through recording actual sail data and analysing them

Well while programming you get some ideas, so now there is more in the pipeline:

• Full WYSIWYG configuration of multiple instrument panels: 100% finished
• All Polarcom goodies have been integrated 100% finished
• Night view 100% finished
• Analysis tool incorporated for NMEA datastream 100% finished
• Reproduce all polarcom dials + extra usefull dials 100% finished
• implement alternate dials: by clicking on a dial panel, you get a next alternate panel (i don't need same instruments for manoeuvers in the harbour as when i'm sailing) 100% finished
• Get a compass band on top as on chart plotters. 100% finished
• Dial displays without window borders to optimize display (borders can be switched on and off) 100% finished

To do:

• 'connect NMEA decode' routine to dial procedures 0% (but easy work)
• Setting up sail polar database 20% (well here is still some work to do)
• Recording routine is ok, but analysis for polar has to be done, so finished 20%

My deadline of end of march seems quite realistic
Scope of project will be extended with full trip recorder & playback possibility by end of march i hope...
Will be posted then in open source, but is written in Lazarus...

I'll post some screenshots if somebody is interested
Greetings,
Francis

[jonasaberg]

Francis,
Yes I am very interested in this. Please post screens.
Will this be an opencpn plug in?

/J

[idpnd]

Originally Posted by Sailing Hanse37

• making a good instrument panel for displaying sail polars. Polarcom is a good example for an instrument panel approach, but lacking sail polars

Sounds great Francis, you may wish to look at capcode, he made free software polars albeit in java

[Sailing Hanse37]

Hi,
i made some screenshots. See Below
First of all the answer to some questions: since i started this project at the very beginning of the opencpn plugin development, and since i didn't want to get stuck on my program due to not mature plugin structure... i programmed this as standalone. I'll first finish it as standalone and will later on look to have it adapted to the plugin structure (if possible since written in Lazarus, which is object-pascal and not c++) At this moment you have to consider the program as a more sophisticated polarcom. (which i.m.h.o. is not a problem, since i'm using polarcom nowadays, till this one gets completely ready. And it justs works fine)
Capcode: i looked at this program. it has a lot of possibilities but to me user-interface looks as if not finished.
Now the screenshots:

1. Normal view in daycolors. You see the compass band on top, on the right side you have true wind and app.wind in analog and SOG + STW in digital. Under that you have sail polar information in analog and digital. Don't look at displayed value at this moment, since the panels are not yet coupled to the NMEA datastream (for testing purposes)
2. Alternate view: when entering harbour you just click somewhere on sail polar panel and it will toggle to alternate panel. In this case we display rudder angle and depth information.
3. Now same screen in night view.
4. Layout of panels, number of panels, alternates and number of alternates can be configured on the configuration panel which has a WYSIWYG approach.
5. NMEA analysis tool allows you to get input from com port or from file and analyse sentence by sentence, check which instruments are transmitting on the bus, check GPS-signal, ... It also keeps track of errors on the bus and can of course record the NMEA datastream for later analysis.

Footprint of the program: 1.5 MByte standalone file (no libs or dlls needed just 1 file), processor charge typically 2% on my quadcore. (will be a bit higher on my laptop, but should be acceptable)

[Sailing Hanse37]

rest of screenshots

[petermoree]

Looks great.

Can you have a look to my comments on the graphical depth representation.
See FS#292 : Depth graphic representation

I enclose the Tsunamis pictures here again

Peter