LORA [ 3: De Software : installeren en configureren van de IDE]

Nu moeten we de software kant aanpakken . Zoals beschreven kan de ESP2866 geprogrammerd worden vanuit de Arduino IDE.

Dus 

Stap 1:

Installeer de Arduino IDE. Ik heb versie 2.0.2

https://www.arduino.cc/en/software#future-version-of-the-arduino-ide

Stap 2:

Installeer in de IDE de voorbeeld-sketches voor onze ESP8266

Ga naar Github :  https://github.com/esp8266/Arduino

en haal het  Arduino-master.zip -bestand overen plaats deze in de Arduino map op uw PC.

Voor Windows weet ik het niet maar voor mijne Linux is dat onder mijn homedirectory/user

 U hoeft deze zip niet uit te pakken en deze bevat allemaal nieuwe sketches speciaal voor ons en andere ESP8266 boardjes

 

Als je een .zip bestand wilt toevoegen vanuit een andere map (bv Downloads) kan dit via  <Sketch> <include library> <Add.ZIP Library> Normaal moet je de nieuwe zip niet uitpakken !

Stap 3:

We moeten ook nog ons board bekend maken in de IDE. Dit wordt gedaan door een .json bestand. Hiervoor gaan we terug naar Github in dezelfde repository als hierboven en kopieren  de link beginnend e met https://arduino.......

Open de IDE en ga naar <File> <Preferences> en plak de link zoals te zien in onderstaande afbeelding in het veld " Additional board manager URL's "

Nu kunnen we kijken of ons board aanwezeig is in de IDE.

Ga naar <Tools> en zoek  <Board manager> , dit kan naargelang uw arduino versie anders voorkomen dan bij mij. Als je de manger open hebt zie je iets zoals onderstaande afbeelding( hier IDE versie 2.02)

Klik op de INSTALL knop en na installatie zul je onder <Tools> < board> <esp8266> allemaal nieuwe boardjes zien zitten . Wij gebruiken het (LOLIN) Wemos D1 mini en in mijn geval de clone.

Stap 4. Als laatste moet je nog de COM poort instellen waarmee je de soft overzet naar het boardje . In mijn Linux is dat /dev/ttyUSB0 maar in Windows zal dat de één of andere COM poortnummer zijn.

Sluit eerst je boardje aan en kijk dan in de IDE onder <Tools> <Port> welke je kan kiezen.

Hier komt de mosterd van :

https://www.youtube.com/watch?v=Q6NBnPfPhWE

LORA [ 2: De Hardware]

 Als hardware heb ik een paar modulekes in mijn schoot geworpen gekregen.

Deze al dan niet clones komen uit China.

Na wat onderzoek bleek ik de volgende modules in mijn bezit te hebben:

1.Lora module : Een sx1276 compatibele module, genaamd HPD13A

 

Onderkant

Bovenkant

 

 

2.Breakoutboard: Om bovenstaande module op te plaatsen en over te kunnen gaan naar SIL header connectors.De beschrifting zegt : Lora Node Micro

 

3.Een Wemos D1 mini  clone , genaamd D1 m1n1. Deze bevat een processor van het type ESP8266 met de nodige randcomponenten zoals een 3V3 regulator , een USB hardware driver en een micro USB aansluiting. Alsook 4MB geheugen en een blauw ledje. Als laatste heeft deze ook WiFI aan boord.

 

 

Hierbij het schema:

 

Deze processor zou kunnen omgaan met Arduino code , dus dat is mooi meegenomen.

Ik heb een kladschemaatje gemaakt omdat de aansluitbenamingen niet éénduidig zijn .

Elk boardje heeft wel zijn eigen scriptie en dat maakt het alleen maar verwarrend , want uiteindelijk gaan we de LoRa module moeten aansturen/uitlezen via een SPI verbinding en de stuurlijnen zullen moeten kloppen met de code in de software.

