donderdag 31 december 2020

ADSN [ 45 : Link Budget , nog wat cijfermateriaal]

Ik moet toch nog het één en ander opzoeken vooraleer ik me toch een gedacht kan vormen hoe dat nu zit voor de gevoeligheid van de LNA. Ruis is in normale omstandigheden altijd aanwezig . Het hoeveel ervan in mijn frequentiegebied is hetgene is toch zou moeten te weten komen. Mijnheer Nyquist en Johnson en met bijdrage van Mijnheer Boltzmann hebben dit uitvoerig bestudeerd. 

 Uit wiki : Noise

 

 

Blijven we bij de extreme smalle bandbreedte ( BB ) van 10 Hz , dan zou een weerstand bij die  BB een ruisvermogen opwekken van - 164 dBm, bij 300°K.
Alle signalen die dieper liggen dan  dat ruisniveau zal voor mij niet te ontvangen zijn. Signalen erboven ( dus minder negatief) dan wel.
Ik zou bij een  BB van 10 Hz van ON0EME een signaal mogen verwachten aan de LNA van - ca 161dBm , dus 3dB boven mijn ruisniveau.
 

 
Wat zegt  EMEcal  over dat ruisvermogen ?:





Hierbij een berekening ( simulatie) waarbij  ik de system noise temp ingesteld heb op 300°K en de BB op 1 Hz . Alle andere faktoren zijn op 0 ingesteld.

Hierbij is de uitkomst:    -173.82 dBm.

Dit komt dus overeen met de tabel van wiki . Dit bevestigt dus de goeie berekening van dit programma en kunnen we dit met gerust gemoed verder gebruiken.

 

Hetzelfde voor BB van 10 Hz, waarden kloppen ook.

 


 

Nu wordt het interessant.

De 300°K is een parameter voor het ruisvermogen . Echter de parabool "ziet" geen 300°K maar een veel lagere temperatuur afhankelijk hoe hij kijkt .

Daarvoor zijn er in te vullen velden voorzien om dit te compenseren en hiermee wordt de gevoeligheid van het ontvangstsysteem verbetert.

Dit is dus een pluspunt. Volgende maal simuleer ik de NF en Gain van de eerste préamp , de LNA dus , en de invloed ervan op onze gevoeligheid.

 



woensdag 30 december 2020

ADSN [ 44 : Link Budget , de interpretatie ]

 

System Sensitivity


Een poging tot interpretatie van de EMEcalc berekeningen .


Ik heb berekend hoeveel EIRP nog in " mijne hof " terecht komt na de ping pong met de maan.

Dit zou ca -214dBW  zijn . Na de gain van mijn parabool en omzetting naar dBm 

kom ik aan een signaal van  ca -161 dBm . Ik noem dit EIRP aan de LNA.

Eigenlijk uit de helical maar deze is rechtsreeks ( met één connector) verbonden met de LNA 

Nu wat betreft de gevoeligheid van mijn RX setup.

Volgens hetzelfde programma kunt ge ook uw RX gevoeligheid berekenen.

Dit is natuurlijk  afhankelijk van de gewenste bandbreedte , hoemeer bandbreedte hoe meer ruis en de verhouding verandert met 3dB bij dubbele bandbreedte of 10 dB bij een decade meer ( tienvoudige) .

Dus als ik héél smal zou kunnen " kijken" naar de cw signalen van ON0EME , zeg 10Hz , dan zou ik deze moeten kunnen detecteren bij mijn setup van Helical en parabool en  met een LNA van 28 dB en een NF van 1.25 dB .

Nu nog eens mijn LNA aan de tand voelen en versterkt mijne LNA wel op zo'n laag niveau ( -161,68 dBm ) ?

dinsdag 29 december 2020

ADSN [ 43 : Link Budget , een poging tot berekening ]

Ik heb nu een 23 cm helical en ik heb een LNA liggen ,maar kan ik nu ON0EME ontvangen ?

Hiervoor moet er een inschatting ( berekening ) gebeuren hoeveel er van dat vermogen er nog in mijn tuin te verwachten is .

