Feature Requests

[bdardy]

Why not !
I am not a developer, but I have not actually seen in the code i18n.
so how we can work ?

[GPS-Marco]

About translation, I know Italian (and the Italian nautical language). If someone gives me a list of words, I can translate them.

Ciao, Marco.

[idpnd]

The PO file that was discussed here is most probably based on GNU gettext; the source will have to be modified as described here. I would do the modifications (with a little pointing from Dave?) or perhaps "rkuris" will magically reappear. I would certainly finish the German translation.

Although most people are able to learn the limited nautical language associated with an icon-driven GPS programme, I do feel people are more likely to use and support OpenCPN if it were to be supplied in their native language.

Thanks for your attention

[bdardy]

Ok
I get PO, it is valable for 1.3.4 ?
bd

[jonasaberg]

I might have misunderstood this since I have yet to use OpenCPN during "real" navigation.

When using an active route there is a "Route" and a "Leg" window.

Leg:
I guess that the "TTG" means Time To Go and indicates the time to the next waypoint.

Route:
I guess that TTG indicates the time remaining to the final waypoint in the route.

I suggest that the route TTG is renamed to TTTG for Total Time To Go. This is a notch more clear.

If possible I would like it to be possible to adjust the font size in the route/leg dialogue (and other windows too) to customize the appearence for different sized displays.

/Jonas

[sinbad7]

Ref use of GRIB overlays in OpenCPN.

Is anyone aware of this fact?

While this looks like a good tool, people should realize that GRIB is merely a data interchange format, and that GRIB files from different sources have different content, based on different underlying meteorological models. The GRIB files from this organization use the GFS 0.5 degree (about 55 km) resolution model, which provides useful data on a world-wide basis, but is much too coarse for detailed local forecasting. Remember that a gridded dataset can't represent features smaller than twice the grid interval, and that little things like mountains and hills are represented by blocks 55 km on a side! The models used for short-range forecasting by the Met Office are 12.5 km resolution - still too coarse for inshore detail, but much better. What this means in real terms is that a small weather system can easily be missed in these data.

[jonasaberg]

That is true.
But true is also that meteorological models are always differing to varying degree in their result/prognosis. This is no surprise considering the complexity in weather.

It is always good in all situations in life to critically evaluate the information you build your decisions on, but that does not mean you should not evaluate the information that is available.
Most of the time a grib file representing a prognosis made with a course grid is still better than just putting your wetted finger in the air.

This said, Sinbad is right and one should value the validity of the data in the grib file and not trust it blindly.

There is usually much better grib files availlable than the "free" ones. As an example there are 5km models and finer availlable for the baltic sea and commercial products that use these. There is a free application here, http://sailplanner.net/ but you have to pay to get the high quality forecasts so I guess it is not really totally free. It is nice to check out though...

/Jonas

[jonasaberg]

Dave,
We have a Nexus Marine navigation system in our yacht. It is similar to a Raymarine/B&K or any other similar system but maybe a bit more open since all protocols are published or open.
It consists of a "server" to which GPS/Compass/Wind/Log/Sounder sensors are connected. The sensors can be proprietary or NMEA
The server contains logics so that you can program waypoints and routes by a pc interface. (Putting numbers in boxes, totallly ungraphical and quite static)
The server communicates with instrument displays using a RS485 bus.
The server communicates with a pc using a RS232 serial interface using NMEA183 or a proprietary protocol called FDX.

We use the system like this:
1. During short trips we use a navigation program like Fugawi or Seaclear. (we have tried Tsunamis earlier and it works too). We graphically program waypoints and routes and let the navigation program feed BTW/DTW/XTE information back to the Nexus server that relays the data to the displays in the cockpit for the person at helm to read.

2. During long offshore legs we export the route using the "Export NMEA" function in Seaclear to the Nexus server. We then turn of the pc and let the Nexus system keep control of position BTW/DTW and XTE. This save batteri power since the Nexus system use power in the milliwatt scale instead of 30W or so for the pc.

3. It is also possible to let steering information from the pc to control the autopilot which is nice at times.

I guess that the other big ones (Raymarine etc) have similar capbilities of displaying navigation information sent from a pc.

