Feature Requests

[Hakan]

All..
I’ve a suggestion and want opinions:
When an activated route has a TTG for more than 24 hours the Route dialog has some limitations.
The ETA shows only the time for arrival. Not which day.
The TTG shows number of hours even if more than 24 h.

I’ve a proposal ready for PR but have some hesitations about your opinions.
Personally I prefer suggestion 2) of below pictures. That is: When TTG is more than 24h , show ETA date and time and TTG in format days – hours:minutes; 2 – 06:42
When TTG is < 24h let it be as it is now.

For the TTG format I think it’s important to not emphasize the days – hours format to include any letters, like 2 days – 13 hours. Translations can disturb the dialog format to grow unnecessarily??

So, please; do you think my proposal (2) of below pictures is good enough?
Or is this change of no interest at all?

Thanks
Håkan

[nohal]

Hakan...
I would personally make the format "%dd %02d:%02d" if more than 24 hours. More logical for me. If the translator is insane and translates it to "%d whatever my very long term for day abbreviation is %02d:%02d", it of course won't fit the box. But it is the translators insanity, not our problem...

Pavel

[P_Dub]

Originally Posted by nohal

Hakan...
I would personally make the format "%dd %02d:%02d" if more than 24 hours. More logical for me. If the translator is insane and translates it to "%d whatever my very long term for day abbreviation is %02d:%02d", it of course won't fit the box. But it is the translators insanity, not our problem...

Pavel

The ETA should give:- day month year and hour minutes and noting else.
ETA is eta and no ........

[nohal]

Originally Posted by P_Dub

The ETA should give:- day month year and hour minutes and noting else.
ETA is eta and no ........

No doubt, but this the format for TTG - time to go.

[Hakan]

Pavel..
For TTG: May I understand your "%dd %02d:%02d" as "days hour:minute" as of my example (1)? i.e. [wxTimeSpan].Format("%D %H:%M") as I used for that.

P-Dub..
For ETA: I used month-day hour:minute and omitted the year due the restricted space in the dialog and that we seldom have a track that long. If plenty of space I would have used YYYY-MM-DD hh:mm. (acc.to: ISO 8601)
But, I know US people often stuck to another format where it can be doubtful what's month and day for others and vice versa so it's maybe better to use Jan(short month) #day hh:mm like the pict. below? (4)
That short month format is also local system dependent so no internationalization problem.

Thanks
Håkan

[nohal]

Originally Posted by Hakan

Pavel..
For TTG: May I understand your "%dd %02d:%02d" as "days hour:minute" as of my example (1)? i.e. [wxTimeSpan].Format("%D %H:%M") as I used for that.

P-Dub..
For ETA: I used month-day hour:minute and omitted the year due the restricted space in the dialog and that we seldom have a track that long. If plenty of space I would have used YYYY-MM-DD hh:mm. (acc.to: ISO 8601)
But, I know US people often stuck to another format where it can be doubtful what's month and day for others and vice versa so it's maybe better to use Jan(short month) #day hh:mm like the pict. below? (4)
That short month format is also local system dependent so no internationalization problem.

Thanks
Håkan

Almost like this, just with "d" after the first number. As in

printf("%dd %02d:%02d",2, 10, 43);
printf("%dd %02d:%02d",2, 9, 43);

2d 10:43
2d 09:43

[Hakan]

Pavel..
I've no problem using [wxTimeSpan].Format("%Dd %H:%M") but what about the "d"? Does every language understand that as a abbreviation for days? - I may think it would so I agree to (5):

[nohal]

Hakan...
No, not every language understands the "d", that's why the formatting string should be localizable like in [wxTimeSpan].Format(_("%Dd %H:%M")), so eg. Gilletarom can translate it to "%Dj %H:%M" in fr_FR.po

Pavel

[Jon Hacking]

I like the short month spelled out. I've spent enough time outside the US that I'm not sure what 04/07 means. Spelling it out resolves any confusion, & my system time display reflects that on all my computers. And for TTG, I like something between the days and the hours: dash at the least, but d would be better.

[rgleason]

Grib Sat 06 Jan 2018 12:00 UTC (pref Local or UTC)
WxRte 6/15/2017 12:00 UTC (no preferences)
Tide&Cur Sat Jan 13, 2018

Perhaps we should try to be consistent whatever is picked.
It will make it easier later. Maybe the developers could name it the same so later it is easier to search form, align and to unify?

[skipperearly]

Originally Posted by Jon Hacking

I like the short month spelled out. I've spent enough time outside the US that I'm not sure what 04/07 means. Spelling it out resolves any confusion, & my system time display reflects that on all my computers. And for TTG, I like something between the days and the hours: dash at the least, but d would be better.

Agree - short spell of month is the best for ETA, but for TTG whats wrong with just hours , minutes - anyone can calculate the days by mental calculation (if at all neccessary )

[Hakan]

TTG/ETA change implemented acc. to (5).
Thanks for your comments.
Håkan

[stevead]

I'm not suggesting that OpenCPN becomes a hardware development platform and I apologize if by mentioning "Arduino" & "CANOpen" that was inferred from my post.

My question is simply whether it is now time to plan how OpenCPN will support NMEA 2000 ?

