zondag 4 december 2022

LORA [ 10: P2P test]

Zoals al eerder beloofd , een test gedaan met een P2P verbinding in " real life" situatie.

Samengevat : teleurstellend!

Zolang open veld , lukt het aardig maar als er bomen aan te pas komen in het bos gaat de demping zeer snel de hoogte in en er staan nog geen bladeren aan de takken !

Ik had een oled display aan mijn "mobiel" LoRa bordje verbonden en het vaste bordje zond op regelmatige basis een bericht . In dit bericht had ik een teller laten oplopen zodat ik aan de RX kant kon zien of er nieuwe berichten binnenkwamen .

Ook werd de RSSI uitgelezen zodat ik een idee had van de sterkte van het signaal.

De "mobiele" rx in een bokaal ondergebracht.


Voorlopig is dit de laatste test met LoRa . We gaan ons eerst verder herbronnen.

donderdag 1 december 2022

LORA [ 9: Terug verbinding! ]

 Tijdens deze twee mistige dagen kreeg ik geen enkel packet dppr naar de gateway in Terneuzen 

Waarom weet ik niet , maar de zon schijnt hier terug en het werkt weer.

Nochtans was ik mobiel tot in Axel gereden en toch nog geen verbinding.Misschien werkzaamheden aan de gateway ?

Enfin , het werkt terug. En deze keer niet op alkaline batterijen maar op deLiPo batterij.

Ondertussen ook nog het volgend javascript ingevuld onder " payload formatters/uplink"



Javascript voor de uplink

 

 function Decoder(bytes,port ){
  var result = "";
  for ( var i = 0; i < bytes.length; i++) {
    result +=(String.fromCharCode(bytes[i]));
    
  }
 
  return{text:result};

}


Hiermee kan je de hexadecimale code die je ziet in de "Live Data" van de GW omzetten naar leesbare tekst.



Eens benieuwd wanner de verbinding terug verbreekt.

LORA [ 8: Batterij-bordje! ]

 Het leuke aan al die bordjes is dat je ze kunt stapelen .

Zo zijn er ook batterij-bordjes die op de stapel kan bijgevoegd worden .

Dit bordje kan dan uw LiPo batterij laden via een USB connectie en ondertussen blijven werken (denk ik toch).

De batterij die ik heb is een 18650 model.Deze heeft een juiste spanning voor de bordjes ( nominaal ca 3.3 V) en de batterijspanning kan voor een LiPo bij volledige oplading wel tot 4.2 V gaan maar is nominaal ca 3.7V

Gelukkig zit er op de Wemos een low drop spanningsregulator zodat de 3.3 V verzekerd is:

Datasheet van de ME6211 low drop :

 

https://github.com/Edragon/Datasheet/blob/master/Microne/ME6211.pdf

De dropout spanning is slechts 100 mV !

 

Dit is het bordje :


 En dit is het schema


En hier mijn proefopstelling


Een opmerking:

De meegeleverde connectors waren met een verkeerde polariteit !

Gelukkig in tijds gezien en met een pinnetje kun je de weerhaak naar beneden duwen en de draadjes omwisselen.

Ook heb ik de batterijhouder aangepast want de veer was niet sterk genoeg om de plus pool tegen de lip te houden. Door een M3 boutje als stelschroef te gebruiken kan ik de cel opspannen !

Een lintje rondom de cel vergemakkelijkt het uitnemen van de cel ( nadat de stelschroef is teruggedraaid).


maandag 28 november 2022

LORA [ 7: ABP verbinding succesvol ! ]

De test tussen twee bordjes is toch opgeschoven . Ik had vastgesteld dat geen enkel van mijn " rubber ducky" antennes goed werkte op 868 MHz . Dit heb ik vastgesteld  met mijn nanoVNA.

Daarom , tijdelijk, een bordje in een glazen pot gestoken en meteen ook een GP antenne op maat gemaakt.