My feature request is:
I would like it to be possible to send information from OpenCPN to the Nexus system for all three above. If you think this is interesting I will try to figure out exactly which NMEA strings that are needed to make it work, at least for the Nexus system.

For us it is almost essential since it is to far from the helmsman to the navigation table and we often sail shorthanded, an sleeping and one sailing. The instruments are real nice, even if we always keep charts as backup.

Is this interesting?

It probably means that there is a need to output some NMEA strings, maybe RMC and XTE for 1. above.

Maybe an NMEA export of the waypoints in the route, unsure of the format but can check

The autopilot may work already, since OpenCPN is sending out an autopilot string.

/Jonas

[idpnd]

Uploading waypoints to a hand-held GPS unit would certainly improve redundancy and permit switching off the pc to save main battery power.. Is this not doable via GPX export?

[bdbcat]

jonasaberg...

This is interesting.

I wonder if the simple WPE/RTE NMEA strings that are used for Route->SendToGPS will work unmodified? Or a special config flag to alter the behavior may be needed.

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.

Apparently the NMEA0183 spec is ambiguous on some stuff, at least to some developers. Things like upper/lower case conversions, waypoint naming conventions, etc. That's why GPSbabble needs so many individual unit modules, for instance.


Can you somehow capture the NMEA data stream between your PC and the NEXUS system for analysis? Then we could look at it, and see what must be done.

Thanks
Dave

[jonasaberg]

Dave,
I am going to make a try. It will take a while.

I will try to do this:
1. Get the data stream sent from seaclear to Nexus during normal navigation.
2. A datastream when sending waypoints/route info to Nexus.
3. Autopilot info sent from Seaclear to Nexus.

All will be "dry sailing" since the yacht is at its winter rest - on land.

/Jonas

[jonasaberg]

After a somehat shorter while than I had assumed...
Seaclear has a "NMEA ouput monitor" built in.

I created a route with five waypoints and exported it. This is the content of the "NMEA output monitor window":

$ECWPL,5914.424,N,01840.002,E,01-*72
$ECWPL,5913.632,N,01840.161,E,02-*77
$ECWPL,5913.291,N,01838.696,E,03-*7B
$ECWPL,5912.389,N,01838.296,E,04-*71
$ECWPL,5911.598,N,01835.663,E,05-*76
$ECRTE,5,1,c,SEACLEAR,01-*2C
$ECRTE,5,2,c,SEACLEAR,02-*2C
$ECRTE,5,3,c,SEACLEAR,03-*2C
$ECRTE,5,4,c,SEACLEAR,04-*2C
$ECRTE,5,5,c,SEACLEAR,05-*2C

The EC is, I think, just to letters that are supposed to indicate the type or manufacturer of the sending equipment. It can be set to any other two letter combination. If I change it to OC för OpenCPN the output reads:

$OCWPL,5914.424,N,01840.002,E,01-*78
$OCWPL,5913.632,N,01840.161,E,02-*7D
$OCWPL,5913.291,N,01838.696,E,03-*71
$OCWPL,5912.389,N,01838.296,E,04-*7B
$OCWPL,5911.598,N,01835.663,E,05-*7C
$OCRTE,5,1,c,SEACLEAR,01-*26
$OCRTE,5,2,c,SEACLEAR,02-*26
$OCRTE,5,3,c,SEACLEAR,03-*26
$OCRTE,5,4,c,SEACLEAR,04-*26
$OCRTE,5,5,c,SEACLEAR,05-*26

I downloaded the proprietary, (but free), configuration and virtual instrument console that communicates with the Nexus systemsoftware. It is called "NX2 Race". It can be started with recorded data and this will make it run as while sailing.
If I start NX2 Race using a virtual output port (com6) and start Seaclear using com6, open the Waypoint/Route dialogue and in Seaclear export the route I created above the NX2 race dialogue will show as the attached screendump.
The window to the left shows the imported waypoints. They are prefaced with "NMEA" by NX2 Race to differentiate between imported waypoints and waypoints programed in NX2 Race itself.

/Jonas

[idpnd]

