Onderwerp: NMEA2000 niet naar top van de mast

Zeilprutser schreef :
Latency en jitter hebben alles te maken met de kwaliteit van het signaal. Deze worden mede veroorzaakt door het protocol waarmee de data verstuurd word. CANbus is ontworpen om deze fouten te minimaliseren. Dat weet jij ook wel.

Nachtvlinder schreef : Zeilprutser schreef :
Waarom neem je aan dat N2K problemen niet eerst op fora gepost zouden worden en 0183 issues wel!? Gefrusteerde mensen posten maar al te graag hun issues!

Maar goed, wat zijn de typische problemen waar jij in combinatie met jouw product tegenaan loopt?

Zeilprutser schreef : ...heb ik het meeste wel over gezegd; niet nodig dat te herhalen. Mooi dat je dit verhaal hebt kunnen vinden. Ik ken er een boel betreft multiplexer-problemen, isolatie etc.


Zeilprutser schreef :
Verdiep je eens in de Bosch topologie en modules raad ik je aan. Gescheiden CAN bussen heeft andere redenen (bandbreedte en hierarchische lagen). Staan interessante white papers over online!

Uiteraard vind je problemen bij alle automerken. Er rijden er nogal wat van rond. Maar stel je nu dat de automotive niet voor CAN had moeten kiezen? Deze club heeft daar goed over nagedacht denk je niet? Als common-mode faillure een significante issue was geweest, had de automotive vast een andere standaard gekozen...

@ 3Noreen: Latency heeft in dit verhaal er niets mee te maken dat kan nog eerder optreden bij NMEA2000 bij NMEA0183 bestaat dat niet, ook is NMEA0183 per definitie beter bestand tegen "Jitter".
Dat is precies mijn punt als je de keuze moet maken tussen waslijn in je mast met kroonsteentjes of een N2K netwerk conform de specs natuurlijk is dan N2K betrouwbaarder.
Maar als je netjes afgeschermde signaalkabel gebruikt en een 4 polige waterdichte stekker dan is NMEA0183 veel betrouwbaarder!
Het probleem is dat als je bij NMEA0183 waslijn gebruikt en kroonsteentjes er vast nog wel een zinnetje doorkomt en de gebruiker denkt nou dat heb ik mooi voormekaar en ik ga zeilen, het werkt ook nog eens een jaar en ineens allerlei vreemde problemen, hoe kan dat nou????? En dan is NMEA0183 ineens onbetrouwbaar!!!

Lees ook galvanische scheiding in verschillende andere draadjes de laatste tijd, omdat de boel kennelijk niet meteen kapot gaat gebruiken de fabrikanten steeds vaker geen optocoupler op de ingang van NMEA0183 (dat ding kost maar een paar cent) ik krijg de indruk dat ze dat doen zodat je eerder overstapt naar het duurdere N2K.

Zeilprutser schreef :
Kan ik het helemaal mee eens zijn!

Om ook zo maar eens een quote te gebruiken:


Now my second caution......
Now consider this. If there is a problem with the NMEA2000 back bone, every piece of gear on that network that is dependent on it, stops working. Everything, that comunicates with each other, becomes non effective.
•The GPS stops working, including the plotter
•The fluxgate compass doesn't work
•Engine instruments don't work
•AIS doesn't show anything
•the autpilot stops working because it doesn't get a heading from the compass
Get the picture? Now we all know this will happen at the most inopportune moment. One may start (trying to find the fault) by unconnecting and reconnecting every connector on the back bone to make sure that they are properly connected. There can be meters of cabling in hard to reach and dar,k places on your boat and all it takes is just one of those connectors to fail and it's "lights out". And if the problem is intermittent, as it very likely will be, then the trouble shooting is going to be ten times more difficult. Then if cleaning and reseating connectors or terminators cannot solve a problem, then by all means seek the professional help of an NMEA-certified electronics technician. Good luck with that, in some of the locations we go to!

