De praktijk van het vorige schema.
Links de eerste versie en getest op Azimuth en goedgekeurd , rechts de nieuwere versie met minder brugjes en nog te testen op Elevatie.
Gebruikte MOSFETS:
P kanaal : IRF4905
N kanaal : IRLZ44N
Gate wordt aangestuurd via fotokoppelaars zo ben ik gescheiden tussen "vermogen" en het RPI gedeelte. Hierdoor is ook de levelshifter niet nodig.
Er zijn ook leds voorzien zo dat ik kan zien welke MOSFET er aangestuurd wordt.
Het schema:
Het is een normale configuratie . Enkel de clamping tussen de N en P kanaal MOSFETs is misschien niet zo bekend . Ik heb dit gedaan omdat de VgMmax niet zo kunnen overschreden worden , want dit is één van de oorzaken die een MOSFET doet sneuvelen . Dus is er een 7812 gebruikt in het "middelpunt". hierdoor kan de Vgs van het P kanaal niet lager worden dan 24 V - 12 V = 12 V. tov de source Langs de andere kant bij het N kanaal is er hierdoor ook maar 12 V positief tov de source mogelijk.
Veelal is VgsMax ongeveer 16V tot 20 V.
Door elke MOSFET apart aan te sturen ben ik baas over de sequentie . De logica voor deze aansturing is geen hardware maar zit in mijn soft.
De vier fotokoppelaars 4N35 hebben als voordeel dat er ook galvanische scheiding is en dat ik deze kan aansturen rechtstreeks uit de RPI . De levelshifter kan verdwijnen.
Let er goed op dat bij de P kanaal MOSFET de source ( S) aan de voeding ligt( 24 V) en dat deze bij het N kanaal aan de massa (24M) ligt. De drains vormen dus het brugpunt.
Zoals reeds eerder aangehaald heb ik na diverse pogingen met de LN298N deze piste verlaten en zelf een H bridge met MOSFETs gemaakt.
Ik had er nog een aantal op een oude print gevonden met twee P en twee N kanaals MOSFETs
Ideaal om een H bridge samen te stellen . De oude MOSFETs hebben wel nog een vrij hoge R-on weerstand maar om te testen kan dit geen kwaad . trouwens ik kan de spanningsval compenseren door de voeding te verhogen maar de dissipatie over de MOSFET blijft natuurlijk.
Elke tak van de H bridge stuurde ik apart aan , eerst met een gewone drukknop en defintief zal het met 4 fotokoppelaars worden , zo scheid ik beide spanningen én kan ik de levelshifter laten vallen .
Als proef op de som heb ik eens twee verkeerde MOSFETs in geleiding gebracht om te zien of deze wilden overleven . Ik heb natuurlijk wel de stroombeperking van de voeding ingesteld op 1 A maar de MOSFETs hebben het overleeft.
Ook de remmode getest en alles OK.
Zal later nog het schema bijvoeren maar hier alvast een snapshot van de testopstelling mét de fotokoppelaars.
Nog steeds problemen met de H bridge sturing.
Nu ik er zeker van ben dat deze niet ongewild wordt aangestuurd in een eventuele onbekende modus, ben ik eens in de datatsheet gaan kijken van de L298N.
(Had dit beter al vroeger gedaan !)
Deze zou 25 W kunnen dissiperen en volgens mijn manual van de rotor vragen deze maar 18 W . In principe zou dit voldoende moeten zijn .
Ik ga nog één poging wagen met deze H bridge en anders wordt het een zwaarder type of bouw ik hem zelf.
Wat ik een beetje over het hoofd heb gezien is dat door inertie de schotel bij het afschakelen nog effe doordraait . Hierdoor wordt de motor een generator en stuurt deze een emk terug naar de brug. Dit had ik trouwens ook al opgemerkt doordat de ledjes die parallel aan de rotor , met een dimeffekt uitdoofden en niet plots .
Dit effekt noemt men breaking of bij ons remwerking of remfase.
Dat doordraaien had ik ook reeds gemerkt bij het debuggen van de soft . Er kwamen nog tientallen pulsen door ná het afschakelen . Ik had reeds in de soft een variabele voorzien om hierop te anticiperen en zelfs uitgesplitst naar beide richtingen ( dus of ik van Oost of van West naar het punt kwam) en dit werkte goed .
Op internet , dit gevonden : http://www.bristolwatch.com/ele/h_bridge.htm.
Hier wordt de break functie uitgelegd , die bij sommige H bridgen kan toegepast worden en gelukkig ook bij de mijne.
Ik heb nu de soft aangepast en twee kleine motoren hier in de shack aangesloten op mijn electronica zodat ik kan kijken of het remeffekt ook daadwerkelijk plaatsvindt.
Eerst getest zonder remwerking natuurlijk en ook hier gingen de ledjes zachtjesaan uit. Met remwerking doven ze onmiddellijk.
Nu nog " in het veld" testen , hopelijk zijn de weergoden mij gunstig gezind.
Ik heb al enkele H brugjes opgeblazen.De laatste keer kon ik ook vaststellen dat dit gebeurde bij het manueel verplaatsen van de schotel.
Het sturen gebeurt gewoon met een drukknopje en daar zat geen ISR achteraan
ISR is een Interrupt Service Routine. Deze loopt " in de achtergrond" en verwittigt het hoofdprogramma dat er op die gedefiniëerde ingang een verandering is gebeurd , de zogenaamde "callback" . Dat kan zowel een positieve als een negatieve flank zijn naargelang de instelling én op alle voorzien GPIO dit in tegenstelling met een Arduino, één van de reden om voor RPI te gaan.
Ik heb deze nu ook laten lopen voor die drukknopjes .
Het resultaat was al een héél stuk beter , maar de ISR kan niet bepalen of de volgende flankverandering gewenst is of dat ze van een dendering van het contact komt.
Gelukkig zit er ook een glitchfilter in voor o.a. die ISR.
Deze heb ik ook mee in de soft genomen en het resultaat is goed .
Het bewijs ziet men op onderstaande foto:
Onderste trace is het schakelgedrag van het drukknopje, de bovenste is het bewerkt signaal met ISR en glitchfilter.
Het bovenste signaal is een direkte copy naar een uitgang hier speciaal voor geprogrammeerd met een ledje als visueel hulpmiddel en een methode om de oscilloscoop er aan te hangen.
Nog een paar mooie voorbeelden
Ondertussen wat testen gedaan en ook de parkeerpositie geschreven en getest.
Eerst waren er wat afwijkingen in de reproduceerbaarheid van de parkeerpositie , maar ik wijt dit aan het slecht monteren van een richtlaser in het focuspunt .
De laser verplaatste zich door het bewegen van de schotel
Hieronder de ( slechte) laserbevestiging , dit is laters verbetert en zit nu goed vast
De eerste metingen met de slechte bevestiging van de laser.
 |
