Onderwerp: nmea wifi repeater

HEEE ZIJN ER NOG MEER VAN DIE LEUKE VOORBEELDEN???

HPV schreef : Zekers.
Veel mensen vragen zich af wat het verschil is tussen een zogenaamde singe-ended NMEA verbinding (een data draad en massa) en een differential NMEA verbinding (twee data draden). Bij de eerste heb je meesta een TX (uit), een RX (in) en Gnd (massa). Bij de tweede heb je TX+ en TX- of TX-A en TX-B (uit) en RX+ en RX- of RX-A en RX-B. Het nut en de werking ervan kun je uitleggen met emmers water

Stel, je wilt een boodschap overbrengen in zijn meest simpele vorm: een Ja (1) of Nee (0). Bij een single-ended verbinding breng je de boodschap over van zender naar ontvanger d.m.v. een emmer met of zonder water (TX signaal). Emmer vol is Ja, emmer leeg is Nee. Onderweg regent het soms (ruis en storing) of je moet over moeilijk begaanbare paden (weerstand).

Als je bent aangekomen, kijkt de ontvanger of er water in de emmer zit of niet, voor een Ja of een Nee. Het zal duidelijk zijn dat er onderweg vanalles gebeurt kan zijn: er kan water uit de emmer geklotst zijn of door een regenbui kan er water bijgekomen zijn. Het is dus niet eenduidig of er nu een Ja of Nee werd overgebracht en je kunt alleen maar de emmer wegen (meten t.o.v. Massa) en een grens stellen welk gewicht je als Ja of Nee beschouwt.

Dit systeem is dus gevoelig voor storingen.

Nu gaan we een differential verbinding nabootseen. We nemen 2 emmers, TX-A en TX-B. We spreken af dat een Ja wordt overgedragen door water in de rechter emmer te doen en de linker emmer leeg te laten. Een Nee is precies andersom: links vol, rechts leeg.

Nu wandelen we met beide emmers dezelfde route naar de ontvanger en aan het einde gaan we niet beide emmers apart wegen maar we zetten ze tegelijk op een balans. Wanneer de rechter emmer zwaarder is dan de linker, was de boodschap een Ja, andersom een Nee. Het zal duidelijk zijn dat waterverlies onderweg veel minder effect heeft want we verliezen uit beide emmers evenveel water (dit wordt bij de elektrische verbinding gewaarborgd door gelijke lengte van de draden) en als het regent, komt er evenveel water bij in beide emmers (draden zijn getwist, storing en ruis is op beide draden dus even sterk). Dit systeem is dus heel robuust want met emmers van 10 liter kunnen we nog steeds eenduidig bepalen wat de boodschap was als er nog maar 1 kopje water verschil is.

Meindert, je bent je roeping misgelopen!
(of heb je in het onderwijs gezeten?)

Free Bird schreef : Als je al 14 jaar multiplexers maakt en de vragen op je af ziet komen, dan leer je snel dit soort dingen te verzinnen om technisch lastige zaken te verduidelijken. Ik zou dit eigenlijk eens in de handleiding moeten opnemen
Zo heb ik laatst een hoofdstuk "IP adressen voor Dummies" geschreven omdat klanten die een WiFi multiplexer gebruiken ineens geconfronteerd worden met IP adressen en netmaskers. En dat zijn ze niet gewend van hun thuisnetwerk. Dus dan moet je dat gaan uitleggen.

Al met al is het allemaal helemaal niet zo ingewikkeld.
In het instelprogramma voor de mux wat ik mee lever kan je zien dat je voor de wifi alleen een naam ( bijv bootnaam) hoeft in te vullen.
Bij aflevering staat er als naam star. Als je die zou houden hoef je helemaal niks in te stellen op de mux!

Bij de tablet moet je wifi verbinding maken, wat zo ongeveer iedereen wel kan tegenwoordig.

Alleen in het navigatie programma zelf moet je naar de instellingen.
ip adres : 192.168.1.1
poort 10110
type UDP of als dat er niet in staat TCP.

Een kind kan de was doen, je hoeft niet eens te weten wat een ip adres is. Ik denk ook dat de meesten het niet Willen weten

Chris,

Neem van mij aan dat het in de ogen van de meesten niet eenvoudig is. Er zijn mensen die denken dat het IP adres wat je iPad krijgt van je mux, het adres is wat ze moeten invullen in hun navigatiesoftware.... Dus vullen ze 192.168.1.10 in en dan bellen ze dat het niet werkt. Of iemand met een app die de interne GPS gebruikt en denkt dat deze App ook de multiplexer benaderd omdat er al een IP adres in de WiFi instellingen van de iPad staat, terwijl zo'n app niet eens TCP of UDP data KAN ontvangen (navionics).

