Onderwerp: Incorrect RMC bericht! Hoe kan dit?

roozeboos schreef :
Ok, Iets nu gedaan wat ik normaal nooit doe als ik onderweg ben. Op vage grond een firmware update doen.

Nu heb ik een mux die alleen nog maar om de paar minuten
wacht op data
CCCCC
*****update mislukt mededeelt

Was duidelijk geen goed plan.

Nu dus letterlijk verder van huis. Met een niet meer functioneerden systeem.

Oei.........
Heb je de laatste instelsoftware ook ge- update?

Anders zou ik dat ook doen, en dan nogmaals firmware up date uitvoeren.

koko schreef :
Helaas wel. Ben nu hier naarstig op zoek naar backup van oudere werkende versie.

Helpt deze?

Firmware ook downloaden en unzippwn naar c:\st

roozeboos schreef :
Helaas gedaan nu geen werkend mux meer aan boord. Varen dus nu met beperkte nav middelen. Geen ais,log. Dieptemeter provisorisch. Wil toch vandaag echt naar een leuke veilige plek om de komende depressie en bijbehorende wind het hoofd te bieden op een prettige manier.

Nu hier even aan boord andere prio.

Straks verder zoeken naar instel programma en firmware van vorig jaar.

Firmware vorig jaar zoeken heeft geen zin.
Er zit nu geen firmware meer in.
Zeer waarschijnlijk omdat de nieuwe firmware bin file niet op je pc staat.
Eerst controleren of je iets hebt staan in je c:\st mapje.

Begrijp niet helemaal waarom je dit doet net voor of tijdens varen.
Hoe dan ook. Het komt goed

3Noreen schreef :
Beroerd. Ik hoop dat het spoedig weer werkt.
Maar het is wel een les in Close Coupling en Unexpected Interactions... zie het boek Normal Accidents met vele voorbeelden. https://en.wikipedia.org/wiki/Normal_Accidents

Alles aan alles koppelen en bovendien een single point of failure (de mux) opnemen in de keten is een risico... Dat probeer ik zoveel mogelijk te vermijden door dingen niet mee te koppelen (AIS niet via de mux maar direct USB de PC in, GPS kan buiten de mux om aan de Seatalk en PC, reserve-GPS en reserve-PC, stuurautomaat kan buiten mux om aan GPS, etc).

Sterkte ermee!

Met een dieptemeter en gps kom ik een heel eind hoor. Het is een beetje primitief zelf sturen en zo.

In het zip bestandje zitten 4 files

ncwf.bin dd 25 mei 2017
ncwf2.bin dd 8 mei 2017
ncwf3.bin dd 8 mei 2017
ncwf4.bin dd 8 mei 2017

klopt dit wel die datums ?

Ja dat is correctbin dit geval

Instel programma is 1.j1

Ok

roozeboos schreef :
Nee, niet Ok..... 2x Mux dood na Update. Bricked zoals ze dat aan deze kant van de Noordzee zou treffend kunnen zeggen.

Kan niet

roozeboos schreef :
Jawel hoor. Het enige wat ze aan de wereld nog laten weten is

.
.
.
.
.
.
.
.
geen reactie
.
.
.
enz. enz.

Of als ik met het instel programma een update wil uitvoeren.
lange tijd enig gedoe en dan de mededeling update mislukt.

Je moet vinkje update uitvoeren aanzetten. Dan moet ie updaten. Kan haast niet anders.
Of je moet de bin files niet in c:\st hebben staan.
Ik kan het oplossen met teamview maar ben nu niet op de zaak.
Pas disndag of woensdag helaas

3Noreen: Forumlid Koezt heeft onlangs hetzelfde probleem gehad, en weer opgelost. Helaas heeft hij niet precies gemeld hoe. Wat ik er van begreep ging er bij hem iets mis met de compoort waardoor de communicatie verstoord werd. Ook hij melde nog slechts puntjes te zien. Die puntjes schijnen te betekenen dat de mux bezig is te zoeken naar de update info. Ergo: de mux leeft nog.
Wellicht kan je Koezt een pb sturen en van hem horen hoe hij het heeft opgelost.

