This wiki is not maintained! Do not use this when setting up AuScope experiments!
This is an old revision of the document!
GNSS calibration project
Nov 5, 2020: we have set a date for initial test observations, friday Nov 13; some thoughts beforehand:
We believe that we can do the measurements from the control room
We will select a few suitable satellites (Lucia and Tiege) and use the TLE-RADEC satellite function for the 26m to actually track the satellite (Tiege looks into that – but we have used it previously)
All we need for a start is a snapshot from the spectrum analyser over the transmission bands (L1 & L2)
What we also need is a calibration of the antenna
Once we have a few measurements, we can look into the formulas and try to derive the actual values that we need.
Nov 13, 2020: first tracking tests:
setup: split off the multi-feed channel 1, nominally one of the linearly polarized ones; permanently installed; spectrum analyser connected of that; receiver multifeed 2 (L-band), agilent (1st LO) set to 4.1 GHz, 16 dBm output.
spechb: on the network via vnc and socket connection; settings: input attenuation manually fixed at 10dBs; center freq and span adjustable; freq 500MHz, span 1 GHz; 100 counts average seems to look good by eye. video bandwidth of 10 MHz, resolution BW 3 MHz, sweep time 2.5 ms. (setup in automatic mode); narrower bandwidth allow better discrimination between RFI and signal; use different tracers; sky range 1.1 - 2.1 GHz;
RFI: bruny island microwave link ~330MHz IF (1430 sky), mobile phones above 1.8 GHz, something at about 60-70 MHz (1160-70, blocking L5?)
tracks: tracking using the satellite tracking module (sattrack); scheduled with 10sec updates.
sattrack: satplt.pl window is the one to look at for current track; infos in spaceX_26m.pdf; has to be run on newsmerd; to stop: abort in vdesk window 3 - emergency: big red button
Nov 18, 2020: Tiege solo show:
Spectrum analyser traces: When I got out here the spectrum analyser was not showing the expected spectrum despite L-band being on axis. Removing cable produced no change in the output, looks like after it was unplugged it needed to have the 'pre-set' button pushed (I think) in order for it to switch to the 'RF in' input. In the process of troubleshooting this I seem to have changed the behaviour of trace 1 and am not sure how to change it back to how it was. Trace 2 is still set to a 100 count average.
Tracking testing: Testing the shell wrapper calling the 5 minute block schedules. All seems to run fine so far - Looks like it takes between 60s and 120s for the telescope to settle between schedule blocks - will need to take this into account for when we should be pulling from the spectrum analyser.
Late start tracks: The current wrapper when run after the schedules start time will try each of the blocks in order until it finds one with a tracking point in the future - this is OK, but it takes a long time to iterate through all the previously observed blocks (~20s for each 5 min block - ~4 mins per hour of catchup). Not a big deal if you are only starting the track <1hr late, however, longer than this and you start to lose a significant amount of your observing time just catching up. Will need to look into a better solution for this - I have a solution which would work for python but need to look into what is possible in the shell script.
Recording from spectrum analyser: I have written a very ugly script that currently grabs trace outputs from the spectrum analyser every 5 seconds during valid time periods (currently from 90s past the start of the scan to the end time). Between the 5 minute blocks it averages all grabbed spectra together and writes them to a file with the timestamp of the scan.
Nov 19, 2020::
Late start tracks: The bash script generated during schedule generation has now been updated to include 'if' statements with time conditions - this should fix any issues with starting tracks late. Current version of the scripts can be found on my github in a repository named 'antenna_thrust_scripts' (https://github.com/tiegemccarthy/antenna_thrust_scripts)
TO DO:
prepare tracks for 5 min on source off source (for 1 satellite at a time); probably try 1 sec updates; how does sattrack handle this? code up 5 minute tracks to load after each other (run in sequence) - after the track finished, the antenna sits at the final az/el