VK3UM heeft hiervoor EMEcalc geschreven en is zowat het standaard werk geworden .

Het is nogal wat zoeken en het draait normaal onder Windows , maar Wine kan er ook overweg mee.

Van ON0EME heb ik wat gegevens kunnen opvissen en die staan netjes in het rekenblad. Mijn gegevens zijn natuurlijk ook bekent.

Hier een voorbeeld .


Ik hoop dat het nog te lezen is .Klikken op de foto opent deze in een groter formaat.

In de purpere kaders zijn de gegevens van ON0EME ingebracht. In de rode , mijn gegevens.

Dit is een budget berekent voor een bandbreedte ( BB) van 100Hz. Dit kan met een SDR normaal ingesteld worden . U ziet dat ik dan een SNR krijg van  -2.83 DB , dus toch nog in de ruis .

 

Als ik hetzelfde doe voor 50 Hz en voor 10Hz dan wordt het een stuk beter.

SNR voor 50 Hz


SNR voor 10Hz

Dit laatste is al een stuk boven de ruis en zou een plaatje kunnen opleveren .


Ik zit nog met één zwart gat dat ik niet goed weet hoe ik het moet interpreteren.

De System Sensitivity is hierbij -167.6 dBm.

Dit zou willen zeggen dat ik zo diep in de ruis kan "kijken" .

Echter , kan mijn RX ( LNA + SDR)  setup dat wel ?


Nog een apart plaatje van de de RX setup.



zaterdag 19 december 2020

ADSN [ 42 : Helical 23 cm--> De bouw en metingen ]

Ik heb " snel" een prototype gebouwd volgens de berekeningen zoals hiervoor gepost. Ik heb lang nagedacht of ik de helical zou ondersteunen en ik heb het toch maar gedaan met een nylon stud.

Deze staat op ca een halve golflengte van het voedingspunt. Ik weet niet of dit een juiste keuze is of niet maar ik was een beetje genoodzaakt omdat de stud een ingegoten bout heeft en ik wou daar toch een eindje vanaf blijven .Na een halve spiraal zit je ongeveer ook een halve spoedstap boven de massa.

Het materiaal voor de helical zelf moest ca 4.6 mm diameter zijn en dat is al wat.

Dit zou kunnen met een electriciteitsdraad van 16mm² maar dat had ik niet en is ook niet zomaar in een bouwmarkt te vinden .

Omdat ik om een andere reden naar een auto-onderdelen winkel moest heb ik vandaar 4.75 mm remleiding meegebracht . Dit zijn dus dunne buisjes , stevig genoeg en toch met de hand plooibaar.

Hieronder een foto , genomen halfweg de montage.



De spiraalwindingen komen op de juiste afstand dmv een malletje uit een aluminium plaatje.

De jampot is mijn " doorn" om op te wikkelen . Neem wel een model dat enkele mm dunner is dan het uiteindelijk resultaat , want de spiraal heeft de neiging om zich wat te "ontplooien".

Het blik wordt mijn reflector en is al voorzien van de nodige gaten.

 


 

Eerste metingen in huis waren nogal verwarrend . Toen heb ik het opgesteld met een radiator die de parabool moest voorstellen ( reflecterend vlak), en toen kwam alles duidelijk .

Het verschuiven van de afstand gaf duidelijk andere waarden maar plausibel.

Toen heb ik de helical opgesteld even ver als hij in de parabool zou hangen en dat was veelbelovend.

Eénmaal in de parabool kreeg ik goeie waarden en na wat aan de helical te friemelen  had ik plots mooie waarden .

Ik had een driehoeksvaantje aangebracht aan het eerste kwart van de winding om deze af te regelen . Dit heeft echt wel impact maar ik moest het vaantje bijna helemaal rond het buisje aanplooien om dit mooi resultaat te krijgen .



Dit zijn de waarden . Een mooie dip op ca 1296 MHz met een reflectiecoëfficient

van - 36 dB ! Dit zijn héél mooie waarden . Ik hoop dat ze waar zijn .

En ja de VNA was eerst genormeerd met open , gesloten en afgesloten toestand.

