Visit our Popular Forums

reflectionsv37 · 10-09-2014, 22:59

Hi Dave!

Tested the Furuno upload this morning and everything is working properly!

I noticed that you changed the number of waypoints in the route sentences to 6 vs. 7 in 3.3.1824. I suspect you must have had a good reason to do that as I noticed something unusual.

I tested a route upload with 3.3.1824 before I started testing 3.3.2107 to make sure everything was still working correctly. The upload worked fine on 1824. I then installed a parallel version of 2107 and created a 28 waypoint route to test the upload. It failed and after a quick look, I realized you cut the number of waypoints per route segment to 6. Went back to 1824 to try and upload the 28 point route and it failed. Checked to make sure I hadn't missed anything and confirmed that 1824 was uploading 7 waypoints per segments. Tried uploading the route I originally successfully uploaded in 1824 and it failed. After installing 2107, I could no longer upload any routes using 1824.

It seems something in the 2107 installation changed the upload for 1824. Maybe the number of characters transferred in one sentence was less than previous? Might explain why you cut back number of waypoints to 6.

In any event, it's not a problem as 2107 is now working properly with 24 or less waypoints. I tried lots of variations on the number of waypoints they all work fine.

I did notice a couple of other things and don't know if it existed in the past but a waypoint with a latitude of say 11.11.1119 gets sent to the Furuno as 11.11.111. It is truncating the last digit rather than rounding it. Same for longitude.

Another thing I noticed is that the distance to the first waypoint in the route varied slightly from the distance shown on the GPS for the first waypoint. The waypoint was about 45 miles away but was .2 NMi off If I place the cursor on the waypoint. The GPS shows the waypoint 44.6 and Opencpn shows it at 44.8. When I activate the route, the range shown on the screen that shows range, bearing, cross track error, shows the range at 45.3. I have GPS datum set to WGS84 and am using the CM93 charts. Strange? I've never noticed this before, but I've likely never it looked at it before.

Update: Ignore my comment about the range on the activate screen being 45.3. I randomly created that route and when I activated it, it selected the second waypoint in the route. After testing a little further, the activation screen matches the GPS but the cursor range is still off by .2 for a waypoint 41 miles away.

Gene

bcn · 10-09-2014, 23:04

Quote:

Originally Posted by bdbcat

bcn...

re your post (Barcelona):
MAC-OS, OpenGL on
S63 charts

Panning produces different areas which are not correctly rendered.
Outlines of charts with varying width

Aside from outline variable widths, what other rendering problems am I looking for here?

Dave

Dave...

have a look at the rendering of the texts and objects like lighthouses on the land: partly clipped off or not visible at all depending how one pans.
That might be also a combination of panning and zooming and related to the observation about the lighthouses (Australian Westcoast) - this morning I can't reproduce it without zooming.

Hubert

reflectionsv37 · 10-09-2014, 23:16

It looks like over zoom is not working on this release for CM93 charts.

bcn · 11-09-2014, 01:54

Playing a bit more with quilting, clipping and tiled chart cells:

As seen in the Australian case Hydrographic Offices are going more and more in the direction of producing aligned tiles of cells instead of traditional overlapping charts. Norway has a lot of those as well and the upcoming (year 2025??) S100 series of standards will make this the required approach.

When we have a look at the tiles/cells/charts in the St.Vincent Gulf (Adelaide, AUS) we have an underlying chart with a scale of 1:3.500.00 and tiled (=not overlapping) charts with a scale of 1:90.000 and another one with 1:180.000 that are covering some parts of the underlying cell.

In the screen shots are the results when zooming in step by step.
The lower left cell (1:180.00) is rendered.
There are more details available from the two top 1:90.000 cells but those only kick-in when zooming in further.

It looks to me that the logic of the layers is not right, but I'm not sure neither how it should be....

bdbcat · 11-09-2014, 06:02

Hi folks...

A query, a bit arcane....

