Wie kent dit nog ?

 

Gevonden tussen mijn papieren

ADSN [ 107 : ID lijst ]

 Elk body , target , object of hoe je het ook wilt noemen heeft een eigen ID nummer . Dit kan zowel positief zijn als negatief.

Het voordeel hiervan is,als je de lijst hebt,  dat je kunt kiezen wat je eigenlijk wilt.

Als ik   moon   invul voor de maan bij JPL dan kan ik kiezen uit twee mogelijkheden , maar als ik 301 invul , dan heb ik de juiste .

Dankzij een forum ben ik te weten gekomen waar ik die lijst kan ophalen , en zodoende nu jullie ook.

For planets, natural satellites, and many (but not all) spacecraft:

API
https://ssd.jpl.nasa.gov/api/horizons.api?format=text&COMMAND=%27MB%27

... or browser
https://ssd.jpl.nasa.gov/horizons/time_spans.html

For asteroids and comets, there is an ASCII text file updated hourly:
https://ssd.jpl.nasa.gov/ftp/xfr/DASTCOM.IDX

The primary SPK ID is the integer starting in column 35.

 

Het is de API die ik zal gebruiken , eerst nog een Pythonscript ervoor schrijven .

De laatste tijd ben ik mij aan het verdiepen in Python , om een samenhangend geheel te brouwen ,waar ik zowel manuele ingave , als JPL , als Gpredict via één server met mijn rotor kan laten communiceren .

Dus het zal een poosje stil zijn hier.

 

ADSN [ 106 : Eigen script met JPL data ]

Het is gelukt !

Ik kan nu de data ophalen via de api van JPL en direkt daarmee mijn rotor aansturen .

Het is allemaal nog wat prématuur maar het werkt .

Dit script moet dan later in mijn GUI komen om alles grafisch te maken .

 

Links het eigen script , gebouwd op Radecl.py. Rechts mijn terminal venster van de RPI en in het midden het astronomische venster van WSJTX om een vergelijk te kunnen maken .

Er zit een verschil op van 0.6° tussen mijn script en dat van WSJTX voor AZ en 0.2° voor EL.

Dit is het tracken van de Zon

Snapshot is genomen juist op het einde van mijn AZ limiet (nu 260°) en wordt daardoor niet gehaald , de elevatie echter wel .

ADSN [ 105 : Script vergelijken met JPL ]

Ik heb eens het Python script vergeleken met de app op de JPL website zelf om te testen of de data wel hetzelfde zijn .

En jawel , het script is OK.

Zie hieronder het resultaat. Boven in het zwart , het Python script , onderaan JPL.

De waarden zijn identiek.

Dus ik kan me nu betrouwen op mijn Pythonscript en hiermee mijn parabool ansturen via het andere Pythonscript met Radecl.py

ADSN [ 104 : Een andere manier met JPL]

 Er bestaat nog een andere , meer geautomatiseerde , manier om data over te halen .

Dit noemt het JPL batch data bestand.

Zie : https://ssd.jpl.nasa.gov/horizons/app.html#/

Indien men een script schrijft , bv in Python, kan men ook de benodigde data ontvangen zonder dat men alle stappen moet invullen in de app.

Zo'n script ben ik tegengekomen ergens op Twitter en ik vind de auteur niet meer terug , maar gelukkig heb ik wel het bewaard.  Aangepast als  voorbeeld voor de LRO , een satelliet die nog rondjes draait rond de maan 

Hier is het :

 

import requests

url = "https://ssd.jpl.nasa.gov/api/horizons.api"

param = {     "format": "text"
        ,    "COMMAND": "LRO"
        ,   "OBJ_DATA": "YES"
        , "MAKE_EPHEM": "YES"
        , "EPHEM_TYPE": "OBSERVER"
        ,     "CENTER": "500@399"   ## site @ body
        , "START_TIME": "2022-08-31"
        ,  "STOP_TIME": "2022-09-01"
        ,  "STEP_SIZE": "1h"
        , "QUANTITIES": "'1,20,23,24'"  ## RA&DEC, RARR, sun-observer-target, sun-target-observer   
        ,  "TIME_ZONE": "+00:00" ## relative to UTC
    }

