Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rate Thread Display Modes
Old 26-03-2014, 08:42   #16
Nearly an old salt
 
goboatingnow's Avatar

Cruisers Forum Supporter

Join Date: Jun 2009
Posts: 13,649
Images: 3
Re: NMEA Failover Data Sources

Quote:
So maybe redundant failover controllers running a vrrp/master-slave-like mechanism between them?
A solution indeed

dave
__________________

__________________
Check out my new blog on smart boat technology, networking and gadgets for the connected sailor! - http://smartboats.tumblr.com
goboatingnow is offline   Reply With Quote
Old 26-03-2014, 08:57   #17
Senior Cruiser
 
colemj's Avatar

Cruisers Forum Supporter

Join Date: Oct 2005
Location: Presently on US East Coast
Boat: Manta 40 "Reach"
Posts: 10,049
Images: 12
Re: NMEA Failover Data Sources

It just occurred to me that if I set the Furuno NN3D as the "source" for all data on our other instruments, then all the rest of our instruments would automatically fail over to the secondary sensors/transducers when the Furuno does.

Not a workable solution for us because we often use the rest of the instruments when the Furuno is off.

Mark
__________________

__________________
www.svreach.com

You do not need a parachute to skydive. You only need a parachute to skydive twice.
colemj is offline   Reply With Quote
Old 26-03-2014, 08:59   #18
Nearly an old salt
 
goboatingnow's Avatar

Cruisers Forum Supporter

Join Date: Jun 2009
Posts: 13,649
Images: 3
Re: NMEA Failover Data Sources

Quote:
Originally Posted by colemj View Post
It just occurred to me that if I set the Furuno NN3D as the "source" for all data on our other instruments, then all the rest of our instruments would automatically fail over to the secondary sensors/transducers when the Furuno does.

Not a workable solution for us because we often use the rest of the instruments when the Furuno is off.

Mark
how can you do that ? how can your MFD be a GPS source?

dave
__________________
Check out my new blog on smart boat technology, networking and gadgets for the connected sailor! - http://smartboats.tumblr.com
goboatingnow is offline   Reply With Quote
Old 26-03-2014, 09:03   #19
Senior Cruiser
 
colemj's Avatar

Cruisers Forum Supporter

Join Date: Oct 2005
Location: Presently on US East Coast
Boat: Manta 40 "Reach"
Posts: 10,049
Images: 12
Re: NMEA Failover Data Sources

Maybe I did not say that correctly. I can set the Furuno to repeat data on the network. I can set our other instruments up to get their data from the Furuno instead of the actual sensor/transducer. In other words, the Furuno shows up in the data source page for them, so I can just pick that instead of the actual data source.

Mark
__________________
www.svreach.com

You do not need a parachute to skydive. You only need a parachute to skydive twice.
colemj is offline   Reply With Quote
Old 26-03-2014, 09:23   #20
Nearly an old salt
 
goboatingnow's Avatar

Cruisers Forum Supporter

Join Date: Jun 2009
Posts: 13,649
Images: 3
Re: NMEA Failover Data Sources

Quote:
Originally Posted by colemj View Post
Maybe I did not say that correctly. I can set the Furuno to repeat data on the network. I can set our other instruments up to get their data from the Furuno instead of the actual sensor/transducer. In other words, the Furuno shows up in the data source page for them, so I can just pick that instead of the actual data source.

Mark
Its the same system really, If all your receivers can handle multiple sources, then to work they need a failover mechanism, if thats the case just let them failover on the original sensors.

What you are in this case, doing isn't adding anything, not does it solve the issue where there isn't selectable source selection , or where selecting the next source on the list is done automatically , i.e. lots of devices just take the first one and if that fails , they error.
__________________
Check out my new blog on smart boat technology, networking and gadgets for the connected sailor! - http://smartboats.tumblr.com
goboatingnow is offline   Reply With Quote
Old 26-03-2014, 09:43   #21
Senior Cruiser
 
colemj's Avatar

