Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rating: Thread Rating: 4 votes, 5.00 average. Display Modes
Old 13-01-2018, 06:39   #2521
Registered User

Join Date: Nov 2012
Location: Orust Sweden
Boat: Najad 34
Posts: 2,066
Re: Feature Requests

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
Attached Thumbnails
Click image for larger version

Name:	ETA_route.PNG
Views:	32
Size:	35.3 KB
ID:	162129  
__________________

__________________
Hakan is offline   Reply With Quote
Old 13-01-2018, 06:45   #2522
Registered User

Join Date: Feb 2010
Location: On the go. Not in Prague.
Posts: 4,106
Re: Feature Requests

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
__________________

__________________
nohal is online now   Reply With Quote
Old 13-01-2018, 06:52   #2523
Registered User

Join Date: Feb 2011
Posts: 506
Re: Feature Requests

Quote:
Originally Posted by nohal View Post
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 ........
__________________
P_Dub is online now   Reply With Quote
Old 13-01-2018, 06:54   #2524
Registered User

Join Date: Feb 2010
Location: On the go. Not in Prague.
Posts: 4,106
Re: Feature Requests

Quote:
Originally Posted by P_Dub View Post
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.
__________________
nohal is online now   Reply With Quote
Old 13-01-2018, 09:17   #2525
Registered User

Join Date: Nov 2012
Location: Orust Sweden
Boat: Najad 34
Posts: 2,066
Re: Feature Requests

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
Attached Thumbnails
Click image for larger version

Name:	ETA_day.PNG
Views:	12
Size:	26.3 KB
ID:	162136  
__________________
Hakan is offline   Reply With Quote
Old 13-01-2018, 09:24   #2526
Registered User

Join Date: Feb 2010
Location: On the go. Not in Prague.
Posts: 4,106
Re: Feature Requests

Quote:
Originally Posted by Hakan View Post
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
Code:
printf("%dd %02d:%02d",2, 10, 43);
printf("%dd %02d:%02d",2, 9, 43);

2d 10:43
2d 09:43
__________________
nohal is online now   Reply With Quote
Old 13-01-2018, 09:36   #2527
Registered User

Join Date: Nov 2012
Location: Orust Sweden
Boat: Najad 34
Posts: 2,066
Re: Feature Requests

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):
Attached Images
 
__________________
Hakan is offline   Reply With Quote
Old 13-01-2018, 09:39   #2528
Registered User

Join Date: Feb 2010
Location: On the go. Not in Prague.
Posts: 4,106
Re: Feature Requests

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
__________________
nohal is online now   Reply With Quote
Old 13-01-2018, 09:50   #2529
Registered User
 
Jon Hacking's Avatar

Join Date: Sep 2010
Location: Currently cruising Southern Indonesia, heading for peninsular Malaysia
Boat: Wauquiez 45' (now 48') catamaran
Posts: 533
Send a message via Skype™ to Jon Hacking
Re: Feature Requests

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.
__________________
-- Jon Hacking s/v Ocelot
Jon Hacking is offline   Reply With Quote
Old 13-01-2018, 19:18   #2530
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 9,770
Re: Feature Requests

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?
__________________
rgleason is online now   Reply With Quote
Old 13-01-2018, 22:56   #2531
Registered User

Join Date: Feb 2012
Location: Austria
Posts: 114
Re: Feature Requests

Quote:
Originally Posted by Jon Hacking View Post
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 )
__________________
skipperearly is offline   Reply With Quote
Old 14-01-2018, 09:13   #2532
Registered User

Join Date: Nov 2012
Location: Orust Sweden
Boat: Najad 34
Posts: 2,066
Re: Feature Requests

TTG/ETA change implemented acc. to (5).
Thanks for your comments.
Håkan
__________________
Hakan is offline   Reply With Quote
Old 17-01-2018, 22:20   #2533
Registered User

Join Date: Mar 2011
Posts: 12
Re: Feature Requests

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.
__________________
stevead is offline   Reply With Quote
Old 17-01-2018, 23:30   #2534
Registered User

Join Date: Feb 2010
Location: On the go. Not in Prague.
Posts: 4,106
Re: Feature Requests

Quote:
Originally Posted by stevead View Post
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).
Quote:
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
__________________
nohal is online now   Reply With Quote
Old 18-01-2018, 00:49   #2535
bcn
Registered User

Join Date: May 2011
Location: underway whenever possible
Boat: Rangeboat 39
Posts: 2,814
Re: Feature Requests

Quote:
Originally Posted by nohal View Post
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.

Quote:
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.
__________________

__________________
bcn is online now   Reply With Quote
Reply

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Yet anothr of my stupid requests Little Otter Multihull Sailboats 2 30-06-2008 00:29
Any requests for pics at Strictly Sail Oakland? Redbull addict Monohull Sailboats 0 30-03-2007 19:33
Capt.Jack requests permission to come aboard canatc1 Meets & Greets 8 10-04-2006 17:54



Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 12:25.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2018, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.