Ook de lengte van de meetkabel is meegenomen in de normering ( zoals het moet !)


De imp komt héél dicht in de buurt van 50 Ohm met een beetje capacitieve load erbij. Het rode bolletje op de Smith kaart komt dicht bij het middelpunt .


Als ik nu nog mijn LNA vind kan ik beginnen testen .


PS: Blijkbaar is dit  mijn 500ste post!

dinsdag 15 december 2020

ADSN [ 41 : De polarisaties bij EME en Deep Space ]

 Voor mezelf om te onthouden (en eventueel voor anderen)


Deeps Space is hoofdzakelijk RHCP (de oude voyagers daarentegen zijn LHCP)

EME is RHCP voor TX en LHCP voor RX.

Info tnx ON7UN


Dus de polarisatie voor  mijn helical voor EME RX moet  dus RHCP zijn omdat de paraboolspiegel deze bij reflectie omdraait en zo LHCP komende van de maan kan ontvangen .

Is maar een weet ,maar kan grote gevolgen hebben !

maandag 14 december 2020

ADSN [ 40 : Helical 23 cm ]

 Zoiets moet het worden :


 

Met dezelfde uitgangsparameters als voor Oscar 100
 
Openingshoek op - 3dB van ca 77 °, komt ongeveer overeen met ca 136° bij -10dB
3 windingen.
 


ADSN [ 39 : Tweesprong nr 2 ]

Er is nog een mogelijkheid .

Ipv op 13 cm zouden we ook eerst op 23 cm kunnen testen .

Hier in ON land staat er een baken die de maan als target heeft en regelmatig in de lucht zit.

ON0EME is de naam en hier is er een link naar toe.

ON0EME


De status en wanneer het baken operationeel is kan men hier bekijken .


status ON0EME


Hier een afbeelding


Het baken komt in de lucht wanneer zich deze 10° boven de horizon bevindt.

Er is nog een voordeel om dit te kiezen.

Als ik een helical maak met hetzelfde uitgangspunt als diegene die ik gemaakt heb voor Oscar 100, dan kan ik rechtstreeks en m.b.v. een LNA rechtstreeks testen op een SDR dongle , want die gaan tot een goeie 1700 Mhz.

Dit is een mogelijkheid die snel is te verwezelijken .



zondag 13 december 2020

ADSN [ 38 : Tweesprong ]

 Nu sta ik op een tweesprong.

Doe ik eerst verder met de software langs de client kant of probeer ik eerst "iets" te vangen op  2.2GHz met de parabool en zijn autotracking.

Ik kan de client die ik wil schrijven nog opzij laten en het skytrack/radecl programma gebruiken om te tracken .Dit is al uitvoerig getest en na enkele softwarefoutjes ( die ik doorgestuurd heb als pull request naar Github en die door de auteur is aanvaard) voldoet deze soft voor de eerste testen meer dan genoeg.


Aan de andere kant heb ik al ervaring met de ontvangst en zenden naar Oscar 100.

Deze zit op een iets hogere frequentie ( nl 2.4GHz) en de zelfgemaakte helix werkte goed.

Dus ik zou een nieuwe helix kunnen maken met dezelfde bouwvorm en in de parabool plaatsen 

Tweede mogelijkheid is eens de MMDS down convertor te testen .

Er zijn veel modellen op de markt en ik weet niet precies wat zijn juiste ingangsfrequentie-bereik is maar dat kan ik mss wel uitvlooien.

De antenne moet ik mss wel ombouwen om de juiste afstralingshoek te krijgen en ik hoop als deze goed werkt ik ook de GPSDO kan inkoppelen.

MMDS Lo = 1998 MHz

Derde mogelijkheid is enkel bouwstenen aan elkaar te koppelen zoals een antenne met een LNA4ALL of een Chinees  , een mixer van mini-circuits zoals de ZX05-30W-S+   of een Chinees enz ...

Dan moet ik wel nog een hoog mixsignaal hebben en dat weet ik niet zo direct.

 

 



Vierde mogelijkheid is de Adalm Pluto .


