Onderwerp: Fast Packet errors Wat moet ik er mee?

Allen,
Mijn n2k netwerk lijkt goed te werken, echter in het diagnosescherm krijg ik steeds Fast Packet errors. Me iets ingelezen te hebben zou dit kunnen betekenen dat er ergens een connectie niet helemaal 100% zou kunnen zijn. Na alles te hebben nagelopen, krijg ik nog steeds die errors, zo'n 1 per 1/2- 1 uur. Nu blijken ook nog eens de meningen op het www verdeeld te zijn of je er iets aan zou moeten doen of niet. Mijn apparatuur is vooral B&G, maar zeker niet alles, dus daar zou het ook nog eens aan kunnen liggen. Twee vragen: wie weet er alles van en kan mij hierbij helpen, en, hoe spoor je het beste de bron van zo'n error op?
Het netwerk geeft verder geen enkele error :

Heb je op de uiteinden van de netwerk kabel wel afsluitweerstanden?

Mijn mening je hoeft er niets aan te doen, een fast packet is volgens mij een bericht dat zich vaak en snel achterelkaar herhaald (aangepast opnieuw wordt verzonden) waardoor het geen zin heeft om hem opnieuw te sturen als hij niet is ontvangen. Als je er dan 1 per half uur mist is het geen probleem.
Je moet je bijvoorbeeld voorstellen dat het kompas 10 keer per seconde zijn richting verstuurd, dat vindt je stuurautomaat prettig maar als je er een keer eentje mist is het niet erg.

opsporen: één voor één componenten uit het netwerk halen tot de fout verdwijnt, dan is de laatste de boosdoener

Een standaard N2K bericht bestaat uit een header en 8 databytes. Zo’n PGN kan een normale of “fast update” rate hebben.

“Fast Packets” is iets anders: dit zijn PGN’s waarvan de data niet in de standaard 8 bytes passen. Deze worden dan als sequence verzonden, waarbij elk deelbericht uit dezelfde header met 8 bytes bestaat, elk voorzien van volgnummer zodat de ontvanger(s) deze kan decoderen. Wanneer daar PGN’s van andere bronnen tussendoor komen is dat geen probleem.

Ik krijg deze errors incidenteel wanneer ik een apparaat opstart. Is in de praktijk geen probleem, informatie zal automatisch opnieuw verzonden worden, of zelfs op verzoek.

Je kunt via een RPi met CAN ondersteuning of Actisense software kijken welk apparaat deze fast packets verstuurt; de fout hoeft echter niet door dat apparaat veroorzaakt te worden.

Daar zou ik mij geen zorgen over maken.


Lekker zo laten dus, of steeds een apparaat ontkoppelen, dan zie je wanneer deze fouten ontstaan.

Dan heb ik wel de bel gehoord nu de klepel nog vinden

Die “small fast packets” in de screendumps ken ik niet trouwens...

Hier de info inzake fast packets te vinden op:https://en.m.wikipedia.org/wiki/NMEA_2000

The Fast Packet protocol defined in NMEA 2000 provides a means to stream up to 223 bytes of data, with the advantage that each frame retains the parameter group identity and priority. The first frame transmitted uses 2 bytes to identify sequential Fast Packet parameter groups and sequential frames within a single parameter group transmission. The first byte contains a sequence counter to distinguish consecutive transmission of the same parameter groups and a frame counter set to frame zero. The second byte in the first frame identifies the total size of the parameter group to follow. Successive frames use just single data byte for the sequence counter and the frame counter. Because many of the NMEA 2000 parameter groups exceed 8 bytes but do not require the 1,785-byte capacity of multi-packet, the default method of transmitting multi-frame parameter groups in NMEA 2000 is using the Fast Packet protocol.

Regardless of which protocol is used, multi-frame parameter groups are sent on a frame-by-frame basis and may be interspersed with other higher priority parameter groups using either protocol, or even single- frame parameter groups. Each device is responsible for reassembling the parameter group once all the frames for the parameter group are transmitted.

Alvast bedankt voor de reacties. Inderdaad, er zitten terminators op de uiteinden. Ik heb ook de stroom eens gemeten. Er is een verschil van 1/2 volt tussen het ene uiteinde van de backbone en de ander. Dus alhoewel er ongeveer evenveel devices aan beide zijden van het stroompunt zitten, zou ik daar qua balans misschien wat aan kunnen doen.

De hele exercitie ben ik aan het doen omdat nadat de stuurautomaat zich ineens vreemd is gaan gedragen, met schade tot gevolg, ik op zoek ben naar een aanwijsbare oorzaak. Bovendien zitter er soms grote hiaten in de track die door de Zeus3 word opgeslagen, gewoon weg.
Ik weet ook niet wat de Zeus noteert. Zijn dat algemene errors op het netwerk, of Zeus specifieke errors die verder geen invloed op de rest hebben.
Door een B&G tech werd ik op de fast packet errors gewezen, volgens hem moet dat op '0' staan. Hij vertelde er helaas niet bij hoe deze errors precies mijn problemen verklaren, dus ik probeer het maar op 0 te krijgen. Daarnaast is t weer zo dat wat ik er van lees op t www, alleen B&G deze errors noteert, en de n2k gemeenschap er zich vooral niets van aantrekt.

@Nachtvlinder De small fast packets kan je vinden als je gaat naar sources, dan tussen de devices waar de Zeus uit bestaat, staat ook de MFD zelf, dan selecteren. Daartussen staat dan ook een diagnose mogelijkheid.

Beide stuurautomaten? Dan lijkt je fluxgate de boosdoener.

Geen volledige tracks? Dat kan ook een GPS-probleem zijn.

Koppel beide af en kijk of de foutmelding verdwijnt.

Ik ga natuurlijk alles afkoppelen, en uitproberen zodra ik weer op de boot ben. Maar, die tracks zijn geen GPS probleem denk ik. Tijdens het varen is er niets vreemds aan de hand, pas naderhand blijkt dat de track gaten vertoont. Zo zit er een gat van een aantal dagen in een track van 24 juni tm 6 juli. In de alarm history ( andere plek waar meldingen bewaard worden) zit een gat van 24 juni tm 13 juli. Dit lijkt me niet veroorzaakt door GPS, of een gebrek daaraan. Bovendien heb ik natuurlijk een gps in de plotter zelf, en een gps van de AIS.
Nu las ik op het www van iemand die met een scope in staat was snel storingen op te sporen. Weet iemand hoe ik dat zou kunnen doen? Ik heb ook een n2k log meelopen, kan ik daar iets uithalen?