Onderwerp: iSailor verbinding met NMEA host herstellen.

Ik probeer sinds kort iSailor te gebruiken op iPad en iPhone. Ik heb aan boord een WiFi-router. iPad en iPhone maaken via WiFi verbinding met het netwerk, waarin bekabeld een ethernet multiplexer opgenomen is. iSailor en multiplexer praten via UDP port 10110 met elkaar.

Op zich werkt alles prima. Positie, instrumentgegevens en AIS komen binnen op iSailor. Alles blijft ook prima werken, zolang ik de iPad of iPhone maar aan laat staan met iSailor actief. Zodra ik echter even iets anders doe, e-mail checken, of even iets opzoeken op internet, verliest iSailor de verbinding met de multiplexer, terwijl de WiFi verbinding nog steeds prima bruikbaar is voor internet etc. Hij toont dan rode gegevens en zegt NMEA invalid. De verbinding herstelt niet vanzelf. Ik moet iSailor echt afsluiten en opnieuw starten, of binnen iSailor bij sensors de connection herstarten. Dan blijft alles het weer prima doen totdat ik de iPhone of iPad voor iets anders dan iSailor gebruik.

Is dit zoals het hoort te werken of doe ik iets verkeerd? Ik vind het nogal irritant dat ik steeds iSailor moet stoppen en starten als ik even snel op de kaart wil kijken. Iemand ervaring?

dank alvast!

Ik vind het een bug...
Sinds een jaar of 2 zit het er in..
herstarten van de connectie is idd de workaround. Is ook al gemeld bij isailor

Een klant van mij heeft het zelfde probleem, ik heb echter de indruk dat niet iedereen met een iPhone of iPad icm iSailor dit probleem heeft, ik zou anders meer klachten verwachten.
Heb je met de Roosmux dit probleem ook of is de oplossing tcp gebruiken?

Ik ken het probleem (nog) niet, ik heb pas recent een Wifi (van Rooseboos) aangelegd om NMEA data naar iSailor te sturen. Maar waarschijnlijk krijg ik er ook niet mee te maken omdat ik de iPad onderweg exclusief voor de navigatie gebruik en nergens anders voor. iSailor staat dan gewoon continu aan als enige actieve app.

Mocht het toch nodig zijn om onderweg op internet iets te zoeken dan heb ik daarvoor tijdens vakanties en langere tochten een tweede iPad aan boord en uiteraard de nodige telefoons.

Ik ben ook bekend met het probleem maar het stoort me niet echt.

Dit gebeurt bij mij ook.
Niet alleen wanneer ik een andere app gebruik maar ook wanneer het beeldscherm even uit is.

De wifi verbinding blijft inderdaad wel intact.
Mijn eigen voorlopige conclusie is dat de app 'denkt' dat hij in stand-by wordt gezet dus de verbindingen afkapt.
Maar ik ben geen software developer.

Al met al zie ik het niet als een groots probleem.
Sunday merkte al terecht op dat je toch niet 24 uur per dag naar een iPad aan het staren bent en dat je ook moet genieten van wat er om je heen gebeurt.

Wij hebben dit probleem niet, maar maken via wifi rechtstreeks contact met de multiplexer (dus niet via een router). We hebben op deze iPad dus geen internet tijdens het varen maar kunnen verder probleemloos switchen tussen iSailor en willekeurig welke andere app op de tablet. Ook scherm uitzetten en weer aan maakt geen enkel verschil, alles blijft gewoon werken.

Alleen het op de achtergrond bijhouden van de track wordt onderbroken als we NMEA positiegegevens gebruiken en de iPad in stand-by zetten (scherm uit). Bij gebruik van de interne GPS van de tablet (en uiteraard 'Background position tracking' aan) loopt de track netjes door.

Hans zou je me de instellingen kunnen geven die je hebt in iSailor voor de verbinding?
TCP of UDP en welk poortnummer?

Zeilprutser schreef :
We verbinden via TCP op poort 10110 naar een ShipModul MiniPlex 3 (MiniPlex-3Wi-N2K om precies te zijn) multiplexer.

Ik gebruik UDP port 10110 naar een Miniplex-3E-N2K en heb het probleem dus wel. Als ik van het weekeinde tijd heb zal ik eens experimenteren met TCP.

Amazone schreef :
Als ik dit weekend de gelegenheid heb zal ik eens testen met UDP.

Ik heb hem op een Roosmux met UDP.
Zal zondag eens proberen hoe het gaat met TCP verbinding, dat heb ik nooit geprobeerd.

Van het weekeinde wat aan het experimenteren geweest en ik heb de indruk dat dit probleem alleen voorkomt bij gebruik van UDP. Ik heb hem nu op TCP en denk dat het opgelost is. Ik hou het nog even in de gaten.

Amazone schreef :
Ja, UDP lijkt inderdaad problemen te geven. Afgelopen weekend iSailor via UDP laten verbinden en we konden ook niet meer probleemloos (her)verbinden bij switchen van apps.

Onder TCP werkt het prima.
Ik ben wel benieuwd waar de bug uiteindelijk zit (iSailor, iOS of multiplexer).

Speelt dit ook bij Isailor onder Android ?

Grt Hans