Deze laatste twee zouden dan al moeten ingebouwd worden in iets dat het slechte weer kan trotseren . 


Ik denk dat ik eerst toch maar eens de MMDS onder handen zal nemen en dan heb ik iets om te luisteren . Is het echt geen weer om aan de parabool te werken dan kan ik stilletjesaan de clietn soft ontwikkelen.

maandag 7 december 2020

ADSN [ 37 : RaDecl ]

Van dezelfde auteur en in hetzelfde pakket zit er ook radecl.py

Dit doet ongeveer hetzelfde als Skytrack maar je moet zelf de coördinaten ingeven om het object te tracken .

Interessant aan deze oplossing is dat je dan nieuwe objecten , zoals een net gelanceerde missie naar mars of de maan kunt volgen .

Waar haal je dan de juiste info hierover?

Wel JPL is een vaak bevraagde website of je snor ze op bij een of andere twitteraar.

Het is Ra en Dec dat je moet hebben en het programma berekent dan voor U de juiste AZ en EL gegevens voor je meegegeven  positie in LAT en LONG formaat.

Ra staat voor right ascension en Decl voor  declination .

De referentie is hier het punt wanneer de 0° meridiaan gekruist wordt (Ra) en op welke hoogte (Dec)

Voorbeeld van de JPL horizons website


Website : https://ssd.jpl.nasa.gov/horizons.cgi#top

Ik heb hier de MOM Mars Orbiter Mission gedownload .

Men krijgt dan iets zoals dit : ( is wel maar een extract)

Table format    : Comma Separated Values (spreadsheet)
*******************************************************************************
 Date__(UT)__HR:MN, , , R.A._(ICRF), DEC__(ICRF),
*************************************************
$$SOE
 2020-Dec-07 00:00, ,m, 01 06 42.75, +07 16 29.0,
 2020-Dec-08 00:00, ,m, 01 07 35.04, +07 23 39.3,
 2020-Dec-09 00:00, , , 01 08 33.52, +07 32 46.3,
 2020-Dec-10 00:00, , , 01 09 36.74, +07 40 49.8,
 2020-Dec-11 00:00, , , 01 10 36.06, +07 48 54.8,
 2020-Dec-12 00:00, , , 01 11 41.99, +07 58 49.7,
 2020-Dec-13 00:00, , , 01 12 49.02, +08 06 35.0,
 2020-Dec-14 00:00, , , 01 13 55.04, +08 15 26.3,
 2020-Dec-15 00:00, , , 01 15 09.22, +08 26 15.0,
 2020-Dec-16 00:00, , , 01 16 18.65, +08 33 35.1,
 2020-Dec-17 00:00, , , 01 17 31.03, +08 43 07.5,
 2020-Dec-18 00:00, , , 01 18 51.53, +08 53 22.1,
 2020-Dec-19 00:00, , , 01 20 04.58, +09 01 41.8,
 2020-Dec-20 00:00, , , 01 21 23.06, +09 11 51.5,
 2020-Dec-21 00:00, , , 01 22 46.91, +09 21 37.6,
 2020-Dec-22 00:00, , , 01 24 05.77, +09 30 47.0,
 2020-Dec-23 00:00, ,m, 01 25 30.13, +09 41 31.6,
 2020-Dec-24 00:00, ,m, 01 26 56.89, +09 50 55.3,
 2020-Dec-25 00:00, ,m, 01 28 21.15, +10 00 42.6,
$$EOE
*******************************************************************************

Als je deze data( enkel ra en dec ) meegeeft als argumenten bij de opstart van het radecl.py programma, tesamen met uw lat en long berekent deze de juiste AZ en EL en stuurt ze door naar uw rotorcontroller.

 

Voorbeeld syntax op programma te starten 

python3 radecl.py --lat=51.2227 --long=4.0227 --altitude=5 --ra=01h06m42s --dec=07d16m29s --delay=10 --rotor=192.168.xxx.xxx:4533

Elke 10 sec een nieuwe setup voor de rotor

Het wordt alleen maar leuker !

zaterdag 5 december 2020

