A month ago, I spoke about planning the passes of the Moon through the beam of my QO-100 station. These give an occasion to observe the Moon without moving a dish that is pointing to Es’hail 2. The next opportunity after writing that post was on May 16 at 20:16 UTC.
Since I wasn’t going to be at home at that time, I programmed my computer to make a recording for later analysis. I recorded 4MHz of spectrum centred at 10367.5MHz using a LimeSDR connected to the LNB that I use to receive QO-100. The recording was planned to be 30 minutes long starting at 20:01 UTC, but for some reason only approximately 27 minutes were recorded.
This kind of events can be used to measure Moon noise and receive 10GHz EME signals. This post is an analysis of my recording, looking at these two things.
The Moon noise measurement was done at 10366.5MHz with 1MHz of bandwidth, in order to avoid the LimeSDR centre spur and any possible signals at 10368MHz. GNU Radio was used to filter this chunk of spectrum and perform average power measurements, taking one power reading per second.
The power readings were analyzed in a Jupyter notebook. The figure below shows the noise compared with the separation of the Moon from the centre of the dish (assuming that it is pointing perfectly well to Es’hail 2).
We note that the noise decreases almost 0.2dB in the first 10 minutes of the recording. This is caused by the change in temperature of the LimeSDR as it starts receiving and streaming samples. The LimeSDR had been connected to the computer by USB for a long time before the recording started, but it wasn’t streaming samples. This is a lesson I’ve learned: it is important that the receiver is completely functional for a long time before the start of the recording, so that it has a stable temperature.
It is convenient to remark that many RF active components have a gain that varies noticeably with temperature and other factors. These gain variations place a practical limit to long Amateur radioastronomy observations.
We see that there is a hump of approximately 0.05dB in the noise which coincides perfectly with the Moon passing through the beam of the dish. This is the Moon noise. After the Moon has passed through the dish, the noise varies somewhat erratically. I don’t know the reason for these variations.
The receiver used for this experiment was a 1.2m offset dish from diesl.es and an Avenger PLL321S-2 Ku-band LNB modified to use an external 27MHz reference. I would have expected a higher Moon noise from this station: between 0.1 and 0.15dB. Thus, I have spent some time trying to understand why I am getting a reduced performance.
One thing to be cautious of is the noise figure of the LNB. The measurements done by Ian Roberts ZS6BTE show that commercial Ku-band LNBs can have a rather high noise figure below 10.7GHz. To assess the performance of my LNB, I performed a Y-factor test a few days after the Moon observation. I used the LNB placed in the dish as cold measurement, and the LNB dismounted from the dish and pointing to the nadir as hot measurement.
I have obtained the following Y-factors depending on frequency: 2.5dB at 10366.5MHz, 3dB at 10488MHz, and 3.4dB at 10800MHz. The ambient temperature was 17ºC, so we take the hot source as 290K. For the cold source we use an educated guess of 70K (which is supposed to come mainly from dish spillover). Using these values we get noise figures of 2.4dB, 1.8dB and 1.4dB at the measurement frequencies.
Note that this is just a rough approximation, since an typical estimate was used for the cold temperature. Also, it is possible that the measurement of the Y-factor at 10800MHz is too low due to signals from the GEO satellites affecting the cold measurement, even though I tried to select a clear frequency for the measurement.
Using the VK3UM EME Calculator, a noise figure of 2.4dB, spillover of 70K, and a 1.2m dish with 40% efficiency yield a Moon noise of 0.11dB, which is noticeably more than the 0.5dB I have obtained.
Something we need to have in mind is that the Moon didn’t pass through the centre of the dish beam during the experiment. We can assume that the closest the Moon got to the centre of the dish is 0.5º. According to this calculator, a 1.2m dish can be between 0.5 and 1dB down at 0.5º off-beam depending on its efficiency. However, this decrease in gain would only account for a small difference in the Moon noise.
Therefore, I haven’t come up with a convincing explanation for the difference between the theory and my observations. It will be interesting to observe future passes of the Moon through the dish beam to see if I get different results.
Now we turn our attention to any possible EME signals present in the recording. The first signal to search is the DL0SHF EME 10GHz beacon, which transmits at 10368.025MHz every time that the Moon is visible from Germany. According to the VK3UM EME Planner, the Doppler between Germany and my station in Spain at the time the recording was made was 7.3kHz.
By looking at the recording using rfplot from strf (see this post for a tutorial), we find the signal at the expected time and frequency, as shown in the image below.
If you look at the figure above, perhaps you’ll notice something odd. The DL0SHF beacon is supposed to transmit FSK-CW on odd minutes and QRA64D on even minutes. The FSK-CW transmissions can be seen more clearly in the image, but it seems that there is an FSK-CW transmission every minute rather than every two minutes as expected.
At first I suspected that I messed up something with my recording (maybe the sample rate, or the sample format), but the shift between the FSK-CW tones is 400Hz, as expected, and the signals are visible between 20:14 and 20:20, which coincides with the period when the Moon passed through the dish beam and when the Moon noise hump was visible.
Therefore, I think it is very unlikely that I’ve messed something up with the recording, and somehow the beacon was transmitting “faster” than it should. I have asked some Spanish EME operators and they didn’t observe anything odd with the beacon, even on the same day that I performed the observation. Maybe this was a temporary problem of short duration.
Besides the DL0SHF beacon, I haven’t detected any other EME signals in the recording.
One comment