res = requests.get(url, params=param)

print (res.text) 

 

LET OP : Verander de START en STOP_TIME !  naar uw wens

Bewaar het bestand met een naam naar eigen dunk ,   bv JPL_LRO.py en opstarten met :

python3 JPL_LRO.py

Indien een foutmelding ivm met requests import , dan deze installeren met :

pip3 install requests.

Je moet wel pip3 geïnstalleerd hebben maar dit is op het internet te vinden.

 

 

Een extract uit het resultaat.

 

 

Dit script moet gemakkelijk aan te passen zijn om te voldoen aan je eigen wensen .

Zal dit dan ook eens proberen , na het weekend ,want nu is het Velddag !

U kunt ons werken met de call ON6WL. Ik ben van dienst op zo-morgen van 6h00 tot 9h00 lok tijd, persoonlijke call ON4AOL

Naschrift:

ik heb het bestand een beetje aangepast voor mijn lokale positie.

import requests

url = "https://ssd.jpl.nasa.gov/api/horizons.api"

param = {     "format": "text"
        , "COMMAND": "LRO"
        , "OBJ_DATA": "YES"
        , "MAKE_EPHEM": "YES"
        , "EPHEM_TYPE": "OBSERVER"
        , "CENTER": "COORD"   ##
        , "COORD_TYPE":"GEODETIC"
        , "SITE_COORD": "'+4.02662,+51.22180,0'" ## opgelet dubbele quotes plus enkele quotes !!!!!
        , "START_TIME": "2022-08-31"
        ,  "STOP_TIME": "2022-09-01"
        ,  "STEP_SIZE": "1h"
        , "QUANTITIES": "'1,20,23,24'"  ## RA&DEC, RARR, sun-observer-target, sun-target-observer   
        ,  "TIME_ZONE": "+00:00" ## relative to UTC
    }

res = requests.get(url, params=param)

print (res.text) 

Documentatie over de API:

https://ssd-api.jpl.nasa.gov/doc/horizons.html

https://ssd.jpl.nasa.gov/horizons/manual.html#intro

ADSN [ 103 : Het tracken met JPL data]

Radecl.py is een Python script waarmee "bodies" in de ruimte kan worden gevolgd indien men de juiste data te pakken kan krijgen .

Binnenkort wordt Artemis gelanceerd waar ook Orion met meereist waar dan alle cubes en andere ruimtetuigen zich bevinden , die op gepaste tijden zullen gelanceerd worden.

Op de website van JPL Horizons is er een api ( app) waarmee ge data kunt opvragen , hier is de link:

https://ssd.jpl.nasa.gov/horizons/app.html#/

U komt dan het volgende te zien:

 

Er zijn 5 stappen die je allemaal moet doorlopen .Wil je iets wijzigen , klik dan op de EDIT knop.

Stap 1. Ephemeris Type : kies hier voor Observer Table 

Stap 2. Target Body : als voorbeeld heb ik hier de LRO genomen 

Stap 3. Observer Location : Typ Brussels in , en de app doet de rest.

Stap 4. Time Specification: Spreekt voor zichzelf , kies start en stoptijd.

Stap 5; Table Settings: Hier kunt ge kiezen wat er moet gegenereerd worden . Als je op edit klikt krijg je een keuze wat je zou willen . Kies enkel voor RA & DEC.

Door dat jezelf kiest wordt de keuze  custom genoemd.

Als laatste stap klik je op Generate Ephemeris en de tabel wordt onderaan getoond.

Hier een extract uit de tabel:

 

Kopieer bv de erste lijn en enkel de waarden die onder R.A.______(ICRF)______DEC staan.

Dit wordt dan           14 03 50.20  -12 17 07.9

Dit formaat herkent radecl.py niet en moet dus worden aangepast naar:

 

                                  14h03m50s     en   -12d17m07s