ADSN [ 36 : Skytrack ]

 Volgend hoofdstuk.

Het tracken van de maan ( of andere hemellichamen ) vanuit de shack.

Hiervoor is  een Python software gevonden op Github die aan de meeste volwachtingen voldoet, nl skytrack.

Skytrack


Spijtig liep alles niet van een leien dakje omdat er nog wat foutjes inzaten .

Ook moest ik nog twee bibliotheken installeren die ik nog mistte , maar dat was snel opgelost.

Op te lossen met :


pip3 install skyfield

pip3 install tzlocal.

 

Toen ik echter ook nog de limieten meegaf waar de rotor niet voorbij mocht gaan , kreeg ik telkens een foutmelding.

Gelukkig is wat na try and error ook dat opgelost.

Het was een vergelijk tussen een string  en een float en dat kan nie! 

Bijgevoegd een afdruk van het terminalscherm waarbij ik Mars aan het tracken ben , bij afwezigheid van de maan.


Ik hoop deze avond op helder weer , want na 21h20 komt de maan te voorschijn.

Ben benieuwd of alles een beetje klopt.

Laters hoop ik deze software in een GUI te plaatsen , zo dat  alles wat netter is.


23 okt 2021.

Bij een install op een andere laptop heb ik ook nog volgende pythonmodule moeten installeren met:


pip3 install astropy


 



zondag 29 november 2020

ADSN [ 35 : Gpredict+ RPI + rotor --> Succes !]

Eindelijk is het zover !

Na errors in de  code , segmentation faults, NULL pointers is het systeem eindelijk werkend .

De C code bestaat uit 2290 regels code ( met witruimte erbij gerekend) en 24 zelfgeschreven functies . Aan de declaraties van alle variabelen ben ik niet eens begonnen met tellen .

Er zijn nog enkel kleine akkefietjes , zoals het vrijgeven van de socket bij ongeoorloofd afsluiten , maar dat is meer een praktijkfout dan wat anders.

Gisteren heb ik de CHANG'E5 getrackt , dit is de Chinese satelliet die ondertussen aangekomen is aan de omloopbaan van de maan . Hiermee was ik in feite ook de maan aan het tracken , wat uiteindelijk mijn eerste bedoeling zal zijn.

Ik heb echter nog geen echt maantrackings programma , dat wordt dus de volgende stap. De H bridgen houden het zonder verpinken uit , dit was een probleem bij de aangekochte modules , maar de zelfgebouwde werken prima.

Ik heb al zekers 100 keer een kalibratie uitgevoerd . Het is te zeggen de soft heeft dat gedaan omdat ik een automatische kalibratie laat uitvoeren bij het opnieuw opstarten van de RPI nadat er weer een verbeterde versie ingeladen was.

Ook de omloopsatellieten zijn te volgen , enkel wel in de zuidelijk hemisfeer maar de rotoren kunnen de snelheden aan. Dit was meer een test , is geen uiteindelijk doel.

Ik heb wel vastgesteld dat ik in het begin een deel van het maanvolgen mist omdat de maan vroeger of het echte Oosten (90°) opkomt . Dus overweeg ik om de schotel van bv 70° en tot 250 ° te laten werken ipv van 90 ° naar 270° . Mijn Westen kant wordt toch een deel geblokkeerd door mijn huis.

Dit was het voor vandaag.

vrijdag 20 november 2020

ADSN [ 34 : Gpredict : rotatorcontroller]



Hier een overzicht hoe de rotatorcontroller in Gpredict eruit ziet en wat ge er met kunt.


Nadat uw Gpredict is ingesteld en ge modules hebt aangemaakt kunnen we verder.

Mijn modules hier zijn SpaceX;Starlink9;wx en Amateur.


Helemaal aan de rechterkant en bovenaan vind ge een minuscuul driehoekje .

Dit doet een keuzemenu open en daar kies ge < Antenna Control>.

U krijgt dan de volgende afbeelding te zien.




In de twee rode kaders zijn de target AZ en EL  te zien , ze staan nu grijs want de tracking staat aan .