SPI is nieuw voor mij , maar we komen er wel uit.

Het resultaat van dit tekenen is dat de benaming van de I/O op het schema van Wemos uiteindelijk overeenkomt met de benaming op het HPDA13A boardje.

Bv : GPIO14 komt overeen met 14  op de HDPA13A print. Dit is het clock signaal.

De chipselect loopt dan weer naar GPIO 2 , dit zal ik in de gaten moeten houden in de soft

 

De frequentie waarop dit alles werkt is gebonden aan reglementen en is voor EU 868 MHz . Dit is een zo'n genaamde ISM band en beperkt in frequentie , vermogen en tijdsbezetting van de kanalen.

Naschrift: 30 nov 2022:

Ik heb het blokschema opnieuw geplaatst.Er was een pin verkeerdelijk benoemd. 

Pin 4 en 5 zijn nu juist ingetekend en zijn ook de I²C lijnen die men zou kunnen gebruiken om een OLED display aan te sluiten .

Het nieuwe blokschema

Nog een belangrijke opmerking:

De diodes zijn wel degelijk nodig als je ABP en vermoedelijk ook OTAA wilt doen en vormen in mijn ogen een OF poort .

 

De signalen die uit de module komen op IO0 ( DI0) en I01 ( DIO1) zijn gebruikt om respectievelijk CAD en RX timeout uit te sturen . Deze worden dan in de soft als één interrupt gezien 

De diode op IO2( DIO2) is niet gebruikt.

 

Zie dit stukje soft:

const lmic_pinmap lmic_pins = {

.nss = 2, // chip select on feather (rf95module) CS

.rxtx = LMIC_UNUSED_PIN,

.rst = 0, // reset pin

.dio = {15, 15, LMIC_UNUSED_PIN}, // assumes external jumpers [feather_lora_jumper]

// DIO1 is on JP1-1: is io1 - we connect to GPO6

// DIO1 is on JP5-3: is D2 - we connect to GPO5

};

 

 

 

Er wordt dus tweemaal naar pin 15 verwezen ( OF-poort knooppunt  ) voor de interrupts en de laatste  IO wordt gedeclareerd als LMIC unused pin. 

De commentaren in dat stukje  soft zijn voor ons niet geldig !

 

 

LORA [ 1: Het LORA bos]

Een zijsprongetje naar het LORA gebeuren .

Ik wil een P2P opzetten via tweemaal twee lora modules  ,maar als je YT bekijkt is het weer het spelletje van de bomen en het bos.

De modules zijn een  ESP8266 en een Wemos clone D1 mini

Zal terzijnertijd hier iets over posten .

ADSN [ 113 : Artemis 1 : Toch iets !]

 Ik kan toch ook iets positief vermelden😄

Tijdens de Fly By van Artemis en zijn retrograde traject rond de maan heb ik het signaal zien wegvallen .

Ik was natuurlijk niet zeker , na de foutieve metingen op 2.22GHz , maar dit was op TDRS1 op 2.216500 MHz

Daarbij kreeg ik ook een tweet van Dwingeloo Telescoop met hetzelfde verschijnsel.

en van Cees Bassa

 

 Helaas heb ik hem nadien niet meer kunnen ontvangen omdat het traject net achter mijn huis verdwenen was !

ADSN [ 112 : Artemis 1 : Verontschuldigingen ! ]

 Ik moet hier mijn verontschuldigingen aanbieden .😟

De telemetrie signalen op 2.2 GHz waarvan ik dacht dat ze van Artemis 1 kwamen blijken dat niet te zijn .

Het was mij al opgevallen dat ik deze altijd rond hetzelfde uur s'morgens ontvangde en ze verzwakten hoe later het werd en dan , raar genoeg,  plotseling verdwenen op bijna altijd hetzelfde tijdstip met een bepaalde marge.