Vier batterijen erbij van 1.5 V en enkele diodes in serie gezet om de spanning naar beneden te halen .Ik had gezien dat de spanningsregulator op het Wemos bordje max 6V kon verdragen , daarom de spanning wat verlaagt.Uiteindelijk gebruikt het bordje zelf geen 5V en ook de LoRa module niet , die werken allemaal op 3V3.

 

 De opstelling op het venstertablet 1m agl

De juiste sketch ingeladen en bijna direkt contact met een Gateway.Niet direkt de verwachtte gw maar een heel eindje verder in Terneuzen .Volgens Google maps toch 16 km in vogelvlucht.




De packets



De identifikatie van de Gateway


Hierboven is ook te zien wat mijn RSSI is , nl -113dBm en een SNR van -4.

Dwz dat er nog wat "rek" op zit en ik misschien nog verder kan .De hoogte van 60 m is natuurlijk in mijn voordeel.

zondag 27 november 2022

LORA [ 6: P2P verbinding.]

 Een tweede bordje samengestoken en deze met elkaar laten " babbelen".

Het gebruikte voorbeeld is weer zoals reeds gebruikt in aflevering 4:

"Using LoRa for P2P half-duplex long range communication " van Sayanee Basu

maar dit keer wel in duplex uitgevoerd.

Het werkte direkt van de eerste keer.

Hiermee ga ik eens kijken hoever duplex werkt en wel in een " normale "omgeving en niet met vrij opgestelde antennes.


Het berichtenverkeer

Wat er te zien is op de SDR stick.


zaterdag 26 november 2022

LORA [ 5: Verbinding in ABP mode.]

 Als tweede test was de vraag of ik een ABP ( Activation By Personalisation ) verbinding kon opstellen en dit terechtkrijgen op LoraWan bij The Things Network.

Daarvoor moet je eerst een account aanmaken en ook een applicatie.

Ik beperk mij tot een link naar daar, er zijn wel YT filmpjes genoeg om dit te bewerkstelligen.


https://www.thethingsnetwork.org/


Het is natuurlijk met hetzelfde boardje dat we dit gaan doen ( ik heb trouwens geen ander) , en daarvoor moet er natuurlijk een nieuwe sketch ingeladen worden.

De library die we gaan gebruiken zit natuurlijk op Github en wel op deze link:

 https://github.com/mcci-catena/arduino-lmic

Het is een verbeterende versie van de nu niet meer ondersteunde  arduino-lmic versie van Mathijs Kooijman omdat nu ook mcci ondersteunt wordt en niet enkel lmic.

Lees zekers ook het READM.MD bestand , zekers als je een ander boardje gebruikt als mij.

 

Installatie :

Haal het ZIP bestand over en zet dit bijv in de Downloads map.

Doe de IDE open van Arduino en dan <Sketch> <Include Library> < Add .ZIP library>

Haal het zip bestand uit Downloads en de IDE zal deze installeren . Onderaan het venster kunt ge dit volgen of het gelukt is.

Daarna de sketch overhalen:

< File> <Examples> en dan helemaal onderaan bij <" Examples from custom libraries > kiest ge     "MCCI LoRaWan MMCI library" en daaronder dan uiteindelijk " ttn-abp"

Als de sketch open is moeten er een paar lijnen veranderd worden :

1: de NWKSKEY , de network session key

Vul hierin de verkregen key die ge bij The Things Network ( verder TTN genoemd)

gekregen hebt. Maak dat ze in hexadecimale notatie staat ( bv 0x23, 0x1A ...) en dat ze als MSB first staat. Dit alles is te kiezen bij TTN

Ge krijgt dan zoiets als:


static const PROGMEM u1_t NWKSKEY[16] = { 0xEE, 0xD5, 0x18,... enz }

 2:  de APPSKEY , de application session key

zelfde verhaal , goed zetten kopiëren en plakken

static const u1_t PROGMEM APPSKEY[16] = { 0x09, 0xA1, 0x21,....enz }
 

3: de DEVADDR , de end-device adres

ietsjes anders , slechts éénmaal 0x vooraan en dan de key:

DEVADDR = 0x11223344 ; ( dit is een fiktief adres !)

 

Het volgende is ook zekers van belang, namelijk de pinbelegging:

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
};
 

