Onderwerp: Never change a winning team. Of toch wel?

Na de 200 Myls moest het er toch maar van komen. Een AIS transponder. Want die is verplicht als je de zee op wil tijdens de 200Myls. Dus een aanbieding gepakt van een Emtrak 923 met een Quark Elec 032 N2K->Wifi converter en verrek, de hele boel is binnen een mum van tijd aangesloten en operationeel. Althans.....

Nu had ik de setup al best mooi voor elkaar. De backbone in de boot is modern, ik heb een moderne Raymarine plotter, ik heb een losse NMEA converter en een goedkope maar erg effectieve NMEA->Wifi converter waarmee ik op de iPad Iregatta draai voor de performance metingen en Navionics daarnaast succesvol kan gebruiken. Ergo; in de 'oude' setup krijg ik netjes GPS data binnen van het netwerk die Navionics op de ipad ook netjes 'ziet' en gebruikt.

Enfin, lang verhaal wat langer, in de nieuwe setup met de Quark Elec wifi converter zie ik nog steeds alle boorddata voorbij komen op de iPad, maar ik krijg met geen mogelijkheid meer de GPS fix in Navionics op de ipad. Wel netjes alle AIS doelen, Navionics meldt ook netjes de gevonden nieuwe hardware, maar GPS-sen? Ho maar. Switch ik terug naar de oude wifi converter, dan heb ik plots weer plaatsbepaling.

Nou ben ik ook niet voor 1 gat te vangen, dus ik heb een NMEA logger erop gezet. En dan zie ik eigenlijk alleen maar een klein verschil tussen de 'oude' en de 'nieuwe' situatie. De GPS wordt met een andere string geduid. Oude sentence: $IIGLL Nieuwe sentence: $GPGLL. Geen idee of dat het probleem kan zijn, maar het valt me op. Het enige wat ik kan bedenken is dat in de oude situatie de N2K data eerst via een converter naar regulier NMEA0183 4800 baud wordt geconverteerd, alvorens het in de wifi converter wordt gestopt. In de nieuwe situatie ga ik rechtstreeks van N2K de nieuwe wifi converter in (want die kan dat). Maar of dat nou echt het verschil mag uitmaken?

Anyways; ik heb me inmiddels suf gepeinsd en heb er een hard hoofd in dat ik het nog ga fixen. Maar wellicht heeft iemand een slim idee en zie ik nog wat over het hoofd. Let me know in dat geval!

(N.b. voor de duidelijheid; alle overige apparatuur werkt en blijft gewoon werken want zit hardwired op het n2k netwerk. Het gaat dus uitsluitend om de iPad met Navionics.)

Gps gegevens kunnen in verschillende nmea berichten versleuteld worden. De quark converter zet je nmea2000 bericht in een ander nmea183 bericht. En Navionics haalt blijkbaar niet uit dát bericht zijn/haar gps gegevens… deze gps gegevens kunnen uit de reguliere gps nmea berichten verstopt zitten of in AIS nmea berichten. Kijk even of je in Navionics daar iets mee kan. In iSailor kan ik dat iig wel instellen.