Like the NMEA gauges.. Capcode is a free software project with some gauges and VMG etc., unfortunately it's in Java so we can't port it to OpenCPN..

[bdbcat]

jonasaberg.....

OK, I think I am following you.

The Seaclear export route looks very much like what opencpn produces for Route->SendToGPS. Several WPL sentences, and (in the case of opencpn) one RTE sentence.

So, in opencpn you could simply create a route, and do Route->SendToGPS. The Nexus should pick it up, and you could turn off the PC.

Does this work in real life for your scenario 2?

Considering scenario 1: opencpn uses NMEA sentence RMB for autopilot control. This sentence contains information on XTE, WP name, DTG, etc. So, what happens if you configure opencpn to treat the Nexus as an autopilot, and simply activate the route, thereby sending the RMB sentences out the configured port? Does Nexus pick this up and send the proper stuff to the cockpit? If not, can you capture a trace of the NMEA stream from the PC running Seaclear, etc. to the Nexus in this case? Maybe we need to add some more sentences (like BTW/DTW) to be output on Route->Activate.

btw you are correct regarding the first two characters of an NMEA message. They are normal ignored by programs and devices. Opencpn sends "ECRMB", ECWPL", etc.

Let me know how this goes....
Dave

[jonasaberg]

Dave,
I dont know how you are testing OpenCPN as you are programming it. I guess you have programmed something that sends NMEA sequenses to simulate a GPS?

Anyway, I did the same using my Nexus NX2 Race software.

Further down in this post there are instructions how to download, install and run NX2 Race using pre-recorded data. It an then be used to relay NMEA data to OpenCPN.
I have also attached a kap (very crude) file covering the area of the recorded data to make it nicer to view.

One reason I do this is that on my machine I get crashes. It is possible to vary the speed of the simulated data sent to OpenCPN. If the speed is increased OpenCPN crashes.
I understand this is somewhat artificial - but I guess there is something strange since OpenCPN should not crash just because we feed it "bad" or "unlikely" data.

Back to the problem regarding getting the instruments to show DTW/BTW/XTE:

I tried to simulate according to your suggestion but my setup does not work for this, or at least the test is not conclusive (it doesnt work but neither do Seaclear in my setup). I need to try it in the boat.

I recorded the NMEA out strings from Seaclear, they look like this:
**
$OCAPA,A,A,0.15,R,N,V,V,217,M,04-
$OCAPB,A,A,0.148,R,N,V,V,216.8,M,04-,254.5,M,306.8,M*2C
$OCRMB,A,0.148,R,03-,04-,5916.379,N,01858.031,E,0.24,259.7,-0.9,V*12
$OCBOD,222.0,T,216.8,M,04-,03-*54
$OCBWC,112352,5916.379,N,01858.031,E,259.7,T,254.5 ,M,0.24,N,04-*0E
$OCRTE,1,1,w,SEACLEAR,03-,04-*31
**
As you see I left the OC header.

It turns out that Seaclear is configurable to send up to these five NMEA sentences and they are all marked to be sent. I am not sure if it is by default or if I have triggered them to make it work earlier.

Anyway - it would be nice if OpenCPN could do something similar - and that it is possible to turn on/off different NMEA sentences. I guess this would make it work with different systems. It is good to be able to configure which sentences are sent since NMEA is a bit restricted on the transmission rate. If to many sentences are sent the update frequency will suffer.

To the problem with crashing:
NX2 Race can be downloaded here:
SILVA Marine FDX
It runs for 20 minutes before closing down without registering. The reg is free using the form here:
Sign up for the NX2 Race Software - www.nexusmarine.se
After starting click on the "connector" icon and then choose use pre recorded data. use the attached file.
Rename it from .kml to .zip
Unpack the two files.

In the same dialogue choose "enable secondary connection" and choose a port.

After this, start openCPN, set it to talk to the same port and watch the yacht sail around.
You can open virtual instruments of your liking...

If you increase the speed of the playback of data to go through the recorde data quickly my OpenCPN crashes. (File->open Playback dialogue)

I have also attached a small .kap of the area, change the name of sandhamn.doc to sandhamn.kap.

/J