Met deze pinbelegging schijnt het te werken .

Als laatse , maar zekers niet het minst onbelangrijk is nog het bandplan instellen .

 

Deze is te vinden onder het volgend path

/Arduino/libraries/arduino-lmic-master/project_config/ en het is dit bestand dat gewijzigd moet worden :

lmic_project_config.h

en bevat hetvolgende:

 

// project-specific definitions
#define CFG_eu868 1
//#define CFG_us915 1
//#define CFG_au915 1
//#define CFG_as923 1
// #define LMIC_COUNTRY_CODE LMIC_COUNTRY_CODE_JP      /* for as923-JP; also define CFG_as923 */
//#define CFG_kr920 1
//#define CFG_in866 1
#define CFG_sx1276_radio 1
//#define LMIC_USE_INTERRUPTS 

 

Maak dat  #define CFG_eu868 1    zonder commentaartekens staan ( // ) alsook 

#define CFG_sx1276_radio 1

 

Het resultaat is voor een volgende aflevering.

 

 



 


vrijdag 25 november 2022

LORA [ 4: Een sketch inladen en testen.]

Nu komt het echte werk.

We gaan proberen om enkele LoRa packets te verzenden .

Als handleiding heb ik volgende YT filmpje gevolgd. Althans voor een deel , want er waren wat probleempjes die we moesten oplossen .

 

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

Using LoRa for P2P half-duplex long range communication  Sayanee Basu.

 

 

Dit voorbeeld is ook wat ik wil proberen , namelijk een P2P verbinding.

Zij gebruikt een Adafruit RFM95W board en ik natuurlijk het ESP8266 board.

Ik had voor alle zekerheid de connecties op mij boardje uitgetekend en dat kwam nu goed van pas ,want er is een verschil met de CS stuurlijn tussen die twee.

Daarom moet de soft worden aangepast . Ik wist ook niet goed hoe de registers van de ESP2866 aangesproken moesten worden , bij een Arduino is dat de pinnumer , maar is dat ook bij de ESP?

Gelukkig bleek achteraf dat ik het cijfer dat achteraan de benaming zat ( bv GPIO14) ik gewoon 14 mag declareen in de soft.

De soft is op Github te vinden en wel hier:

https://github.com/sandeepmistry/arduino-LoRa#semtech-sx1276777879-wiring

Je kan de gehele zip overhalen of zelf onder examples de INO file open doen en alles kopieren en in een nieuwe sketch plakken .

Ik heb hetzelfde voorbeeld genomen als in YT en de duplex genomen , ook al test ik maar met één board.

Zorg ervoor dat je eerst het boardje selecteert ( bij mij LOLIN Wemos D1 mini clone)

 

Dit is een deel van de sketch:

 

De omkaderde lijnen moet juist ingesteld worden . de csPin moet zekers 2 zijn met onze configuratie ,de andere , daar ben ik nog niet zekers over maar het werkt.

Héél belangrijk ! Stel de juiste frequentie in . In EU is dat 868, de E6 wilt zeggen 10 tot de 6de macht.( MHz dus)

Dan de sketch compileren en opladen naar het board.

Indien geen compileerfouten zou alles moeten werken .Start het board niet , dan zit er een kleine resetknop opzij het board.

Start de Serial Monitor op 9600 Baud  in de IDE en volg mee wat er gebeurt.


 


 Op mijn SDR stick zie ik het volgende:


De horizontale strepen zijn de packets ( chirps) van het LoRa boardje.

Test 1 geslaagd !




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


donderdag 24 november 2022

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 !
 
 

woensdag 23 november 2022

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 !


maandag 21 november 2022

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.

zaterdag 19 november 2022

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


 

vrijdag 18 november 2022

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 .


vrijdag 11 november 2022

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



donderdag 27 oktober 2022

Wie kent dit nog ?

 


Gevonden tussen mijn papieren

donderdag 22 september 2022

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.

 

donderdag 8 september 2022

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 .


maandag 5 september 2022

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


vrijdag 2 september 2022

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

donderdag 1 september 2022

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.


 

 


woensdag 31 augustus 2022

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 ?