Elke zichzelf respecterende MUX kan een NMEA header aanpassen (die van Roos, de miniplex, zelfs brambo's RPI met signalk lukt dat).

Dus waarom zou een Quark het niet kunnen?

Je kunt bij de Emtrak de gps info uitzetten (Tenminste bij z'n broertje wel). Dan krijgt de Navionics z'n gps info volgens mij weer op de manier als voorheen en zou het weer werken.

Even wat antwoorden in volgorde van reacties (dank!)

OFRI: Nee, bij Navionics kun je niks, helemaal niks configureren en/of kiezen qua datastream.
Reuver: Helaas. De Quark kan dat niet, voor zover ik weet. Ik check het nog ff bij de leverancier.
Unster: dat maakt geen verschil. Daar zit het dus niet.

mystudio schreef :
II is officieel NMEA0183 voor Integrated Instrumentationc (niet specifiek 1 leverancier)
GP staat voor GPS.

Deze Talker-ID's horen niet gebruikt te worden door een navigatietoepassing.
De GLL is het enige waar ze naar moeten kijken.
Kennelijk heeft Navionics de IIGLL message ooit voor zichzelf ingesteld als 'de GPS'.
En nu dat GPGLL is negeert Navionics dat, denk ik.

Zou je toch ergens moeten kunnen instellen in die app, of anders eens een verse installatie doen en dan laten wennen aan GPGLL

Met een degelijke mux ertussen kun je deze Talker IDs wel gebruiken, voor Routing, voor primair en backup, voor blokkeren etc. Misschien eens overwegen?

Ik denk dat ik je begrijp BK. Dus het zou niet mogen uitmaken wat er voor de GLL string staat. Toch is het opvallend dat zowel Navionics als iRegatta BEIDE niet meer de GPS ontvangen via de nieuwe setup. Kan die $II vs. de $GP string dan toch ergens roet in het eten gooien? Concreet mis ik in de nieuwe setup dus de SOG, COG en exacte plaatsbepaling. Het is dus niet een uniek Navionics probleem. Bijgaand ook 2x de log die ik gemaakt heb met een NMEA log programma.

Het is overigens geen mega probleem, merkte ik vandaag. Want de GPS uit de nieuwe AIS wordt WEL doorgegeven aan Navionics en iRegatta op de iPad. Alleen blijf ik het merkwaardig vinden dat de bestaande GPS'sen in het N2K netwerk NIET worden doorgegeven. Ik ga eens contact zoeken met de leverancier, wie weet zijn er firmware updates mogelijk.

het komt vrij veel voor dat de prefix gewijzigd wordt en de suffix niet.
De prefix bepaald vanuit welk toestel het komt, de suffix bepaald welke data het is.
Een NMEA ontvangend toestel mag eigenlijk nooit last hebben van de prefix, anders is de software brak.

$GP mag dus alles worden zoals $II (integrated instrument), maar GLL veranderd niet.

Kortom brakke software in de achterliggende toestellen die niet goed uitgedacht is.
Wij komen het vaak tegen.

In de 2e log zit geen RMC. Alleen GLL. En de sog en cog zitten in de RMC, niet in de GLL.
En dus heb je dan geen koers en snelheid.
Instelling in dat apparaat wijzigen en RMC laten verzenden.

Ik zie in het 1e log wel RMC
$IIRMC,143215.25,A,5220.429,N,00507.911,E,

Gepost met de officiële Zeilersforum-app

IIRMC, dus niet uit de AIS.

Baasklusje schreef :
Dat weet je niet. $IIRMC kan voortkomen uit een hernoeming van &GPRMC
Daarbij is de prefix:
$GP = GPS
$GB = Beidu
$GL = Glonas
$GA = Galileo
&GN = GNSS (algemeen)

En nog ean paar. Om die redenen moet het achterliggende toestel uitsluitend letten op de suffix RMC en zich niks aantrekken van de prefix.
$II mag dus geen verschil maken.

Brakke software.

Thx mannen. Ik ben er nog niet achter waar het misgaat. Vandaag verschillende nieuwe logs gedraaid met de NMEA capture en die zal ik eens napluizen. Voorlopig lijkt het toch echt 'brakke software' zoals Calidris al zegt. Wat niet heel raar is want Navionics heeft nog nooit fatsoenlijk NMEA data ondersteuning geboden in hun apps. Niet hun businessmodel. Aan de andere kant, het werkte uitstekend op de 'oude' manier. Dus met een extra conversie stap van N2K naar NMEA0183/4800 naar een WIFI converter is er geen centje pijn. Haal je die extra stap er tussenuit en ga je rechtstreeks van N2K naar WIFI gaat het mis. Rara. Voorlopig kan ik alleen maar verschil ontdekken in de prefix. Want de GLL data is in alle gevallen gewoon aanwezig.

Elk nadeel hep wel een voordeel; ik begin NMEA steeds beter te begrijpen nu ik erin moet duiken

mystudio schreef :
NMEA2000 is totaal anders opgebouwd dan NMEA0183. Weet je zeker dat de N2K naar Wifi niet ook een converterslag maakt naar 183?

Zeker wel. Via WIFI wordt altijd NMEA 0183 verstuurd. Dus de nieuwe situatie converteert de WIFI router het N2K signaal naar NMEA0183. Maar goed, dat verklaart voor mij nog niet het 'probleem'.

Ik herhaal mezelf nog even:
in het log oude situatie zit wel een RMC.
In het log nieuwe situatie zit geen RMC

In RMC zitten positie, SOG, COG, Datum en Tijd.
En die zal dus vast gebruikt worden door de nav-app.
Niet de GLL, met alleen positie.

Dus, kijk of je je AIS met GPS een RMC kan laten versturen.

Er is een mogelijkheid dat de fout toch in de NMEA data zit en niet in Navionics: als de checksum niet klopt is het correct dat de data genegeerd wordt.

Bij een luxe MUX wordt alle data omgezet en kan de IIGLL of GPGLL naar keuze op een lagere prio gezet of gefilterd worden.

De checksum wordt hier gegenereerd door de MUX.

Maar, Thomas, ben jij nou zo slim of ben ik nou zo dom:-)? Je constateert zelf dat de sentence die waarschijnlijk benodigd is al wel op het netwerk aanwezig is. Dan moet de nieuwe WiFi router die toch 'gewoon' ook de lucht in gooien, zou je verwachten? Net zoals de oude dat doet?
Ik kan het overigens ook niet op de Emtrak aanzetten; die heeft heel beperkt settings die aangepast kunnen worden. Maar goed, dat zou ook niet nodig moeten zijn als de sentence al aanwezig is. Het enige wat moet is de nieuwe WiFi converter; die moet dat ding gewoon de lucht in gooien. Of dus niet en dan werkt het niet. Stel dat je dit wel (nogmaals) ook op de Emtrak aan zou kunnen zetten, dan maakt dat toch geen verschil als de WiFi router het niet naar WiFi converteert?

N.b. ik pak dus niet het wifi signaal rechtstreeks van de Emtrak AIS af he, de 923 heeft namelijk helemaal geen Wifi)