Uiteindelijk wordt de gehele syntax voor de commandolijn om radecl.py op te starten het volgende:

python3  radecl.py --lat=51.2227 --long=4.0227  --altitude=6 --ra=14h03m50s --dec=-12d17m07s --rotor=192.168.xxx.xxx:4533 --rotorleftlimit=90.0 --rotorrightlimit=270.0

U moet zelf uw tcp adres van uw rotor  natuurlijk invullen en alle andere gegevens aanpassen

 

Dit krijgt ge bij eerste opstart:

De soft wordwel afgesloten , waarschijnlijk omdat het target nog niet zichtbaar is , maar ik volg dit op . ik weet dat bij mijn eerste testen het wel goed liep.

Zie : ADSN [ 37 : RaDecl ]

 

Fout gevonden :

Ik was een argument vergeten meegeven , nl delay.

Dat is de tijd waarna de setup opnieuw wordt verzonden.

Dit wordt dus :

 python3  radecl.py --lat=51.2227 --long=4.0227  --altitude=6 --ra=14h03m50s --dec=-12d17m07s --delay=10 --rotor=192.168.xxx.xxx:4533 --rotorleftlimit=90.0 --rotorrightlimit=270.0
 

Er is wel wat werk aan vooraleer alles in het juiste formaat staat , maar misschien is dit script aan te passen zodat het vlotter verloopt.

 

 

ADSN [ 102 : S band :Zonneruis]

 Met de verkregen gegevens in het programma van VK3UM blijkt dat ik inderdaad geen grote Y factor zal hebben .

Optimistisch gezien 1.9dB.

Dit is niet veel en vooral te wijten aan de filter en de vrij slechte NF.

Hier de berekening.

En dan een meting, die ik nog eens zal moeten herhalen.

Ongveer 1.5 dB !

Dit verklaart dan ook dat mijn vroegere meting waar ik amper 1 dB mat , er toch niet zover naast was.

ADSN [ 101 : S band : Systeemmetingen ]

Een poging om de gevoeligheid te meten van de MMDS + filter is niet goed afgelopen .

Het signaal "waaiert"  overal erdoor. Ook al zet ik  de SA die met de TG dienst doet als bron , in een ander kamer en breng ik het signaal over via een coax kabel , de metingen zijn niet reproduceerbaar en daarom verwerp ik ze ook.

Dan maar met de Receiver Performance Calculator  van VK3UM ( onderdeel van EME calc) een simulatie gedaan op 2304 MHz

De antenne temperatuur is overgenomen door EMEcalc nadat ik mijn parameters voor de parabool had ingegeven.

Voor de filter heb ik de data voor een antennerelais "misbruikt" Ik heb een loss van 2 dB genomen . Volgens de nanoVNA was het minder , volgens de SA was het meer.

Voor de  SWR heb ik 1.38  genomen wat overeenkomt met een Return Loss van 16 dB , ook een VNAwaarde.

Voor Cable 1 ( tussen MMDS conv en de LNA) 0.6 m ( opgemeten) en een slechte RG58 . De kabel zelf is dit niet , maar ik heb geen gegevens van die kabel.

Voor Cable 2 , nul meters omdat er hier een dubbele connector zit , die ik in rekening breng in het veld daaronder.

Vier connectors van het sm( a)  type.

Voor LNA , de gegevens zoals hieronder uit de tabel van DD1DUS komt:

Omdat we tss 2200MHz en 2300 MHz werken heb ik 10 dB genomen en een NF van 2 dB ( naar de veilige kant dus)

 Gain en NF van de Chinees

 

Voor de MMDS heb ik ook  een NF van 2 genomen , de waarden variëren nogal wat , dus weer een gemiddelde.

De te ontvangen bandbreedte zet ik op 120Hz . Het zijn als eerste testen toch de carriers die we willen zien en horen .

Dit geeft volgend resultaat:

Ik heb ook eens gesimuleerd , wat als ik een dubbele LNA kan gebruiken zodat ik 20dB heb ipv 10.