What we need to think about is what a network failure will do to us on a dark night in a tricky situation. We must have a backup plan. And because of the issues with trouble shooting these complex systems in remote places, it would be good to have a plan for continuing our cruise without all this interconnection potential problems.

Een rechtstreeks gevolg van de bus topologie.

Nachtvlinder schreef :
Dankje nachtvlinder, netjes van je.

Je hebt een mooi, overzichtelijk system. Ongetwijfeld goed aangelegd, maar ik mis redundancy.

Ik durf die uitdaging best aan, maar zoals ik al zei ik heb een hybride system, prima werkend en met voldoende redundancy. Ik zal het schema even updaten en plaatsen.

@ZP: 3Noreen bedoelt met "jitter" het niet met vaste, precieze, tussenpozen beschikbaar komen van 0183 zinnen. Jij verwijst naarklokjitter, variantie in kloksnelheid, stijlheid flanken op bitniveau.

Beetje flauw om hem hier op te pakken.

Verder val je in herhaling. Dat is ook logisch omdat jij hier voor je broodwinning vanaf hangt. JE zou wel gek zijn om gevoelig te zijn voor argumenten die je product buiten spel zetten.

Eenzelfde vooringenomen houding (kan ook een self fulfilling phrophacy zijn voor eerder gemaakte keuzes) tref ik, 100% voorspelbaar, aan bij een andere ZF-sponsor. Dat geeft niet, maar mede daardoor worden dit soort draadjes popcoern draadjes.

En ja, ik geniet van het gemak, betrouwbaarheid en "schoonheid" van N2K installaties. Tegelijkhertijd gruwel ik van de NMEA0183 schema's die hier af en toe langs komen. Geen touw aan vast te knopen. Het CAN principe deugt en de kostbare certificering houdt de crap uit de winkels (nu weer een ander draadje daarover - ben je momenteel in aan het posten

Succes verder!

Sjonge jonge. En dan bemoei ik me er niet eens mee! Zien jullie dat?

Je wordt wel genoemd hoor!

37south schreef :
Ik niet. Omdat commom mode failure voor mij geen issue is met grote kans laat staan hoog risico.

Nachtvlinder schreef : Ik vindt je suggestie dat ik hem probeer te pakken flauw en 37south heeft al uitgelegd wie hier het popcorn gehalte heeft ingebracht.

De tussenpozen (data rate) worden bepaalt in de gever en heeft niets te maken met NMEA0183 vs N2K natuurlijk heeft N2K wel meer bandbreedte om mogelijk meer data te versturen.
Ook dit heeft 37South al uitgelegd de mastunit kan gewoon op een baudrate van 4800 op 10Hz data versturen, zie ook de datasheet van de Autonnic windgever.

Zeilprutser schreef :
Een multiplexer plak de binnenkomende berichten nogal random aan elkaar, voorzover ze uberhaubt in de gemiltiplexte stream passen. Zowel dit als de lengte van de zinnen heeft een behoorlijk effect op het moment van beschikbaar komen van de data in de gemuiltiplexte stream. Dit is bij N2K veel voorspelbaarder:

-het network heeft een hogere bandbreedte;
-in geval van dreigende overload wordt op bitniveau geregeld welke PGN PRIO's weggedrukt worden

Hoe kan een 0183 multiplexer gespecificeerd zijn met 4 stuks 4800 baud inputs, een 38k4 input maar ook een 38k4 output? Hoe gaat het apparaat om in geval overload en wat betekent dat voor mijn 10 Hz kompas naar de AP?


Verdikkie, had al afscheid genomen hier!