Daaronder in de lila kleine kaders ziet ge " Read " en een hoek staan . Dit zijn de waarden die dit menu terugkrijgt en is de actuele stand van uw rotor.U ziet bij AZ dat dit niet overeenkomt . Target zou 57,86° moeten zijn en dit is kleiner dan 90°. 

Dit is  bij mij verboden gebied en wordt dan ook niet gehaald. Bij EL zijn de waarden wel gelijk.

Ook is er boven en onder elk digit een klein driehoekje te zien , hier kunt ge manueel een hoek kiezen en doorsturen naar de rotor.( zie verder)

De twee lila pijltjes laten een cirkel en een kruis zien op de radarplot. Dit is interessant want de cirkel geeft uw rotor positie aan en het kruis de positie van in dit geval de KAITUO 1A satteliet. Als uw tracker goed werkt dan zal het kruis zich precies in de cirkel bevinden . Bij mij hier  dus niet door mijn grensgebieden.

Verder zien we nog een aantal velden rechts waar ge kunt instellen om de hoeveel msec ge wilt dat er een update van de gegevens gebeurt en wanneer dit moet gebeuren , maw hoeveel graden mag de satteliet al verplaatst zijn voor er een nieuw bericht naar de rotor gestuurd wordt.Verder is ook uw gegeven naam van de verbinding te zien of alleszins te kiezen ( ADSN)

Met de knop <Engage> start ge uw TCP verbinding op. deze moet ook aktief staan vooraleer ge daarna de <track> knop wilt gebruiken

 In de velden links daarnaast kunt  ge uw satelliet  kiezen en daar worden ook de actuele AZ en EL waarden meegegeven . Wilt U deze satteliet volgen dat moet ge op de knop < Track>  klikken.


Indien ge enkel de <Engage> knop hebt gebruikt, dan ben je in de mogelijkheid om manueel dmv de driehoekjes bovenaan uw rotor te sturen , bv voor een test of om hem eens af te gaan kuisen 😀.

Let op ,ook hier beperkt uw vorige instelling in de config dat ge niet buiten uw werkdomein kunt komen !

Het gebruik in manuele mode , kan enkel als <Engage> is ingedrukt .De cijfers zijn allemaal zwart en de driehoekjes zijn bruikbaar.

U ziet dat de wenswaarde en de gemeten waarde perfekt overeenkomen.

Nog een afbeelding waarbij de satelliet en de rotor perfect in sync staan . De cirkel omschrijft perfect het kruis.



Dit was het voor vandaag.

ADSN [ 33 : Gpredict en Firewall : de instellingen]

Hierbij de instellingen voor Gpredict.

Deze draait normaal op een  PC  in huis (zoals bij mij) en bevindt de RPI zich op een andere plaats , bv in het tuinhuis ( ook zoals bij mij).

Gpredict heeft enkel instellingen nodig bij eerste gebruik , zoals uw positie enz , maar dat vind ge allemaal op internet of op YT.

Waar het hier overgaat zijn de instellingen voor de rotorcontroller.

We maken immers gebruik van de mogelijkheid om via ethernet en het TCP/IP protocol te praten met de RPI. Hiervoor zijn enkele instellingen nodig.

Gpredict

1. Via <Edit> en <Preferences> kom je in de instellingsmenu terecht.




Kies daar <Interfaces> en vervolgens <Rotators> en daarna onderaan < Add New>.


2. Er komt een nieuwe menu te voorschijn. " Edit rotator configuration".

3. Geef een bijpassende naam aan uw configuratie , bij mij is dit ADSN

4. Geef uw IP adres in van de RPI in deze vorm xxx.xxx.xxx.xxx  . 

  x is hierbij een cijfer van uw LAN  , veelal beginnend met 192.168 of soms ook 10.1.xxx.xxx.  Het IP adres van uw RPI is op uw RPI te vinden of ge typt  ifconfig in op de terminal van de RPI. Zoek naar eth0 bij een vaste verbinding of naar wlan0 voor een WiFi verbinding.

5. Port is 4533 , dit staat vast als standaard ingesteld . Mag verandert worden als je weet wat je doet.