Het scheelt natuurlijk een beetje , maar zo groot is die slok op de borrel nou ik weer niet!

Nog maar weer eens het bewijs dat de eerste trap bepalend is .

 

Resultaat bij 2304 MHz

Systeemgevoeligheid : -150 dBm  ofwel 0.0066 µV

Systeem ruistemperatuur :  524.0 K ofwel  4.48 dB (ruisgetal NF)

Ontvanger ruistemperatuur : 508 K 

Ontvanger ruisgetal  4.39 dB

Ik hoop met deze opstelling toch een zonneruismeting te kunnen doen maar hoe moet dat ook weeral ?

ADSN [ 100: Artemis I bandplanning]

Geheugensteuntje voor mezelf

Te vinden op https://sgcderek.github.io/blog/artemis-1.html

En meer over OMOTENASHI op : https://www.isas.jaxa.jp/home/omotenashi/JHRCweb/jhrc.html

ADSN [ 99: Wat een plezier !]

 Het heeft bijna 100 afleveringen geduurt vooraleer ik signalen kon ontvangen die de (lichte) stempel ADSN  mag hebben , maar het was het wachten waard.

ON4DPX , Kenny , had me de raad gegeven om LRO eens te monitoren op 2271.2 MHz omdat deze sterk is .

Eerst dacht ik hem gevangen te hebben maar het bleek een birdie te zijn (ongewenst signaal , kan een mengprodukt zijn of een harm. van een LO).

Dat signaal was trouwens loeiend hard.

Toen , na een poosje de Queqiao te hebben gevolgd , zag ik een tweet die net gepost was over de LRO.

Ik heb dan ook afgestemd en ja hoor daar was ie !

Je moet natuurlijk weten wanneer deze de juiste kant van de maan aan zijn omloop bezig is en dat kan je zien op volgende link :

 

https://www.lroc.asu.edu/about/whereislro

En dit krijg je dan te zien:

of dit 

Het oranje is de huidige positie. Op deze foto rechts zit de LRO achter de maan , de linkse foto is  het gedeelte van de maan dat naar de aarde is gericht , dus op dat moment was die niet hoorbaar. Bemerk ook de landingsplaatsen van de apollo's .

Wat is er zoal te beleven ?

Wel , in de eerste plaats het doppler effekt natuurlijk . Ook hieraan kan je soms bepalen welk ruimtetuig er rond vliegt als de de shift te weten komt.

Omdat de LRO dicht tegen de maan vliegt is ook zijn snelheid hoog en daardoor ook de dopplershift.

Ik heb eens 1300Hz/ min gemeten. 

Links de ontvangst met Gqrx en met twee merkbare zijbanden . 

Rechtsonder de snelle dopplershift in WSJTX gemeten in WSPR mode.

Rechtsboven , mijn trackingsprogramma voor de maan ( e.a.)

 

 

Dit hier is vermoedlijk het ontkoppelen van het grondstation met de LRO.

Hierdoor springt de LRO uit de frequentielock .

De zijbanden verdwijnen ook.Dit was op het einde van de omloop langs de zichtbare kant in de buurt van de zuidpool , als ik dat zo mag noemen.

Bemerk ook dat de carrier lager in frequentie zit dan de marker LRO. Dit betekent dat de LRO van mij weg vliegt.

 

En hier als de LRO naar me toe vliegt  . Dit gebeurt dan als hij over de noordpool komt.

De sprong rechts in het beeld heeft niets te maken met een lock of unlock situatie maar een manueel ingijpen van mij om hem weer een beatfrequentie te geven die zicht- en hoorbaar was.

 

 

Nog iets mooi. De LRO verdwijnt uit het bereik van mijn parabool. Ik kan max tot 265° AZ gaan en de maan was voorbij dit punt aan het gaan .

Nog iets raar gezien en nog niet te verklaren :

Het lijkt wel of er een test loopt om de bandbreedte te toesten , wie weet hier meer over?

 

 

ADSN [ 98: S band :nieuwe nanoVNA metingen]