Persoonlijk vermoed ik dat Windows iets heeft gewijzigd in zijn beveiliging, want het updaten liep eigenlijk altijd goed. Het blijft ontzettend balen, zo tijdens een tocht hier mee geconfronteerd te worden. Succes

Ja. ,maar de mux geeft wel de juiste data weer in het disgnosecscherm. Dat er geen App in zir.
Normaal gesproken is dan het vinkje aanzettrn voldoende. Als dd bedtanden ook op de juistr plek staan. Maar dan krijg je een melding als dat niet het geval is.

Nog een spinsel:

Heb je per ongeluk de firmware van de Multiview gedownload ipv de multiplexer?

koko schreef :
Om je de waarheid te zeggen, het probleem is complexer. Wij gaan komende drie maanden zeilen richting Spanje. Daarvoor wil ik dat de apparatuur aan boord zo goed mogelijk functioneert. We zijn nu aan de oostkust van Engeland. De komende dagen gaat het flink waaien met als gevolg dat we het hier even rustig aan kunnen doen. Dus tijd om even naar wat problemen te kijken.
Op de overtocht van Den Helder naar Harwich had ik met enige regelmaat een alarm van mijn RM C120 plotter dat de AIS connectie lost was. Vervelend, gepiep, diegene die ligt te slapen wakker, de plotter moet aan en uit gezet worden. Zo’n 6 a 8 keer in de 22 uur oversteek.

De RM C120 plotter heeft 1 nmea ingang. Deze is verbonden met de uitgang 1 van de roosmux. Op die mux zit de AIS, log/diepte, kompas en windmeter. Deze data worden door de mux doorgezet naar uitgang 1 als mede de USB. De USB is verbonden met mijn Raspberry mini computer. Hierop draait mijn eigen software. Eén van de dingen die deze software doet is een log bijhouden wanneer er een Checksum fout van een NMEA bericht is. Uit dat logje bleek dat tijdens de oversteek een keer of tien een Checksum fout in een AIS bericht zat. Hiermee heb ik een indicatie waarom de plotter een alarm afgeeft.

Mijn zoektocht is dus waar deze Checksum fout vandaan kan komen. In mijn idee kan dat vier oorzaken hebben.
1. Er is een slechte verbinding AIS mux.
2. De AIS ontvanger zelf maakt die fout zelf
3. De gecombineerde datastroom die de mux binnenkomt is meer dan er via 38400 baud uit kan naar de plotter.
4. De mux maakt fouten.

Om een idee te krijgen of 1 of 2 het geval was heb ik de draad vanuit de AIS los genomen van de mux en aangesloten op de raspberry. Vervolgens een nacht laten lopen. Dit resulteerde in NUL Checksum fouten in het log. Daarmee zijn oorzaken 1 & 2 voorlopig van argwaan ontheven.

Oorzaak 3 dan ? Maar de raspberry die de Checksum fout constateert is via USB met de mux verbonden.Een USB1.0 moet met gemak de aangeboden datastroom van 38400+(3x4800) baud aankunnen. Kortom even hier niet teveel de oorzaak zoeken.

Komen we bij oorzaak 4 aan. Kan de mux de data wel fout vrij doorgeven.

Een voor mij makkelijk uit te voeren test is mijn 10Hz GPS die normaal gesproken direct op de raspberry zit als enige instrument op de mux aan te sluiten.
Het volgende plaatje is de output van de gps naar Hyperterminal.




Dit is een schermafdruk van de mux.