Wat voor jou en mij simpel lijkt omdat wij de makers van een product zijn, hoeft voor jouw klanten niet simpel te zijn...

Meindert ik was al in 1969 bezig met elektronica, (en sinds 1991 in mijn eigen bedrijf hardware en software aan het ontikkelen voor onderhand een dikke 100 projecten), dus je hoeft me niet uit te leggen dat er ook niet technische mensen zijn op deze wereld... Wat dat betreft heb ik alles al meegemaakt.

Ik beweer alleen dat je het niet ingewikkelder moet maken dan het is.
Je kan helemaal gaan uitleggen wat een ip adres is en wat het technische verschil is tussen udp en tcp. Maar dan haken de meesten al af na de eerste alinea. Verspilde energie. . Mensen zijn niet geinteressseerd in de voordelen van een gebalanceerde verbinding.
Het moet gewoon werken.

Het gaat er daarom m.i. om dat je het simpel houdt.

De meesten kunnen echt wel drie waardes invullen in een tablet. En die het niet kunnen bellen een paar keer. Geen probleem voor mij hoor.

roozeboos schreef : Als jij een klant niet vertelt (in je handleiding) dat je een NMEA uitgang van jouw multiplexer (TX+ em TX-) niet aan een single ended ingang op zijn GPS kan knopen (RX en Gnd) dan zal jouw klant dat gewoon doen. Dan hoop ik dat die TX- uitgang kortsluitvast is. En ik weet ook uit ervaring dat zijn SSB plat gaat in het ritme van de NMEA data.

Ik vind het dan niet meer dan normaal dat je zulke situaties beschrijft in je handleiding en uitlegt wat het verschil is tussen ongebalanceerde en gebalanceerde verbindingen, omdat dat essentieel is voor de goede werking van je navigatiesysteem.

Heb nog zo'n oude Philips MK8 GPS. Daar zat tenminste een goede specificatie sheet bij! Altijd goed als je het naadje van de kous wilt weten of een niet-standaard situatie had. Voor diegenen die echt dieper willen werden zelfs de schema's gegevan van de in- en uitgangsbuffers! Dat laatste zie ik bijna nooit meer!

@mhsprang, helemaal helder nu, dank.

Nog een vraagje aan Roozeboos; in de handleiding staat dat je het RMC-bericht kan omzetten naar een !AIVDO. Ik kan deze optie niet vinden in het instel-programma (v1.4 van je website, de screenshot in de manual is v1.5.....)

Nachtvlinder schreef : Volgens de NMEA 0183 standaard dien je dat als fabrikant ook te doen. Moet ik ook nog een aanpassen

mhsprang schreef : Voor UDP hoef vaak geen IP-adres in te vullen op de tablet. Hoe werkt dit in de mux? Werkt dat met een broadcast (UDP-pakket naar IP-adres 255.255.255.255) die door iedereen die op de betreffende poort luistert ontvangen wordt?

Anno 2014 is het plug and play. Tenminste dat zou het moeten zijn. Zeker alles wat met computers te maken heeft. Eindeloos lopen klungelen en hopen dat iets het belieft te gaan werken ben ik klaar mee. Als iets niet binnen 15 minuten werkt gaat het richting cliko. Gedoe met pull up weerstandjes en ander ongerief zitten we toch niet op te wachten.
Single ended versus geballanseerd met een draadje van 5 meter of door een alu / carbon mast. Lijkt me allemaal overdreven.
En als het echt niet wil lukken een mens van vlees en bloed die er verstand van heeft aan de andere kant van de lijn.

Ah een échte Heideggeriaanse bestelling. Een ding hoort te dingen. Prachtig! Techniek hoort te ontsluiten en niet te besluiten...

kunnen we in een nieuw topic MET SPELD niet dit soort uitleg verzamelen en voor de eeuwigheid bewaren?
Is goud waard!
En we noemen het topic "pindakaas van computers" omdat de meesten er geen pindakaas van hebben gegegeten...
(en pindakaas is zo slecht nog niet)

edit: Je moet t snappen om door te hebben maar als je t niet door hebt snap je er soms ook werkelijk geen jota meer van.

3Noreen schreef :
zo is dat.

op die manier al afgevoerd:
- goedkope serial-to-usb dingen
- memorysticks met eigenzinnig gedrag
- Hema schakelklokje
- iTunes
- Quicktime
- OpenCPN

(dit alles de laatste 2 jaar; de 32 jaar met computers daarvoor nog een eindeloze lijst.....)

Bij mij vliegen ze naar verloop van (steeds minder) tijd horizontaal de kajuit uit en te water ...tenzij de luiken ervoor zitten en ik mezelf kan beheersen en t in de betreffende bak kwak .

