Onderwerp: TZ iBoat een alternatief?

De bitmapkaart laat bij ver inzoomen ook niets zien (zoals bij mij wel het geval is)?

Op de rasterkaart zijn de boeien inderdaad bij inzoom wel te zien, maar mijn voorkeur gaat toch uit naar vectorkaarten. Zo vind ik ook de digitale rasterkaart van NV Charts alles behalve fijn. Het kan goed zijn dat TZ nu de randmeren niet meer opnemen, zoals ze eerder ook de Friese wateren geskipt hebben. Raar is echter dat dit zomaar gebeurt met een product dat je al gekocht hebt, zonder enige communicatie vooraf. Maar laat ik alvorens conclusies te trekken antwoord op de aan hen gestelde vraag afwachten.

En hieronder het snelle antwoord:

Thank you for reaching out.
I'm Simon, glad to assist you.

I confirm the lack of data on the TZ Maps Vector chart.

The chart team will work on a solution, and I hope it will be deployed in a couple of weeks.

In the meantime, you can use the TZ Maps Raster chart on this area, were the data is available.


​I'm coming back to you as soon as possible.

Hoewel bij mij Navionics en iBoat prima werken op mijn iPad, wilde ik ook eens TZ iBoat proberen na alle positieve geluiden hier op het forum. Dus gisteren gedownload, North West Europa gekocht, en de AIS plugin aangeschaft.
Dat viel allemaal niet mee. Het downloaden van de kaart lukte slechts voor 80% en daarna liep hij vast. Verder downloaden lukte niet meer.
Vandaag maar eens op de boot geprobeerd met het wel gedownloade deel van de kaart en mijn Yakker wifi brug. Lastig om verbinding te krijgen, pas na een paar keer herstarten (van zowel de app als de Yakker) kreeg ik verbinding en kon ik de AIS targets zien op de kaart. Helaas duurde de pret niet lang: na een paar minuten verbrak de app de verbinding en verdwenen de targets weer. Na wisseling van het TCP protocol met UDP het zelfde resultaat: na een paar minuten 'host time out' /'failed connection' en weg zijn de targets.
Met enige nadruk: bij Navionics en iBoat blijft mijn AIS verbinding gewoon werken. Niks geen 'host time out'. Die 'failed connection' zit echt in de TZ app.
Het ziet er naar uit dat deze app (nog) niet stabiel is. Jammer, want een paar features vond ik best wel aantrekkelijk (die schuif onderin waarmee je gemakkelijk kunt zien wanneer de stroom draait bijvoorbeeld). Al neemt de app bij mij ook een smak geheugen in beslag, bijna 10 Gb.
Iemand een idee wat er mis is? Ik heb het ook bij de support neergelegd - maar als dit zo blijft zeg ik het abonnement weer op.

Je hebt het over 'iBoat' en 'TZ iBoat' als twee verschillende apps? Bedoel je 'iSailor' en 'TZ iBoat'?

Bij ons is de TZ iBoat wifi NMEA-verbinding (bij ons met een ShipModul Miniplex 3) zeer stabiel. Nooit een probleem geweest ook.

Heb je andere apparaten die tegelijkertijd bij je Yakker zijn ingelogd?
Je zou die dan eens kunnen proberen uit te zetten.

Herken dit probleem ook niet (Vesper XB-8000 via TCP/IP)

Ik bedoelde inderdaad iSailor - en die werkt bij mij prima. Het lijkt er inderdaad op dat iets na een tijdje de dataverbinding stoort. Uiteraard heb ik het ook geprobeerd met de Navionics en iSailor helemaal afgesloten (al zou dat bij UDP niets mogen uitmaken), maar hij blijft alsnog na een paar minuten de AIS verbinding eraf gooien. Vreemd is ook dat Navionics en iSailor elkaar in ieder geval niet in de weg zitten. Heb trouwens een zeer snel antwoord van TZ gekregen (dat is dan weer positief!). TZ zegt ook dat ik de andere apps moet afsluiten en levert verder een standaard verhaaltje over hoe je de connectie moet invullen. Maar dat is bij mij niet het probleem. Er komt gewoon een NMEA verbinding tot stand - maar die vliegt er na een paar minuten uit. Enfin, morgen nog maar eens proberen. Als ik het er niet uit krijg stop ik uiteraard met deze app.

Hier ook nooit problemen met TZ iBoat icm onze Vesper AIS transponder via Wifi.

Zit net nog te denken: het enige apparaat dat ook bij de Yakker was ingelogd was natuurlijk mijn iPhone. Die gaat automatisch naar dit voor hem bekende netwerk. Zal het morgen is proberen met de wifi van de iPhone uit. Hoewel dat niet verklaart waarom TZ het met UDP ook niet doet.

Het aantal gelijktijdige UDP verbindingen is ook beperkt. Heb je de Yakker ook uit gehad zodat alle 'verbindingsslots' worden vrijgegeven en dus beschikbaar zijn?