Het rare was dat de AZ en EL van het traject klopte , maar dat deze  de hoek kruiste waar het echte signaal zich bevindt , nl op ca 145 ° AZ en 25 ° EL.

Ook zit dit signaal ook nog eens op dezelfde frequentie en DSN NOW gaf aan dat er signalen op die frequentie ook door Madrid ontvangen werden.

Waarvan dit " stoorsignaal" komt is mij nog een raadsel , misschien een geostationair satteliet op die hoek . De elevatie zou allezins kunnen kloppen voor een geostationair.

Ik probeer dit verder uit te spitten.

Dan ben ik deze morgen proeven aan het uitvoeren geweest en vast ingesteld op die AZ en EL en ja hoor de signalen bleven nu binnenrollen.

Enfin , weer wat geleerd . Altijd dubbelchecken voor ge iets rondbazuint.

ADSN [ 111 : Artemis 1 : Vervolg]

 Zou nu op ca 388000 km zitten ( ik heb het zelf niet uitgerekend)

Dit zijn de ontvangen signalen op 2.22 GHz en dit is geweten dankzij  DSN  NOW

Ben eens benieuwd wat dit gaat worden in de toekomst

 SET-UP:

HARDWARE

1.4 m PF schotel

3,5 helical homemade als feed

Homemade 2.25 GHz filter 

Chinees breedband LNA

MMDS als convertor

Splitfilter  200MHz / 700MHz + dc   ( dit om te Oscar 100 en ADSN over dezelfde coax te brengen) De DC is 12 V( MMDS) en wordt ook naar 5V gebracht voor de LNA

Gewone TV coax ca 25 m

Filter in shack voor DC injectie en RF uitkoppeling

SDR stick als ontvanger.

RPI en rotor als schotelsturing 

Ethernet kabel voor TCP/IP berichten

SOFTWARE

Gqrx  als sdr programma

Pythonscript om JPL data over te halen om AZ en EL te berekenen

Pythonscript voor de gateway tussen JPL (of Gpredict) en RPI

Eventueel Gpredict voor de omloopsatellieten

RPI soft in C voor de sturing over  TCP  

That's all folks

 

ADSN [ 110 : Artemis 1 : Eindelijk ]

 Artemis 1 is eindelijk gelanceerd !

Hier zat ik al een tijdje op te wachten . Het is een goede test voor mijn " radio-observatoruim".

Het eerste probleem was om de juiste efemeriden te pakken te krijgen want JPL was niet scheutig met data.

Gelukkig heeft iemand op Github de TLE data gepost die volgens hem " in de buurt" waren en dat was ook zo !

Deze geladen in Gpredict en de schotel hiermee laten uitrichten.

Bijna direkt de eerste signalen van de TDRS1 van Orion ( de capsule) ontvangen .

De volgende dagen ben ik wat beelden gaan verzamelen

Dit is telemetrie van TDRS1 , met een bredere bandbreedte dan mijn sdr stick aankan.

En plots heb je alleen nog maar een draaggolf. Op WJST zie je wel mooi de dopplershift

 

 

Totdat ik hem plotseling kwijt ben .

En nu vandaag vrijdag , vond ik geen signalen meer terug. Ik ben ondertussen ook wel overgeschakeld naar de JPL vluchtdata en deze bleken nu juister te zijn dan de eerste ( wat natuurlijk normaal is).

Maar .... Op de website van DSN NOW : https://eyes.nasa.gov/dsn/dsn.html

Kun je zien welke DSN station met Artemis "praat" en daar zag ik dat er datastream kwam van Artemis op 2.22 GHz , een andere freq dan dat ik gewoon was.

Met mijn  JPL en gateway script kon ik perfect de rotor aansturen en volgen .

ADSN [ 109 : Gateway ]

 Ik heb altijd al het nodig gevoeld om een gateway te hebben om mijn RPI rotorcontroller van de parabool te kunnen koppelen met verschillende programma's . Ik stuur nu de rpi server aan vanuit verschillende programma's en ik wil dit meer geordend.