Als je deze twee plaatjes goed bestudeert zie je dat de mux tussen het RMC bericht tijd 085739.3 en 085739.6 de mux de fout in gaat twee RMC berichten weglaat en andere zinnen muteert. De berichten 085739.4 en 085739.5 zijn verdwenen en er staat een stuk van een GGA zin.
Afgezien van het nut van een snelle GPS kun je hier dus een mogelijke oorzaak zien. De mux kan de datastroom niet verwerken. Hetgeen ik ook hier in dit draadje gemeld heb.
De remedie, door Roozeboos aangegeven, zou zijn om de Firmware te updaten. Met een duidelijke ondertoon dat zonder de meest recente Firmware een discussie niet zinvol kon zijn. Uiteindelijk bracht de update alleen heel veel meer problemen. Hetgeen hier duidelijk mis gegaan is.

Nu vind ik dat een product wat al 3 jaar bij mij aan boord gebruikt wordt en al herhaaldelijk van nieuwe Firmware voorzien in de basale functie van het multiplexen en doorgeven van data tot een zeker maximum aan zou moeten kunnen. Dat het dit na deze periode nog niet doet is op zijn minst onbevredigend. Je zou zeggen dat hij getest is tot een volle datastroom op de uitgang van de maximale baudrate van 115200. Bovendien verwacht je dan een fallback dat volledige zinnen met een lage prioriteit weggelaten worden. Niet dat er dan halve zinnen uitkomen.

Wat is nu in mijn geval wijsheid. Eind van deze week zou ik toch graag weer met een volledig functionerend systeem weg willen van deze plek.
1. Moet ik er van uitgaan dat tegen het einde van de week een goed geteste roosmux hier is die gegarandeerd een datastoom van 115200 baud aan kan. Verder bij overflow geen halve zinnen produceert. Kan de processor die in de mux zit dit eigenlijk wel aan ?
2. Of moet ik door de zure appel heen bijten en bij Meindert Sprang een alternatief bestellen. Waarvan Meindert garandeert dat zijn product een 100% belasting aan kan.
3. Of hier de zaak provisorisch met een raspberry aan elkaar koppelen in de wetenschap dat nmea0183 aan zijn EOL gekomen is en datastromen die van ais, snelle kompas en gps niet kan verwerken en toch maar in de nabije toekomst overgaan naar n2k.

3Noreen schreef :
Begint de garantie bij elke firmware-update opnieuw?
Zou wel moeten eigenlijk, als updates niet alleen oude ellende oplossen maar ook nieuwe ellende introduceren.....

Mijn Miniplex van 2003 heeft nog nooit een update gehad, kan niet eens in the field.
Maar ja, ook niet nodig gehad, dus het geeft niet.

Is het zeker dat die checksum errors direct gerelateerd kunnen worden aan een C120 alarm?

De reden dat ik dat ter discussie stel is dat ikzelf een C120 bezit waar geen mux aanzit maar het AIS verkeer rechtstreeks van een transponder op die ene NMEA ingang van de C120 komt. En ik heb dezelfde regelmatige alarm situaties van "AIS connection lost".

"BK: Je ziet dat verkeerd! De miniplex is een marktwaardig product, de mux een community ontwikkeling. Dat is nooit klaar - vergelijk het met het aantal posts hier om het opensource project "OpenCPN" stabiel en volledig aan het lopen te krijgen/houden. Brambo's advies is bijna altijd te wachten op een nog nieuwere versie. Of eventjes een kernel upgrade te doen. Daar doet deze draad mij aan denken...

Anyway Chris is flexibel en slim genoeg om ook dit even op te lossen hopelijk! The moment of truth...

Nachtvlinder schreef :
In mijn idee betekend open source open broncode. Van de mux is bron code niet open. Verder zijn de prijzen van de mux best wel in de buurt van miniplex.
Maar mocht het zo zijn dat het geen marktwaardig werkend product is lijkt me heel duidelijk wat mijn actie moet zijn. Heel snel morgen een marktwaardig werkend product bestellen.
Verder zou dat inhouden dat we de mux kunnen beschouwen in de zelfde categorie als de raspberry e.d. Dat is niet zoals Roozeboos het brengt.