Het is wel vreemd dat je eerst wel een tijdje een werkende verbinding hebt, en iSailor en Navionics de verbinding (ik neem aan op dezelfde iPad) wèl in stand houden.

Hans V schreef :
Inderdaad dezelfde iPad. Kreeg ter plekke heimwee naar iSailor - maar dat lijkt voorlopig verleden tijd. Ik heb ook een paar keer de Yakker uit- en aangezet. Dan werkte alles weer, maar wel tijdelijk.

Probeer het inderdaad een keer met de wifi van je iPhone uit (of je iPhone uitgelogd met ‘vergeet dit netwerk’) en ook de andere apps zoals Navionics en iSailor afgesloten. Het lijkt alsof die de verbinding ‘kapen’, hoewel het gelijktijdig zou moeten werken zolang je het maximale aantal verbindingen van de Yakker niet overschreidt.
Apps gaan verschillend om met het vrijgeven van hun TCP/UDP verbinding als ze in de achtergrond draaien, vandaar het advies om al het andere even uit te zetten.

Is de firmware van de Yakker (wifi module) up to date? Misschien ook Yakker support vragen of zij dit probleem herkennen?

Als mijn vraag niet té veel off-topic is…

Kan iemand uitleggen hoe vanuit een app nu een TCP/IP connectie naar een NMEA server op een bepaald IP adres:poort in dat netwerk opgezet wordt?

Wat ik volgens mij bij mijn Vesper (als Wifi Access Point) meende te zien wanneer daar al het maximaal aantal clients aan hing, is dat de wifi connectie met die extra client al niet slaagde.

Ik weet niet of dit klopt en ik mss verwarring schep nu, maar gaat dát wel goed?

Ofwel: wordt bij het falen (na een tijdje) van de verbinding naar de Yakker NMEA server het device uit het netwerk gegooid, of blijft díe verbinding werken zit de issue (dus) op app/software niveau (in een hogere applicatielaag)?

Voorbeeldje thuis: blijft dit deel wel gezond bij het verbreken van de verbinding?


Waar ik nog aan dacht: Laat de Yakker ook schrijven naar de NMEA server toe? Als dat niet zo is, mss de “enable pilot output” uitzetten?



Wat zie je in het onderste deel? Is er nog wel een netwerkverbinding maar wordt de connectie gewijgerd, of is de netwerkverbinding na het falen óók weg?

PS: in dit voorbeeld bestaat er (is thuis…) geen NMEA server, vandaar de foutmeldingen

Nachtvlinder schreef :
Goede vragen. De connectie problemen die wij in het verleden hebben gehad met onze Miniplex 3 waren op wat jij denk ik 'app/software niveau' noemt. De wifi verbinding met de iPad bleef intact, maar alle TCP / UDP 'slots' op de wifi server (multiplexer) bleken bezet. Niet elke app geeft de TCP / UDP connectie netjes vrij als dat wel zou moeten. Of de wifi server module in de multiplexer heeft niet door dat één van de slots niet langer gebruikt wordt. Ik weet niet waar het precies mis ging.

Vandaar mijn advies om met een schone lei te beginnen (iPad als enige apparaat en TZ iBoat als enige app aanmelden) en de multiplexer (Yakker) even uit te zetten om alle 'TCP / UDP slots' gegarandeerd vrij te maken. In de Miniplex 3 is de wifi server software een tijdje geleden ook geüpdatet, even checken of de Yakker firmware op de laatste versie staat kan denk ik daarom ook geen kwaad.

Ha! Over mijn connectieproblemen met TZ: als ik mijn telefoon uitzet (de wifi, dus niet automatisch inlog bij Yakker)) en verder alleen TZ iBoats op de iPad activeer, werkt de zaak normaal. En blijft ook werken.
Als ik echter daarna TZ afsluit en bijvoorbeeld iSailor opstart, dan werkt nu iSailor niet meer ('adress in use'). Vind ik wat merkwaardig, want ik kon altijd wel wisselen tussen iSailor en Navionics. Blijkbaar is de relatie tussen TZ en Yakker een stuk inniger dan met de andere navigatie apps. Verder kan ik er goed mee leven, nu ik weet hoe je het moet oplossen.
Dank voor alle adviezen!

Staan beide apps op het UDP protocol (i.t.t. TCP/IP)? Er kan vaak maar één TCP/IP verbinding met een multiplexer worden gemaakt en meerdere UDP verbindingen. Als een app de TCP/IP verbinding niet vrijgeeft heb je met TCP/IP per definitie een 'in use' melding. Via UDP lukt dan doorgaans nog wel.

