Onderwerp: nmea wifi repeater

nee hoor Anjo, gaat alleen om schrijven naar seatalk.

Baasklusje schreef :
Och Thomas.......Bouw eens een Kathedraal (D. Quakernaat)

dat ging ook met stapelen en weer neerstorten. Toch zitten daar gebouwen tussen die nog wel een paar eeuwen mee gaan........

roozeboos schreef : Tip van de "Meester" :
Neem een tweede mux en programmeer die met code die constant een byte uitzendt op de SeaTalk bus (of een compleet datagram) met net iets minder tijd dan de verplichte 1-byte wachttijd. Op de eerste mux, de "DUT", kun je nu gemakkelijk zien waar het fout gaat want je mag nu dus nooit gaan zenden.

Om een collision tijdens het zenden te testen, programmeer je op de eerste mux code die, zodra die het begin van een datagram zit van de tweede mux, meteen een byte op de lijn stuurt. Dan kun je mooi testen of je code op de DUT dit meteen detecteert en stopt met zenden.

Toen ik probeerde om met jouw mux de lichten uit te laten gaan, kreeg ik de indruk dat het pobleem alleen bij bepaalde datagrammen optrad, wat de suggestie wekt dat je niet een generieke SeaTalk driver hebt die het collision management afhandelt.

Ik zou dus, maar ik hoop dat je dat ook zo gedaan hebt, een goede SeaTalk driver schrijven waar je je helemaal focussed op het goed ontvangen en zenden van SeaTalk datagrammen op, zeg maar, laag 1 en 2/3 van het OSI model. Als dat eenmaal goed is, kun je op je applicatielaag nooit meer de mist in gaan als je nieuwe datagrammen toevoegt.

Wat ook helpt is dat je werkt met tijdslots van bijvoorbeeld 50ms (het langste datagram neemt 34ms). Ieder datagram heeft z'n eigen tijdslot en dit voorkomt dat je zelf ineens teveel data op de bus gooit en zorgt ervoor dat je je netjes gedraagt voor andere instrumenten op de bus. Ik zag dat jouw mux een binnenkomende NMEA zin meteen omzet in de benodigde datagram(men) en die meteen op de SeaTalk bus zet. Dit is niet wenselijk omdat je bij een GPS met een RMC zin per seconde ook de positie, COG, SOG, tijd, datum en variatie met 1Hz op de bus zet. Bij een hogere NMEA frequentie zal je dan de SeaTalk bus volledig overbelasten.

Je moet dus de frequentie van een NMEA zin loskoppelen van de datagram-frequentie. Een SeaTalk GPS of NMEA bridge zet bijvoorbeeld een keer per 2 seconden de positie op de bus. De heading komt 2 keer per seconde. En zo heeft ieder datagram zijn eigen frequentie die ook nog eens licht random is en soms afhankelijk van de waarde (diepte is 0,5Hz boven een bepaalde diepte, daaronder 1Hz).

dank u meester

Gaat nu vast goedkomen.

Het begint met een goed ontwerp inderdaad!

om een open deur in te trappen..

nou voor jullie alle werk aan de kant gegooid en de aanpassing zoals door de Grote Meester is aangegeven ingebouwd.
Het staat nu te testen.
Wil het niet nogniet online zetten, want dat mag niet van de chef testers hier.

roozeboos schreef :
Dat alles binnen dezelfde dag!?

Bestond de structuur zoals mhsprang aanraadt dan al? Of stelt het allemaal écht veel minder voor dan het voor mij lijkt? Die verschillende abstractie-lagen van hardware naar applicatieniveau lijken mij behoorlijk fundamenteel (wat je volgens mij niet in een namiddag in elkaar zet/wijzigt). Overschat ik dat?

het is zelfs simpeler als dan dat ik het had.
Het voordeel van de nmea naar seatalk in de mux is dat bekend is welke commando's verstuurd moeten worden.
ze hebben ook elk een eigen bekende lengte. (nu totaal 15 verschillende berichten)
Door nu ieder bericht een eigen plek en lengte te geven in de buffer is het heel simpel te beheersen.
ik voeg een extra byte toe aan het begin van ieder bericht. 0= leeg ander zit er een geldig bericht achter.
Alle 15 lengte bytes worden om de beurt afgescand. met een interval van 50 millisec.
komt er in die tussentijd een update vanuit de nmea, dan wordt de oude overschreven. Je mist dan wel de tussenliggende, maar krijgt dan wel de nieuwste waarde. En daar gaat t maar om.

Grote voordeel dan deze wijze is dat de seatalk buffer niet een overflow kan krijgen. In het oude systeem werd alle binnenkomende nmea data die vertaald moest worden meteen toegevoegd in de seatalk verzend buffer. natuurlijk had ik een plafond ingebouwd. Daardoor kreeg je toen ook niet teveel berichten, maar hij kon wel volraken met zelfs dezelfde bericht types!
Nu krijgt ieder verschillend bericht de kans om verstuurd te kunnen worden.
En hetzelfde bericht wordt sowieso niet binnen (15 x 50 millisec=) 0,75 sec opnieuw gestuurd. Mooi om te voorkomen dat seatalk te druk wordt. Het blijft een compromis dit.

Dus, nee, je overschat t niet, maar ik kon het vrij eenvoudig aanpassen.

De genoemde detectie om te zien en te stoppen als een ander tegelijk staat te zenden was trouwens al ingebouwd hoor.


nu afwachten of het licht niet uit gaat...

nieuwe software staat online.
vannacht zijn de lampjes aangebleven in de raymarine displays.

www.star-tracking.com/documenten.html

