New electronics. Nmea 2000. Multiplexer etc

GHA said:
The raspberry pi I have onboard puts out nmea0183 over TCP (plus signalk and some web page stuff) I just tried 3 devices, laptop, netbook and tablet all running opencpn receiving over TCP port 10109 - gps, ais, barometer pressure & temperature which seemed to all run OK without complaining. The Pi connects to an access point run on a mobile phone as does eveything else, then the data comes through the RPI IP address given out by the phone. Or everything could connect direct to an access point created by the Pi, I just use the phone as that's where the internet is.

A Pi running openplotter might be worth at least having a think about, very powerful data shuffler/creator.
Click to expand...

Trouble is that i will be buying nmea2000 instruments if I do this. So need 2000—0183. I sort of can't be bothered with all of this even though it is well within my technical abilities. I want to go sailing.....! The shipmodul is attractive as it seems to do everything.
 
smartcom said:
For a multiplexer, ShipModul is streets ahead of VYacht, as you can filter messages on each port, decide which ports they are routed to, etc. Also, I believe that they have just brought out a firmware upgrade that does both TCP and UDP simultaneously. VYacht's advantage is that it is also a router, if you want to have shared access to marina Wi-Fi for example.
Although primarily concentrating on NMEA0183 to Wi-Fi, you can see a comparison of devices here: http://nmeatools.com/Comparison
Tim
Click to expand...

Aha yes says up to four devices. I am liking it. Buy any sensors. Stuff them into shipmodul with ais from radio and gps. Available to anything else.
 
roblpm said:
Trouble is that i will be buying nmea2000 instruments if I do this. So need 2000—0183. I sort of can't be bothered with all of this even though it is well within my technical abilities. I want to go sailing.....! The shipmodul is attractive as it seems to do everything.
Click to expand...

Sounds fair enough, set up probably not much different but it's a load more of a faff with a Pi sorting out cases and power supplies , powered hubs etc. It will do n2k as well though.
 
roblpm said:
Hmmm. Tricky. Does someone know the technical difference between the wifi broadcast? Is it just tcp vs udp?
Click to expand...

From the standpoint of marketing for marine wifi data products yes. "broadcast" and "udp" both invariably mean "udp broadcast over IP over wifi". From the technical standpoint not exactly...

UDP and TCP define structures (containers for data and some "metadata" about those data) for transporting data across a network. Neither specify where the data are to be sent. That's the job of the layer below: Internet Protocol ("IP"), which wraps data contained in a udp or tcp structure in a bigger structure which does contain an address to which the data are sent. An address can refer to a single endpoint (a "unicast" address") one of a set of special addresses which zero or more computers may have chosen to listen on ("multicast") or special addresses which mean "everything on a particular network" ("broadcast"). Broadcast doesn't exist in next-generation version of IP but let's ignore that...

udp is a simple container and can be sent to a unicast, multicast or broadcast address.

tcp is more complex and involves metadata including sequence numbers which allow two endpoints to reliably ensure that all data is transfered in the correct order. Because it involves two endpoints talking to each other, it is necessarily "unicast".

udp is not necessarily "broadcast" but "broadcast" cannot be tcp so for our purposes "broadcast" will probably be udp.

So tcp can't be used to send data to more than one device? Actually it can. It can only be used to send data to one device per connection, but we can write a server to accept multiple connections and send a copy of the data down each one. Unfortunately some devices have firmware which is a bit mickey mouse and doesn't cope with more than one connection at a time.