Sorry dat ik me hierin meng, maar ik wil toch waarschuwen. Bij UDP is er geen sprake van een "verbinding". Pakketten worden verstuurd op hoop van zegen, zonder dat er bevestiging van ontvangst of hertransmissie plaatsvindt. Er is geen garantie dat alle data aankomt. Ook de volgorde van pakketten is lukraak. Via wifi kan data zomaar verminkt worden, door drukte op het kanaal, slechte radioverbinding of andere reden en dan loopt het mis zonder dat je weet hoeveel data is kwijtgeraakt. TCP geeft een betrouwbare point-to-point verbinding, een TCP-session met een begin en eind. Voor serieuze datacommunikatie waar alle data goed moet overkomen is UDP ongeschikt. Het is wel lekker snel zolang het goed gaat en de benodigde apparatuur en software is veel eenvoudiger. Daarom kunnen veel goedkope embedded wifi modules maar 1 TCP sessie aan.

En wat gebeurt er met de tcp verbinding als je last hebt van al de genoemde zaken?

Dan vindt hertransmissie plaats. Er is garantie dat alle data aankomt. Bij een slechte verbinding kan het dus iets langer duren maar dat is nauwelijks merkbaar bij de kleine hoeveelheden data die bij NMEA worden verstuurd. Als de verbinding zo slecht is dat de TCP sessie moet worden afgebroken wordt meestal automatisch een nieuwe sessie gestart. Gedurende dit alles blijft de wifi verbinding gewoon bestaan of het protocol nu UDP of TCP is.

Bij storing komt TCP ook niet aan , maar hij detecteert dat wel.
't Is alleen de vraag of dat ergens terug wordt gemeld....

Er vindt een timeout plaats en de ontvangende kant verstuurt een bevestiging tot welk pakketnummer ontvangst heeft plaatsgevonden, zodat de zendende kant weet bij wel packet de hertranmsmissie moet beginnen. Dit ligt allemaal binnen het protocol besloten. Pas wanneer de TCP sessie misloopt wordt dit aan de applicatie doorgegeven. Goede applicatie software reageert hierop.

@37s je gaat uit van de theorie en dan heb je helemaal gelijk, maar nu moet je gaan kijken wat er in een praktische situatie kan en zal gebeuren:

De meeste navigatie data wordt continu herhaald en is dus niet kritisch, als je 1 keer de gps positie mist krijg je hem na 1 seconde weer binnen, ook ais is geen probleem je zou een naam van een schip kunnen missen maar als hij 5 knopen vaart krijg je binnen enkele seconden al weer zijn positie en is hij gewoon zichtbaar, in die situatie is waarschijnlijk zijn naam al en half uur bekend en staat dat gewoon nog bij het schip.

Bij tcp krijg je in dit geval verouderde data binnen, en je belasting wordt nog groter, het meest waarschijnlijke is dat je storingsbron ook weer door jouw verbinding wordt gestoord en zo stapelt de data zich op.

Natuurlijk wil je wel zeker weten of je uitgezonden waypoint naar je stuurautomaat binnenkomt maar dat kan prima icm UDP je kan namelijk heel simpel een acknowledgement krijgen over udp.

Er speelt echter nog veel meer mat dat wordt wat te veel voor vandaag.

Wij wachten met tcp op onze Signalk implantatie daar zit die functie gewoon bij in.
icm Signalk heb altijd een tijd bij je bericht en kun je daar dus al op filteren.
Daarnaast kun je de dataload gigantisch omlaag brengen.
Waarom zijn wee daar mee bezig? nou tegenwoordig willen mensen ook internet via de zelfde verbinding, radar overlay en zelfs youtube filmpjes kunnen kijken icm een volle NMEA2000 bus heb je dan toch weel wat data te verstouwen.

Zeilprutser schreef :

Praktijk kan ik je verzekeren, al vele jaren. Je kunt toch ook hierboven lezen dat het inderdaad mis gaat. Verouderde data bij TCP? We praten over milliseconden. Wie stuurt volgens jou de acknowledgement over UDP? De autopilot? Sommige hogere (applicatie) protocollen kunnen funktioneren met onvolmaakte lagere transport protocols, maar niet NMEA, wat geen acknowledgements, time-out of hertransmissie kent.

precies wat ik zeg beide zijn dus niet te vertrouwen, behalve als je een antwoord zou krijgen, dat regelt de Signalk server en in ons geval de BoatController, je weet dan in ieder geval dat de zin via de fysieke poort er uit is gegaan, op dat moment vindt ik dat ik als leverancier wel aan mijn verantwoordelijkheid voldoe . Tot die tijd lever ik die optie niet aan een leek! En ga ik dus niet zeggen met een tcp verbinding garandeer ik een goede verbinding!

Waar het eigenlijk om gaat is dat ik vindt dat in deze discussie het duidelijk moet zijn, dat beide protocollen niet te vertrouwen zijn, vervolgens mag je de 2 verbindingen niet generaliseren, dat wij een heel betrouwbare UDP verbinding hebben wil niet zeggen dat elke udp verbinding dat is, maar dat geld net zo goed voor tcp verbindingen.

Op dit moment is er geen betrouwbare wifi verbinding mogelijk!
Hier komt signal-k om de hoek kijken die met dit soort zaken rekening houd en die dus wel antwoord kan geven of iets is overgekomen.