Onderwerp: nmea wifi repeater

in het instelprogramma zit een optie 'volgen' , daarin wordt ook een positie weergegeven, kun je controleren of die juist is?

vwb wifi, als ik het hier probeer gaat het goed, ook als ik mijn mobiel ( sailtracker) bot uitzet en weer aanzet. hij connect dan weer gewoon goed.
Wat als je eerst disconnect en dan de tablet uit zet, gaat het dan wel goed bij opnieuw inloggen?

roozeboos schreef :
Hoe kan ik disconnecten op een iPad/iPhone? Gewoon de WiFi uitzetten? En de WiFi mux moet dan gewoon aanblijven neem ik aan. Anders heeft deze test geen zin. Ik ga het zo even proberen.

Beste Chris,

Ik heb jouw en mijn WiFi configuratie eens vergeleken zou je het navolgende adviseren:

1) Jij hebt de AP linkmonitor op 3600 seconden staan. Dat zorgt ervoor dat na wegvallen van een WiFi verbinding 3600 seconden lang geen nieuwe verbinding tot stand kan worden gebracht. Zet 'm op 10 seconden met met "set a l 10". De omschrijving in de datasheet is wat vaag maar ik heb dit proefondervindelijk kunnen vaststellen.

2) Jouw IP Flags staat op 7. Bit 1 is hier gezet en zorgt ervoor dat bij wegvallen van de WiFi verbinding de TCP verbinding tot 60 seconden in stand wordt gehouden. Gedurende deze tijd kun je dus niet reconnecten wanneer de WiFi terug is. Zet Bit 1 op '0' en de TCP verbinding valt meteen weg bij een WiFi disconnect. Dan kan een client meteen weer opnieuw verbinden. (set i f 0x6)

3) Je hebt de comm match character op 13 gezet. Lijkt logisch omdat dan steeds een complete NMEA zin wordt verzonden. Maar dit leidt tot heel veel protocol overhead en de RN module wordt hierdoor veel trager in dataverwerking en kan in principe niet sneller dan op 38400 Bd data ontvangen zonder handshake. Wanneer je dit uit zet (set c m 0) loopt de data sneller door en ontstaan er minder "onduidelijke" hiccups in dataoverdracht. Dat er meerdere zinnen en zelfs fracties in een TCP of UDP frame komen, is bij geen enkele navigatiesoftware een probleem.

4) je hebt de data rate via WiFi op 1Mb gezet. Lijkt voldoende maar op 11Mb loopt het beter, zeker bij veel data. Nu heb jij de seriele poort op 38400 Bd staan dus zal het meevallen, maar ik draai op 230400 Bd en dan is dat absoluut nodig om vier ingangen op 38400 foutloos over te dragen.

5) Jij hebt de seriele poort van de module op 38400 staan. Dit wordt problematisch wanneer iemand AIS data op 38400 baud wil inlezen en ook nog een paar andere "ingangen" erbij voegt. Waarom niet een hogere snelheid? Ik draai op 230400 en dat zorgt ervoor dat in ieder geval alle ingangen op 38400 kunnen werken zonder problemen.

Ik ben er van overtuigd dat wanneer je in ieder geval 1 t/m 4 veranderd, je een veel beter en stabieler access point hebt.

Doe er je voordeel mee

oh nou dank je wel hoor, hoe heb je dat allemaal uitgevonden? Heb je een mux van mij gekocht?

vwb punt 4, met lagere datasnelheid heb je meer afstand.
en punt 1 waag ik te betwijfelen hoor, ik kan veel sneller reconnecten. Maar goed, kan geen kwaad inderdaad.

roozeboos schreef : Ik heb zo mijn bronnen en probeer graag uit wat anderen hebben gemaakt...
Klopt maar dat is op een "plastic" boot niet zo'n probleem.Mag, maar ik heb dat geprobeerd met NMEARemote op een iPhone. Ik ben weggelopen van de MiniPlex totdat de WiFi verbinding wegvalt. Daarnaa teruggelopen. Bij een tijd van 3600 seconden kwam de verbinding niet meer automatisch tot stand. Bij een tijd van 10 seconden wel.