Now strictly speaking "IP broadcast" is a layer above "wifi broadcast" (though again for marketing purposes it's all munged together and "wifi" is a marketing term anyway) and there are some good reasons for using udp unicast over wifi which don't so much apply over ethernet but the 3rd martini is kicking in so we'd best leave it there...
 
smartcom said:
http://nmeatools.com/Comparison
Click to expand...

From the link:
There are two flavours: broadcast sends data out to all devices, and multicast where an app has to request the UDP data. Multicast is generally more reliable and with less data loss.
Click to expand...
Leaving aside the unicast "flavour", why do you believe that multicast is generally more reliable than broadcast with less data loss?
 
laika said:
From the standpoint of marketing for marine wifi data products yes. "broadcast" and "udp" both invariably mean "udp broadcast over IP over wifi". From the technical standpoint not exactly...

UDP and TCP define structures (containers for data and some "metadata" about those data) for transporting data across a network. Neither specify where the data are to be sent. That's the job of the layer below: Internet Protocol ("IP"), which wraps data contained in a udp or tcp structure in a bigger structure which does contain an address to which the data are sent. An address can refer to a single endpoint (a "unicast" address") one of a set of special addresses which zero or more computers may have chosen to listen on ("multicast") or special addresses which mean "everything on a particular network" ("broadcast"). Broadcast doesn't exist in next-generation version of IP but let's ignore that...

udp is a simple container and can be sent to a unicast, multicast or broadcast address.

tcp is more complex and involves metadata including sequence numbers which allow two endpoints to reliably ensure that all data is transfered in the correct order. Because it involves two endpoints talking to each other, it is necessarily "unicast".

udp is not necessarily "broadcast" but "broadcast" cannot be tcp so for our purposes "broadcast" will probably be udp.

So tcp can't be used to send data to more than one device? Actually it can. It can only be used to send data to one device per connection, but we can write a server to accept multiple connections and send a copy of the data down each one. Unfortunately some devices have firmware which is a bit mickey mouse and doesn't cope with more than one connection at a time.

Now strictly speaking "IP broadcast" is a layer above "wifi broadcast" (though again for marketing purposes it's all munged together and "wifi" is a marketing term anyway) and there are some good reasons for using udp unicast over wifi which don't so much apply over ethernet but the 3rd martini is kicking in so we'd best leave it there...
Click to expand...

I was waiting for the bit where u told me not to be so soft, buy a pi, put your software on it and live happily ever after..... Your martinis must be strong...!!
 
roblpm said:
I was waiting for the bit where u told me not to be so soft, buy a pi, put your software on it and live happily ever after..... Your martinis must be strong...!!
Click to expand...

Nah: that wasn't the question and I don't do marketing :-). There's always trade-offs. I can argue my software corner but there's an attraction in a compact little box with opto-isolated screw-down inputs over a raspberry pi with a bunch of adapters hanging off it, particularly if needs are (as they are in most cases) simple.

In other news, Tanqueray 10 on special offer in waitrose at the moment...
 
laika said:
Nah: that wasn't the question and I don't do marketing :-). There's always trade-offs. I can argue my software corner but there's an attraction in a compact little box with opto-isolated screw-down inputs over a raspberry pi with a bunch of adapters hanging off it, particularly if needs are (as they are in most cases) simple.

In other news, Tanqueray 10 on special offer in waitrose at the moment...
Click to expand...

Hmmmm. How many evenings is it going to last.....!! I haven't touched a martini since a night on the vodka martinis in a place in LA a few years ago. At one point I couldn't feel my body.....!!
 
laika said:
but there's an attraction in a compact little box with opto-isolated screw-down inputs over a raspberry pi with a bunch of adapters hanging off it, particularly if needs are (as they are in most cases) simple.
Click to expand...

Nah, Raspberry Pi's are objects of great desire before even loading the software, all the useful tasks they do are just like the cherry on top :cool:

What's not to like ;)

1479159613-IMG1597.jpg
 
GHA said:
Nah, Raspberry Pi's are objects of great desire before even loading the software, all the useful tasks they do are just like the cherry on top :cool:

What's not to like ;)

1479159613-IMG1597.jpg
Click to expand...

Fantastic...

My mate and i just built a box for racing based on an intel edison. Great idea. But it still osnton the boat......

There is tinkering.....

And there is sailing.

Two admirable pastimes but not necessarily compatible with each other.....
 
There's been a thread running on here about that device for a while. In terms of capabilities it's right at the bottom and won't help the OP.

From the Shipmodul website it seems their miniplex 3 has UDP broadcast since last year. The WiFi module has its own firmware from an external source and changes haven't made their way into the miniplex documentation.

It's a rather expensive unit but tempting as it will deal with any system connections current or future.
 