6. Daaronder staan nog velden om in te vullen wat je rotors aankunnen . Bij mij kan ik enkel tussen 90° en 27O° werken ( Oost naar West) en van 10° naar 50 ° elevatie . Ik zie dat mijn minimum elevatie hier dus nog verkeerd staat.


Daarna op <OK> en uw configuratie is gedaan.


Firewall

Om de communicatie over uw huiselijk LAN te laten verlopen moet ge ook uw poort 4533 nog vrijgeven . Dit wordt gedaan op uw plaatselijk PC ( dus niet in de router, omdat ge niet naar internet buiten moet ).

 

Open firewall ( OS afhankelijk) . Ik heb Linux,  dus bij mij ziet er dit uit als volgt. 

Dit overzicht is nadat ik de regel heb toegevoegd.  U ziet dat zowel voor IPv4 als voor IPv6 er regels voor poort 4533 is aangemaakt. 


U kunt dit zelf doen door eerst te klikken op < +> onderaan.


Daarna krijgt ge een nieuwe menu en kies ge voor de < Eenvoudig> tab.



Vul de velden in zoals bovenstaand en klik op de < + ADD > knop.

Uw firewall is nu ingesteld en kunnen er TCP verbindingen gebeuren via poort 4533 op uw eigen huis LAN.


Firewall RPI

Standaard heeft de RPI geen firewall ingesteld . Je kan echter dit wel doen indien je wenst .Zoek op de raspberry pi website op volgende url:

https://www.raspberrypi.org/documentation/configuration/security.md 

 en zoek naar   ufw .

Daar staat de uitleg hoe het moet.

Vanaf nu zijn we in staat om via TCP de rotor op afstand te besturen , ttz als alle software en hardware in orde is , maar dat is nog niet tenvolle uitgevoerd hier.

 

Volgende keer , een kort overzicht van de bediening van de rotor in Gpredict.

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.



zondag 15 november 2020

ADSN [ 31 : Kalibratieblad voor schotel]

 Eens een geschaald kalibratieblad gemaakt.



Hier is de openingshoek van de schotel op 8.8 GHz getekend met daarbij:

In het geel : de onnauwkeurigheid gerekend naar twintig impulsen ( 0.2°) 

In het rood: de geschaalde  diameter van de maan naar mijn kalibratieafstand , zijnde 4m. Dus als ik de maan uitknip en het is volle maan en ik houd deze op 4 m afstand van mijn oog , zou dit knipsel juist de maan moeten afdekken ? Of ga ik hier in de mist ? ( komt overeen met 0.52°)

Wat is er hier uit te leren( als het allemaal juist is 😀)?

Mijn onnauwkeurigheid valt binnen de maandiameter 👍

Op 8.8GHz - 3dB overstraal ik ferm de maan , zal op 2.3GHz nog veel meer zijn , maar dat kon niet meer op mijn blad. 😡

 


ADSN [ 30 : Nog wat cijfermateriaal]

Van de blog van PE0SAT:

https://www.pe0sat.vgnet.nl/eme/

Enkele gegevens:

 

  • De maan is gemiddeld  384.400 km verwijdered  van ons
  • Diameter van de maan is 3.476 km
  • De maan neemt slechts  0.52 van een graad in beslag van de 180° hemelsbreed

 

Hoe zit het met mijn schotel ?

Al berekend dat:

bij 2.3 GHz de openingshoek 6.5 ° bedraagt

bij 8.8GHz  deze 1.7° bedraagt , zie daarvoor in deze blog

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

Als ik deze hoeken uitzet naar een afstand van 4m( mijn kalibratielengte)  kan ik een lijn teken waarin mijn laserpointer zich steeds zou moeten bevinden bij gelijk welke verplaatsing ik maak.

Daarvoor gebruik ik de tangens van een hoek en neem de halve hoek  en waarvan ik de uitkomst terug verdubbel. Dit geef mij het gevoel dat ik beter de cirkelboog  zal benaderen die in feite de schotel maakt bij het azimuthaal draaien.

 

De lijnlengte van het target bij 2.3 GHz bedraagt