Nachtvlinder schreef :
Dat jij niet weet hoe ze dat doen wil niet zeggen dat het niet kan.
Zoals hiervoor aangegeven kan een gewone multiplexer ook prima voldoen. Natuurlijk moet je oppassen voor port overflows als je data doorstuurt naar 4800 Poorten maar een beetje multiplexer heeft daar een tooltje voor.
Uitleg:
De maximale data uit een AIS is 2X9600 (kanaal A vol en kanaal B vol)= 19200 je houd dus nog 19200 ruimte over voor extra data dus 4 nmea ingangen van 4800 = 19200
Nu is het niet logisch dat alle Ports vol zitten dus ruimte genoeg.

Nachtvlinder schreef :
+1

And I thank you, I thank you for doing your duty,
You keepers of truth, you guardians of beauty.
Your vision is right, my vision is wrong,
I'm sorry for smudging the air with my song.

Nachtvlinder schreef :
Het is heel triest dat ik van de Moderator inhoudelijk niet op deze beschuldigingen mag reageren.
Mijn postings zijn verwijderd.

Nachtvlinder schreef :
Daarom heb ik zo eigenwijs als ik ben , gewoon voor dat uit 1856 stammende 0183 gekozen

Als ik dan toch weer het papier er bij moet pakken is de frustratie van 0183 stukken minder dan die berg dure kabels en dan nog op papier moeten varen .

In mijn geval een diepte metertje en een windmetertje, 4 draadjes moeten toch wel ook door mij een beetje fatsoenlijk aan te sluiten zijn , misschien zelfs zonder kroonsteen

Zeilprutser schreef :
Ik stel een vraag HOE iets kan... Dan kun je dat toch uitleggen? Ik stel de vraag niet voor niets, ben benieuwd hoe dit soort dingen hier geregeld zijn.

Zeilprutser schreef :
Dit betekent dat de het apparaat alleen gespecced is om een AIS op deze ingang te multiplexen toch? Er wordt aangenomen dat de load van deze ingang max. 50% zal zijn, waarbij de overige ingangen dan wel vol belast mogen zijn. Ben benieuwd wat voor tooltjes er zijn voor iemand die méér dan 50% op die poort wil aanbieden (2 multiplexers in serie bv): kun je bv per scentence een prioriteit geven? Of per talker-ID?

Overigens is onderstaande discussie nog niet klaar. Of klopt mijn feedback...?
Zeilprutser schreef :
Waarop ik antwoordde:
Klopt dit of werkt dit anders volgens jou?

Ik weet dat dit voor 3Noreen de reden is om van 0183 af te stappen. Ook ik ben (PolarPlot projectje, doet ook aan dynamische compensatie pitch&roll) afgestapt van het binnenhalen van data via een TCP/IP NMEA0183 server en lees en schrijf nu direct van de bus. 4 Hz, 5 devices lezen; 4 (virtuele) devices schrijven. Toch wel handig als de tijds-relaties tussen de data enigszins consistent zijn. Als je "gewoon wat op je metertje" wilt zien maakt dit allemaal niet uit en kun je zelfs met Signal-K aan de gang.
Het gaat hier echter over je opmerking "De tussenpozen (data rate) worden bepaalt in de gever en heeft niets te maken met NMEA0183 vs N2K".

Ook hier de toren van Babel?
Lijkt er op dat we het goed bedoelen maar het wordt vervuild door een portie argwaan

Nachtvlinder schreef:Het antwoord/uitleg staat er onder.

Nachtvlinder schreef:Ja een goede multiplexer heeft die mogelijkheden kijk maar in bijvoorbeeld de handleiding van de shipmodul ik mag niet verwijzen naar eigen producten.

Nachtvlinder schreef:Een goede multiplexer plakt in volgorde van binnenkomst de zinnen achterelkaar maar heeft ook filter en prio opties. (zelfs fallback opties)

Nachtvlinder schreef:Ja N2K heeft een veel grotere/hogere bandbreedte

Nachtvlinder schreef:Dat weet ik niet mbt N2K