$GPGLL,5220.4282,N,00507.9082,E,,A,A*4F

$IIGLL,5220.429,N,00507.911,E,143216.05,A*14


Verschil is de fix tijd en in de bovenste regel, staat en A die er niet hoort, te veel.


En dan nog is het de vraag gebruikt Navionics xxGLL of xxRMC

De xx sufix staat er verder voor de sier, moet niets uitmaken wat er staat.

mystudio schreef :
Ik dacht dat je of de AIS-GPS of de gewone GPS gebruikte. Met beide tegelijk aan is het idd vreemd.

henkvd legt vermoedelijk de vinger op de zere plek: de GPGLL mist de UTC.
Foutje van Emtrak of van de conversie.

En wellicht stopt de navigatie met GLLs te verwerken als er steeds zoiets binnenkomt, er zijn er nogal wat.

De layout van een GLL sinds NMEA 2.3 van 1998:

$--GLL,ddmm.mm,a,dddmm.mm,a,hhmmss.ss,a,m*hh<CR><LF>

Die m aan het eind is nieuw sinds 1998, de FAA Mode indicator. Die kan ook een A zijn.
Dus 2 maal een A zou kunnen, maar missende UTC is fout.

Check! Dan zijn we eruit. Met dit in het achterhoofd weer allerlei logs gedraaid, heel veel dingen uit het netwerk gehaald en 1 voor 1 dingen weer aangezet. Maar dit is het dus. Welke GPS ik in het netwerk ook gebruik (de Raymarine E7, De N2K GPS, de AIS GPS), het maakt allemaal geen flikker uit, ze doen het allemaal netjes met zowel de RMC sentence als de GLL sentence voorzien van timestamp, via de OUDE wifi converter. Echter, zodra ik de nieuwe WiFi converter gebruik, wordt elke keer de RMC niet verzonden en ook de timestamp van de GLL ontbreekt. Kortom; ik kan nog maar 1 conclusie trekken; de uberhippe nieuwe wifi converter heeft een zeer eigen willetje en heeft geen interface om ook maar iets te configureren. Dat maakt de prijs van 169 euro wel fors
(Bijlage als voorbeeld de gps van de AIS; die heeft wel RMC en timestamps. Echter via de nieuwe wifi converter heeft ie ze niet meer. Emtrak doet het dus netjes)



Benieuwd of QE hier een reactie op kan en wil geven. Lang leve de standaardisatie.

Okay, ze gaan ernaar kijken. Benieuwd. De RMC string wordt wel ondersteund door Quark. Maar ik zie dat daar een ruime definitie aan gegeven wordt. "RMC* Recommended Minimum Specific GNSS Data 126992, 127258, 129025, 12902"

Voor wat betreft de ontbrekende timestamp van de GLL string is het eigenlijk interessant om te zien dat alleen Navionics daarover valt. iRegatta en OpenCPN op de laptop hebben geen moeite met de positie te pakken zonder deze timestamp. Wat is dan eigenlijk de brakke software? Navionics die eea precies zo verwacht zoals het beschreven staat en anders niet reageert of de andere pakketten die vergevingsgezind zijn?

Zelf denk ik liever niet na over fouten de verder geen moeite kosten om op te lossen en die verder geen consequenties hebben.

Timestamp boeit weinig bij een zeilboot. Check value (CRC) weer wel. Een programmeur moet dat verschil weten.
Misschien dat je blij wordt van "correct software to a fault".

Ik denk dat het probleem hoofdzakelijk in de gebruikte NMEA 2000 naar NMEA 0183 en WiFi converters zit.
Er zijn op jouw netwerk meerdere GPS bronnen aanwezig: de plotter, een GPS en een AIS.

Die EmTraks geven op NMEA 0183 een volledige RMC zin, maar op NMEA 2000 sturen ze geen PGN 129029 (GPS position info met alle toeters en bellen) uit, alleen een PGN 129025 (GPS Fix, Rapid Update). Die laatste bevat geen Time and Date of Fix informatie

De GPS(sen) op jouw netwerk sturen wel de volledige GPS fix.

Voor zover ik weet, bieden die goedkope NMEA 2000/NMEA 0183 > WiFi converters geen mogelijkheid van een Data Source selectie, dus welke van de GPS bronnen op NMEA 2000 daadwerkelijk wordt gebruikt voor de conversie naar NMEA 0183, weet je niet. En blijkbaar pakken ze de data van de Emtrek en niet die van de plotter of GPS.

In een weliswaar fors duurdere en NMEA 2000 gecertificeerde MiniPlex kun je dat wel. Ook het probleem van de missende Time and Date of Fix van de EMtraks wordt daar opgelost.