De door jou voorgesteld veranderingen zijn doorgevoerd. ( behalve de 1Mb datasnelheid, vanwege wifi bereik)
dus als het nu niet werkt is het jou schuld meindert!

Misschien kan zeilbootje als hij in de gelegenheid is eens kijken of het nu beter gaat!

update te vinden op :
Star-tracking site

ik ga morgen updaten...
zijn dit soort instellingen ook de sturen voor de USB poort?
kijken of mijn overload daarmee ook minder wordt..

Gr Hans

nee usb kan ik niet aanpassen, voor zover ik weet. en anders hoor ik het wel.
Het lijkt erop dat de mux wat snelheid heeft ingeleverd met de data verwerking, waarschijnlijk door alle toevoegingen.
dat moet ik onderzoeken en verbeteren, kom ik zsm op terug.

Vandaag de volgende test uitgevoerd met de oudere versie, dus niet de versie die Chris vandaag beschikbaar heeft gesteld.

- wifi mux power cycle,
- connect iPad successvol.
- connect iPhone successvol,
- data komt op beide devices goed binnen via UDP,
- iPad wifi uitgezet en weer aan, wifi verbinding successvol,
- iPhone wifi een aantal malen aan en uit gezet en slechts 1 keer de melding gehad dat die een wifi verbinding niet mogelijk was
- met de ipad een aantal maal switchen tussen wifi mux and iphone hot spot. ook dat gaat goed.
- in de haven nog een paar keer tusen haven wifi en mux wifi geswitched en dan ging ook goed.
ik snap dus niet waarom ik het nu niet kan reproduceren. misschien heeft het met de tussen tijd te maken. maw dat ik savonds de ipad afsluit (klaar met varen) en dan een dag later weer probeer te connecten. dat het dan misschien niet goed gaat. Echter dan kon ik vandaag niet testen.

bedankt voor de nieuwe versie. die ga ik zeker weten proberen en testen. ik ben komende 2weeken niet op de boot dus de test resultaten moeten nog even op zich laten wachten. zodra ik meer weet laat ik me weer horen.

zo zie je maar, we lossen zelfs problemen op die er niet zijn!

roozeboos schreef :
Ik zou willen zeggen die er niet MEER zijn. Want ze waren er echt wel. Ik zal van elke keer dat het voorkomt een scherm afdrukje maken.

roozeboos schreef : Ik zal dit ook even proberen wanneer het probleem zich weer voordoet. Als het nog voorkomt, want heb net de nieuwe firmware van vandaag erop gezet.

zeilbootje schreef :
jaja,het was maar een grapje van mijn kant. ik neem iedere klacht serieus hoor.

roozeboos schreef :
Weet ik en ik ben ook zeer tevreden met de support! En eeehhh het was geen klacht maar een verbeterings verzoek. Haha

Die connectie problemen waren er met name een paar maanden geleden ( begin april). Sindsdien zijn voor mij de connectieproblemen sporadisch. Wanneer dat ernu ook uit zou zijn alleen maar beter ..

Ik heb vanavond de firmware ge-update ... Wat mij opvalt is een enorme performance verbetering van ais overlay op de iPhone en iPad met isailor.. Direct veel meer targets in beeld en ook completer met target informatie . Te vergelijken met wat ik eerder zag met open CPN op de laptop.
Reconnect ook prima maar daar had ik al weinig problemen mee.
Verder helaas geen oplossing voor mij vollopende seatalk bus wanneer ais data spuugt naar USB.. Maar dat was ook niet verwacht natuurlijk.

Vandaag de firmware geupdate. Ik kan nu weer connecten met iPhone en iPad. Alleen ik raak die connectie steeds weer kwijt. Ik had iSailor aangezet om de track op te laten slaan en na een paar minuten geen data meer. Wat kan dit zijn?