roozeboos schreef :
Errug blij mee!
Dank aan Rooz en Meindert

Als de spulletjes allemaal weer aan boord zijn zal ik mijn drukke seatalk verkeer er eens overheen gooien. Zal ik gelijk ook kijken of er meer rust zit in de performancemeter. Die was al flink vooruit gegaan, maar wellicht nu nog beter.

Chris: als ik navtexberichten (nmea) over wil brengen (ook in nmea), lukt dat dan met de mux?

koko schreef :
Geinig.
In welk programma kan je dat dan weergeven of heb je daar iets anders voor?

Als het een nmea bericht is (begint met $ of ! ) dan wordt het gewoon doorgegeven door de mux.
ben wel benieuwd welk bericht dat dan is. En de maximale lengte!

koko schreef : De meeste navtex ontvangers leveren de berichten gewoon als "platte tekst". Dat is dus geen NMEA zin en zal nooit door een multiplexer worden doorgegeven. Ook heb ik nog nooit navigatiesoftware gezien die Navtex berichten weergeeft. Er is, sinds V4.00 van de NMEA 0183 standaard, wel een NMEA zin ($--NRX) voor gedefinieerd. Misschien een optie voor Chris en mijzelf om een conversie optie in te bouwen, die platte Navtex tekst omzet. Maar als dit niet door de softwaremakers wordt opgepakt, heeft dan niet zoveel zin.

ja precies, dat beweer ik ook steeds.
Het is niet helemaal precies duidelijk wat koko bedoelt. platte tekst wordt in ieder geval niet doorgegeven, uiteraard.
En ook de lengte van het bericht kan een probleem zijn.

Evengoed kan ik wel het naxtex protocol inbouwen en dat gewoon doorgeven. Dat de mux daar even mee bezig is omdat het een lang bericht is lijkt me niet zo'n probleem. Reageren op ZCZC als start bericht en timeout op eind..

nb: Ik krijg deze vraag wel vaker.

Bijvoorbeeld de FAX30 van Furuno geeft, naast weerkaarten e.d., ook NAVTEX berichten door middels HTML. Maar da's geen NMEA.

Hoewel ik geen enkel programma ken wat er mee over weg kan, heb ik wel eens bekeken wat er uit een Navtex komt met een nrx sentence, wat opvalt is dat ivm met de lengte van het navtex bericht bij het omzetten naar een nrx sentece deze wordt verdeeld over meerder sentences om 1 bericht te kunnen overbrengen, begrijpelijk binnen de nmea norm is het proppen van alle text in 1 sentece niet voorzien, de sentences zouden veel te lang worden.

ja dat kan ook niet anders. blokken van 100 bytes ofzo.

Maar niets stopt mij om het door te geven als blok, buiten nmea om.
Maar dan moet je nog wel een programma hebben die het inleest. (als je via wifi of usb naar een pc/laptop gaat, waar ik even van uit ga.)
Koko zal vast binnenkort meer licht inde zaak brengen over wat hij nu precies wil.

nog steeds alle lampjes aan hier , de test is nog steeds positief!

Wellicht heb ik hier vooral de klok horen luiden

Ik heb sinds kort een Furuno NX300 navtex ontvanger en al een poosje een Raymarine C80 plotter die navtexberichten kan weergeven. Daar had ik het tijdens de meeting kort over met iemand en begreep toen dat de NX en plotter via een mux gekoppeld worden. Mijn eigen conclusie was dat het nmea moest zijn

Ik zal de documentatie er eens echt serieus op naslaan, want uit mijn hoofd moeten de navtex betichten binnen komen via de nmea ingang op de plotter. Waarschijnlijk zit ik mis........Ik kom er op terug.

Volgens mij ben ik er uit

De manuals gebruiken verschillende termen lijkt het, al bedoelen ze het hetzelfde.
De NX300 manual heeft het over een verbinding met de computer via rs232c, 4800 baud.
De plotter, Raymarine C80, heeft het over nmea, maar kent 4 keuzes. Nmea 4800, Navtex 4800, Navtex 9600 en Nmea 38400 AIS.
De verbinding aan de plotterzijde gaat via de nmea ingang, die twee draadjes kent voor nmea in en twee uit. Wat ik niet teruglees is iets over rs232c, maar ik vermoed, hoop, dat het Navtex 4800 in de Raymarine manual eigenlijk staat voor Navtex berichten in rs232c, 4800 baud.

Dan blijft er een vraag voor de mux kenners over: is het mogelijk om de Navtex aan de rs232 poort van de mux te hangen en te multiplexen via de nmea out naar de plotter, waar ook de AIS berichten uit komen?
Dan hoef ik geen stekkers om te pluggen, maar alleen de nmea instelling in de plotter om te zetten.
Overigens ben ik volop aan het verbouwen aan de navigatiehoek dat een extra stekker geen groot bezwaar is. Ben vooral nieuwsgierig of het kan, qua protocollen en multiplexen.

Edit: ik zal morgen een proef opstelling maken om te kijken of de plotter inderdaad de berichten weergeeft van de NX300. 'LL keep you guys posted.....

koko schreef : Nee dat kan niet. Wanneer je de NMEA poort op de C80 instelt op Navtex, dan verwerkt deze poort dus ook alleen nog maar Navtex en geen NMEA zinnen meer. Gemultiplexed aanbieden heeft dus geen zin.

Helder. Dank voor je snelle reactie. Ik maak morgen een proefopstelling met de navtex rechtstreeks aan de plotter. Als dat werkt maak ik een extra stekker.

Maar zou multiplexen wel kunnen? Dan zou enkel het juist setten van de plotterinstellingen nog moeten gebeuren. Maar het is geen must