Presently, O Dashboard PlugIn implements a fixed priority scheme for NMEA messages, with no message filtering at all. That is, the input filters set up for the base O do not propagate to the Dashboard PlugIn.

This can lead to some confusing situations in the PlugIn display. For example, if one has multiple heading sources (I have a KVH compass as well as heading input from autopilot), then one cannot configure the Dashboard to ignore the A/P and consider only the KVH for heading display on the mag compass instrument.

So, short of implementing full filtering for the Dashboard (with GUI), is there any reason why we should not apply the input filters from the base O connections dialog to the Dashboard as well?

Comments appreciated.

Dave

nohal · 11-09-2014, 07:42

Dave...
My logic says: Don't send to plug-ins what is set to be filtered out. It still leaves us with handling the data input priorities. Should, in case of the same sentence coming from different sources, just the one with highest priority be sent or all of them (including the priority they have set)?

Pavel

bcn · 11-09-2014, 08:13

Pavel,

a different view:
for me a plug-in is using the internal raw data broker and the connection filtering influences the external routing of information - for example you don't want to saturate a channel by reducing the data flow. Or the fallback mechanism via priorities.

One might want to use data from one source for one listener and the second source for a different one because it's internal filtering is optimized for this source with it's specific errors. (I'm inventing here a scenario

)
This supposes that you can distinguish different sources. In NMEA0183 we have the talker ID - no guarantee, N2K does identify the source and Signal K as well.

The plug-in should define which data it wants to accept. And how it wants to process the data (apply medium filters or more sophisticated ones to avoid spikes or jitter).

Hubert

bdbcat · 11-09-2014, 08:17

Pavel...

I'm proposing that we send all messages that pass the configured OCPN base input filter to the PlugIns, regardless of priority. The Dashboard PlugIn has its own priority scheme, using somewhat different logic than the base.

Of course, there is probably a better way to do all this, and in the land of infinite resources we might do so. But....

What I wonder is if anyone's Dashboard setup will be broken by this change. I guess we try it in the next Beta, and see.

Dave

nohal · 11-09-2014, 08:46

Dave...
Yes, I agree. I know the logic in the dashboard - My point is that unless we will let it know about the priority of the original source of a message (and make it actually honor it in it's logic), it *might* result in showing values inconsistent with the core in some scenarios.

Pavel

bdbcat · 11-09-2014, 09:04

bcn/nohal..

The proper solution is of course to send all messages, unfiltered, to all PlugIns. What they do is up to them. The Dashboard. for example, would then need a configurable priority/filter scheme, with GUI.

However, at this point I'm trying to avoid a major re-factor of the Dashboard, or at least decouple the work.

By the most conservative logic, I should not change the core. PlugIns get all messages. Some current PlugIns may get confused, but at least they can be upgraded in due course without a change to the core.

And I can hack the current Dashboard PlugIn for my immediate use, until I/we/the elves get around to a correct solution in the PlugIn.

Nothing is trivial, always options....

Thanks
Dave

Littlechay · 12-09-2014, 07:52

I think this my be the overzoom issue that others have mentioned, but I'm not sure. My collection of Antarctica raster charts have become unusable in this version. At small scale zooms I can see some charts but as soon as I start to zoom in the charts disappear (I can see OCPN's base chart behind).

OGL on/off makes no difference.
preserve zoom scale when switching makes no difference (apart from the obvious at small scale zooms).
unloading my CM93 package makes no difference.

Is this new or is it the overzoom bug others have reported, I don't even know where to begin with posting debugging info; ideas please?

Chris

bcn · 12-09-2014, 07:57

Chris,

did you try quilting on/off?

Hubert

colemj · 12-09-2014, 09:10

Am I the only one on Mac OS (10.8.5) where the OCPN menu in the tool bar no longer works with this version? I can use CMD-Q on the keyboard to quit OCPN, but none of the other keyboard shortcuts work. The menu itself doesn't react at all when clicked.

Mark