GPS monitor for GPSDO

Op zaterdag 18 januari 2025 08:56:54 schreef EricP:
[...]
Mooie afwerking, Gertjan. Waar heb jij display en bezel vandaan? LCDs vind je op elke straathoek. Bezels lijkt toch wat moeilijker te liggen. Iets passends vinden en dan ook nog een plastic en geen 'gouden^*' variant...

^{*Niet vastgesteld, maar de prijzen die men er zo her en der voor vraagt doen het vermoeden.}

Haha laatst een fotolijstje gescoord voor €3 wel een beetje erg groot! Maar wel met bezel (niet op de pic) aansturing kan, makkelijk? Geen idee. Wel kleurdisplay met retro FL tubes.
Spuitbussen met verf zijn overal te koop. De kleur is geen probleem. Laatst een rood stuk doorzichtig perspex op laten sturen ter grootte van een display, gratis sample, en goud transformen gaat makkelijk met een spuitbus.

maar ik zit Gertjan zijn topic vol te spammen, so sorry.

Dank je Raaf

.

Ontwikkeling van het ingangstrapje

Wellicht leuk om te laten zien hoe dat ingangstrapje tot stand gekomen is.

Ik begon met een vrij populair 1 transistor trapje:

^{alle schema's klikbaar voor grotere versies}

Eigenlijk is dat simpele ingangstrapje, mooi gedimensioneerd, erg elegant.
Het werkt al met slechts iets meer dan de B-E spanning aan de ingang. Met een goed gedimensioneerde basisweerstand krijg je een groot ingangsspanningsbereik. (weerstand zo klein dat er met de laagste Uin voldoende basisstroom loopt om de tor goed open te sturen, en groot genoeg zodat de tor bij de hoogste Uin heel blijft)

Voeg daar de diode aan toe om de tor te beschermen tegen negatieve input (RS-232…), en een C’tje om een ingangsfilter te maken. Die beide functies maken gebruik van de al bestaande basisweerstand.
Die extra 10k over de ingang brengt ingangsimpedantie op ong. 5kΩ, de richtwaarde voor RS-232.

Het navolgende schakelingetje is om de processor te laten kiezen tussen een wel- of niet geïnverteerd ingangssignaal. Ik heb zitten puzzelen hoe ik dat in één goedkoop CMOS IC kon gieten. Het neemt veel ruimte in op het schema, maar is slechts een SOIC + SOT32 op de print

.

Daarmee was m’n ingangstrap al vrij ideaal. Maar toen bedacht ik dat ik galvanische scheiding wilde….

Dus op zoek naar een zuinige en snelle opto-coupler. In m’n laatjes vond ik een stel 6N139, en verder zoeken leverde niet veel beters op. Daarmee kwam ik bij versie 2:

Een basic opzet met 6N139. Met al wel ingangsfilter en negatieve spanning protectie.
Erg leerzaam om mee te spelen. Want het bleek niet makkelijk om de opto-coupler én zuinig én snel te houden. Belangrijkste probleem is dat de collector uitgang wel snel hoog wordt, maar slechts langzaam weer laag…
Dat komt omdat de lading die je in die foto-darlington stopt, op een of andere manier er ook weer uit moet. En dat kost tijd.

Vandaar die 22kΩ aan de basis van de uitgangstor. Om de eerste tor leeg te trekken. Dat kost gevoeligheid, maar levert snelheidswinst op. Verder was de sleutel om niet te veel stroom door de opto-LED te sturen. Anders verzadig je de darlington te veel. Rond 0,8mA bleek optimaal.
Omdat de flanken nu minder stijl waren, zijn de poorten van de achterliggende inverter vervangen door Schmitt-triggers.

.

Die LED stroom wordt nu groter met stijgende ingangsspanning. Niet ideaal dus.
Daarmee komen we bij versie 3:

M’n eerste poging om die opto-LED stroom te begrenzen. Werkte prima. Dat wil zeggen, voor positieve ingangsspanningen (TTL) . Maar natuurlijk niet voor negatieve spanningen (RS-232…)
(De inverter is verder niet meer veranderd, dus die teken ik er niet meer bij)

.

Malend op bovenstaand, en bedenkend dat m'n oplossing dus symmetrisch moest zijn, kwam ik op versie 4:

Een symmetrische oplossing met FET stroombronnetjes. Voor elke polariteit staat 1 stroombron te werken, terwijl de andere dan vol open staat. Ik ben altijd al een fan van FET stroombronnen geweest, omdat het een elegante 2-draads oplossing is. En dit is een mooie toepassing.

Maar die gate-source weerstanden (de stroom instelweerstanden) zaten me niet lekker. Het hele ingangscircuit mag niet te veel weerstand hebben, anders loopt er te weinig stroom bij 3V in.

.

Daar op puzzelend viel het kwartje door, en kwam ik bij versie 5:

Gebruik de spanning over de opto-LED als instelspanning voor de stroombron! Eerst gezocht naar FETjes die precies 1,4V nodig hadden voor een stroom van 0,8mA. Natuurlijk niet gevonden. Dan maar een spanningsdeler over de opto-LED om de FET’s precies naar wens in te stellen (Eigenlijk sowieso beter natuurlijk ).

Doordat de stroombron instelweerstanden verdwenen zijn, konden de ingangsweerstanden weer wat groter worden.

.

Nu de beveiliging nog op orde: de Tranzorb clampt zowel positief als negatief op 24V. Door voor de ingangsweerstanden MRS25 typen te kiezen (max 625mW) blijven ze tot 60V in heel.

Nadeel van de stroombronnen is dat de ingangsimpedantie nu oploopt met stijgende ingangsspanning:

In rood de ingangsimpedantie, in blauw de ingangsstroom.
Bij 3V in is de ingangsimpedantie 5kΩ. Maar bij oplopende ingangsspanning stijgt ook de ingangsimpedantie. (zo’n 17kΩ bij 15V in, de hoogste RS-232 spanning). Bij 24V in zie je de Tranzorb op de lijn komen.
Aan de blauwe curve is te zien dat de stroombron inderdaad op de ideale 0,8mA begrenst. En bij 24V begint de tranzorb stroom te trekken.

De RS-232 norm zegt dat de ingangsimpedantie tussen 3kΩ en 7kΩ moet zijn. Daarom 10kΩ over de ingang toegevoegd om de impedantiepiek te dempen:

Nu blijft de ingangsimpedantie over het hele werkzame gebied mooi tussen 3kΩ en 7kΩ .
Die 10k is een compromis: Je wilt bij 3V in zo min mogelijk stroom kwijtraken. Om dat verlies te compenseren zijn de ingangsweerstanden weer wat verkleind tot de uiteindelijke 681Ω. Zo toch alle doelen bereikt .

Bovenstaande schakeling was overigens nog niet helemaal het eindresultaat…
Ik kwam er achter dat die Tranzorb een flinke capaciteit heeft (ong. 550pF!), en daarmee het kantelpunt van het ingangsfilter te laag…. Dus die C van 680pF verkleind. Verder is die ingangs C van 470pF verdwenen. Bij nader inzien eigenlijk overbodig: HF troep komt toch niet door de opto-coupler.
Want de koppeling (over de galvanische scheiding) is zeer laag: slechts 8,5pF…

Voor de liefhebbers: alle input versies in een PDF
Alle ingangsimpedantie metingen in een PDF

Groet, Gertjan.

Grappig om je 'ontdekkingsreis' te zien. Ooit, heel lang geleden, ben ik ook met zoiets bezig geweest - galvanische scheiding NMEA. Toen ik op een look-alike van jouw 'versie 3' kwam, struikelde ik toevallig ook over een service manual van een VHF-DSC controller. Waarop ik eens in dat schema kijk en denk: verrek, zij hebben hetzelfde verzonnen! Dat was toch geen kleine jongen en blijkbaar maalden zij niet om een stukje asymmetrie. En die is bedoeld voor NMEA, dus bij benadering 5V, symmetrisch. Die negatieve spanning zit daar dus ook gewoon in.

Het 'probleem' van een optocoupler die de ene kant op veel trager is dan de andere kant is daar van minder groot belang: de baudrate ligt vast en daarmee ook min of meer de benodigde rise / fall time. En dat is op 4k8 allemaal niet zo spannend (ik heb mijn eigen creatie destijds gewoon met een 2k4 blokgolf door een MAX485 ofzo als signaal, een potmeter op de betreffende pin van de optocoupler en ff draaien tot het op de scope op het oog symmetrisch is. Weerstand meten. Dat is de goeie

Ik doe de laatste jaren nauwelijks nog wat met NMEA aan de hardware kant, maar je ontwerp heb ik bewaard: beter goed gejat dan slecht zelf verzonnen tenslotte Dank voor het beschrijven van je overwegingen.

Awel hé, dat is nu eens duidelijk.

Hadden de projecten in Elektuur destijds zo uitgelegd geweest dan had ik niet eens naar school moeten gaan.

Ha EricP,

Leuk om over jouw ervaringen te lezen.
Natuurlijk prima om mijn ontwerp te hergebruiken. Tenslotte leren we allemaal van elkaar, en komen zo verder.

.

Nog wat betreft mijn "meer elektronicus als programmeur": Ik ben waarschijnlijk de enige die een oscilloscoop aan zijn software hangt .

(foto is uit het prille begin, hier nog op een Mega 2560)

Ik had een subroutinetje gemaakt die na elke doorloop van de hoofdlus een poort toggelt.
Met de scope aan die poort kan ik in de gaten houden hoe snel mijn programma is.

Als ik wat veranderde of toevoegde aan m'n programma wat vertraagde, dan kon ik meestal een andere oplossing vinden die sneller was. Betere aanpak, of ander commando.
Zo bleek "lcd.write()" 30% sneller als "lcd.print()".

Invloed van dingen die vertraagden (zoals schrijven naar het display) kon sterk teruggedrongen worden door ze niet vaker uit te voeren dan noodzakelijk, en dan alleen laten doen wat echt nodig is.

Met de recentste software is de loop doorlooptijd 52us, met om de 100ms een pauze van 12ms waarin het display ververst wordt.

In TestController kan ik loggen met 0,03 sec interval zonder dat de GPSDO monitor het loggen vertraagd. Testcontroller leest dan SATS (aantal satellieten in de fix), SNR (gemiddelde signaal/ruis van alle sats), PDOP, HDOP, FIX en MODE uit.
Omdat de NMEA data ongeveer 1x per seconde ververst wordt, wordt dan dus wel 33 keer dezelfde gegevens uitgelezen .

groet, Gertjan

Leuke ingangstrap, maar waar komt de voeding vandaan. De opto wil wat stroom zien, haal je die uit het input-signaal.
RS232? Bij de ingang staat 'NMEA' en dat is 4800 Bd, RS485 (biploair +/-5V). Unipolair aansluiten op een RS232 ingang werkt meestal wel. Dat wordt bij bootjes vaak gedaan (onkunde?), maar leidt af en toe wel tot een Oops! moment. Shit, mijn GPS doet het niet meer, waar moet ik nu naar toe sturen? Wat de 'gemiddelde' GPS receiver uitstuurt is vaak onduidelijk. Je schreef ergens 'reversed RS232'. Zou dat gewoon de TTL bitjes-stroom kunnen zijn binnen het apparaat voordat de line-driver er (geïnverteerd) -/+ 15V van maakt.

Arduino soft-serial library heeft inderdaad zijn eigenaardigheden. Ben zelfs ooit in de source gedoken om uit te vinden waarom mijn RS485 netwerkje met meerdere deelnemers niet foutloos werkte. Bibliotheek is beslist niet robuust. (Keywords: Buffer, interrupts, overrun detectie etc.).

Ha Soldeersmurf,

Bij de ingang staat "NMEA in", met daaronder "TTL en RS-232 compatibel" .

De enige stroom die de ingang nodig heeft is de 0,8mA door de fotodiode. En die komt inderdaad uit het ingangssignaal. Bij 3V in staan de current sources nog vol open, en begrenzen de weerstanden de stroom, daarboven gaat de current source aan de plus kant begrenzen op 0,8mA.
(Die current sources zijn 2-draads schakelingetjes, die geen aparte voeding nodig hebben)

Bipolair of Unipolair zou niet uit moeten maken. Zolang er meer als 3V tussen de twee ingangspennen staat, komt er een pulstrein uit die de processor kan lezen. Indien nodig inverteert de processor het signaal zelf.

'Reversed RS232' klinkt als een vies woord . Maar inderdaad, je hebt "gewoon" TTL, en de RS-232 driver inverteert dan dat signaal, en maakt er +/-7...15V van. En inderdaad, er zijn ook GPS fabrikanten die hun TTL geïnverteerd uitsturen, en dat dan "RS-232" noemen.
Voor de GPSDO monitor maakt dat dus allemaal niet uit, hij slikt alles .

Mijn probleem met soft-Serial was dat het opzich wel werkte. Maar ik check ook de CRC van de NMEA sentences. Met soft-serial waren er na verloop van wat tijd altijd wel een paar CRC fouten. Met hardware serial in, blijft het aantal CRC fouten nul.

groet! Gertjan.

Nog wat betreft mijn "meer elektronicus als programmeur": Ik ben waarschijnlijk de enige die een oscilloscoop aan zijn software hangt .

Zolang het 'simpel' is, dan kan dat. Als het complexer wordt, dan houdt dat op: je kunt niet alle mogelijke paden 'testen', dan ga je meer voor 'snelheid by design' (ofwel: als er zaken zijn die timing-kritisch zijn dan zorg je dat die gedaan worden en de rest ergens 'tussen door'.
Overigens heb ik zo'n 'toggle poot' ook wel eens toegepast voor een watchdog, maar dan extern (8051 derivaat waar dat op draaide had dat niet intern). ff kijken hoe 'we' in de loop time zaten

Zo bleek "lcd.write()" 30% sneller als "lcd.print()".

Dat is dus altijd een beetje het punt met libraries die 'ergens' vandaan komen. Je hebt geen idee (zonder de source door te spitten) wat de maker in gedachten had. Soms boeit dat niet zo, soms dus wel...

Met de recentste software is de loop doorlooptijd 52us, met om de 100ms een pauze van 12ms waarin het display ververst wordt.

Omdat de NMEA data ongeveer 1x per seconde ververst wordt, wordt dan dus wel 33 keer dezelfde gegevens uitgelezen .

Die dus. Als het iets met een display is, is een refresh van 1x per seconde doorgaans genoeg. Er zijn wat uitzonderingen (HMI met rotary encoder bijvoorbeeld), maar het impliceert ook dat het al snel 'snel genoeg' is zonder daar over na te denken.
Overigens is mijn insteek bij dit soort dingen vaak anders: process de data als het binnenkomt en display het dan. Ondertussen reset je nog ergens een timer om te voorkomen dat het display stabiel blijft als er niks meer binnen komt. Maar zo zal jouw library wel niet werken.

Met soft-serial waren er na verloop van wat tijd altijd wel een paar CRC fouten.

Was het maar CRC. Meer dan een simpele checksum (zo uit mijn hoofd) is het niet. Maar goed... wat je feitelijk beschrijft is dat deze library dus eh... niet werkt Leuk dat het de meeste bits juist weet te ontvangen, maar ja... 1 bit verkeerd maakt een string onbruikbaar. Tenzij je er weer 2 verkeerd doet op een handige plaats en daarmee het probleem maskeert: de checksum klopt, de data niet...

Overigens: als het je interesseert, zoek dan ff op wat verschillen tussen CRC en checksum. De CRC is meer rekenwerk, maar ook robuuster (minder kans op 2 bit fouten die elkaar in de controle opheffen). De wiskunde achter CRC heb ik nooit helemaal doorgrond, waarschijnlijk omdat ik er nooit echt en studie van gemaakt heb

Op woensdag 22 januari 2025 07:54:29 schreef EricP: Die dus. Als het iets met een display is, is een refresh van 1x per seconde doorgaans genoeg. Er zijn wat uitzonderingen (HMI met rotary encoder bijvoorbeeld), maar het impliceert ook dat het al snel 'snel genoeg' is zonder daar over na te denken.
Overigens is mijn insteek bij dit soort dingen vaak anders: process de data als het binnenkomt en display het dan. Ondertussen reset je nog ergens een timer om te voorkomen dat het display stabiel blijft als er niks meer binnen komt. Maar zo zal jouw library wel niet werken.

Wel goed lezen Eric . Ik schreef:

Op maandag 20 januari 2025 15:42:50 schreef miedema:
Invloed van dingen die vertraagden (zoals schrijven naar het display) kon sterk teruggedrongen worden door ze niet vaker uit te voeren dan noodzakelijk, en dan alleen laten doen wat echt nodig is.

Met de recentste software is de loop doorlooptijd 52us, met om de 100ms een pauze van 12ms waarin het display ververst wordt.

In TestController kan ik loggen met 0,03 sec interval zonder dat de GPSDO monitor het loggen vertraagd. Testcontroller leest dan SATS (aantal satellieten in de fix), SNR (gemiddelde signaal/ruis van alle sats), PDOP, HDOP, FIX en MODE uit.
Omdat de NMEA data ongeveer 1x per seconde ververst wordt, wordt dan dus wel 33 keer dezelfde gegevens uitgelezen .

Ik laat dus juist het display slechts 10x per seconde verversen in plaats van dat elke loop te doen (= elke 52µs).
(Maar dat zou inderdaad nog wel wat minder kunnen)

Het is juist mooi dat TestController, bij zeer snel loggen, 30x per seconde gegevens kan opvragen bij de GPS monitor zonder problemen.
En dat Testcontroller dan 30x dezelfde data uitgeserveerd krijgt, tjaa... Natuurlijk log je alleen maar zo snel als de data waar het om gaat wél snel verandert, en het is fijn dat de GPS monitor het loggen dan niet vertraagt.

groet, Gertjan.

Nog wat over PolyFuses (PTC zekering)

Polyfuses lijken zo mooi: zelf herstellende zekeringen .
Maar het bleken zo ongeveer de minst ideale componenten die ik ken .

Ik heb bij de GPS monitor er een sport van gemaakt om ook de voedingsingang optimaal te beveiligen. Een glaszekering leek niet elegant: bij een zekering op de print moet je eerst het kastje open maken. Een zekering op de achterkant kost ruimte op een klein kastje, en extra bedrading.

Oplossing? Tada: de Polyfuse

^{klik voor grotere versie}

Maar met wat lezen en experimenteren viel dat al snel tegen:
- De trip stoom is minstens het dubbele van de maximale houdstroom
- En het duurt dan ook nog lang (seconden...) voor de polyfuse tript.

Tot zover lijkt het op een gewone zekering, die zijn ook niet ideaal. Maar:

- Een PolyFuse heeft een flinke serieweerstand.
- En erger: na een keer trippen is die toch al flinke serieweerstand minstens verdubbeld .
- Zelfs na een uur is de serieweerstand nog meer dan de dubbele nominale waarde.
- En elke keer dat de Polyfuse tript is de serieweerstand daarna weer wat hoger.
- En na zo'n 100x trippen wordt die serie weerstand zelfs helemaal niet meer laag....

Toen ik bovenstaand op een rijtje had, begon ik te denken dat ik polyfuses maar beter kan vergeten. Een grotere polyfuse met laag genoeg serieweerstand, die zal nooit trippen. En een polyfuse met acceptabele tripstroom heeft een te hoge serieweerstand in normaal bedrijf....

.

Toch besloot ik met verschillende polyfuses te experimenteren, om te kijken of er een goede tussenweg te vinden was.

Ik bouwde het relevante stukje schema op een stukje print om te mishandelen:

De polyfuse heb ik oranje gemerkt, wat die wil ik na mijn tests nooit meer gebruiken

En inderdaad bleek er toch voor mijn toepassing een polyfuse te zijn waar al die matige eigenschappen toch nét voldoende bleken: De Bourns MF-R020. Specs: I_hold=0,2A, I_trip=0,4A, Initial Resistance = 2,5Ω, 1 uur post trip Resistance = 4,5Ω, Max time to trip: 2,2sec @1A.

.

Bovenstaand schakelingetje met die Bourns MF-R020 gemeten met Testcontroller:

De rode lijn is de ingangsspanning, de blauwe de ingangsspanning van de 7805 regelaar. Grijs is de 7805 uitgangsspanning (naar de ProMicro). De paarse lijn is de ingangsstroom.
Ik belastte de voeding met 100Ω. Dus een belasting van 50mA, ongeveer gelijk aan wat de GPS monitor trekt.

Op 0:20 wordt de voeding ingeschakeld. Ingangsspanning is 9V, op de ingang van de 7805 staat iets minder. Spanningsval over D4 en die polyfuse...

Op 0:46 vergroot ik de ingangsspanning naar 33V. De ingangsspanning van de 7805 (blauw) schiet ook omhoog, maar wordt geclampt door de 24V tranzorb D5. D5 sluit in feite de voedingsbron kort, dus de ingangsstroom (paars) schiet omhoog, tot zo'n 1,1A

Vrij snel begint de polyfuse te werken, met een wake-up call van die 1,1A. Na 1...2 sec is de stroom weer laag. De ingangsspanning van de 7805 blijft hangen op zo'n 4V. De uitgang van de 7805 staat dan op 1,5V (door de 100Ω belasting).

Op 1:48 gaat de ingangsspanning weer van 33V naar de nominale 9V. De polyfuse daalt in een paar seconde voldoende in waarde om de nominale situatie te herstellen.

.

Nog een meting, maar nu met 60V in, en het trippen van de polyfuse wat uitgesmeerd:

Nu stijgt de ingangsspanning naar 60V. Een spanning die een 7805 niet zou overleven. (U_{in max}=35V).
Je ziet mooi dat het de Tranzorb lukt om de ingangsspanning van de 7805 te clampen op 24V. Maar ook dat hij dat 1,5sec vol moet houden voordat de polyfuse de stroom beperkt.

Met deze combo van PolyFuse en Tranzorb lukt het dus toch prima om de 7805 tot 60V input heel te houden
De serieweerstand van de polyfuse betekend wel dat de minimale ingangsspanning nu iets hoger is geworden....

groet, Gertjan.

Ha Gertjan

Ik heb gelezen Feit is dat mensen doorgaans niet in staat zijn om meer dan 1x per seconde een display te lezen - de ene wat sneller, de andere wat langzamer. Vandaar de opmerking.

Over je input: Het is 4k8. Dus mex. 480 char/sec (start bit, stop bit, 8 data bits). Als je nou (lekker makkelijk rekenend) uit gaat van een message van 48 characters (dat is dus echt van kop-tot-staart), dan zou je max. 10 messages/sec binnen kunnen krijgen. En dan doe ik de aanname dat er niks anders verstuurd wordt. En als je message de helft aan lengte redt, dan worden het 20 messages/sec... Maar dat is wel heel erg optimistisch, dus niet realistisch).
In het kort: op 480bps, is het qua snelheid allemaal niet zo spannend.

Mijn eerste kennismaking met polyfuses (ook al een tijd terug...): een matrix printer. Ding was omgebouwd naar 24V voeding. Dus voedings trafo eruit, printje met brugcel, elco, regeling eruit, ander printje er voor terug. Klacht: de printer print maar 1 tot 2 regels en stopt er dan mee.
Het duurde even voordat ik doorhad dat die polyfuse roet in het eten gooide. Dus die vervangen. Printer terug. Werkte prima. Jaar later: zelfde euvel. Nou is die rommel 'gecertificeerd', dus nu maar eens wat dieper gespit en wat rondgevraagd. Het blijkt dat het ding zo 2x per maand klem loopt met het kettingpapier. DAT zal die polyfuse wel triggeren. En die wordt rap slechter - dat laatste duurde ook heel ff voor ik het door had. Stomme dingen.
Inmiddels heb ik daar een vrij pragmatische insteek in: hoe vaak zal het stuk gaan? In de voeding van mijn eigen apparaat, zal dat wel loslopen. De zekering wordt dan door iets externs 'meegenomen', dus de kast moet toch open: douw er maar een smeltzekering in. Blijft over: een overspanning. Nou ja, dom geweest, nu ff schroeven. Maar ik geef direct toe dat ik het 10 jaar terug ook zou 'overengineeren'

Bij mij wordt het display ververst na ontvangst van een G_RMC bericht, de RMC staat voor "recommended minimum" of zoiets, en ik heb nog geen enkele GNSS-ontvanger gehad die dat niet uitzond. En ze komen exact maar dan ook exact om de 1,0000 seconde

Gemiddelde berichtlengte is naar mijn aanvoelen eerder rond de 100 byte, eerder meer dan min. 4800 Bd mag dan de norm zijn, dat is inderdaad al te traag om iets zinnigs mee te doen. De meeste Chineesjes doen 9600 Bd, maar ik heb ook al 115200 meegemaakt.

Meestal kun je aan/uit zetten wat zo'n ding uitspuugt en hoe vaak. Bijvoorbeeld Furuno laat je bij een aantal modellen zelfs nog zien hoe 'vol' je tijd zit en of het wel kan.
100bytes kan niet volgens spec. Het correcte aantal kan ik je zo niet geven en ook niet of dat inclusief kop en staart is. Maar ik meen 64 bytes als max...

Veel scheepvaart draait op 4k8, botweg omdat dat de NMEA0183 standaard is. Meer dan RMC en soms DTM heb je daar zelden nodig. Past prima op 4k8. En de refresh rate is ook hoog zat in die context...
Gertjan gebruikt natuurlijk andere strings - die wil wat van z'n SATs weten... Maar ook daar: dat zal ook niet per 10mS schokkend veranderen.

Wikipedia geeft u gelijk op 1 punt:

Messages have a maximum length of 82 characters, including the $ or ! starting character and the ending <LF>

daarentegen blijkt de 4800 enkel "typical" te zijn, geen "harde" norm dus:

Typical Baud rate 	4800
Data bits 	8
Parity 	None
Stop bits 	1
Handshake 	None

Ha Gertjan,

Dat is een mooi en vooral handig hulpmiddel. Ik heb ook nog het plan een GPSDO te maken, heb zelfs alle ingrediënten al, en wou het uitvoeren met 2 LED's (3D fix van Tommy Sullivan en PLL lock uit een 74HC7046) om te weten of mijn 10MHz uit betrouwbaar is.
Jouw oplossing gaat een paar stappen verder en is voor mij nog makkelijk te implementeren.

Nou zat ik even op het schema te kijken en zag een 5,3V die je zelf maakt om de Pro Micro te voeden. Op de Pro Micro wordt een +5V gemaakt die jij weer gebruikt voor de rest van de schakeling. Ik vond het schema van de Pro Micro niet duidelijk wat betreft de 3,3V of 5V. In middels heb ik een boardje binnen en wat gelezen, ik begrijp dat de 16MHz versie altijd 5V is en de 8MHz 3,3V.
Bij mij zit er geen MIC5219 op, maar iets van MicroOne met opdruk S8Xt. Mijn Pro Micro zal wel een Chinese kloon zijn, koste maar een paar euro.

Maar ik heb twee vragen over het stukje schema rond het display, zie snapshot:

Ik begrijp de opmerkingen in de rode boxen niet. Kun je dat wat verduidelijken, want dat is nu voor mij een beetje te cryptisch.
R14 is nu een pull-up weerstand, dat zal een vergissing zijn...

Groet, Rob

Ha rob040,

Als je de fase-slip meet dan is dit mijn in ziens overbodig (dubbel).
Zelfs met een simpele lock detector (XNOR) zit je veel vroeger in de keten dan het meten (detecteren) van de BER en, is de resolutie vele malen groter....

Groet,
Henk.

Ha Rob040,

Leuk dat je m'n schema goed hebt uitgeplozen!

Er is inderdaad onduidelijkheid, en tegenstrijdigheid rond die ProMicro 3V en 5V. voor dit project heb ik dat eens goed uitgezocht. Ik kom daar in een aparte post op terug. Voor Nu: Ik gebruik een Chinese (Ali) 5V ProMicro.

.

LCD contrast instelling

R14 is inmiddels R20 geworden . Dank je, ik zal het schema bijwerken...

Met instelpot R20 stel je op de gebruikelijke wijze het LCD contrast in.

Op dat instelpunt (display pin 3, VO) wordt ook vanuit de ProMicro via R18 een spanninkje gedrukt. Dat (PWM) spanninkje staat nominaal op halve waarde. Door bij die nominale waarde R20 af te regelen op goed contrast, kun je daarna door het PWM spanninkje te variëren het contrast softwarematig bijregelen.

Dat kan zowel met commando's in een terminalprogramma (LCD en LCD?), als met het schuifje in de TestController popup:

Dat schuifje in TestController heb ik in de praktijk plezier van. Elke keer als de GPS monitor ergens anders staat, dan is de kijkhoek anders. En dan is het prettig om het LCD contrast bij te kunnen regelen.

Eenmaal bijgeregeld wordt de nieuwe waarde bewaard in flash, en wordt die waarde gebruikt na opnieuw aanzetten.

.

LCD kijkhoek: display "6 o'clock"

Elk LCD display heeft een optimale inkijkhoek.
Bij de meeste displays is dat optimaal als je er een beetje van boven inkijkt. Dat wordt dan "12 o'clock" genoemd.

Uitgebreidere uitleg hier: What is LCD display View angle?

Ik voorzag dat ik m'n monitor ergens op een meetplank, boven mijn hoofd, zou gaan zetten. En dus van onder af naar het display zou kijken.

Dus ging ik op zoek naar een 6 o'clock display. Dat viel tegen.... Bijna alle displays zijn 12 o'clock, of hebben het niet gespecificeerd. (en zijn dus waarschijnlijk ook 12 o'clock)

Uiteindelijk vond ik een 6 o'clock display, bij TME. Maar toen dat binnenkwam bleek de kijkhoek weinig anders dan van de andere displays die ik had...

In de praktijk blijkt het mee te vallen. Vooral omdat ik makkelijk met dat TestController schuifje het contrast kan bijstellen.

.

Button de-bounce

R14 is inderdaad een pull-up weerstand. De display button schakelt naar massa.
Waarom niet de in de ProMicro ingebouwde pull-up gebruikt? Omdat ik nog een hardware de-bounce netwerkje wilde tussenvoegen: R15 met C10.

Ik hing mijn scope achter die drukknop, en hij bleek flink te bouncen (zoals al die drukknopjes ) :

Een klein RC netwerkje van 1k en 0,1uF (RC tijd van 0,6ms) bracht al flink verbetering:

Toen ben ik eens gaan meten hoe snel ik eigenlijk dat knopje kon indrukken. M'n kortste indruktijd bleek 20...30ms. Het was meestal eerder 100ms.

Dus m'n hardware de-bounce kon nog wel flink steviger, zonder risico dat je een korte indruk mist. RC netwerkje aangepast naar 1k en 1uF, voor een RC tijd van 6ms:

En zie, een hele korte button-press van 30ms, geheel zonder bouncing .

Uiteraard heb ik ten overvloede ook in software een de-bounce toegevoegd. Maar die hoeft dus weinig te doen...

groet, Gertjan.

Op maandag 27 januari 2025 00:18:35 schreef rob040:
Ha Gertjan,

Dat is een mooi en vooral handig hulpmiddel. Ik heb ook nog het plan een GPSDO te maken, heb zelfs alle ingrediënten al, en wou het uitvoeren met 2 LED's (3D fix van Tommy Sullivan en PLL lock uit een 74HC7046) om te weten of mijn 10MHz uit betrouwbaar is.
Jouw oplossing gaat een paar stappen verder en is voor mij nog makkelijk te implementeren.
Groet, Rob

Ha Rob,

Als het je alleen om een 3Dfix indicatie gaat, dan is de oplossing van Tommy Sullivan prima. Mooi compacte oplossing, en geeft de essentiële informatie.

Natuurlijk is die 3Dfix indicatie het belangrijkst. Maar je wordt dan niet gewaarschuwd voordat het mis gaat (als de condities verslechteren). En als die condities even verslechteren, dan gaat die LED even uit. Dat is snel gemist. Als ik in m'n log een 3Dfix verlies zie, dan is dan meestal een korte dip.

Als je wilt nabouwen, dan heb ik natuurlijk een .ino voor je. Stuur maar een mailtje.

groet, Gertjan.

Op donderdag 23 januari 2025 15:55:02 schreef Paulinha_B:
Wikipedia geeft u gelijk op 1 punt:

Messages have a maximum length of 82 characters, including the $ or ! starting character and the ending <LF>

2 eraf voor de $ en de LF, 5 eraf voor de identifier, 1 eraf voor de seperator daarna 3 eraf voor de checksum met *... Ben ik nog steeds niet bij 64. Maar dat getal komt ergens vandaan

daarentegen blijkt de 4800 enkel "typical" te zijn, geen "harde" norm dus:

Typical Baud rate 	4800
Data bits 	8
Parity 	None
Stop bits 	1
Handshake 	None

Onzin. In de (wellicht wat oudere) NMEA0183 spec (die je mag kopen...) staat gewoon keihard 4k8. Dat de halve wereld zich er niet aan houdt, dat zal. Dat is met wel meer specs zo. Hoe ik dat weet? Nou, ik heb die spec. En inderdaad, copyrighted, dus ik post 'm niet

Button de-bounce

Een andere oplossing die goed werkt is 2 variabelen in software: is de pin 'hoog' en variabele < MAX, dan eentje erbij. Is de pin laag en variabele > 0, dan eentje eraf. Als je '0' bereikt dan is de boel blijkbaar laag, als je MAX bereikt, dan is de boel blijkbaar hoog. Dat update je elke keer als je de input pin polled in de 2de variabele (en best elegant, want checken op '0' en MAX moet je toch al).
Als je de status wilt weten, dan kijk je naar je 2de variabele.
De polling doe ik - als ik het nergens anders voor nodig heb - in een timer-driven ISR. De waarde van MAX is natuurlijk afhankelijk van de frequentie waarin je polled en je bounce-tijd. En daar volgt dan weer uit hoe 'breed' je 1e variabele moet zijn.

Is het 'beter' dan een RC-netwerk? Mwah... Het is meer dat de engineering simpeler is. Bij grote aantallen zou je nog een wat latere component count kunnen hebben - maakt voor een enkel exemplaar natuurlijk weinig uit. En een kleinere PCB. Als dat al een rol speelt.

Op donderdag 23 januari 2025 15:02:54 schreef EricP:
Ik heb gelezen Feit is dat mensen doorgaans niet in staat zijn om meer dan 1x per seconde een display te lezen - de ene wat sneller, de andere wat langzamer. Vandaar de opmerking.

Eigenlijk nooit zo over nagedacht. Maar dan bedoel je denk ik het lezen van het hele display. Want als ik bv naar mijn multimeter kijk en dan vooral naar het laatste deel wat verandert kan je dat wel een stuk vaker lezen.

3V of 5V ProMicro onduidelijkheid

Bij het bekijken van m'n Ali ProMicro's fronste ik m'n wenkbrauwen, en vroeg me af of dit nu 3V of 5V types zijn. Het is niet duidelijk....
Rob040 was dat ook opgevallen:

Op maandag 27 januari 2025 00:18:35 schreef rob040:
Nou zat ik even op het schema te kijken en zag een 5,3V die je zelf maakt om de Pro Micro te voeden. Op de Pro Micro wordt een +5V gemaakt die jij weer gebruikt voor de rest van de schakeling. Ik vond het schema van de Pro Micro niet duidelijk wat betreft de 3,3V of 5V. In middels heb ik een boardje binnen en wat gelezen, ik begrijp dat de 16MHz versie altijd 5V is en de 8MHz 3,3V.
Bij mij zit er geen MIC5219 op, maar iets van MicroOne met opdruk S8Xt.

De ProMicro is geen echte Arduino, maar ontwikkeld door SparkFun.

Het lijkt overzichtelijk:
- De 5V versie heeft SJ1 gesloten, en draait op 16MHz.
- de 3V versie heeft SJ1 open, en draait op 8MHz.

Dat klopt ook met het voedingschema erbij:

U2 is een 3,3V regulator
- Voor de 3V versie is SJ1 open, en regelt U2 de 5V USB spanning terug naar 3,3V.
- Bij de 5V versie is SJ1 gesloten. De regelaar wordt overbrugt, en de 5V USB spanning gaat rechtsreeks naar naar de processor.

.

En dan hier een foto van m'n 5V Ali ProMicro:

De oscillator is 16MHz. Dat klopt.
Maar Switch J1 is open??? Dat zou op een 3V versie duiden......

Ik had de spanning al eens nagemeten: op de I/O pinnen staat echt 5V (Dat was voor een AR488, op de GPIB bus heb je toch echt 5V nodig...)

Nu er dus maar eens beter naar gekeken:
Wat blijkt: De Chinezen monteren voor U2 een 5V regelaar. De mijne heet S8VK, heb ik nergens kunnen vinden.
Die regelaar staat dus bij USB voeding continue wagenwijd open..... (Met overigens verbazingwekkend weinig spanningsval)

Als je alleen USB voeding gebruikt, kun je J1 dus beter dicht solderen.

.

Voor de GPS monitor maak ik wél gebruik van die 5V regelaar. Ik voed de RAW ingang met 5,3V, via een diode.
Door de dioden (D2 van de ProMicro en D7 van de GPS monitor) is er nu automatische omschakeling van voedingsbronnen. Omdat de externe voeding wat hoger is heeft die prioriteit als beiden aanwezig zijn. En door die 5,3V gaat U2 eindelijk doen waar hij voor gemaakt is: spanning regelen .

groet, Gertjan.

Hi Gertjan,

Dank voor de uitgebreide uitleg!
Nooit geweten dat een fabrikant van LCD displays ook nog varianten in kijkhoek had, altijd gedacht dat je dat alleen met de contrastregeling deed. Zo steek ik altijd weer wat op.

Ik begreep die “LCD = 128” niet, maar nu is het duidelijk. Ik had de link met het balkje in de TestController niet gelegd.

Die anti-dender heb je zo mooi in kaart gebracht en is een handige feature.

Ik vind jouw oplossing wat mooier dan alleen de 3D fix LED, vandaar mijn interesse.
Ik ben er eigenlijk altijd van uitgegaan dat als er eenmaal een 3D fix is het zaakje stabiel en dus betrouwbaar zou zijn. En dus nooit stilgestaan bij het feit dat slecht weer of iets anders roet in het eten kan gooien na de opstartfase. Dus tijdens metingen blijft het dus opletten en dan is jouw oplossing veel handiger dan alleen de 3D fix LED.

Dank voor het aanbod voor de software, is die al mature? (geintje… )
Ik ga je zeker een mail sturen!

Groeten, Rob

Op donderdag 16 januari 2025 19:36:35 schreef Jeroen:
Mooi project en netjes afgewerkt!
[...]
Ah, het not invented here syndroom. Ik besteed mijn tijd liever aan andere dingen, dan aan het maken van libraries die anderen al (beter) hebben gemaakt .

[ beetje off-topic ]
Ieders haar/zijn meug... Maar als ik het goed begrijp gaat NIH over het adopteren van ideeen, daar waar het enkel de implementatie is die ik liever zelf in de hand houd. Het idee van NMEA0183 vind ik prima, en ik ga er vooral niet proberen aan te tornen, het zou trouwens toch niet veel effect hebben.

@Miedema: dank voor de verwittiging over polyfuses, ik had altijd een stevig vertrouwen in die dingen, dat is nu flink bijgesteld!

Eigenlijk nooit zo over nagedacht. Maar dan bedoel je denk ik het lezen van het hele display. Want als ik bv naar mijn multimeter kijk en dan vooral naar het laatste deel wat verandert kan je dat wel een stuk vaker lezen.

Eens. Een paar digits kun je als mens vaker 'refereshen' - de ene beter dan de ander. Maar een 5-cijferig getal wordt al lastiger. Als in: laat er 5 in 1 seconden zien en vraag dan welke 5 het waren: er zal maar een enkeling de helft 'goed' hebben.

Het idee van NMEA0183 vind ik prima, en ik ga er vooral niet proberen aan te tornen, het zou trouwens toch niet veel effect hebben.

Te laat. Dat hebben al die mensen die zich er niet aan houden al gedaan

Ik neem aan dat bekend is waar NMEA voor staat. De spec is een redelijk geslaagde poging om ten tijde van de opkomst van allerlei 'dingen' die data kunnen spugen dat een beetje te standaardiseren zodat apparatuur van verschillende merken ook met elkaar kan praten. Dus vandaar: hoe de hardware in elkaar zit ligt vast, de bitrate ligt vast en het format van de data ligt vast. Als je 'wat anders' doet, dan zou het kunnen dat het goed komt, maar het hoeft niet. 4k8 is dus redelijk 'standaard'. 38k4 werd gebruikelijker met de komst van AIS transponders - 4k8 is te 'smal' om alle data er in te frotten. Toch is alle 'trage' apparatuur altijd op 4k8 blijven zitten, met wat merk-specifieke uitzonderingen.
Zelfs een GPS kompas kan met een refrsh rate van 10Hz nog op 4k8 werken. Alhoewel het inmiddels vaak ook sneller kan - waar niks op tegen is, als de ontvanger van de data dat ook lust. Nou ja, niks op tegen? Er zijn nog wel wat 'repeaters', 'isolators' of 'splitters' in het veld die tegen dezelfde problemen met een optocoupler opliepen als Gertjan. Op 4k8 zal het allemaal wel (of ze hebben het net zo lomp als ik destijds gedaan). Op 38k4 werken die niet meer of onbetrouwbaar.

In jachten land zet NMEA 2000 steeds meer door. Da's een heel ander beest. Persoonlijk zie ik de voordelen er niet zo heel erg van, maar dat komt waarschijnlijk door een technische insteek. Voor 'de leek' is het makkelijk om 'iets' ergens aan 'de bus' te hangen en meestal werkt 'het' dan. Meestal.

Dat met die spanningsregelaar op Arduino-achtigen: ik heb het een paar keer eerder gezien. Die controller wordt er niet nerveus van - die doet het ook wel op een heel klein beetje minder van 5V en dat is nog binnen spec ook. Voordeel is wel dat die spanningsregelaar mogelijk nog wat 'zooi' buiten de deur houdt als-ie niet overbrugd is.

Hi Gertjan,

Ondanks dat ik voorlopig nog niet ga bouwen kon ik het toch niet laten om alvast te kijken hoe ik jouw schakeling kan implementeren in mijn GPSDO ontwerp.
Omdat de GPS monitor in dezelfde kast komt pak ik het datasignaal rechtstreeks uit de Jupiter GPS ontvanger, (Tx) pin J1-11. Dan kan ik de hele gescheiden ingangscircuit wegbezuinigen, maar volgens mij ook de inverteromschakeltrap.
Kun jij dat zo bevestigen of wordt het gewoon proberen of het werkt?

Groet, Rob