ja dat weet ik zo even niet, Erik. hoe is je veldsterkte?

Vandaag alle appjes maar eens uitgezet en daarna de iPad herstart. Daarna bleef de connectie wel aan, dus dat is weer opgelost!

kijk,dat is goed nieuws!

ErikSnel schreef : een ITer zeker? Even herstarten... Dat kan toch niet de echte oplossing zijn?

Baasklusje schreef :
theoatmeal.com/blog/fix_computer

Baasklusje schreef :
Zou je niet zeggen. Mijn ervaring met iOS is dat het behoorlijk stabiel is; Maar als er 1 ding is wat nog wel eens tegen kan werken is als je erg veel apps open hebt. Dus alle apps sluiten is zowiezo een goed idee. En herstarten is dan het mooiste om zeker een ' schone' start te maken...

Ik worstel op het moment met mijn Garmin GPS 126 icm de wifi mux.
Communicatie met de GPS staat op nmea 1.5 4800baud. Dit is nodig voor mijn Nasa GPS repeater. GPS data stroomt keurig binnen, komt bij de marifoon en ook de repeater laat zien wat hij moet tonen.

Echter, ik heb ook de rs232 van de gps aan de rs232 van de mix geknoopt (rx aan tx, tx aan rx en- naar de algemene -
Als ik nu waypoints/routes via Opencpn naar de gps wil sturen, krijgt hij niets binnen. Als ik de communicatie op Garmin omzet (in opencpn en gps) lukt dit ook niet. Nmea data valt dan ook stil.
Opencpn hangt dan per USB aan de mux. Ook per wifi hetzelfde beeld.

Hoe pak ik dit nou aan?

Het sturen van waypoints naar een GPS via een multiplexer is altijd ietwat problematisch.
Wanneer je een PC direct aan een GPS koppelt, bepaalt de datasnelheid hoe snel de waypoints worden overgedragen en een moderne GPS kan dit gemakkelijk "bijbenen". Bij oudere GPS'sen zoals de veelgebruikte Furuno GP32 is het zelfs zo dat na ontvangst van een waypoint, de GPS een speciaal karakter naar de PC stuurt, een "XOFF" om te vertellen dat de PC even z'n mond moet houden totdat de GPS het waypoint heeft opgeslagen. Daarna stuurt de GPS een "XON" karakter ten teken dat de PC het volgende waypoint mag sturen. Dit is iets wat niet via een NMEA multiplexer kan, tenzij deze het XON/XOFF mechanisme ondersteund. Een moderne GPS is echter wel snel genoeg om de waypoints te ontvangen en op te slaan "as they come".

Met een multiplexer ertussen wordt het nog ingewikkelder. Over het algemeen is de poort die met de PC praat, op een veel hogere snelheid ingesteld dan de poort die met de GPS praat. Data moet dus tijdelijk worden gebufferd in de multiplexer. Zie het als een emmer die je met dmv een brandslang met waypoints vult terwijl ze er aan de onderkant door een klein gaatje uitstromen richting GPS. Wanneer er veel waypoints worden verstuurd, loopt de buffer/emmer over en gaat er data verloren.

Sommige multiplexers hebben hier een mechanisme voor, de zgn. handshake (RTS/CTS). Een extra signaal vanuit de multiplexer (RTS) naar de PC (CTS) geeft aan wanneer de buffer bijna vol is en de PC z'n mond moet houden terwijl de buffer op een laag tempo geleegd wordt richting GPS. Je moet hiervoor in je navigatiesoftware wel kunnen instellen dat er gebruik moet worden gemaakt van een handshake. Andere programmas bouwen een vertraging in waardoor de waypoints met tussenpozen worden verzonden, alsof ze met 4800 baud worden verstuurd.

Kijk eens of het versturen van een of twee waypoints wel goed gaat. Als dat zo is, is het bovenstaande aan de hand.