Een nieuwe nanoVNA meting drong zich op nadat ik de curve van de filter wat  meer effen in de doorlaat heb gebracht.

U ziet hier duielijk twee bulten , dit zijn in feite twee afstemmingen dicht tegen elkaar die de mogelijkheid biedt om de doorlaatband te verbreden .

 

De data:

Meting Marker 1 in tweede bult: QRG 2282 MHz

S11:  -16.2 dB

S21 :  -0.62 dB

Z : 41.6 Ohm + 807pH

 

 

 

Meting Marker 1 in eerste bult : QRG  2225 Mhz

S11: -17.05dB

S21: -0,54 dB

Z: 65.1 Ohm // 12.5pF

Daartussen heb ik natuurlijk slechtere waarden en zoals ik al zei , ge moet keuzes maken .

Tussen de twee bulten en op het hoogste niveau:

S11 : - 4dB

S21 : -2.86 dB

Z:  45 Ohm ( de reactantie heb ik vergeten te noteren)

 

ADSN [ 97 : S band - Testen in de parabool ]

Zag op Twitter tweets passeren over sterke signalen in de S-band, die met simpele middelen te ontvangen waren . Het was dus tijd om zelf ook eens te proberen .

De maan zat ( bijna) goed , want het waren signalen die vandaar kwamen .

Het gaat hem over LRO en tweemaal Queqiao , de TT&C en de data denk ik .

Queqiao is een relais stations dat zich in feite een eind achter de maan bevindt en als tussenstation fungeert voor de Chinese  maanlander . 

Dus Filter en de Chinese LNA  gekoppeld aan mijn Helix en mijn programma's gestart om de maan te volgen . In het begin zat de maan nog eigenlijk buiten mijn bereik ( ik akn maar tot 50° EL) maar de openingshoek was toch voldoende om de signalen op te pikken .

Hieronder enkele voorbeelden :

LRO Lunar Reconnaissance Orbiter:

 

Het sterkste signaal is een birdie  , het andere is zal LRO zijn VERMOED ik. De frequentie sprong ook soms , en dat gebeurt vaker als het ergens gelockt wordt met een grondstation.

Queqiao:

 

Dit is het TT & C signaal. Dit staat voor Telemetry, Tracking and Command.

 

 

Update 30 aug 2022:

Queqiao TT&C met zijbanden op 100kHz afstand

 

 

 

 

 

En dit is het andere van  Queqiao:

 

 

 

Dit signaal is héél sterk , zelfs als ik de LNA uitschakel ( maar wel in de keten laat zitten) komt het er nog door !

Nog een bewijs dat dit geen birdie is , is de doppler op het signaal .

Ik hoop dit nog eens te bevestigen op een andere dag.

ADSN [ 96 : S band - Filter : Het resultaat ]

 Wel , we zullen het maar leergeld noemen.

Het loodgieters werk is niet zo simpel , ttz men moet vooraf erg doordacht te werk gaan wat ge eerst monteert en zo verder te werken .Het heeft mij drie kapotte connectoren gekost ! De staafjes vastsolderen aan de basis is ook niet zo'n goed idee, als je naderhand nog moet tweaken of het deksel moet vastsolderen , ze komen natuurlijk los!

Daarom heb ik mijn twee echte verzilverde buisjes aan de ingang toch maar vervangen door dezelf gemaakte buisjes van remleidingsmateriaal en deze voorzien van schroefdraad zodat ik ze kan aanschroeven met een M3 boutje.Indien alle elementen wel goed werken kan ik deze nog eens vastsolderen.

De verbindingen tss connector en de staafjes moet ook snel gebeuren . Een oplossing is om de staafjes te voorzien van een boring van ca 1mm om daar dan de zilverdraad al in te solderen zodat je enkel nog de kant van de connector moet doen 

Wat de deksels betreft , deze zijn absoluut nodig om de juiste afstemming te krijgen ! Gebruik geen slap blik maar een stevig  koper of messing plaatje . Anders loop je kans op  verstemming.