tan (halve hoek) x 4000mm 

bv tan ( 6.5/2) x 4000 = 0,056784115 x 4000 = 227mm

dit nog verdubbelen geeft  een lijn met een lengte  van  454,4 mm , wat best veel is .

Hetzelde berekenen voor 8.8GHz geeft een lijnlengte 258 mm.

 

Wat met de nauwkeurigheid van mijn rotor ?

Bij de laatste opmeting ( moet deze nog bevestigen) had ik een tolerantie van 7 pulsen linksom en 7 pulsen rechtsom. Deze geven samen 14 pulsen wat overeenkomt in het AZ met 0.14 ° . Ik neem 20 pulsen en bereken een wat onnauwkeuriger situatie.

Twintig pulsen komen overeen met 0.2°

Uitgezet vogens hetzelfde stramien geeft mij dit op 4m afstand een lijnlengte van 

14 mm .

Als dit alles bevestigt wordt kan ik zekers met deze opstelling op 8.8 GHz een nauwkeurigheid behalen die voldoende is . Dit alles wel berekend bij een openingshoek van de schotel op de - 3dB punten , wat toch maar de helft is van het vermogen .

 

Hetzelfde moet ook nog berekend worden  met de Elevatierotor .


Ik zou dit eens moeten kunnen herhalen voor bv - 1 dB punt .

Maar zover ben ik nog niet


woensdag 11 november 2020

ADSN [ 29 : hardware : Hbridge uitgevoerd]

 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.



woensdag 4 november 2020

ADSN [ 28 : hardware : Hbridge schema]

 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.

dinsdag 3 november 2020

ADSN [ 27 : hardware : Hbridge eigen ontwerp]

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.




zondag 1 november 2020

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.


woensdag 28 oktober 2020

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

 

 



 




zondag 25 oktober 2020

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.


donderdag 22 oktober 2020

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 🤭


zondag 18 oktober 2020

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 ?

zaterdag 10 oktober 2020

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.



zaterdag 26 september 2020

Nieuw Speelgoed [ nanoVNA_V2 ]

 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


tindie products


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.

dinsdag 22 september 2020

ADSN [ 20 : Broodplank uitgebreid]

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.

 

 



zondag 6 september 2020

ADSN [ 19 : schema level shifter]

Niet echt schokkend nieuws....

Gewoon uit de junk box wat ik nog kon vinden en dat was deze oude CD4050, niet inverterende hex buffer. Deze kan wel maar amper 2 TTL poorten sturen
 ( waar is de tijd ?  ) .
Volgens datasheet is dit 5 mA bij 5V voeding.Als je weet dat mijn led al 3 mA consummeert , schiet er niet veel meer over....

Het schema:




ADSN [ 18 : premature opstelling test H bridge deel 3]

Ondertussen is er al wat gewijzigd .


De electronica is nu aangesloten aan de rotor , dus geen controller meer van het originele )
D.m.v. de drukknoppen kan ik zelf bevel geven en de richting kiezen .
Ook de orig schakelaars komen binnen en tijdens beweging komen de pulsen nog steeds binnen .

De twee losgekoppelde printjes " simulatie" was om in de shack te testen , maar nu hangt er de rotor aan.

Volgende stap ,in  het C programma verder programmeren en veiligheden inbouwen ( bv als de orig komt stop de motor en keer de keuze automatisch om.)

De levelshifter is een oude ( recup) CD4050. Het is niet hét van hét , maar het doet zijn werk , nl omzetten van de rpi uitgangen van 3.3 V naar 5V die de H bridge nodig heeft.
De CD4050 kan wel niet veel stroom sinken of sourcen  , dit laat ook de datasheet zien . De groene ledjes vragen enkele mA en het uitgangsniveau zakt al naar 4V , wat nog ruim voldoende is voor de H bridge . Deze groene ledjes zeggen mij of de brug vriigegeven is


donderdag 3 september 2020

ADSN [ 17 : voorlopig schema interface RPI <--> Rotor]

Interface tss H bridge en RPI nog te bepalen.


Het schema met de dual bridge rechtsbovenaan