Hoolie said:
There's been a thread running on here about that device for a while. In terms of capabilities it's right at the bottom and won't help the OP.

From the Shipmodul website it seems their miniplex 3 has UDP broadcast since last year. The WiFi module has its own firmware from an external source and changes haven't made their way into the miniplex documentation.

It's a rather expensive unit but tempting as it will deal with any system connections current or future.
Click to expand...

Yes i think multiple devices is fine.

Expensive but if I do this it won't be a massive percentage of the whole project..... Which will be a great percentage of the value of the whole boat..... Hmmmm. Removable project i think...
 
Catching up with things here, as I've been busy launching our device on Kickstarter, but following up on a few of the threads:
- our device isn't intended to be a multiplexer or a router or a NMEA0183/Seatalk/NMEA2000 converter, but just to do one thing well. And it's simplicity is reflected in the price (at the Kickstarter price, you could get 7 for the price of 1 ShipModul, for comparison). Why pay for features that many people don't need?
- on UDP and TCP, quite a few apps out there just support one or the other, and some are also fixed on the port number they can use, so any device should offer both TCP and UDP, and have a configurable port number. Also, quite a few devices offer TCP but only to 1 user, and most have to switch between TCP and UDP rather than offering both simultaneously, so you need to reconfigure them to change betwee4n protocols. As UDP is broadcast, it can be used by many users at once, but it only goes in 1 direction, so doesn't allow changing the route or controlling the autopilot from the app.
TCP guarantees delivery, with data being resent if its receipt isn't acknowledged by the app, so is inherently more reliable. However a down side is that if an app on an iPhone or iPad is brought up over your nav app then the operating system cuts the network connection, and unless the app is well written it isn't properly closed at the NMEA Wi-Fi device, so unless the device has a timeout the connection can be left open until it is reset (this isn't a problem with Android, as it is multi-tasking). The same can happen with either platform if the phone disappears down the dock and gets out of range for Wi-Fi.
With UDP the data is just squirted out with no guaranteed delivery or resending - not a problem for most NMEA data, but it can be if you want to receive things like waypoint arrivals or alarms or other 1-off messages.
From the above you can see that UDP is inherently more lossy than TCP. But as well as the normal broadcast UDP (which sends data to anyone) there is also multicast (where it is sent to a specific set of subscribers), and this is more reliable than broadcast. I first came across this in this post: http://stripydog.blogspot.co.uk/2015/09/marine-data-transports-re-visited.html and have duplicated these findings using both our and other devices that support both types of UDP.
 
smartcom said:
As UDP is broadcast, it can be used by many users at once, but it only goes in 1 direction, so doesn't allow changing the route or controlling the autopilot from the app.
Click to expand...

This may be true of your device and undoubtedly several others, but isn't a truism: Whilst there's no convenient broadcast equivalent of IP_MULTICAST_LOOP socket option and ignoring what you've written is a bit clunkier, you can still implement a read-write udp broadcast data bus architecture. Autopilot control over broadcast udp over wireless, for the reliability reasons you mention, would not be ideal though. kplex and opencpn can both read and write a broadcast socket. It's not always a good idea of course.....

smartcom said:
With UDP the data is just squirted out with no guaranteed delivery or resending - not a problem for most NMEA data, but it can be if you want to receive things like waypoint arrivals or alarms or other 1-off messages.
From the above you can see that UDP is inherently more lossy than TCP. But as well as the normal broadcast UDP (which sends data to anyone) there is also multicast (where it is sent to a specific set of subscribers), and this is more reliable than broadcast. I first came across this in this post: http://stripydog.blogspot.co.uk/2015/09/marine-data-transports-re-visited.html and have duplicated these findings using both our and other devices that support both types of UDP.
Click to expand...

So here one of us has a misunderstanding. Obviously I think it's you but I may have just misunderstood you (ie it could be me :-), or you're missing out some crucial detail. There should be no fundamental difference in reliability of delivery of multicast vs. broadcast over wifi to an endpoint in the kinds of situation we're considering here. The article you're referencing is comparing delivery of unicast udp (reliability ensured at layer 2) vs broadcast udp. Multicast over wireless is no different from broadcast: there's no reliability of delivery at layer 2. The only situation where it does become reliable is if the device implements IP multicast over 802.11 unicast. If your device does that you should most definitely be playing it up as a major feature which will vastly improve people's experience of garmin/navico radar over wireless in opencpn. If you *don't* do that then I argue that multicast will be just as lossy as broadcast.
 
Another question for anyone who knows about nmea 2000. Further down the line the Raymarine EV100 tiller pilot looks interesting. For my epic single handed voyages......! So I think they use different connectors to standard nmea2000? Ridiculous. But then am I better going for Raymarine depth & wind and I70s. I assume shipmodul have the facility to connect to a ray nmea2000 network?!
 
AFAIK Raymarine protocols and data formats are standard NNEA2000. The different connectors carry an additional Seatalk1 wire for back compatibility with earlier equipments. They have a Seatalkng to NNEA2000 adapter cable so I don't think there will be any problems with the Shipmodul device.
 
Hoolie said:
AFAIK Raymarine protocols and data formats are standard NNEA2000. The different connectors carry an additional Seatalk1 wire for back compatibility with earlier equipments. They have a Seatalkng to NNEA2000 adapter cable so I don't think there will be any problems with the Shipmodul device.
Click to expand...

Sure. But then if i have normal nmea i have 2 backbones? Or not?
 
laika said:
This may be true of your device and undoubtedly several others, but isn't a truism: Whilst there's no convenient broadcast equivalent of IP_MULTICAST_LOOP socket option and ignoring what you've written is a bit clunkier, you can still implement a read-write udp broadcast data bus architecture. Autopilot control over broadcast udp over wireless, for the reliability reasons you mention, would not be ideal though. kplex and opencpn can both read and write a broadcast socket. It's not always a good idea of course.....



So here one of us has a misunderstanding. Obviously I think it's you but I may have just misunderstood you (ie it could be me :-), or you're missing out some crucial detail. There should be no fundamental difference in reliability of delivery of multicast vs. broadcast over wifi to an endpoint in the kinds of situation we're considering here. The article you're referencing is comparing delivery of unicast udp (reliability ensured at layer 2) vs broadcast udp. Multicast over wireless is no different from broadcast: there's no reliability of delivery at layer 2. The only situation where it does become reliable is if the device implements IP multicast over 802.11 unicast. If your device does that you should most definitely be playing it up as a major feature which will vastly improve people's experience of garmin/navico radar over wireless in opencpn. If you *don't* do that then I argue that multicast will be just as lossy as broadcast.
Click to expand...

OK, I've been writing this for a marine audience, and not for computer network experts. So some things have been simplified in order not to lose or confuse people.

Yes, there can be UDP going the other way, but to the best of my knowledge nobody has implemented this in the marine sector. There's a couple of good reasons for this. First, data going from the app to the instruments tends to be commands, so you want to be pretty sure that they get through . UDP doesn't have any guaranteed delivery, so you either take the brute force approach of sending (say) 50 times, or you add a protocol on top to check delivery - in which case you may as well use TCP. Secondly, a surprisingly large number of NMEA to Wi-Fi devices have fixed SSIDs and no security. So if 2 boats with the same device are in range of each other, boat A's commands to its autopilot may also be picked up by boat B, much to the consternation of boat B's crew. You may say that devices like this shouldn't be around, but the reality is that they are. So there are good reasons why marine apps don't implement 2-way UDP.

On your second point, it is my error. Too many long and busy days over the last week or two, and failing to insert my brain between eyeball and keyboard! You're right that there is no difference between multicast and broadcast, and that the difference is compared to unicast. We are looking at implementing unicast, as multicast to unicast conversion, though this is at any early stage and it will probably be a firmware upgrade rather than being finished when the initial Kickstarter orders ship, assuming we are successful. This will significantly reduce data loss over UDP. There will be limitations, such as a limited number of clients, and also only working when our device is in AP mode. As well as your interest in radar over Wi-Fi, it will also benefit those apps that only support UDP mode. But in the short term we have to finish off the core functionality for the Kickstarter project.
 
You must log in or register to reply here.

Share this page

Top