Ik heb ook de lengte van de staafjes toch vrij heftig moeten aanpassen . Van 31.6 mm naar 27mm !Dit kon ik maar vaststellen nadat alles was gemonteerd  inclusief beide deksels. Gelukkig deden mijn stelschroeven ( koper , 5mm) hun werk en kwam ik uiteindelijk op de gewenste frequentie terecht.

Het afregelen zelf is een zoeken tussen de vier stelschroeven ,maar mbv de SA ging dit vrij vlot. Toch zat ik eerst met een vrij grote piek buiten de doorlaat en in de Wifi band . Dit heb ik nog kunnen wegregelen maar ten koste van wat doorlaatdemping . Liever de ongewenst signalen meer verzwakken . het is altijd een afwegen wat ge wilt bereiken .

Ik heb hem al geprobeerd en ik kan nog het 13 cm baken ontvangen van ON0ZT , dit staat opgesteld op ongeveer 72 km van mij maar ik kan dit enkel ontvangen via airplane scatter ( Baken 100 mW in dubbelquad 50 m asl , en richting ZO , Ik zit voor het baken NO) en te herkennen door de dopplershift dat er op zit.

 

 

 

 

De piek op marker 4 is in de buurt van Wifi en zat eerst heel wat hoger , bijna gelijk met de doorlaat.

Volgende stap is buiten verder testen van de filter , de gevoeligheid op 13 cm nagaan en kijken of we de zonneruis kunnen meten.

Nog twee nanoVNA metingen om de impedantie te zien

1. S11 op uitgang , S21 op ingang Dit is eigenlijk " achterwaarts" gemeten , maar dit kan geen kwaad omdat het filter symmetrisch is.

Data:

Op 2250MHz -->    57.03 Ohm + 2.29 nH    S11: -10.5 dB  S21 : -1.58 dB

2. Voorwaartse gemeten , S11 op N connector ( ingang) , S21 op SMA connector  (uitgang ).

Data : 

Op 2254MHz -->    50.2 Ohm //  4.65 pF    S11: -16.6 dB  S21 : -1.84dB

 

TIP! Als je enkel S11 meet ,ALTIJD uw filter afsluiten met 50 Ohm op de uitgang. 

Detail opname na definitieve(?) afregeling

De data is af te lezen van de tabel . De doorlaatband op - 3 dB is zoals berekend 100 MHz. Ik heb wel wat doorlaatdemping , maar dit is voor lief genomen om de doorlaat zo vlak mogelijk te krijgen en de WiFi kanalen zoveel mogelijk te verzwakken.

De enige moeilijkheid is nog om eraf te blijven !

PS: Wifi band is tss 2412 en 2472 MHz

ADSN [ 95 : S band - Filterbouw ]

Hier al een foto van mijn zaterdagwerk.

Een beetje een exploded view .

Moet nog eens nadenken over de samenbouw en dan alles assembleren .

 

ADSN [ 94 : S band - Filterontwerp ]

 Terug van nooit weggeweest.

Ik moet dringend een filter bouwen op 13 cm , wil ik verder doen met deze MMDS convertor.

Wijlen VK3UM heeft daarvoor een tooltje geschreven op basis van een artikel van G3SEK in Radio Communication van feb 1984 en aangehaald in de blog van 

GM3SEK  :  https://gm3sek.com/2018/09/29/interdigital-filter-design/

Daar kan je ook de software en het artikel in pdf  downloaden .

 

Ik kom voorlopig tot dit voorstel.

De staafjes zijn 4.75 mm en zijn in feite stukjes koperen remleiding die ik proberen te verzilveren heb, met zacht zilversoldeer en een goeie brander.

Voor de regelschroefjes zou ik graag 4 mm of 5mm koperen schroefjes gebruiken maar die moet ik nog halen.

Hét grootste probleem is de behuizing . Niet alle doosjes komen precies uit ( in feite geen enkele) Ik heb wel plat messing liggen ( ooit opgekocht in een uitverkoop van een hobbywinkel!) . Misschien moet ik daar iets met aanvangen.