Desondanks draait open cpn nog steeds en werken een aantal dingen al jaren tot tevredneid

roozeboos schreef : mhsprang schreef : Ik denk dat jullie allebei gelijk hebben.
'Het moet gewoon werken.' Inderdaad, het is het mooiste als alles ook voor 'dummies' direct en altijd werkt. Maar de praktijk is natuurlijk dat het niet altijd gewoon werkt. Daar zijn jullie het volgens mij over eens.

Sommige klanten zullen naar de telefoon grijpen. Chris vindt het geen probleem om (ook als het er veel worden?) deze allemaal persoonlijk te woord te staan. Kan nuttige feedback opleveren voor de leverancier en spaart de klant soms (lees)tijd.

Ikzelf behoor tot de groep eindgebruikers die wel van een zorgvuldige en uitgebreide documentatie houd (idealiter in de vorm van een pdf, die ik op mijn tablet mee aan boord kan nemen):

1. Installatievragen of storingen aan boord doen zich nogal eens buiten kantoortijden voor (Murphy), als de ontwikkelaar of leverancier even niet telefonisch bereikbaar is.
2. Installeren van dit soort boordsystemen is nou niet direct een project waar de meeste twee-linkerhanden-types zich aan zullen wagen; bij doe-het-zelvers op dit gebied mag je wel enige interesse in de materie verwachten.
3. Achtergrond informatie (context) heeft mij meermalen geholpen om een installatieprobleem of storing zelf op te lossen. Als mensen snel afhaken (zoals Chris constateert) of vaak heel slecht lezen (is mijn ervaring) is het naar mijn idee toch geen verspilde energie om degenen die wèl iets willen leren van goede informatie te voorzien.
4. Leveranciers die iets van hun kennis of ervaring met mij willen delen hebben bij mij altijd een streepje voor. Wat dat betreft zijn jullie allebei - op jullie eigen manier - heel goed bezig.

Zelf problemen kunnen oplossen (soms op gekke tijden en locaties) of voorkomen (zoals Meindert terecht opmerkt) hoort naar mijn idee bij goed zeemanschap. Daar heb je wel goede documentatie bij nodig. Of een satelliet telefoon en 24/7 support...

de oplossing voor veel problemen:

Meindert is net als ik een techneut, en die zijn het maar weinig eens hoor.
Maar je hebt gelijk. we willen allebei dat het goed werkt bij de eerste poging.
Het is een goed punt om zoveel mogelijk uitleg in de manual te verzamelen. De gebruiker kan zich dan inlezen in de materie.
Ik zal vanavond nog een keer door de manual gaan en trachtten het wat meer uit te leggen voor de electrisch wat minder begaafde gebruiker.

Ook juist door dit draadje hoor ik doorlopend over gebruikers en hun ervaringen. En daar doe ik dan weer wat mee.

Ik geef ook terug hoor, inmiddels is Startracking weeer sponsor. om de paar minuten kom ik links een tijdje in beeld bij de banners!!

Is er iemand met een iPhone of iPad die de UDP data zou willen loggen met de (gratis) app iNMEAlogger?

Ik ben druk in gesprek met de ontwikkelaar van iRegatta over het niet werken van UDP met iRegatta (op Android). HIj is heel behulpzaam, maar we komen er niet met de logfiles die ik met iNMEAlogger op diverse Android apparaten gemaakt heb.
Na het mailen verschijnt daar een hoop troep in, maar het is onduidelijk waar dat vandaan komt.

Als iemand een idee heeft hoe ik de data via UDP op een Windows pc kan loggen zijn we ook al geholpen...

Het zou leuk zijn als iRegatta met UDP van de WiFi NMEA box overweg kon....

de app van nke heeft een logfunctie en kan UDP. Het laatste heb ik niet zelf uitgeprobeerd. Ik werk met tcp/ip Waar je wel rekening me moet houden is dat de ipad meer stroom blijft gebruiken omdat die continu “iets” moet doen.

H3arth schreef : UDP ontvangen is eigenlijk heel simpel als je weet hoe het moet Vraag die omtwikkelaar maar contact met mij op te nemen, dan wil ik hem wel adviseren. Dat kan via Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.
Die logfiles bevatten gewoon nmea in ascii formaat, dus daat heeft hij niet zoveel aan.

In de ontvangen UDP frames kan de data maar op twee manieren in zitten: een zin per UDP frame of verdeeld over meerdere UDP frames. Maar het zit er gewoon in als leesbare nmea..

mhsprang schreef :
Bedankt, zal ik doen!
Het is nu alleen dat hij er zelf nog niet van overtuigd is dat het aan iRegatta ligt. Hij heeft met zijn DMK box geen problemen via UDP.

H3arth schreef :