Nachtvlinder schreef:Juist N2K en TCP/IP hebben potentieel kans op Latency ze verwachten een antwoord als door storing of data overflow of timing problemen en reflecties in de bus data niet overkomt kan het opnieuw verzonden worden waardoor de dataload extra toeneemt en dus Latency kan optreden.
Je kunt dus veel beter UDP toepassen juist bij hoge datarates is het niet erg als je een keer een waarde mist, binnen dit UDP protocol kun je prima een acknowledge vragen voor cruciale data.


Nachtvlinder schreef:Misschien begrijp ik niet wat voor jou hier nog niet duidelijk is?

Het gaat nog steeds over een windmetertje en een paar draadjes ?

Volgens mij leer ik een moslim sneller varkensvlees te eten , dan dat dit topic wordt opgelost

Een enkeling hier zou beter over kunnen stappen op een analoge windmeter, niks geen jitter of latency.

Nu nog eens...

in het huidige tijdperk is een ronddraaiende windmeter met magneetcontactje en richtingssensor GATACHTERLIJK en niet meeuw-resistent.

twee differentiele druksensoren in een onverwoestbare behuizing met NMEA2000 out en ingebouwde terminator

Wie maakt dit megaproduct ?

Toch nog veel misverstanden over de NMEA standards. Geen commercieel belang, maar toch nog maar wat ervarings input na vele jaren hiermee bezig te zijn geweest:

NMEA2000 is in de eerste plaats een consumer product en domineert anno 2018 in de recreatieve scheepvaart, met de belofte van eenvoudige installatie door hoge graad van standaardisatie, hoewel dat ik de praktijk soms tegenvalt. Bandbreedte is groot, waardoor redundant data geen probleem is. Helaas is de bandbreedte onvoldoende groot om ook grafische informatie zoals e-charts en radar te versturen. Door de bus topologie is NMEA2000 kwetsbaar, maar bij zorgvuldige installatie kan de kwetsbaarheid geminimaliseerd worden.

Installaties met NMEA0183, vooral waar multiplexers worden gebruikt vereisen vaak betere planning en wat meer technisch inzicht. Een nadeel dus vanuit consumenten oogpunt, maar met betere foutopsporingsmogelijkheden en minder kwetsbaar mits goed ontworpen en verstandig geinstalleerd. De mindere kwetsbaarheid is een gevolg van de ster-netwerk topologie en de relatief lage transmissiesnelheden. Zoals bekend is in de professionele wereld NMEA 0183 nog steeds de norm.
Veel oceaanzeilers prefereren de 0183 standaard om die redenen ook omdat redundancy en backup eenvoudiger zijn aan te brengen tegen lage kosten.

De NMEA 0183 standaard specificeert dat berichten 1x per seconde worden berstuurd met de snelheid 4800 baud. Later is daar 38400 baud bijgekomen, met name voor AIS transmissie. 9600 baud wordt wel toegepast, maar is niet standaard NMEA en wordt bijna uitsluitend voor GPS transmissie gebruikt ter vergroting van bandbreedte vooral wanneer meerdere GNSS systemen worden ondersteund, zoals GPS, Glonass, Egnos.
Andere baudrates moeten in geintegreerde systemen vermeden worden.
Van de 1Hz frequentie wordt tegenwoordig in de praktijk vaak afgestapt, met name voor compass heading bij radar overlay van e-charts en voor betere stuurkarakteristieken van auto pilots.

Bij ontwerp van multiplexers en toepassing daarvan staan efficient gebruik van de bandbreedje en minimale vertraging door buffering centraal. Eenvoudige multiplexers bestaan niet, maar goed ontworpen base-models bieden mogelijkheden tot filtering van redundant data, zodat bandbreedte problemen voorkomen kunnen worden.

Hoewel vrijelijke configuratie van in en uitgangen van een multiplexer een voordeel lijkt, leidt dit vaak tot data overflow. Bij een goed ontwerp moeten grenzen in de configuratie mogelijkeden worden ingebouwd.