| Spreiding meetpunten |
Dus hoe doe ik dat ?
Ik laat eerst de parabool kalibreren op het punt OOST en op zijn laagste elevatie ( 10°). Deze punten preset ik met een bepaalde waarde ( voorlopig 18000 en 16000).
Daarna laat ik de schotel rijden naar een bepaald punt in het azimuth . dit punt noem ik de parkeerpositie omdat deze positie mij toelaat om gemakkelijk aan de parabool te werken .In het verlengde van die parkeerpositie bevindt zich mijn gastank. Hier kleef ik een etiket op en laat de parabool meerdere malen vanuit de kalibratiepositie naar dit punt rijden.
U ziet de spreiding van de metingen ( hier slechts 3).
Als ik met driehoeksmeetkunde uitrekent hoeveel dit is in graden kom ik aan < 1°
Ik neem eigenlijk wat extra want het was in werkelijkheid 0.7°.
Dan komt nu de vraag : is dit nauwkeurig genoeg om in eerste instantie de maan te volgen ?
Hiervoor moet ik de openingshoek berekenen van mijn schotel bij 2.3 Ghz, want daar zitten enkele signalen van wat er rond en naar de maan vliegt.
Dit kan met de volgende formule , dit is de openingshoek bij -3dB.
 |
| De -3dB openingshoek formule |
Voor 2.3 GHz ( 6.5 °) valt dit reuze mee . Ik vermoed wel dat ik deze moet halveren omdat de fout zowel links als rechts van de lobbe kan gemaakt worden .
Voor 8.8GHz wordt dit kritisch , ik moet een reproduceerbaarheid hebben van de helft van 1.7° dat is 0.85 ° ! om het onderste uit de kan te kunnen halen .
Bij mijn nieuwe laseropstelling is de spreiding beter. De laser kwam steeds juist op een gemarkeert zwart bolletje terecht
Ik heb 10 metingen genomen volgens bovenstaande procedure . De waarden zijn wat de pulsgever mij telkens gaf op de terminal van de RPI.
Als ik mag geloven wat de producent van de rotor beweert is elke unit slechts 0.01 °.
Ik ga dit eens uitproberen door twee metingen te doen met bv 100 punten verschil.
Dit zou dan op mijn etiket een afstand tussen deze twee punten moeten geven die na omrekening inderdaad 1° verschil maakt
Het etiket hangt op 4m en met behulp van een tangens is dit gemakkelijk te doen.
Niet volledig perfect maar toch nauwkeurig genoeg.
Hé , he
We zijn terug op punt waar alles werkte , ttz de manuele sturing en de kalibratie zijn terug OK.
Ik heb ook de code heel wat kunnen uitzuiveren , dwz, ik doe nu precies hetzelfde met minder code !
Als het dit weekend goed weer is , zal ik alles nog eens aansluiten en testen in het "veld".
Ondertussen ook wat hardwarematig omgebouwd en de RPI voorzien van een behuizing die op een symmetrische rail kan geklikt worden , tesamen met de I/O.
En ja , ik heb nu een ( dubbele) backup van mijn sourcefile 🤭
Misschien kent U dit gezegde niet maar " het is van de hond"
Ik ben 90 % van mijn soft kwijt door mijn eigen schuld. Had ik maar een backup genomen !
Het kaartje in de RPI is stuk gegeaan . Er was een kleine crack overlangs en de sd kaart was naar de Filistijnen !
TIP : als U uw eigen RPI opstart en U ziet het groene ledje vier maal pinken in een herhalende sequentie , mag je denken dat ook Uw sd kaartje eraan is .
Gelukkig heb ik nog mijn flowcharts met mijn gebruikte prototypes van de funkties .
Dit is toch een kleine hulp bij het herschrijven van de soft.Misschien pak ik het wel anders aan ?
Het heeft wat voeten in de aarde gehad maar uiteindelijk ben ik er in geslaagd om hier op de broodplank een automatische kalibratie te simuleren .
In principe is het simpel , kijk waar ge staat met de schotel en rijdt tweemaal naar de kalibratiepunten , eenmaal voor elevatie (EL) en nogmaals voor azimuth( AZ).
Eénmaal de kalibratiepunten bereikt , preset de tellers en klaar is Kees ( in dit geval Luc).
Alles is geschreven in C op de raspberry pi . Géén C++ want hierover is nogal wat onduidelijkheid . Het is gewoon " platte" C , ik werk dus niet met klassen.
Ik werk wel met de PIGPIO bibliotheek, zie pigpio
In de soft van de RPI is er ook een simpel , maar goed bruikbaar IDE aanwezig.
Geany is de naam.
Deze bevat naast de editor ook een mogelijk om te compileren en/of builden en direkt het programma te starten. Tevens kan men ook een terminal oproepen en heeft men in de linkerzijbalk een overzicht van alle variabelen , functie s, macro's enz..
Ik heb ooit in school C gehad , met wat "schooloefeningen" , maar ik heb toch serieus moeten bijstuderen om het weer onder de knie te krijgen . Op een gegeven moment kunt ge niet zonder pointers werken en dat was toch weer een hindernis . gelukkig is alles terug goed gekomen . Ook met interrupts werken en de daarbijhorende callbacks was effe doorslikken .
Uiteindelijk heeft het mij veel geholpen om flowcharts aan te maken , dit geeft meer inzicht in de code.
Enfin , de auto-kalibratie werkt en nu wordt het uittesten in werkelijkheid . Ik moet dit nog steeds buiten doen , dus het mag stoppen met regenen .
De volgende stap is een sequentie schrijven om hem naar een parkeerplaats te brengen. Dit is de positie van de schotel waar ik dan gemakkelijk toegang heb om er aan te werken.
Dit is , en dankzij vrij goedkoop, een must-have als je wat antennewerk wilt doen op SHF gebied . Het spul " loopt" tot 3 GHz en dit op de echte carrier , niet op een harmonische.
LET OP ! Er is veel kaf tussen het koren .De mijne komt , zonder reclame te willen maken , van deze site
Zal van pas komen bij verdere bouw van antennes op 2.4 GHz
Heb ook de helical van de parabool eens terug uitgebouwd en gemeten .
Zat er een beetje naast en het is echt wel zoeken naar de juiste afregeling .
Maar uiteindelijk goed gekomen .
Nu is ook pas te zien wat de ingangsimpedantie is en de reflectiecoëfficient of de SWR wat in feite hetzelfde is.
Enkele foto's.
 |
| De helical waarvan sprake onder test |
De metingen :
1. Return Loss -33 dB
2. SWR 1.03
3. Z: 51.4 Ohm -j 1.23
4. F = 2.4GHz
Bij benadering van mezelf of een blik zie je de impact van de beïnvloeding , eenmaal verder dan een meter is dit nog nihil.
Omdat ik nog meer moet kunnen simuleren is er nog wat uitbreiding bijgekomen .
Zo ben ik nu soft aan het schrijven om de parabool een kalibratie procedure te laten uitvoeren indien alles wordt opgestart of eventueel indien het nodig geacht wordt.
Om de sequentie te kunnen nabootsen zijn er twee schakelaars toegevoegd die de microswitchen in de rotor voorstellen.
Hiermee kan ik dan volgen wat er in de soft gebeurt.
We zitten nu al aan ongeveer 1000 regels C code ( met witruimte erbij natuurlijk) en dan is de gewone sturing nog niet aanwezig.
Dit verklaart ook waarom het de laatste tijd hier nogal stil was op de blog.
 |
| Het schema met de dual bridge rechtsbovenaan |