Daarom heb ik mij wat verdiept in Python en zelf een gateway geschreven.

De gateway is dus altijd verbonden met de rpi server en afhankelijk van wat ik wil hang  ik aan de andere kant een client aan . Dit kan maar één client per keer zijn , want ik wil natuurlijk niet dat het éne programma de parabool naar rechts wilt sturen en een andere client juist naar links.

Vroeger stuurde ik vanuit 

ofwel Gpredict

ofwel JPL

ofwel  Putty

ofwel vanuit een python trackingprogramma.

Ik moest dan telkens de verbinding verbreken en opnieuw opbouwen .

Omdat langs de server kant van de rpi er ook nog het één en ander kan verbetert worden , is het met deze gateway oplossing toch zó , dat deze laatste altijd verbonden blijft met de rpi en enkel de client kant er een nieuwe verbinding moet worden opgebouwd.

In blokschema ziet dit er zo uit:

In werking , zoiets

Links loopt het JPL client programma , dit berekent de huidige positie van de lRO aan de hand van de efemeriden die bij JPL zijn opgehaald.

Rechtsonder is de gateway in aktie , deze koppelt de data van JPL door naar de rpi server  en omgekeerd het antwoord van de rotor als hij de positie heeft bereikt  terug naar de client van JPL ( of Gpredict ,of ....)

Rechtsboven , het venster van de rpi server die de rotor commandeert.

Het enige waar ik nog aan denk , is,  om een " it's alive" event te implementeren.

Dit is een watchdogfunktie om te kijken of de verbinding tussen rpi server en de gateway nog altijd gezond is.

ADSN [ 108 : LRO met een interessante omloop ]

 Zoals ik al voorspeld had in episode 107 is het een beetje stil geweest.

Ik kan niet altijd tijd besteden aan dit aspect van de hobby. Ondertussen is ook de xyl geopereerd en terug thuis én heb ik ook nog een fox - o - ring georganiseerd voor onze WLD clubleden. Ik kreeg ook nog een vraag van iemand uit Frankrijk die zich met weerbalonnen bezig hield , zoals ik enkele jaren geleden ook nog heb gedaan en vroeg om wat technische bijstand. Ook dat hebben we gelukkig kunnen oplossen.

Maar gisterenavond heb ik nogmaals de maan beluistert en meer bepaald de LRO die daar rond vliegt .Ik wist eigenlijk niet meer of ik met mijn nieuwe setup ( helical --> zelfbouw filter --> chinese breedband LNA --> MMDS convertor ) al (nog)  de LRO had ontvangen ?

Deze had voor mijn p.o.v ( point of view) een interessante omloop, namelijk de LRO volgde bijna juist de omtrek van de maan.

En ja , ik heb hem kunnen ontvangen totdat die echt achter de maan verdween.Tijdens het kruisen boven de noordpool ( ik denk dat we van de maan ook van de noord - en zuidpool mogen spreken) was ie nog altijd capteerbaar .

 

 

 Hier het moment van het locken van het signaal.Voor zover ik tot nu toe weet , zendt de LRO zijn carrier uit op zijn frequentie. Een aards station ontvangt dit met een dopplershift  en zendt een carrier terug waarop de LRO dan inlockt . U ziet de jump in de frequentie . Eénmaal aan elkaar vast is de verbinding stabiel . Ik moet dit nog eens uitvlooien hóe dit nu echt werkt .

 

 Ik heb nu ook twee zijbanden ontvangen met waarschijnlijk data ( telemetrie ?)

Spannend om dit te zien.

 

 

De ontvangst rondom de noordpool. U ziet rechts met het oranje veld , de precieze plaats op dat moment.

U ziet ook dat de dopplershift minder en minder wordt ( quasi rechte lijn in WSJT)

en het moment van unlocken van het signaal in het sdr venster

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.