Een andere ontwerp fout die bij diverse multiplexer modellen aanwezig is, is teveel buffering, waardoor onacceptabele vertraging kan optreden. Bij 10Hz talkers loopt de vertraging bij sommige produkten zelfs op tot meerdere seconden. Prioriteiten aan poorten toekennen verschuift het probleem alleen maar en is geen goede oplossing. Het bemoeilijkt ook het configuratie proces, dat zo simpel mogelijk gehouden moet worden.
Fifo processing en dynamische buffer-toekenning maken het proces efficient.
Bij 90% van multiplexer toepassingen is configuratie onnodig en kan "out of the box" installatie zonder instellingen plaatsvinden.
Bij een 10Hz 4800baud talker met berichtlengte van ong. 30 tekens wordt bij een uitgangsnelheid van eveneens 4800baud minder dan 2/3 van de bandbreedte gebruikt, zonder noemenswaardige toename van latency. De andere 1/3 is doorgaans voldoende voor 3 andere (standaard) NMEA talkers.

Wanneer de multiplexer uitgang op 38400 baud gezet wordt (bij computers en plotters, wifi) is er vrijwel nooit een bandbreedte probleem, ook bij aanwezigheid van AIS.
Bij iets meer geavanceerde multiplexer modellen kan de output data stroom worden gesplitst en via verschillende poorten worden verstuurd, zodat latency kritische data voldoende bandbreedte heeft.

Data overflow hoort bij een goed ontwerp NMEA multiplexer niet op te treden.

Prima samenvatting wat mij betreft!

Beide systemen hebben voor- en nadelen, het is aan de gebruiker te bepalen welke eigenschappen hij belangrijk vindt. Voor zover niet gepushed door het aanbod, bepaalt zo'n gebruiker op basis van zijn/haar kennis, ervaring maar ook mening en opinie wat hem het beste past.

@nachtvlinder
Betr. jouw "uitdaging" hier nog even mijn schema, als dat nog even via dit draadje mag. Niet helemaal eerlijk want het is een hybride systeem, maar ach.... Ik weet het, in sommige opzichten overkill voor mijn eigen soort gebruik van de boot (coastal NZ), maar ik gebruikte de boot ook als een "proefbank" en deze configuratie (met varianten) heeft model gestaan voor uitrusting van een aantal long-range blue water zeilboten, met toevoeging van SSB, radar, etc. Bij long range cruising/racing weegt redundancy & backup zwaar, maar is ook voor kortere trips erg plezierig en geeft vertrouwen, zoals ik ondervond toen de ZG100 GPS uitviel toen we in het duister een baai met veel rotsen binnenliepen. Alleen de GPS source op de plotter even naar 0183 veranderen en Bob's your uncle. We hebben ook papieren kaarten aan boord, en een Breton plotter, peilkompas enz. maar daar heb je op zo'n moment door tijdgebrek weinig aan.





Toelichting

Funktionaliteit:
De boot kan genavigeerd worden met alleen het N2K deel werkend, of met alleen 0183.

Alle GPS, AIS en instrumenten data is beschikbaar op plottter en iPad/computer/phone. Soms wordt de boot alleen met iMux, AIS en VHF aan gezeild om accus te sparen, plotter uit. In deze mode wordt automatisch de AIS GPS gebruikt.

Auto pilot:
Bediening via de Zeus plotter of B&G Triton instrument met OP10 remote. Tevens is er een OP10 naast de Zeus bij de stuurstand zodat je overal in de kuip koerscorrecties kunt maken indien nodig of de AP in standby mode kunt zetten.

Funktie van Standaard multiplexer:
Samenvoegen van langzame 0183 en Seatalk1 data stromen (wind, speed, GPS) plus nav data afkomstig van iNavX om met iPad de boot in track-mode (GPS mode) te kunnen sturen. Uitvoer 4800 baud naar N2K (via AT10) en naar iMux wifi multiplexer.