Cruisers Forum Supporter

Join Date: Oct 2005
Location: Presently on US East Coast
Boat: Manta 40 "Reach"
Posts: 10,049
Images: 12
Re: NMEA Failover Data Sources

I was just pointing out that if the Furuno was set as the data source for the other devices, then when the Furuno automatically fails over to another source, the other devices will also do so by default because they are seeing the Furuno as their data source.

The other devices in our case do not have the failover feature that the Furuno does.

Or maybe this doesn't work the way I think it does - I have not tried it.

Mark
__________________
www.svreach.com

You do not need a parachute to skydive. You only need a parachute to skydive twice.
colemj is offline   Reply With Quote
Old 26-03-2014, 10:48   #22
Registered User

Join Date: Jun 2007
Location: SW Florida
Boat: FP Belize, 43' - Dot Dun
Posts: 3,432
Re: NMEA Failover Data Sources

Quote:
Originally Posted by goboatingnow View Post
DHCP is a major single point failure mechanism, distributed address resolution is a better method and is partially implemented in NMEA2k, however it leads to non routable networks.
DHCP can be as redundant as you like, either orchestrated (sharing state) or simply 2 independent DHCP servers serving the same broadcast domain (with different scopes). It's up to the client to chose which server it uses.

Quote:
Originally Posted by goboatingnow View Post
Requires the logic to be in every receiver , and such logic to be standardised, what about receivers with no UI ( or very simple EI). bringing up a new sender manually requires all receivers to be touched.


Major fight between primaries possible, needs an arbitrator ( i.e. fail over controller) or flight computer voting style logic = complex.
Logic doesn't need to be standardized. The logic can be simple, lowest address is the winner. example: Find 3 devices with GPS capabilities, use the lowest address one, if I suddenly don't like it for some reason, use the next higher address.

Quote:
Originally Posted by goboatingnow View Post
Yes, but you have no way in an arbitrary assigned addressing scheme m like NMEA2k, to control which address get assigned what.
I don't understand why this matters, a gps is a gps, wind is wind, why does it matter which one of the redundant sensors it comes from? If it matters, then you don't have truly redundant devices.

Quote:
Originally Posted by goboatingnow View Post
Yes and no , they have specifics for things like ECU failover, because unlike NMEA2k , J1939 has assigned meaning to addresses


for simple historic MFD centric systems yes, how do you handle APs radios, AIS, instruments, fuel flow systems, distributed switching, fly by wire, etc etc



Well after years of proprietary systems, there nothing like the zeal of the converted

The system is fundamentally flawed unfortunately and needs a lot more specification work, I mean look at the time to get the third party gateway specs agreed ( 4 years) and even today the Internet protocol is being still tossed around.
No argument here.
__________________
DotDun is offline   Reply With Quote
Old 26-03-2014, 11:00   #23
Registered User

Join Date: Jun 2007
Location: SW Florida
Boat: FP Belize, 43' - Dot Dun
Posts: 3,432
Re: NMEA Failover Data Sources

Quote:
Originally Posted by colemj View Post
I was just pointing out that if the Furuno was set as the data source for the other devices, then when the Furuno automatically fails over to another source, the other devices will also do so by default because they are seeing the Furuno as their data source.

The other devices in our case do not have the failover feature that the Furuno does.

Or maybe this doesn't work the way I think it does - I have not tried it.

Mark
I don't believe Furuno will repeat N2K data back onto the same network it came from.
__________________
DotDun is offline   Reply With Quote
Old 26-03-2014, 11:46   #24
Nearly an old salt
 
goboatingnow's Avatar

Cruisers Forum Supporter

Join Date: Jun 2009
Posts: 13,649
Images: 3
Re: NMEA Failover Data Sources

Quote:
DHCP can be as redundant as you like, either orchestrated (sharing state) or simply 2 independent DHCP servers serving the same broadcast domain (with different scopes). It's up to the client to chose which server it uses.
oh I know, but in the context of adding a kind of DHCP system to NMEA2k as an alternative to distributed addressing, it creates a single point of failure. I wasn't commenting on DHCP in large TCP/IP environments etc.


