ADSN [ 125: Software verfijningen]

Poosje hier niet geweest en met reden.

Elk nieuwjaar beloof ik mezelf om mijn soft eens aan te pakken .

Let wel , het heeft altijd gewerkt maar er waren nog wat platte kantjes aan het wiel.

Zo kon ik met de server van  de RPI connecteren en alle commando's doorvoeren , maar als ik de client afsloot , kon ik niet meer herconnecteren of ik moest rebooten .

Internet afgezocht en iedereen heeft een antwoord " op papier" . je voelt zo aan dat er veel doorgecopieerd wordt  en zichzelf daar mee belachelijk maakt.

Ik heb het stukje soft van de server  apart genomen en testen gedaan met putty als client en hierdoor is het één en ander duidelijk geworden .

Na wat dieper onderzoek op het internet ( ja dan toch) kwam ik iets interessant tegen . Je moet niet uw socket sluiten maar voordien ook je filedescriptor én je moet ook aangeven aan je socket dat je het opnieuw wilt gebruiken (SO_REUSEADDR).

Dus opgelost en ik blij.

Tweede probleem.

Tijdens het aansturen van de rotor(en) moet ik met een lus werken omdat ik de sturing van de H-bridgen zelf doe. Ik gebruik geen ( latch)  relais , dus ik moet de b rotor blijven aansturen totdat de positie is bereikt.

Dat geeft consequenties : u kan ondertussen niets anders zien of doen.

Ik moet ( nou ja , ik wil) tijdens het aansturen ook de actuele posities terugsturen naar de client zodat er visueel laters iets te beleven valt.

Hiervoor moest ik eerst het programmeren van threads onder de knie krijgen . Dat is gelukt in de nodige mate.

Ik heb ook nog een stukje soft bijgeschreven dat dit pas elke graad gebeurt zodat er niet teveel overhead is.

We zijn al een héél stuk verder . Nu nog de client side visueel iets fabrieken .

Dit zal ws met Python en PyQT zijn . weeral leren geblazen.

ADSN [ 32 : Gpredict en het uitvlooien ervan]

Nu de hardware blijkt te werken wordt het tijd om de schotel automatisch te laten sturen door  een programma.

Uiteindelijk, en als eerste toepassing, zou ik de maan willen volgen .Echter ik heb nog geen gepaste software daar voor gevonden , ttz ik heb er één maar dit moet nog uitgebreid uitgetest worden .

Neen , het is simpelder om eerst een bekend werkend programma te gebruiken en kijken of ik een satteliet of bv het ISS kan tracken weliswaar in mijn bereik van de  zuiderlijke  hemisfeer.

Hoe het één en ander aan elkaar moet geknoopt worden heb ik in een blokschema gezet.

 

 

 Het was lange tijd zoeken hoe nu Gpredict zich gedroeg.

Was het nu een server of een client ? Wat was het protocol en moest ik nu HAMlib gebruiken of niet ?

Door wat te snuisteren op Github in de sourcen van Gpredict kwam ik erachter dat het een clientmodel was en dat deze de letter commando's van Hamlib nabootste maar dat Hamlib niet echt nodig was .

Gpredict gebruikt wel de standaardpoort van Hamlib zijnde 4533 en het protocol is TCP/IP

Hamlib KAN je gebruiken als je een interface wilt tussen een bekende rotor ( bv ene van Yaesu) en de bestaande controller ervan , maar daar ik hier alles zelf heb samengestoken , doe wat ik wil.

Ik moet nu een server socket schrijven op de RPI en luisteren op inkomende clientaanvragen , in dit geval enkel en alleen van Gpredict.

Eénmaal de connectie tot stand gekomen ( wordt allemaal afgehandeld door de socket) kan ik in mijn eigen RPI soft de letter commando's verwerken en antwoorden sturen naar Gpredict.

De eerste testen zijn al gebeurd en na wat zoekwerk hoe nu juist die lettercommando's moesten doorgestuurd worden zijn deze premature testen veelbelovend.

Volgende keer , de instellingen langs de Gpredict kant en over de firewall.

ADSN [ 26 : De software : deel 6 --> Hbridge perikelen]

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.

ADSN [ 25 : De software : deel 5 --> het glitch filter]

 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

 

 

 

ADSN [ 24 : De software : deel 4 + uitgevoerde testen]

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.

ADSN [ 23 : De software : deel 3]

 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 🤭

ADSN [ 22 : De software : deel 2]

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 ?

ADSN [ 21 : De software : deel 1]

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.