Funktie van wifi multiplexer (iMux):
Samenvoegen van AIS, DSC, heading van N2K en gecombineerde langzame instrumenten van std mux.
Totaal gecombineerde data stroom 38400 baud naar wifi en naar B&G Zeus plotter.
Een script in de iMux zet DSC/DSE data van de VHF om naar waypoints voor iNavX, OpenCPN (wanneer notebook aan staat) en de Zeus plotter. Zo weet je onmiddellijk waar de caller is en kun je zo een GOTO activeren om er naartoe te navigeren.
Een ander script blokkeert de GPS van de AIS om dubbele GPS sources te vermijden, Wanneer de GPS van de std mux niet wordt gedetecteerd, wordt de blokkering opgeheven. Dit is dus een automatische GPS backup-switch.
Wifi nav data van iNavX wordt doorgestuurd naar de std mux en vervolgens naar N2K voor track mode steering m.b.v. waypoints of routes in iNavX op de iPad of door OpenCPN.

De nodige filteringen zijn ingesteld om NMEA-loops en redundant data te vermijden.

De diverse verbindingen tussen kuip en nav station lopen via een enkele multi-core kabel.

Belangrijkste redundancy en backup:
Zeus Plotter faalt -> iPad met volledige plotter funktionaliteit inkl. AIS
ZG100 GPS faalt -> 0183 GPS op plotter door source selectie.
N2K backbone faalt -> Volledig 0183 navigatie met iPad of laptop.
AIS faalt -> SH GX2100 AIS receive only. (fysieke 2-way switch)
Alles faalt -> papieren kaart, Breton plotter en peilkompasje. Hoofdkompas bij stuurstand.

Funktie VDM encoder:
Met instelbare tussenposen worden class B NMEA zinnen (VDM) gegenereerd aan de hand van positie en SOG uit RMC zinnen, plus vaste gegevens als MMSI, callsign, bootnaam, boot lengte, positie van AIS op de boot. Dit is dus puur voor (gratis) tracking, niet voor collision avoidance. Via wifi wordt dit naar de 3G router gestuurd en vandaar internet op.
Samen met de eigen AIS data worden ook de gegevens van eventueel in de buurt zijnde schepen verstuurd, die als VDM zinnen via de GX2100 VHF of transponder worden ontvangen. Dit zou ook via een satelliet modem kunnen gebeuren, maar dat heb ik nog niet kunnen (laten) proberen. De hoeveelheid data is minimaal, dus kosten bij 3G/4G zijn verwaarloosbaar. Bij satelliet internet natuurlijk wat meer, maar door de update rate te verlengen tot bijv. 1x per 1/2 uur zouden kosten beperkt gehouden kunnen worden.

Het is bedoeld voor afgelegen plaatsen waar geen AIS tracking ontvangers zijn, maar wel 3G/4G coverage. Ik gebruik een penta multi-frequency antenne die ik ophijs naar een zaling.

De router met penta antenne geeft ons vrijwel overal, ook verder uit de kust, internet toegang voor weerbericht, gribfiles, email etc.
De wifi multiplexer maakt automatisch verbinding met de router in STA mode, als die aanstaat, zodat iPad, computer etc. toegang tot de NMEA data hebben via de router en niet hoeft te worden geschakeld tussen de iMux SSID en de router SSID tussen navigatie en bijv weerbericht bekijken. Direkt verbinding maken met de iMux blijft uiteraard ook mogelijk.

N2K backbone high and dry:



Met cover:

Wauw, je hebt er werk van gemaakt zeg! Helemaal duidelijk wat je bedoelt en waarom dit voor sommige gebruikers beter/veiliger kan zijn!

Ter aanvulling: omdat ik zo'n string van T-stukjes kwetsbaar en weinig compact vind, gebruik ik onderstaande devices. Gevoed via 7/8" connectors ipv een M12 micro-C "power insert".

Inderdaad mooi spul, mechanisch betrouwbaarder en compact. Als ik het had gekend toen ik het aanlegde, had ik het zeker gebruikt.