Quote:
Logic doesn't need to be standardized. The logic can be simple, lowest address is the winner. example: Find 3 devices with GPS capabilities, use the lowest address one, if I suddenly don't like it for some reason, use the next higher address.
I presume you mean the user assigned instance number since you can't actually use nmea addresses as these change all the time.

Yes your approach is fine, it just means that all "receivers" must have a way of implementing the approach exactly the same. This is where we started, equally NMEA2K was designed to be self contained, Now a receiver must have a way of being setup , i.e. have an UI. ( say I have a smart fuel sensor thats uses GPS speed as its sped input, Now my fuel sensor must have an onboard UI to allow me to either enter source selection IDs, or to force failover. In reality this should be a network control function.

Secondly As I said when I started out NMEA should have dealt with the situation as part of the standard. in fact Corrigendum 2-2011 was the first to codify field programmable instance IDs. Uptil then many sensors of the same type couldn't even co-exist!.

even today setting the instance number is a real pain on a multi vendor sensor network

So what I was suggesting was a solution that doesn't require changes to existing devices,

But as you pointed out ( and I did too) the correct way would be to have an automatic fail over strategy, implemented as part of the protocol.


Quote:
I don't understand why this matters, a gps is a gps, wind is wind, why does it matter which one of the redundant sensors it comes from? If it matters, then you don't have truly redundant devices.
Well a key situation where there might be several sensors, is to ensure that all devices failover to the same instance, You hardly want some devices , say reading one GPS and other devices reading another.

This brings up another interesting issue and that is again in NMEA 2k theres no "soft" way to take the device off the network, gracefully . So say I discover my GPS #2 is giving quirky occasional fixes, today Ive no easy way of removing that device and causing failove, other then taking down the bus and removing it.


Again whats missing in NMEA is an ability to "manage" the network using management tools, rather then either having to invoke propritary software or setups methods. If this management layer had been added, then MFDs and other devices with sophisticated UIs could then act as management consoles for the network


dave
__________________
Check out my new blog on smart boat technology, networking and gadgets for the connected sailor! - http://smartboats.tumblr.com
goboatingnow is offline   Reply With Quote
Old 26-03-2014, 13:13   #25
Registered User

Join Date: Jun 2007
Location: SW Florida
Boat: FP Belize, 43' - Dot Dun
Posts: 3,432
Re: NMEA Failover Data Sources

Quote:
Originally Posted by goboatingnow View Post
I presume you mean the user assigned instance number since you can't actually use nmea addresses as these change all the time.
I was referring to the capabilities discovery mechanism. If a receiver discovers the capabilities of every device on the network at initialization and when new devices are added, then network addresses are irrelevant. (e.g. = receiver remembers a gps on 56, 94, and 132) Addresses don't change on a device mid-session, only at network initialization..??

FWIW, Furuno does capabilities discovery relentlessly.

Quote:
Originally Posted by goboatingnow View Post
Yes your approach is fine, it just means that all "receivers" must have a way of implementing the approach exactly the same. This is where we started, equally NMEA2K was designed to be self contained, Now a receiver must have a way of being setup , i.e. have an UI. ( say I have a smart fuel sensor thats uses GPS speed as its sped input, Now my fuel sensor must have an onboard UI to allow me to either enter source selection IDs, or to force failover. In reality this should be a network control function.
Not arguing that a network approach isn't the best, I'm simply saying that lacking that from NMEA, which appears will be the case forever, using a simple algorithm such as capabilities discovery then selecting the lowest network address device would work.

Quote:
Originally Posted by goboatingnow View Post
Secondly As I said when I started out NMEA should have dealt with the situation as part of the standard. in fact Corrigendum 2-2011 was the first to codify field programmable instance IDs. Uptil then many sensors of the same type couldn't even co-exist!.

even today setting the instance number is a real pain on a multi vendor sensor network

So what I was suggesting was a solution that doesn't require changes to existing devices,

But as you pointed out ( and I did too) the correct way would be to have an automatic fail over strategy, implemented as part of the protocol.




Well a key situation where there might be several sensors, is to ensure that all devices failover to the same instance, You hardly want some devices , say reading one GPS and other devices reading another.
Yes, for some applications (none come to mind right now) that could be a problem. But on a properly operating network (i.e. all packets make it from end to end), if all receivers used my simple algorithm, they should all be using the same sources.

Quote:
Originally Posted by goboatingnow View Post
This brings up another interesting issue and that is again in NMEA 2k theres no "soft" way to take the device off the network, gracefully . So say I discover my GPS #2 is giving quirky occasional fixes, today Ive no easy way of removing that device and causing failove, other then taking down the bus and removing it.
Removing a drop cable shouldn't take the bus down causing a complete restart, it may corrupt a single transmission.


Quote:
Originally Posted by goboatingnow View Post
Again whats missing in NMEA is an ability to "manage" the network using management tools, rather then either having to invoke propritary software or setups methods. If this management layer had been added, then MFDs and other devices with sophisticated UIs could then act as management consoles for the network
Agree 100%
__________________
DotDun is offline   Reply With Quote
Old 26-03-2014, 13:21   #26
Nearly an old salt
 
goboatingnow's Avatar

Cruisers Forum Supporter

Join Date: Jun 2009
Posts: 13,649
Images: 3
Re: NMEA Failover Data Sources

Quote:
I was referring to the capabilities discovery mechanism. If a receiver discovers the capabilities of every device on the network at initialization and when new devices are added, then network addresses are irrelevant. (e.g. = receiver remembers a gps on 56, 94, and 132) Addresses don't change on a device mid-session, only at network initialization..??

FWIW, Furuno does capabilities discovery relentlessly.

Well theres no real capabilities discovery system as standard in NMEA. There is the NAME process. ( which is a bit of a mis -mash). Sorry I should say that there is a Class and function ID system, but that is a very general form of ID. There is nothing that actually lets a 2K device really discover whats out there , It can say "hey Ive found a device thats says its an AP", but in reality it knows nothing about that device.

To my knowledge no system on a NMEA2k network should use the actual source address as an "instance" identifier. If Furuno does, its doing it wrong ( and that wouldn't be the first time they broke 2k rules!!). In a small network address rarely change, but In fact address resolution can occur at many time, including adding and subtracting devices, power up and by devices forcing an address resolution ( name clash etc). The network cannot assume any correlation between a physical device and its address. In reality there are serious shortcomings in some software implementations , where assumptions are made and address are stored. This often leads to aberrant behaviour that is sometimes seen on NMEA 2K networks, especially larger heterogeneous ones.

The correct way is to use the user programmed "instance" number, which is a bit field in the NAME field. This of course requires you to have the requisite setup tools. The instance ID does not change on address resolution, instance #1 remains instance #1.

I can't comment on Furunos discovery capability,( especially in a large heterogeneous network) but expecting all receivers on a NMEA 2k network to have the horsepower and software depth of a serious high end ( Well, OK, it runs Windows XP - LOL ) system like NN3D is not practical.

I susoect Furuno uses instance numbers, anything else is not reliable in that it cannot indicate a particular physical device.
dave
__________________
Check out my new blog on smart boat technology, networking and gadgets for the connected sailor! - http://smartboats.tumblr.com
goboatingnow is offline   Reply With Quote
Old 26-03-2014, 13:21   #27
Senior Cruiser
 
colemj's Avatar

Cruisers Forum Supporter

Join Date: Oct 2005
Location: Presently on US East Coast
Boat: Manta 40 "Reach"
Posts: 10,049
Images: 12
Re: NMEA Failover Data Sources

Quote:
Originally Posted by DotDun View Post
I don't believe Furuno will repeat N2K data back onto the same network it came from.
Well, I haven't tried it yet, but from the manual:

NMEA2000 Data Configuration
This page configures the information that the MFD will output on its own NMEA2000 port. The information embedded in the PGN will be the information coming from the Sensor that will be chosen as the Primary Source (see next paragraph). Enable each NMEA2000 Data PGN that will be sent through the individual MFDs NMEA2000 port.

Since there is only a single N2K port on the MFD, I assume that this output is back onto the same network it came from.

I do know that at one time I had the GPS output box checked on the Furuno by mistake and the autopilot saw the Furuno as a source in the GPS setup page along with the Maretron GPS.

Mark
__________________
www.svreach.com

You do not need a parachute to skydive. You only need a parachute to skydive twice.
colemj is offline   Reply With Quote
Old 26-03-2014, 14:07   #28
Registered User

Join Date: Oct 2012
Location: Brighton, UK
Boat: Westerly Oceanlord
Posts: 374
Re: NMEA Failover Data Sources

I don't know what if any failover provision exists in OneNet, but I'm gathering that no-one on this thread is holding their breath waiting for it...
__________________
muttnik is offline   Reply With Quote
Old 26-03-2014, 14:13   #29
Nearly an old salt
 
goboatingnow's Avatar

Cruisers Forum Supporter

Join Date: Jun 2009
Posts: 13,649
Images: 3
Re: NMEA Failover Data Sources

Quote:
Originally Posted by muttnik View Post
I don't know what if any failover provision exists in OneNet, but I'm gathering that no-one on this thread is holding their breath waiting for it...

since its just an encapsulation of NMEA PGNS in TCP?IP no I don't think it will help, nor would I be holding my breath given NMEAs speed, lots of press releases, little actual reality.

Onenet is really just a way for NMEA to stem the transfer to Ethernet issues, I don't think it will work somehow in the long run.
__________________
Check out my new blog on smart boat technology, networking and gadgets for the connected sailor! - http://smartboats.tumblr.com
goboatingnow is offline   Reply With Quote
Old 26-03-2014, 14:15   #30
Nearly an old salt
 
goboatingnow's Avatar

Cruisers Forum Supporter

Join Date: Jun 2009
Posts: 13,649
Images: 3
Re: NMEA Failover Data Sources

Quote:
Originally Posted by colemj View Post
Well, I haven't tried it yet, but from the manual:

NMEA2000 Data Configuration
This page configures the information that the MFD will output on its own NMEA2000 port. The information embedded in the PGN will be the information coming from the Sensor that will be chosen as the Primary Source (see next paragraph). Enable each NMEA2000 Data PGN that will be sent through the individual MFD’s NMEA2000 port.

Since there is only a single N2K port on the MFD, I assume that this output is back onto the same network it came from.

I do know that at one time I had the GPS output box checked on the Furuno by mistake and the autopilot saw the Furuno as a source in the GPS setup page along with the Maretron GPS.

Mark

Be surprised it would do this as there would be instance clashes, NAME clashes, etc. even address revolution issues. how would a receiver distinguish between the original PGN and the "spoof" PGN unless furuno did clever remapping, if so they just invented a "failover" controller !
__________________

__________________
Check out my new blog on smart boat technology, networking and gadgets for the connected sailor! - http://smartboats.tumblr.com
goboatingnow is offline   Reply With Quote
Reply

Tags
nmea

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
Help connecting our NMEA data sources offgridcanuck Marine Electronics 1 29-01-2014 12:17
Question About Alternative Data Sources in N2K Dockhead Marine Electronics 1 27-08-2013 06:58
Favorite sources for historic data? thompsonisland Weather | Gear, Reports and Resources 3 03-11-2012 07:07
Interfacing NMEA Data to Computer bobfnbw Marine Electronics 81 07-03-2012 09:46
Data Converter NMEA to Ethernet ticki Marine Electronics 2 21-03-2010 14:37



Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 22:17.


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

ShowCase vBulletin Plugins by Drive Thru Online, Inc.