Nachtvlinder schreef :
Voor een TCP-verbinding maakt de ontvangende partij een verbinding met IP:Port van de partij die data aanbiedt. Veelal zal een PC of telefoon of tablet als ontvanger dat initiatief nemen.
Er vindt dan actief een 'connect' plaats tussen de 2 apparaten, met elk hun eigen IP-adres en (dezelfde) poort.
Daar kan geen enkel ander apparaat (software) dan nog tussen komen. Het is 1 op 1.
Veel apparaten kunnen maar een beperkt aantal TCP-sessies hebben, soms maar 1 (Minplex3, Vesper).
Er is actieve controle of de data aankomen; de ontvanger zal nooit iets missen. Als hij een packet mist meldt hij dat en wordt dat opnieuw verzonden door de data-aanbieder.

UDP is meestal broadcast. Het zendende apparaat (een IP:Port combinatie) slingert zijn data de wereld in en elk apparaat dat naar die combinatie van IP en Port luistert krijgt de data binnen.
Er is geen beperking op het aantal luisteraars.
Data kunnen verloren gaan; als de ontvanger even niet oplet (iets anders doet) dan mist hij een bericht.
Igv Nmea niet erg, er komt er wel weer een.

Er is ook UDP Directed. Dan stuurt de zender zijn data naar een specifieke ontvanger (IP:port).
Misschien is dat de oorzaak van een aantal in dit topic genoemde problemen?

De data tussen zender en ontvanger (zowel TCP als UDP) moeten over een (ether)netwerk (meestal wifi).
Dat betekent dat er in de buurt een wifirouter moet zijn die dat netwerk in de lucht houdt.
Die router doet meestal ook de DHCP: het uitdelen van IP-adressen aan apparaten die verbinding willen maken.
Daar kan wel een beperking aan de hand zijn: sommige routers kunnen maar een beperkt aantal adressen uitgeven (Miniplex 4 adressen, geloof ik). Dan kunnen er niet meer apparaten meedoen in het netwerk.

Een TCP-verbinding kan na gebruik 'blijven hangen'. Als de gebruiker (ontvanger) de verbinding niet netjes helemaal afsluit (ophangt, in telefoontermen) dan blijft de (enig mogelijke) TCP-verbinding in de zender actief en kan er geen (andere) worden opgebouwd.
Iets dergelijks zou ook bij UDP Directed kunnen optreden.

Hoe weet ik dat allemaal? Ik had het nodig voor SPD
Dat kan NMEA ontvangen over COM/USB, UDP en, speciaal voor de Vesper van Nachtvlinder, ook over TCP

Hans V schreef : Ik heb gisteren alles naar UDP gezet, dus daar kan het niet aan liggen.

Tilikum schreef :
TZ 'beter' afsluiten zou moeten helpen.
Kennelijk sluit TZ de TCP-en UDP-verbindingen niet netjes af en blijft de Port binnen het OS in gebruik.
Helemaal killen dat TZ, niet laten sluimeren.

Verhoog de output van de yakker eens van low naar medium of Max.. bij mij leverde dat de afgelopen dagen een stabiele verbinding

Tilikum schreef :
Het downloaden van kaarten van iSailor is inmiddels hersteld. Er is tevens een nieuwe release van iSailor aangekondigd, maar nog zonder releasedatum. Wärtsilä is bezig met een partij om iSailor over te verkopen.

Baasklusje schreef :
Dat ook in de achtergrond blijven gebruiken van een TCP- of UDP-verbinding door een navigatie app heeft ook voordelen: als je even naar een andere app schakelt tijdens het varen en je navigatie app daarna weer naar de voorgrond haalt hoeft die niet opnieuw een data verbinding op te bouwen (al dan niet met succes) en loopt de weergave van je data (diepte, AIS targets, etc.) naadloos door.
Ook je track loopt netjes door en wordt niet onderbroken zodra de app tijdelijk naar de achtergrond verdwijnt.

Voor sommige programmeurs is dit denk ik de reden om de TCP of UDP verbinding niet vrij te geven en de navigatie app ook niet in slaapstand te plaatsen als die niet de focus heeft (in de achtergrond draait).

Sluiten apps ook na volledig afsluiten de verbinding niet correct af dan ben je op een gegeven moment door de te vergeven (gelijktijdige) connecties heen en helpt vaak alleen herstarten van de multiplexer en opnieuw inloggen met de gewenste apps.

De app in sluimerstand maakt het mogelijk dat je tcpa alarmen blijven werken bijvoorbeeld..

ISO788 Hans schreef :
Goede aanvulling, ook dat blijft werken als de app - ook in de achtergrond - de verbinding niet vrijgeeft.

Ik krijg net van TZ support te horen dat ze geen plannen hebben om hun trip log functionaliteit uit te breiden. Jammer.

Nu maar hopen dat iSailor inderdaad draaiende wordt gehouden zodat we die in ieder geval als 'advanced track recorder' kunnen blijven gebruiken. Zojuist de Tides and currents subscription in iSailor weer geactiveerd, ook die is nog steeds superieur aan die van TZ iBoat.