In five years time I doubt that there will be any external devices (Depth, Speed, Wind and Rudder transducers, GPS receivers, VHF radios, AIS receivers and Autopilots) that continue to support NMEA 0183. In addition to these devices that are available today with both NMEA 0183 and 2000 support, there are families of other devices that monitor and control electrical, environmental, engine and entertainment systems that only support NMEA 2000.

Today there are a few vendors who provide NMEA 0183 to NMEA 2000 converters but can OpenCPN rely on these vendors to continue offering these devices in the future and to be dependent on them to provide NMEA 0183 support ?

On the other hand the underlying technology for NMEA 2000, the CAN bus, has been in use in the automotive and manufacturing sector for many decades and in the marine sector since 2000. PC CAN bus adapters are widely available in both commercial and open source variants and over a range of price points.

The software interface to PC CAN bus adapters is similarly mature, with Socket CAN available on Linux and although no equivalent library exists on Windows, most adapters appear as serial devices. From a developer perspective it isn't rocket surgery to interface with these devices; read/write semantics on either a serial port or network device.

While you make the point that Ethernet is the medium that is available on most platforms, in the next few years NMEA will release the OneNet standard with NMEA 2000 PGN's proposed as the data layer.

There are alternative data layers for networked devices available today; NMEA 0183 over TCP or UDP and various JSON formats such as SignalK or Navico's GoFree but you still have to get the data from the transducer into the gateway and convert it, before it is transmitted using any of these formats.

The difficult part is parsing NMEA 2000 PGN's and today from OpenCPN's perspective this is more of a legal question in terms of NMEA's copyright rather than the technical details for decoding PGN's as these are now quite well documented in many open source projects. There are a few "clean room" variants that suggest that they may not be infringing NMEA's copyright claims, alternatively OpenCPN could utilise a similar "black box" binary approach that was used for the S63 chart plug-in.

If as is suggested that you will need a third party solution to bridge the gap between devices and OpenCPN's NMEA 0183 requirement, and that charts (and their updates) are equally as important as the chartplotter software then at some point one may question the value proposition of OpenCPN, something that would be very sad to see.

[nohal]

Originally Posted by stevead

I'm not suggesting that OpenCPN becomes a hardware development platform and I apologize if by mentioning "Arduino" & "CANOpen" that was inferred from my post.

My question is simply whether it is now time to plan how OpenCPN will support NMEA 2000 ?

SignalK
It makes absolutely no sense to support anything else in the future. If you have some arguments why we should support eg. canboat (used by the SignalK server for NMEA2000) directly, I'm of course willing to hear it.
What exactly would you like to plan on it? Are you going to contribute to the effort? If so, I may publish the code already done, at some moment, when synced with current master (Which is not a trivial task as I have not touched it for more than a year waiting for SignalK to mature a bit).

If as is suggested that you will need a third party solution to bridge the gap between devices and OpenCPN's NMEA 0183 requirement, and that charts (and their updates) are equally as important as the chartplotter software then at some point one may question the value proposition of OpenCPN, something that would be very sad to see.

Someone may and is questioning "OpenCPN's value proposition" for years, I personally don't care and keep using and developing it. OpenCPN's NMEA 0183 requirement will of course not exist once we implement SignalK.

Pavel

[bcn]

Originally Posted by nohal

Someone may and is questioning "OpenCPN's value proposition" for years, I personally don't care and keep using and developing it. OpenCPN's NMEA 0183 requirement will of course not exist once we implement SignalK.

Pavel

As of today there are at least two solutions for N2K that work out of the box:
- the Actisense N2K-NMEA0183 serial gateways (and its clones)
- OpenPlotter on a RasPi plus a CAN gateway delivering a NMEA0183 stream via Ethernet/WiFi or serial.
With all the limitations of NMEA0183 of course.

Even with SK implemented for OpenCPN there will be always the requirement for some hardware device to connect to N2K.
This will not be something OpenCPN can provide. Similar to the myriad of COM-USB converters. Most will work, some might give problems...

A SK server might run on some micro like it does today on the RasPis and Openplotter. Or directly from the same system OpenCPN is running.
Or as a part of OpenCPN in form of a plug-in.
In all these cases the dedicated hardware gateway will exist.


SignalK:
SK is embracing such a wide range of sensors and data sources that implementing a SK client shall not imply to use all these data within OpenCPN.

In five years time I doubt that there will be any external devices (Depth, Speed, Wind and Rudder transducers, GPS receivers, VHF radios, AIS receivers and Autopilots) that continue to support NMEA 0183. In addition to these devices that are available today with both NMEA 0183 and 2000 support, there are families of other devices that monitor and control electrical, environmental, engine and entertainment systems that only support NMEA 2000.

Being a "ChartPlotter and Navigation" software, a careful selection of the data required for this purpose shall be taken. And this selection shall be flexible.
Data like "Exhaust temperature", "Fuel tank level", "Voltage solar panel", "Humidity in salon" do not add information for navigation.
Keep it simple and concise.

SK provides already a big number of plugins on the server and client side, such as Virtual Instruments giving a flexible (glass) dashboard solution running in any of the web browsers.
There is even a plotting app for raster charts being boiled.
Always browser based on the client side.