After publishing that post I started reverse-engineering the short frames. Meanwhile, Peter Horvath pointed me to a Github repository containing an implementation of the FEC used for short frames and long frames. I hadn’t seen that repository before (it’s not easy to search for SMOG-P or ATL-1 in Google, as many unrelated results come up). Indeed this repository contains the source of a FEC decoder for the short frames, so there is no need to reverse-engineer it.

Timur Kristóf, the author of that repository, says that the team plans to release the source for the decoder, but that they are currently very busy with the early operations of the satellites. This is very good news.

I have studied the code in the Github repository and included a decoder for the short FEC frames in gr-satellites.

The short FEC frames are a straightforward modification of the AO-40 FEC protocol. As I suspected, they carry a single Reed-Solomon (160, 128) codeword. The way this is done is by using a 52×51 matrix interleaver instead of 65×80. The length of the distributed syncword is thus 52 bits instead of 65.

However, there is something a little bit strange. Whereas in the standard AO-40 FEC the output of the matrix deinterleaver is sent to the Viterbi decoder after removing the 65 bit syncword, in these short frames the first 80 bits (including the 52 syncword bits) are dropped before sending the frame to the Viterbi decoder. This gives a frame of 2572 symbols to be sent into the Viterbi decoder, which outputs 1283 bits. The last 3 of these bits are dropped to obtain a 160 byte Reed-Solomon codeword.

The list of short frames decoded from the recording I made yesterday can be seen in this gist.

Besides FEC decoding of the short frames, there is still more work to do in order to have a complete decoder. By now I know nothing about the “very short frames” (Timur says that they are used from synchronization). Additionally the format of the data packets is not known. Hopefully this will be made clear when the team releases the source code.

Regarding the AES128 encryption functions that I mentioned in my previous post, Peter stated that the encryption is only used for authentication. I have analyzed the `smogpgnd_x86_64`

more carefully and I am confident that this is true. The `AES128_block_decrypt`

function is only called from the `AES128_builtin_test`

function, which in turn is not called from anywhere. Additionally, the packets I have decoded don’t seem to be encrypted (the data would appear much more random). Therefore, the downlink doesn’t seem to use any encryption.

The function `AES128_block_encrypt`

function is called from `uplink_encoder`

(which, again, isn’t called from anywhere), so it seems that the uplink uses some form of encryption (perhaps only for authentication). This is perfectly reasonable and follows the ITU regulations, since the uplink is a control signal.

Interestingly, there is also the `chk_downlink_pckt_signature`

. It isn’t called anywhere and just returns -1, so it is not implemented in the binaries released by the team. However this hints that the packets sent by the satellite have some form of authentication. Indeed, in the packets I’ve decoded the last 10 bytes seem quite random. These bytes (or just part of them) might be an HMAC or similar kind of signature.

This form of authentication without data encryption is also allowed by the ITU Radio Regulations, for all forms of communications. It is an interesting concept and it is seldom used in Amateur communications. The most similar thing that I have seen in Amateur radio is the elliptic curve signature in DML. AAUSAT-4 software was also prepared to use a HMAC, but I’ve never checked if the downlink transmissions were signed with the HMAC or it was only for the uplink. Congratulations to the satellite team for bringing in these interesting security features while following the ITU regulations.

]]>They transmit in the 70cm Amateur satellite band, and although they have beeen successfully coordinated with IARU (see here and here), documentation about the protocols they use has not been published. There is some groundstation software available here, but the interesting part is implemented in the `atlgnd_x86_64`

and `smogpgnd_x86_64`

binary executables, for which source code is not available. As far as I know both satellites transmit using the same (or very similar) protocols.

In this post I describe my first attempts at reverse-engineering the transmissions of SMOG-P, with successful results. Preliminary support for decoding SMOG-P and ATL-1 has been added to gr-satellites in the maint-3.8 branch.

The first remark is that even though the IARU coordination sheets state that these satellites use 12.5kbaud GMSK, they are using 1250baud GMSK instead. In fact, for the first day after launch they were using some faster modulation for most of the packets, but they have been changed to 1250baud since Saturday. This change can be observed from the difference in the waterfalls of recordings done before and after the change.

In my first look at the packets, I identified that the 16 bit syncword `0x2DD4`

was being used. This is the default syncword for the Si446x family of FSK transceiver chips from SiLabs and is also used in Lucky-7, so most likely the satellites are using this kind of chips. However, a look at the data revealed that it was most likely scrambled.

While trying to get in contact with the satellite team to get some technical details about the scrambler, I decided to take a look at the `smogpgnd_x86_64`

binary to see if I could pull out any useful details easily.

Here you can see the symbol table of the ELF binary `smogpgnd_x86_64`

as printed by `objdump`

. There we see numerous references to AO-40, with several functions starting by `ao40_`

and presumably implementing the different functions of the AO-40 FEC protocol. There are also versions of these functions starting by `ao40short_`

(more on this later).

Interestingly, there are also functions that apparently perform AES128 encryption and decryption. I find this somewhat concerning. Encryption of Amateur transmissions is forbidden by the ITU Radio Regulations except for the control signals of Amateur satellites. Therefore, it is possible to encrypt telecommands (and perhaps also replies to telecommands from the satellite), but telemetry and other data downlinked from the satellite needs to be sent unencrypted. So far I don’t know if any of the data transmitted by the satellite is encrypted.

I’m also concerned about the origin the code used in `smogpgnd_x86_64`

, since most of the code available online to implement the AO-40 FEC uses a strong copyleft licence. More specifically, the symbol `ao40_spiral-vit_scalar.c`

suggests that code generated by SPIRAL is used in the Viterbi decoder. The code generated by SPIRAL is available under the GPL. The code of Phil Karn’s KA9Q libfec is available under the LGPL. This is also probably reused in `smogpgnd_x86_64`

(see the symbols `ao40_Partab`

, `ao40_decode_rs_8`

). Therefore, I wouldn’t be surprised if the satellite team is violating some open-source licences by distributing `smogpgnd_x86_64`

as a binary only.

The symbol table of `smogpgnd_x86_64`

has been very helpful. It turns out that SMOG-P implements the AO-40 FEC protocol completely, including the distributed syncword. A 5200 bit AO-40 FEC frame is sent as the payload of the packets transmitted by the Si446x. The `0x2DD4`

is transmitted automatically by the chip before the payload, but the design intention is probably that the receiver should ignore that syncword and synchronize using the AO-40 distributed syncword.

However, this is not the end of the story. It turns out that SMOG-P transmits frames of three different sizes. These can be seen in the figure below. The frames are the parts of the signal where the amplitude is small. The rest if just noise between frames.

The long frames correspond to the 5200 bit AO-FEC frames. There are also some short frames which are approximately half the length of the long frames. This explains the `ao40short_`

functions, which hint at some modification of the AO-40 FEC protocol for frames of half the size. Perhaps this is achieved by using a single Reed-Solomon (160,128) codeword instead of two, but I will have to take a look at this in more detail.

There are also some very short frames. One of these frames is transmitted at the beginning and at the end of each burst of long or short frames. So far I don’t know anything about them. It is possible that they don’t use any FEC and are intended as some kind of signalling.

A recording of some long frames and of some short and very short frames have been added to satellite-recordings. A decoder for the long frames is now available in gr-satellites. The plan is to add support for short and very short frames once I figure out the details.

I have put a decode of the long frames recorded during the 2019-12-07 19:43 UTC pass on the Budapest University’s groundstation WebSDR in this gist. In a certain sense, the data seems somewhat strange.

]]>In order to try to shed more light onto the possible cause of the oscillations observed in the previous post, I have now processed the broadcast ephemerides of November for all the active Galileo satellites (including the eccentric E14 and E18) except for E11 and E25, which were out of service at least for some days in November.

This post studies the amplitude and phase of the oscillations of the broadcast clocks at a frequency of 1/revolution. More formally, if we denote by \(x(t)\) the time series corresponding to either the broadcast clock bias or the broadcast clock drift, we compute the complex quantity\[\alpha = \frac{2}{T}\int_{t_0}^{t_0 + T} x(t) e^{-i[n_0(t-t_0) + M_0]}\,dt,\]where \(n_0\) denotes the mean motion in radians/second and \(M_0\) denotes the mean anomaly at \(t_0\) in radians. Note that if\[x(t) = a \cos(n_0 (t-t_0) + M_0 + \varphi),\]then \(\alpha \approx ae^{i\varphi}\), which motivates the definition of \(\alpha\).

When computing \(\alpha\) from the broadcast ephemerides, the mean motion \(n_0\) is taken as the average mean motion among all the ephemerides, while the mean anomaly \(M_0\) is taken as the mean anomaly at the first ephemeris. Note that in all the motivation for this definition we are tacitly assuming that\[n_0(t-t_0) + M_0 \approx M(t) \approx E(t),\]where \(M(t)\) and \(E(t)\) denote the mean anomaly and the eccentric anomaly at time \(t\). This approximation is valid for all the satellites in quasi-circular orbits, but it is not true for the eccentric satellites E14 and E18, for which \(M(t)\) and \(E(t)\) can differ significantly.

In any case, the difference between trying to study \(x(t)\) as a function of \(e^{in_0t}\), as a function of \(e^{iM}\) or as a function of \(e^{iE}\) is not so large. Since \(E\) can be considered as a perturbation of \(M\) and vice versa, the difference is just some kind of phase modulation effect in which energy is lost from the fundamental to form sidelobes, so it will be ignored for the rest of this post.

The complex amplitudes \(\alpha_{\mathrm{bias}}\) and \(\alpha_{\mathrm{drift}}\) are computed as defined above for each Galileo satellite using the broadcast ephemerides transmitted during November. To eliminate long-term effects, a polynomial of degree 4 is fitted and removed from the clock bias time series, and the average of the clock drift time series is also removed. The figure below compares the amplitude \(|\alpha_{\mathrm{bias}}|\) with the amplitude of the relativistic clock bias term for each of the satellites.

Next we compare the \(|\alpha_{\mathrm{drift}}|\) with the amplitude of the relativistic clock drift term.

Additionally, E14 and E18, which do not appear in these graphs, have a very large relativistic amplitude, while the amplitude of their broadcast clock oscillations is similar to that of the other satellites. This was first observed by Bert Hubert.

Therefore, there is no apparent correlation between the relativistic term and the amplitudes of the oscillations of the broadcast clocks. It seems that these oscillations are not related to relativistic effects, or to any other factor depending exclusively on the eccentricity of the orbit.

Since the derivative of \(e^{in_0t}\) is \(in_0e^{in_0t}\) and the clock drift term is supposed to be the derivative of the clock bias term, we expect that \(in_0\alpha_{\mathrm{bias}}\) and \(\alpha_{\mathrm{drift}}\) are similar. The figure below compares \(n_0|\alpha_{\mathrm{bias}}|\) and \(|\alpha_{\mathrm{drift}}|\).

A linear regression is also shown. The slope is 0.6, and the correlation coefficient is 0.85. This is somewhat strange, as we would have expected a slope of one.

Next we compare the phases (complex arguments) of \(\alpha_{\mathrm{bias}}\) and \(\alpha_{\mathrm{drift}}\). In order to obtain a clearer graph, we plot the arguments of \(-\alpha_{\mathrm{bias}}\) and \(-\alpha_{\mathrm{drift}}\) instead (which just corresponds to adding 180º to the argument).

Two things are noteworthy in this figure. First, the difference between the phases of the clock bias and the clock drift is small. Since the clock drift is supposed to be the derivative of the clock bias, we would have expected a phase difference of 90º, so this is rather striking.

Additionally, the phase of most of the satellites is around 0º. Since the orbital radius is proportional to \(1-\varepsilon \cos E\), where \(\varepsilon\) denotes the eccentricity, and we are plotting the phase of \(-\alpha\), a phase close to 0º means that there is a positive correlation between orbital radius and clock bias and drift. As the radius grows, the clock bias and drift both grow.

The figure below shows a linear regression for the phase of the broadcast clock drift in terms of the phase of the broadcast clock bias. The slope is close to one, and the phase difference is approximately -20.4º, with a standard deviation of 11.5º.

While most of the phases of the broadcast clocks are around zero, there are some outliers. The phases of eccentric E14 and E18 are close to -135º. The other outliers are E12 and E19, with phases between 135º and 180º. These satellites are the IOV satellites (recall that the E11, the other active IOV satellite) was not studied since it was unavailable during most of November.

The FOC satellites in quasi-circular orbits have phases around 0º. There is a certain correlation between the phase and in what launch each satellite was put in orbit. The figure below shows the satellites coloured by launch. We see that launches 2015-045, 2017-079 and 2018-060 cluster rather tightly. However, launches 2015-079, 2016-030 and 2016-069 do not cluster so well.

Finally, I have also plotted the spectra of the broadcast and SP3 clock biases and broadcast clock drifts of all the Galileo satellites. The list of all the plots can be found at the end of this Jupyter notebook. We see that the frequency component at 1/revolution is clearly visible in most of the plots of the broadcast clock bias and broadcast clock drift.

Some of the satellites, such as E36 shown below display a noticeable frequency component at 1/revolution in the SP3 clock. This is most likely due to clock contamination from inadequate orbit modelling. However, the component in the broadcast clock is always much larger.

So far it seems that any possible relativistic causes for these broadcast clock oscillations have been ruled out. The most likely case for these oscillations now seems unmodelled effects in the orbit solution contaminating the clock solution, as some people have already suggested.

If this is the case, then these results would indicate that the modelling done by the orbit determination centres that produce the SP3 orbits and clocks is better than the modelling done by the centre computing the broadcast orbits and clocks. Of course this is not a very fair comparison, since the SP3 final solutions are provided after one week, while the broadcast ephemerides are computed in advance.

Additionally, for the sake of fair comparisons it is convenient to mention that it is somewhat more difficult to model the orbits of Galileo satellites in comparison to other GNSS satellites, such as GPS satellites, since the Galileo satellites have a higher cross-section to mass ratio that causes larger solar radiation effects. Also, the cross-section of a Galileo satellite varies noticeably with the orientation, because the body of the satellite is elongated. This means that other GNSS constellations might not display these oscillations in their broadcast clocks simply because their orbit modelling is easier, and not because the models or algorithms used for Galileo are any worse.

In any case, these considerations are at best ramblings without more data supporting the hypothesis that the cause of the oscillations is inadequate orbit modelling. Some of the additional questions that this post raises are why the clock bias and clock drift oscillations do not have the amplitude and phase relationship that one would expect in a derivative, and why there seems to be some kind or correlation between the satellite type (recall that the IOV and FOC satellites are physically very different) and launch, and the phase of the oscillations.

]]>However, then I realised that this relativistic effect is not included in the broadcast clock model. It needs to be included back by the receivers. Therefore, it shouldn’t appear at all in the broadcast clock. Something didn’t seem quite right. This post is an in-depth look at this problem.

First we start by reviewing the relevant theory about relativistic effects in GNSS satellite clocks. The article “Relativity in the Global Positioning System” gives a good overview of relativistic effects affecting GNSS systems. In equation (39) it proves the formula given above for the relativistic effect on the satellite clock due to a non-circular orbit.

When GNSS clocks are modelled, it is common to correct for this effect in the clock observations, so as to remove the effect from the clock model. Doing so has the advantage that this relatively large periodic term is eliminated from the clock model, simplifying clock modelling and analysis. However, the GNSS receiver needs to put back the correction in order to compute the satellite clock correctly.

Regarding the major constellations, GPS, Galileo and BeiDou remove relativistic effects from their broadcast clock models. This is described in Section 20.3.3.3.3.1 of IS-GPS-200K, in Section 5.1.4 of the Galileo OS SIS ICD v1.3, in Section 5.2.4.9 of the BeiDou B1I SIS ICD v.3.0 and in other related BeiDou documents, and in equation (E.4.16) in the RTKLIB manual. In contrast, GLONASS doesn’t remove the relativistic effects from its broadcast clock model.

When performing orbit and clock determination for the production of precise orbit and clock products, such as those listed in the IGS MGEX, the common practice is to remove the relativistic effect from the clock model. Therefore, the relativistic correction needs to be added again when using an SP3 file. More information can be found in equation (E.4.37) in the RTKLIB manual.

Therefore, when studying broadcast clocks or SP3 precise clocks, we expect not to find this relativistic effect, except when dealing with GLONASS broadcast clocks.

In the experiment presented in this post we look at oscillations in the broadcast and SP3 clocks of satellites of all the major constellations with the goal of studying oscillations at a frequency of 1/revolution. The set of data under study is the MGEX BRDC files for the complete month of November 2019, and the final SP3 clocks from CODE ranging between 2019-11-01 and 2019-11-23 (since final products for the last week in November are not available yet).

In order to simplify the experiment, we study a single satellite per constellation. To magnify the effects due to a non-circular orbit, we choose the satellite having the largest eccentricity. For GPS, that satellite is G21, but because of some anomalies explained below, we chose instead G02, the satellite having the second largest eccentricity. For Galileo, we ignore the highly eccentric satellites E14 and E18, due to the difficulties of modelling their orbit accurately. We choose E31, which has the highest eccentricity among the operational satellites. For BeiDou, the satellites having the largest eccentricity are in an IGSO orbit. Due to the radical differences between an IGSO and a MEO orbit, we choose an IGSO and a MEO BeiDou satellite. The IGSO having the largest eccentricity is C06, while the MEO having the largest eccentricity is C11. For GLONASS we choose R16, which has the largest eccentricity.

The amplitude of the relativistic effect in the satellite clock bias for these satellites is as follows:

- E31, 0.958 ns
- G02, 44.4 ns
- C06 (IGSO), 24.1 ns
- C11 (MEO), 5.30 ns
- R16, 6.10 ns

The effect in the satellite clock drift is:

- E31, 0.119 ps/s
- G02, 6.47 ps/s
- C06 (IGSO), 1.76 ps/s
- C11 (MEO), 0.717 ps/s

Since the GLONASS broadcast ephemerides don’t include the clock drift parameter, the clock drift of R16 will not be studied.

First we look at the clock drift \(a_{f1}\) parameter in the broadcast ephemeris during November. The figure below shows the clock drift for E31 and G02. The average of each trace has been removed to aid visualization.

We clearly see the oscillatory behaviour that Bert first noticed in the Galileo broadcast ephemeris. In contrast, the broadcast clock model for GPS is very simple. The \(a_{f1}\) term is constant except for some jumps every several days.

Next we show the clock drift for the BeiDou satellites. The IGSO C06 has a strong linear trend that has been removed in the plot. We see some large spikes in some of the ephemerides, but no oscillatory behaviour is visible.

Now we examine the clock bias \(a_{f0}\) parameter in the broadcast ephemerides. We fit and remove a degree 4 polynomial to the data when plotting in order to eliminate long term drift. The figure below shows the clock bias for E31 and G02.

The clock bias of E31 shows the same oscillatory behaviour as the clock drift (but there are other effects, making the graph more noisy). G02 doesn’t show this oscillatory behaviour but shows some noticeable jumps every other day.

The figure below shows the clock bias of the BeiDou satellites. The IGSO C06 has a really large and complex long term drift pattern that is difficult to cancel by fitting a low degree polynomial. The interpretation of this plot is therefore not easy.

Finally, we show the clock bias of the GLONASS satellite R16. Besides a slow variation, the relativistic effect (which is included in the broadcast clock model) can be clearly seen in the graph.

Now we perform a spectral study of the \(a_{f1}\) and \(a_{f0}\) parameters in order to see more easily the oscillations occurring at different frequencies. The figure below shows the spectrum of the clock drift for E31 and G02. The horizontal axis has been normalized to units of 1/revolution (which are different for each constellation, due to different orbital radii).

The oscillatory behaviour that we saw in the time domain for E31 is now clearly seen at a frequency of 1/revolution, with an amplitude of approximately 0.05 ps/s. Note that this is roughly half of the relativistic effect computed above, but I don’t know if this is just a coincidence or if it is significant. A harmonic at a frequency of 2/revolution can also be seen. In contrast, the spectrum of the G02 clock drift doesn’t show any features at integer multiples of 1/revolution.

At this moment it is convenient to remark the effects of unmodelled orbital behaviour in the satellite clock determination. Since unmodelled orbital effects will contaminate the clock determination and these unmodelled orbital effects often happen at frequencies which are integer multiples of 1/revolution, spectral features of the clock model can point to defects in orbit modelling.

Next we study the clock drift of the BeiDou satellites. We see that the MEO C11 doesn’t display any interesting spectral features, while the IGSO C06 has some features at integer multiples of 1/revolution. Probably these are caused by unmodelled orbital effects as remarked above. In contrast to the case of E31, the harmonic at 2/revolution is stronger than the fundamental at 1/revolution.

Below we show the spectrum of the clock bias \(a_{f0}\) parameter of E31, G02 and C11. The spectrum of the IGSO C06 is not shown because it is completely swamped by the slow drift. Here it is clearly visible that E31 is the only satellite which presents oscillations at a frequency of 1/revolution. The amplitude of these oscillations is approximately 0.5 ns, which is roughly half the relativistic effect computed above. Again, I don’t know if this is a coincidence.

Now we compare the broadcast clocks with the SP3 precise clocks for each of the satellites. The figure below shows the comparison for E31. While the broadcast clock has a strong component at 1/revolution, the SP3 clock has only a weak component at this frequency that can be explained by clock contamination from unmodelled orbital effects. This seems to indicate that the broadcast clock for E31 is wrong: the oscillatory effect that is clearly visible in the broadcast clock is not a real effect of the satellite clock, but rather a problem when computing the broadcast orbit and clocks.

Additionally, we remark that the SP3 clock looks less noisy. This is often the case for precise clocks in comparison to broadcast clocks (and also the 5 minute sampling interval of the SP3 files as opposed to the longer sampling interval of broadcast ephemerides helps average noise out). Because of this, a weak component at 2/revolution is visible in the SP3 clock. Again, this is probably clock contamination.

The figure below shows the comparison for G02. We don’t see any major spectral features. Something small (probably clock contamination) is visible at 2/revolution.

The next figure corresponds to G21 and shows why we have avoided considering this satellite. There are large frequency components in the SP3 file at 1/revolution and 2/revolution that are not present in the broadcast clock. Probably these indicate a problem with the orbit and clock solution that generated the CODE SP3 file. I have decided to discard this satellite rather than investigating this problem further and checking if this effect is also present in the clock solutions computed by other centres.

The clock for the BeiDou MEO C11 doesn’t show any major spectral features, as it can be seen in the figure below.

Finally, we show the clock bias spectrum for the GLONASS satellite R16. The large component at 1/frequency that appears in the broadcast clock doesn’t appear in the SP3 clock. This component corresponds to the relativistic effect, which is included in the broadcast clock but not in the SP3 clock. Its amplitude approximately matches the value of 6.1 ns that we had calculated above.

In summary, this post shows that there is something wrong with the Galileo broadcast clock modelling. The coefficients \(a_{f0}\) and \(a_{f1}\) show some oscillatory behaviour at a frequency of 1/revolution which doesn’t appear in the SP3 precise clocks. While this post only studied the satellite E31, Bert Hubert has observed this effect in other satellites as well. The amplitude of these oscillations is in the same order of magnitude as the relativistic correction of the satellite clock due to a non-circular orbit, but it isn’t equal. The comparison with GPS and BeiDou indicates that this is a problem specific to Galileo.

So far I don’t know anything about the cause of this problem. It might be caused by an incorrect relativistic correction of the observations when performing the orbit and clock determination, to clock contamination due to unmodelled orbital effects (but interestingly nothing seems to show up at harmonics of 1/revolution), or to anything else.

The computations and plots in this post have been made in this Jupyter notebook.

]]>I contacted Achim Vollhardt DH2VA asking him if it was possible to record the downlink of the BPSK beacon at Bochum, so as to have a recording referenced to the Z3801A GPSDO in Bochum, which is much more stable than the Vectron. He and Mario Lorenz DL5MLO have been very kind and they have taken the effort to make a recording for me. This post is an analysis of this recording made at Bochum.

The equipment used at Bochum is as follows. A HP Z3801A GPSDO is used as a 10MHz reference. An Octagon LNB is used for downlink reception with a 27MHz reference generated by a DF9NP PLL connected to the GPSDO. The IF from the LNB comes into an AMSAT-DL downconverter, also referenced to the 10MHz GPSDO, and the output of that comes into an Airspy.

The external clock input of the Airspy is connected to the 10MHz GPSDO, but Mario is not sure if this is enabled properly, as he can’t find an option in the software (it might be enabled automatically by the hardware). I couldn’t find anything helpful on the internet either. In any case, after seeing the results of the test, it seems that either the Airspy was indeed locked to the GPSDO or that at the IF it is running its stability doesn’t spoil the Allan deviation.

The recording was made on 2019-11-24 22:45:50 UTC and lasted for 956 seconds. The format was IQ at 39062sps, with the BPSK beacon centred near 0Hz.

The Z3801A GPSDO used at Bochum was provided by James Miller G3RUH. He has sent me the figure shown below, which depicts the Allan deviation of the unit that is running in Bochum. We see that the deviation is around \(3\cdot 10^{-12}\) or \(4\cdot 10^{-12}\) for the range of \(\tau\)’s we are measuring in these experiments.

The recording has been processed with the GNU Radio companion flowgraph test_bochum.grc to obtain phase measurements. As usual, a Costas loop with a bandwidth of 10Hz is used to recover the suppressed carrier, and phase measurements at a rate of 100Hz are stored in a file. This file is then analysed with this Jupyter notebook.

Since in this experiment the transmitter and receiver of the BPSK beacon are both locked to the same clock, the interpretation of the results is simple: as explained in this post, it can be understood as a clock comparison between the Bochum GPSDO and the QO-100 NB transponder local oscillator at a frequency of 8089.5MHz.

The phase difference between the QO-100 local oscillator and the clock at Bochum after removing a linear trend due to frequency offset is shown in the figure below. The quadratic trend is caused by the movement of the satellite. The effects of Doppler in these kind of measurements were treated in my previous post.

Since the observation is short (slightly less than 1000 seconds), we can assume that the frequency drift due to Doppler is constant. Therefore, we can remove the Doppler by fitting a degree two polynomial to the phase difference shown above. The results are shown in the figure below. The frequency drift due to Doppler is \(4.5\cdot 10^{-14}\, 1/\mathrm{s}\). According to the theoretical study I did in the previous post, this is a typical value for the Doppler change rate. An improved measurement could be done at the moments when the Doppler change rate is zero, which happens twice a day.

The phase differece only drifts to +/-0.4ns, which is much better than the results obtained with the Vectron MD-011 GPSDO, so we already see that the Z3801A is much more stable.

The Allan deviation both for the measurements without removing the quadratic term (blue) and with the quadratic term removed (orange) are shown below. We see that for \(\tau\) between 1 and 10 seconds the Allan deviation is between \(2\cdot 10^{-12}\) and \(3\cdot 10^{-12}\).

For the blue trace, the frequency drift due to Doppler starts playing a significant role for \(\tau > 30\,\mathrm{s}\). Indeed, a constant drift of \(a\) in units of 1/s contributes to the Allan deviation as \(a \tau / \sqrt{2}\). Here we have \(a = 4.5\cdot 10^{-14}\, 1/\mathrm{s}\), and we are concerned with stability on the order of \(10^{-12}\), so the Doppler drift starts playing a role for \(\tau\) on the order of 10 seconds.

In the orange trace we see some indication about what the deviation would look like if Doppler was not present. I wouldn’t trust the values for \(\tau > 200\,\mathrm{s}\), where the deviation falls very steeply, as it is likely they are too unrealistic due to the procedure used to remove the Doppler.

My interpretation of the results of these measurements is that the QO-100 local oscillator is at least as stable as the Z3801A, for \(\tau\) between 1 and 100 seconds, and possibly somewhat more stable. The Allan deviation we have measured matches the characterization of the Z3801A done by James rather well. Note that James’ plot only goes down to 10 seconds, where the deviation is around \(2.5 \cdot 10^{-12}\), and we got a deviation of (2\cdot 10^{-12}\) at 10 seconds.

This means that the QO-100 local oscillator has a very good short-term stability. I think it would be hard to find an Amateur station having better stability, and in fact in my quest to measure the QO-100 LO Allan deviation I haven’t found any one yet. Achim points out that a good clock to measure the QO-100 LO would be the Oscilloquartz BV8607, which is below \(10^{-13}\). However these are rather hard and/or expensive to come by.

Many thanks to Achim, Mario, the rest of the AMSAT-DL team, and to James for their collaboration in this series of experiments.

]]>The Vectron MD-011 has an Allan deviation of \(10^{-11}\) at \(\tau = 1\,\mathrm{s}\) and \(2\cdot10^{-11}\) at \(\tau = 10\,\mathrm{s}\) according to the datasheet, so it is an improvement of an order of magnitude compared to my DF9NP TCXO-based GPSDO. I have made more measurements with the Vectron MD-011 as in my previous experiments, measuring the phase of the BPSK beacon transmitted from Bochum and a CW tone transmitted with my station. This post summarizes my results and conclusions.

The first experiment I did was a long measurement of the BPSK beacon phase. Recall from the previous post that this measurement is harder to interpret, since it involves three clocks measured a different frequencies: my station clock, the clock at Bochum, and the transponder local oscillator. Additionally, for long measurements, the satellite movement with respect to the groundstations needs to be taken into account.

The measurement was done on October 21 and 22, spanning a bit over 41 hours. The test_bpsk_beacon.grc GNU Radio flowgraph was used to recover the carrier phase of the beacon with a Costas loop (with 10Hz bandwidth) and write phase measurements at a 100Hz rate. These measurements are analyzed in a Jupyter notebook.

The figure below shows the BPSK beacon frequency offset. The 0Hz level in the graph is set arbitrarily so that the trace is more or less centred at zero. The daily sinusoidal Doppler curve can be seen easily. The frequency averaging period in this graph is 1 second.

The Doppler of Es’hail 2 has been thoroughly studied in several posts in this blog. For instance, this post shows some frequency measurements of the BSPK beacon done back in March. The Doppler curve resembles a sinusoidal curve with a period of one (sidereal) day and an amplitude of approximately 2ppb (or 20Hz). Most of the Doppler on the BPSK beacon is due to the downlink Doppler, owing to the large frequency ratio of 4.37 to one between downlink and uplink frequencies.

The Allan deviation is computed using the method of overlapping segments. It is shown in the figure below.

For \(\tau\) between 1 and 10 seconds the deviation is already limiting the measurement capabilities of the Vectron GPSDO. For \(\tau > 3\cdot 10^2\,\mathrm{s}\) we see the effects of Doppler starting to dominate, increasing the deviation a lot. When \(\tau\) equals one sidereal day, the Allan variance should drop a lot, because of the quasi-periodicity of the Doppler. This effect can be seen at the right-hand side of the figure.

The next experiments involved the measurement of the phase of the BPSK beacon transmitted by Bochum and a CW tone transmitted by my station simultaneously, in the manner described in this post. Three observations lasting between 14 and 45 minutes were made in different moments of the day on October 22 and 23.

To comply with the requirement to identify the transmissions, my signal consisted of a continuous CW tone transmitted at 2400.295MHz for the phase measurement and a telegraphy signal looping the message EA4GPZ FREQ TEST transmitted 500Hz below the main CW tone. This telegraphy signal was 6dB weaker than the main tone. The downlink power of the main tone was some 3dB weaker than the BPSK signal.

The GNU Radio companion flowgraph test.grc is used to transmit the measurement signal and take phase measurements. The phase of the BPSK beacon is detected with a Costas loop, while the phase of the CW tone is tracked with a PLL. Both use a bandwidth of 10Hz and the measurement frequency is 100Hz. The results are processed in this Jupyter notebook.

The figure below shows the phase measurement signal during one of the tests.

As explained in the previous post, by subtracting the phases of the CW tone and BPSK beacon, a comparison of the clocks at my station and Bochum at an observation frequency of 2.4GHz is obtained. The figure below shows the clock difference in nanoseconds for each of the three observations.

The difference reaches values of up to +/-10ns. This might seem large, since a good GPS receiver can compute a timing solution with a noise of perhaps 2 or 3ns. The reason for the variations much larger than 3ns is interesting. While the GPS solution can be rather precise, it is also very noisy, meaning that it varies significantly from epoch to epoch. If the GPSDO was to follow its timing solution closely, the short-term Allan variance would be horrible. Thus, the GPSDO pulls the OCXO slowly, to keep the short-term Allan variance as good as that of the free-running OCXO.

By letting the GPSDO phase difference grow up to 10ns, the Allan variance is kept smaller than by trying to make the difference as close to zero as possible. The Vectron GPSDO shows this quite well in a screen that shows the output offset with respect the timing solution and the OCXO DAC voltage. The offset often reaches 10ns, and the DAC voltage changes only after several seconds.

To analyse the Allan deviation we follow the same approach as in the previous post, except for the fact that the method of overlapping segments is used. The difference between the CW tone and the BPSK beacon is considered as a clock comparison between my station and Bochum at a frequency of 2.4GHz. The CW tone is considered as a clock comparison between my station and the QO-100 NB transponder local oscillator at a frequency of 8.1GHz. The BPSK frequency involves the three clocks at different frequencies, and is considered at a frequency of 10.5GHz (as the expression involves my station clock at this frequency).

The Allan deviation of the three observations is shown below. For reference, the deviation of the long observation of the BPSK beacon is shown in red.

Between \(\tau = 1\,\mathrm{s}\) and \(tau = 2\cdot10^2\,\mathrm{s}\) we get roughly the same results in all the observations and for all the three measurements (CW-BPSK, BPSK and CW). According to the discussion in the previous post, this means that the clock at my station is again the least stable clock in the system. This has come to me as a surprise.

After obtaining these results, I have asked Achim Vollhardt DH2VA what kind of GPSDO is used to generate the BPSK beacon in the AMSAT-DL groundstation in Bochum. He tells me that it is an HP Z3801A. This information also appears in the description of the hardware at the Bochum 20m antenna.

Apparently the Z3801A is one of the best GPSDOs ever made, and its Allan deviation at \(\tau = 1\,\mathrm{s}\) can reach \(10^{-12}\). This page shows an Allan deviation plot of the Z3801A, both locked and unlocked, and this page compares the Allan deviation of several unlocked Z3801A units. In view of these results, it is quite likely that the Bochum clock has an Allan deviation around or below \(10^{-12}\), so it is an order of magnitude better than the Vectron GPSDO I’m using.

Often the short-term stability of an OCXO is quoted to be \(10^{-11}\), so in this respect the OCXO in the Vectron GPSDO is average. It seems that the Z3801 uses a really good OCXO that in many units achieves performance around \(10^{-12}\). It is hard to beat this stability for \(\tau = 1\,\mathrm{s}\). A Rubidium standard will be around \(10^{-10}\) for short-term, and a Cesium standard will often be at \(10^{-12}\). A Hydrogen maser is needed to get significantly below \(10^{-12}\).

The details about the clock used in the QO-100 transponder are under NDA. The results of my experiments show that it is probably well below \(10^{-11}\) for \(\tau\) between 1 and 100 seconds.

The Allan deviation of each of the observations is shown below in separate figures for an easier comparison. While the first observation is too short to examine the medium-term behaviour for \(\tau\) bewteen \(10^2\) and \(10^3\) seconds, the other two observations show significantly different behaviour. These differences are caused by different Doppler behaviour and will be examined in the next section.

We have seen that for \(\tau > 2\cdot10^{2}\,\mathrm{s}\) the effects of Doppler start being noticeable. First let us discuss how each of the three different measurements are affected by Doppler. We denote by \(d_E\) and \(d_B\) the Doppler between Es’hail 2 and my station (EA4GPZ) and between Es’hail 2 and Bochum respectively, measured in parts per one.

For the CW-BPSK measurement, only the Doppler in the uplink legs is important, since the downlink leg is common for the CW and BPSK signals, so the downlink Doppler is cancelled. Also note that the two Dopplers act with opposite sign: a positive \(d_E\) makes the CW signal appear higher in frequency, while a positive \(d_B\) makes the BPSK signal appear higher in frequency. Thus, the total Doppler on the CW-BPSK measurement is \(f_U(d_E – d_B)\), where \(f_U\) is the uplink frequency. Since this measurement is considered at an observation frequency of \(f_U\), the Doppler is simply \(d_E – d_B\).

For the CW measurement, only the Doppler at EA4GPZ plays a role. Since the transponder is non-inverting, the Doppler on the uplink and downlink legs adds up, so the total Doppler is \((f_U + f_D) d_E\). Since this measurement is considered at an observation frequency of \(f_L\), the Doppler is \((f_U+f_D)d_E/f_L\). The factor \((f_U+f_D)/f_L\) is approximately 1.59.

For the BPSK measurement, the Doppler at Bochum plays a role at uplink, while the Doppler at EA4GPZ plays a role at downlink. Both Dopplers act with the same sign: a positive Doppler either at Bochum or EA4GPZ will make the BPSK beacon frequency appear higher. Therefore, the total Doppler is \(f_U d_B + f_D d_E\). Since this measurement is considered at an observation frequency of \(f_D\), the Doppler is \(f_U/f_D d_B + d_E\). The factor \(f_U/f_D\) is approximately 0.229.

The figure below shows the Doppler at EA4GPZ and Bochum in parts per billion. We see that the Doppler curves are very similar.

This similarity is caused by the motion of Es’hail 2 and the geometry between the stations and the satellite. The motion of Es’hail 2 is shown below in latitude, longitude and altitude coordinates. We see that its motion is a sinusoidal curve with an amplitude of 0.04 degrees in latitude and longitude, which corresponds to 27km at an orbital radius of 38000km, and 7km in altitude.

However, taking into account the geometry of the problem, we see that most of the Doppler comes from the variations in altitude, and so the Doppler is similar for all stations in the footprint. Since the Earth radius is small compared with the orbital radius, the line-of-sight vector for any groundstation is close to the vector between the Earth centre and the satellite. Indeed, all the groundstations lie within 9.7º off-nadir as seen from the satellite.

This means that the effect of horizontal (latitude and longitude) movement on the Doppler is reduced significantly. Moreover, Madrid and Bochum are relatively close, so the Doppler due to horizontal movement seen in both stations is similar. More information about the effect of Es’hail 2 movement in Doppler can be found in this post.

Taking into account the remarks above about how Doppler affects each of the three different measurements, we get the following figure. Since the CW-BPSK Doppler equals \(d_E – d_B\) and \(d_E\) and \(d_B\) are similar, it is much smaller than the others. Assuming that \(d_E = d_B\), we have that the CW Doppler is 1.29 times the BPSK Doppler.

Allan deviation is not sensitive to frequency offset, but rather to frequency drift. Therefore, it is affected by Doppler change rate. In fact, for a frequency drift of \(a\) 1/s, the Allan deviation is \(a\tau/\sqrt{2}\). The figure below shows the Doppler change rate that affects each of the measurements. For the CW and BPSK measurement the change rate peaks at around \(10^{-13}\). Therefore, for \(\tau = 10^{2}\) the effects of Doppler start to be on the order of \(10^{-11}\) and are thus visible in the Allan deviation. The Doppler in the CW-BPSK measurement is much smaller.

The figures shown above have been obtained in this Jupyter notebook.

For medium-term measurements the Doppler change of rate can be assumed to be constant. Therefore, it can be estimated and removed by fitting a degree 2 polynomial to the phase measurements. As shown in the figure below, if we remove this quadratic term from the phase measurements, the Allan deviation of all the observations now decreases for \(\tau\) greater than \(2\cdot 10^2\,\mathrm{s}\), since most of the contribution of Doppler has been cancelled.

Observation 1 is perhaps too short for a good estimation of the frequency drift due to Doppler, but observations 2 and 3 give the following good estimates of the drift in units of 1/s:

- Observation 2: CW-BPSK \(8.96\cdot10^{-15}\), BPSK \(4.12\cdot10^{-14}\), CW \(5.60\cdot 10^{-14}\).
- Observation 3: CW-BPSK \(4.89\cdot10^{-15}\), BPSK \(-4.62\cdot 10^{-15}\), CW \(-4.52\cdot10^{-15}\).

We see that there is a difference of an order of magnitude in the drift of the BPSK and CW measurements between observations 2 and 3. The reason is that the observations were done at different moments of the Doppler curve. Observation 2 was made on 2019-11-22 22:08 UTC, when Doppler change rate was high. Observation 3 was made on 2019-11-23 17:10 UTC, when Doppler change of rate was low.

This explains the difference in the Allan deviations of observations 2 and 3. For observation 2, the Doppler in the BPSK and CW measurement is large and appears in the Allan deviation. However, the Doppler in the CW-BPSK measurement is too small to be noticeable, except for \(\tau > 6 \cdot 10^2\), when the deviation starts increasing again. In observation 3, the Doppler in all the three measurements is small, so the deviation decreases until \(\tau = 7\cdot 10^2\), when it starts to increase again.

These experiments have shown that the short-term stability of the QO-100 NB transponder local oscillator is better than \(10^{-11}\), so the Vectron MD-011 cannot be used to measure it. The GPSDO at Bochum seems much better than \(10^{-11}\), so perhaps measurements of the transponder local oscillator can be done by receiving the BPSK beacon at Bochum.

The short-term stability of the QO-100 NB transponder local oscillator is better than that of most Amateur stations. The idea to measure the stability of the transponder LO started with some questions from Amateurs interested in running VARA and other OFDM modes which need a lot of frequency stability through the transponder. These measurements show that the transponder is not the limiting factor when using modes that need frequency stability.

The effect of Doppler in the measurements has been studied. The frequency drift \(a\) is on the order of \(10^{-13}\) 1/s and contributes to the Allan deviation as \(a\tau/\sqrt{2}\), so for the measurement precision of \(10^{-11}\) that we are analysing here it starts playing a role for \(\tau > 100\,\mathrm{s}\). For a study down to \(10^{-12}\), the Doppler needs to be taken into account for \(\tau > 10\,\mathrm{s}\). However, for medium-term measurements the Doppler change rate can be assumed constant and cancelled by subtracting a quadratic term from the phase measurements.

]]>Before starting the measurements with QO-100, I have taken the time to use the Vectron GPSDO to measure the Allan deviation of my DF9NP GPSDO over several days. This post is an account of the methods and results.

The DF9NP GPSDO is based on a 10MHz VCTCXO phased locked to an 800Hz signal coming from an uBlox LEA-4S GPS receiver. Since it doesn’t use an OCXO, it is inexpensive, doesn’t use much power and locks relatively fast. However, its stability is not as good as that of an OCXO-based GPSDO. In my experiments with QO-100 I measured an Allan deviation of \(10^{-10}\) for \(\tau\) between 1 and 10 seconds, which is typical of a TCXO.

The Vectron GPSDO that I’m using is the C6300 series evaluation kit for the MD-0113-BXJ-DAOC. Its datasheet advertises an Allan deviation of \(10^{-11}\) for \(\tau = 1\mathrm{s}\) and \(2\cdot 10^{-11}\) for \(\tau = 10\mathrm{s}\), and great holdover characteristics. It has been running for a couple of days before the start of the experiment, and so it has surveyed in the position of my GPS antenna and it is using a fixed position for its navigation solution.

Both GPSDOs are connected to the same GPS antenna via an (improperly terminated) T-connector. The antenna is a simple patch antenna and is located in a less than ideal position, near the ledge of a north-facing window, so it has only partial view of the southern sky.

I am using a LimeSDR-USB to compare the phases of the GPSDOs 10MHz outputs. To do so, the DF9NP GPSDO 10MHz output is used as an external reference in the LimeSDR as described in this post. The 10MHz output of the Vectron GPSDO is connected to the RF input of the LimeSDR through sufficient attenuation. This attenuation is provided by a Mini-Circuits ZFDC-10-1 directional coupler as follows: the OUT port is connected to the GPSDO 10MHz output, the IN port is terminated with a 50 Ohm load, and the CPL port is connected to the LimeSDR-USB. This is another less than ideal solution, but it gives lots of attenuation.

The LimeSDR-USB is tuned to 9.9MHz with a sample rate of 2Msps. This is possible by setting the LO to 30MHz, running with 32x oversampling, so the DAC rate is 64Msps, and using the NCO at -20.1MHz. This allows us to receive the 10MHz signal from the Vectron GPSDO at 100kHz in the IQ baseband.

A GNU Radio companion flowgraph is used to lock a PLL to the signal and take phase measurements. A bandwidth of 10Hz is used for the PLL and the phase measurements are taken at a 100Hz rate. These are saved to disk for later analysis. The GRC flowgraph can be downloaded here and is shown in the figure below.

According to the phase measurements, the Vectron GPSDO signal is not exactly at 10MHz. There is an error of approximately 0.168mHz. This is caused by the frequency synthesizers of the LimeSDR: the ADF4002 doesn’t multiply the 10MHz reference coming from the DF9NP GPSDO by 30.72 exactly to yield the 30.72MHz LMS7002M clock, and likewise, the LMS7002M doesn’t multiply its 30.72MHz clock exactly by 30/30.72 to yield the 30MHz LO. Moreover, the NCO doesn’t run exactly at -20.1MHz, and the sample rate is not exactly 2MHz. Therefore, the 10MHz signal from the Vectron ends up with some small frequency error in the IQ baseband. This doesn’t affect the Allan deviation, however, so we will ignore this effect in the rest of this post.

The measurements were done between 2019-11-17 21:55 and 2019-11-20 18:15 UTC. However, there are phase jumps around 2019-11-20 04:58:00 UTC, most likely because the DF9NP GPSDO lost GPS lock at that moment. For simplicity, only the segment of measurements between 2019-11-17 21:55:31 and 2019-11-20 04:57:30 is used in the analysis. This amounts to almost 200000 seconds worth of measurements.

The figure below shows the phase difference between the two 10MHz signals after removing the linear drift caused by the instrumental 0.168mHz offset. The RMS phase difference is 14ns, and occasionally we get differences up to 80ns. This is well in line with the usual performance of the 1PPS (or other timepulse signal) of a non-timing-grade GNSS receiver, so we can expect this kind of performance from the DF9NP GPSDO.

The figure below shows the Allan deviation computed using the method of overlapping segments. In blue we show the measurements obtained in this post, while in orange we show a clock comparison between the DF9NP GPSDO and the GPSDO at the QO-100 groundstation in Bochum (Germany) done over the QO-100 NB transponder as described in this post. Both traces measure the performance of the DF9NP GPSDO, since the Vectron and the Bochum GPSDOs are much better.

The same kind of behaviour appears in both traces, although the orange trace is slightly lower. This might be caused by the different instrumental setup used in each of the measurements. The blue trace was obtained at an observation frequency of 10MHz, while the orange trace was obtained at an observation frequency of 2.4GHz using an S/X satellite link.

The longer measurement span done in this post shows the Allan deviation up to \(\tau = 10^5\mathrm{s}\). We see that for \(\tau > 10^2\mathrm{s}\) the GPS disciplination kicks in and the Allan deviation decreases by an order of magnitude per decade. Between \(\tau = 1\mathrm{s}\) and \(\tau = 10^2\mathrm{s}\) we see an Allan deviation around \(10^{-10}\), dominated by the stability of the TCXO.

The calculations and figures in this post have been done in this Jupyter notebook.

]]>Yesterday, the LROC team published a post saying that they had been able to find the crash site in an image taken by the LRO NAC camera on October 5. The impact crater is only 328 metres away from the location I had estimated.

This is amazing, as in some way it represents the definitive end of the DSLWP-B mission (besides all the science data we still need to process) and it validates the accuracy of the calculations we did to locate the crash site. I feel that I should give due credit to all the people involved in the location of the impact.

Wei Mingchuan BG2BHC from Harbin Institute of Technology was the first to take the orbital information from the Chinese Deep Space Network, perform orbit propagation and compute the crash location assuming a spherical Moon, thus obtaining an approximate position in Van Gent X crater. Cees Bassa from ASTRON refined Wei’s calculations by including a digital elevation model. Phil Stooke from Western University first suggested to use a digital elevation model, helped us contact the LROC team, and filled in an observation request for the camera. And of course the LROC team and the Chinese DSN, since the quality of their ephemeris for DSLWP-B allowed us to make a rather precise estimate.

The LROC team has posted the images shown below, where in a comparison between an image taken in 2014 and the image taken in October the small crater can be seen.

The image of the crash is M1324916226L, an image taken by the left NAC camera. However, I can’t find this image yet in the LROC archive, so it seems this image hasn’t been made public yet.

The small crater, which the LROC team estimate to be 4×5 metres in diameter, is visible more clearly if we compute the difference between the before and after images (an idea of Phil Stooke). The figures below show this difference both as a signed quantity and as an absolute value.

Though my eye fails to see it, the LROC team says that the long axis of the crater is oriented in a southwest-northeast direction. This is consistent with the direction of the impact, since DSLWP-B was travelling towards the northeast.

For the comparison with the October 5 image, the LROC team has chosen an image taken with a similar illumination angle. In fact, the lunar phase in both images only differs in 10º, so the shadows are very similar, with the sun located towards the southwest. In fact, the newest image of the area was taken on 2018-10-16, but the one from 2014 probably gave the most similar illumination conditions.

In my post in August I included a link to Quickmap showing the estimated area of the impact. Now I have marked in red the location of the crash. For a sense of scale, the large crater northwest of the crash is some 50 metres in diameter. You can see both points in Quickmap here.

It is good to go back to all the simulations I did to have an idea of what the 328m error represents. My final simulation was done with the ephemeris from July 25, so they were 6 days old at the moment of impact. When I used the ephemeris from July 18, the position of the impact changed by 231m, while the ephemeris from June 28 yielded a change of 496m. Therefore, it seems that an error of 300m is well in line with what we could expect of the precision of the Chinese DSN ephemeris.

The impact location computed by Cees Bassa was 2786m away from my estimate. The main problem with Cees’s estimate is that the orbital model he used considered spherical gravity for the Moon, while my studies showed that it was important to consider non-spherical gravity.

I did most of my simulations with a 10×10 spherical harmonic model for the Moon gravity, but to assess whether this was enough, I also made a simulation with a 20×20 spherical harmonic model. This yielded an impact point which was 74m away from the impact computed with the 10×10 model.

According to my Monte Carlo simulations with a 1km ephemeris error, the 1-sigma ellipse semi-axes of the impact position were 876m in the northeast direction and 239m in the southeast direction. With this information, I gave an educated guess of the position error of 600m in the northeast direction and 200m in the southeasth direction. The actual impact point is 328m northwest of my estimate, so somewhat higher than my error estimate but still within the 2-sigma ellipse. This leaves me quite happy with the quality of my estimate.

]]>Of course, as with any measurement problem, the performance of the measurement equipment should be better than the “device under test”. In this case, to measure the QO-100 LO it is necessary to compare it against a reference clock which is more stable (ideally an order of magnitude better).

My whole station is locked to a DF9NP GPSDO, which is a 10MHz VCTCXO disciplined by a uBlox LEA-4S GPS receiver. That’s great to measure long-term stability, but for short-term measurements you are essentially relying on the stability of the VCTCXO, which is not so great. Therefore, the whole purpose of this experiment is first to determine whether my station is actually able to measure the QO-100 LO or not. Spoiler: it turns out the answer is “no”, as in most articles whose title is phrased as a question.

The main idea of the experiment is to transmit a CW tone through the NB transponder with my station, receive it on the downlink and perform phase measurements of the received tone. In this measurement there are two clocks involved: the reference GPSDO at my station and the QO-100 LO, and the measurement doesn’t tell us anything about how these two clocks compare (i.e., which one is more stable).

To help us with this situation, we rely also on the BPSK beacon. This is transmitted by AMSAT-DL‘s groundstation in Bochum, Germany. The transmitter is locked to a GPSDO of some sort. I can receive the BPSK beacon with my station and perform phase measurements of the BPSK signal.

Before jumping to the measurement setup, let us consider what we can achieve with these two measurements. We are able to measure at my station \(\varphi_{\mathrm{CW}}\) and \(\varphi_{\mathrm{BPSK}}\), the phases of the CW and BPSK signals. There are three clocks involved in the system: the GPSDO at my station, which I will denote as \(t_{\mathrm{EA}}\), the GPSDO at Bochum, which I will denote as \(t_{\mathrm{B}}\), and the QO-100 local oscillator, which I will denote as \(t_{\mathrm{QO}}\).

There are also three frequencies involved in the measurements: the downlink frequency \(f_D = 10489.8\mathrm{MHz}\), the uplink frequency \(f_U = 2400.3\mathrm{MHz}\), and the QO-100 LO frequency \(f_L = f_D – f_U = 8089.5\mathrm{MHz}\).

Writing the phase measurements in units of cycles and ignoring affine terms (which are ignored by Allan deviation), we have\[\begin{split}\varphi_{\mathrm{CW}} &= f_L (t_{\mathrm{QO}} – t_{\mathrm{EA}}),\\\varphi_{\mathrm{BPSK}} &= f_L t_{\mathrm{QO}} + f_U t_{\mathrm{B}} – f_D t_{\mathrm{EA}},\\\varphi_{\mathrm{CW}} – \varphi_{\mathrm{BPSK}} &= f_U (t_{\mathrm{B}} – t_{\mathrm{EA}}).\end{split}\]

As we see, the differential measurement \(\varphi_{\mathrm{CW}} – \varphi_{\mathrm{BPSK}}\) is useful because it cancels the QO-100 local oscillator. Indeed, it gives a clock comparison between the clocks at Bochum and my station made at 2.4GHz. The measurement of \(\varphi_{\mathrm{CW}}\) gives a clock comparison between QO-100 and my station at 8GHz, while the \(\varphi_{\mathrm{BPSK}}\) measurement is harder to interpret, as it involves all three clocks and frequencies.

For the measurement setup, the hardware at my station consists of a DF9NP 10MHz GPSDO, a DF9NP PLL that multiplies the 10MHz reference to 27MHz, an Avenger Ku-band PLL-based LNB which generates a 9750MHz LO from the 27MHz reference, and a LimeSDR Mini clocked off the 27MHz reference that receives at the 740MHz IF and transmits directly at 2.4GHz.

From the software side, I am using my `limesdr_linrad`

tool from the qo100-groundstation repository and GNU Radio. This GNU Radio flowgraph generates the CW tone so that it ends up 5kHz below the BPSK beacon frequency and performs phase measurements of the tone and the BPSK beacon on the downlink. The phase of the tone is measured with a PLL, while the phase of the BPSK beacon is measured with a Costas loop. Phase measurements of each of the signals are written to a file at a rate of 100Hz. The file is then processed in this Jupyter notebook to compute and plot Allan deviation.

The measurement test was made on 2019-11-10, between 11:10 and 11:20 UTC. A continuous CW tone was transmitted approximately 5kHz below the BPSK beacon. Its power was adjusted so that the downlink power was 2dB lower than the BPSK beacon. The phase measurements obtained during the tests are in this file. It is somewhat longer than the 10 minutes that the test lasted “officially”, since I started a bit earlier in order to transmit a CW identification with my callsign and ended up a bit late to transmit another CW identification.

The figures below show the GNU Radio flowgraph performing the phase measurements during the test and Linrad monitoring the transponder downlink. Note that Linrad was only used for monitoring, and not involved in the measurement process.

The plot of the Allan deviation of the measurements is shown below. Note that to compute the Allan deviation of a time series of clock comparisons, you need to know the frequency at which these clock comparisons were made. The equations above show that the CW-BPSK measurements were done at a frequency of 2.4GHz, while the CW measurements were done at 8GHz. The BPSK measurements involve several clocks and frequencies, so it is not clear what to do without further considerations. However, if we use 10GHz as the measurement frequency for the BPSK measurements (as done in the plot below), we see that the three traces line up neatly for \(\tau > 0.5\mathrm{s}\).

For the interpretation of these results, first we know that the CW-BPSK and CW measurements have roughly the same deviation. The clock which appears in both measurements is my station’s clock \(t_{\mathrm{EA}}\). This means that my station clock is less stable that the clocks at Bochum or QO-100, so it can’t possibly be used to measure the QO-100 LO. Since \(t_{\mathrm{EA}}\) is less stable than the two other clocks, it is the dominating term in \(\varphi_{\mathrm{BPSK}}\). This justifies our choice of 10GHz as the measurement frequency when computing the Allan deviation for the BPSK measurement, since \(\varphi_{\mathrm{BPSK}}\) turns out to be a measurement at 10GHz of my station’s clock.

In conclusion, my clock is less stable than the clocks at Bochum or QO-100, so the Allan deviation shown for \(\tau > 0.5\mathrm{s}\) is just a measurement of the Allan deviation of my clock. At least this measurements place an upper bound on the stability of the QO-100 local oscillator. We see that it is better (probably much better) than \(7\cdot10^{-11}\) for \(\tau = 1\mathrm{s}\).

There seems to be interesting data about phase noises in the Allan deviation for \(\tau < 0.1\mathrm{s}\), but I haven’t done an interpretation of that data.

It would be interesting if other stations with more stable clocks can participate in this kind of measurements. A good OCXO would be ideal for this kind of short-term stability measurements.

]]>I wasn’t so sure how well this would work, since there are a few threads with questions in the MiriadRF forums, but I haven’t seen any explaining things in a clear way. There are different anecdotes of things that worked or didn’t work for several people, but not that many definitive answers. Among all the threads, this one seems mostly helpful.

Somewhat surprisingly, everything has worked well on the first try. I am now using a 27MHz external reference with my LimeSDR Mini. Hopefully this post will be of help to other people.

The relevant part of the LimeSDR Mini v1.2 schematic is shown in the figure below (click on it to view it in full size).

As we see, there is a 40MHz VCTCXO that feeds an LMK00105 clock buffer. This fans out the clock to different parts of the LimeSDR Mini, including the LMS7002M RFIC (TxPLL_CLK and RxPLL_CLK), the FPGA (LMK_CLK), and the clock output U.FL connector (REF_CLK_OUT).

It is possible to feed in an external clock instead of using the VCTCXO by removing the 0 Ohm resistor R59 and installing R62, which is not fitted by default. The 0 Ohm resistor R62 goes directly to the clock input U.FL connector.

The figure below shows the LimeSDR Mini board. R59 and R62 are located in the smaller red box. There are only three pads for the two resistors, so they share a common pad and it is only possible to install one of them. To switch R59 to R62, it is enough to rotate the resistor in the red box by 90º (so in the figure the resistor would be rotated from a horizontal position to a vertical position).

This is the only hardware modification that needs to be done. There is also the question of the electrical specifications of the external reference signal. The LMS7002M datasheet says that the chip accepts a PLL reference between 10MHz and 52MHz.

Additionally, we need to take care about what the LMK00105 accepts. Its datasheet says that for a single-ended clock supplied through the CLKin pin, the peak-to-peak voltage swing should be between 0.3V and 2V. Since the clock input connector of the LimeSDR Mini is terminated to 50 Ohms, the clock input should be between -6 and 10dBm.

In my case, I am using a DF9NP PLL to generate the 27MHz reference. This gives a sine output with an open circuit voltage of 3.1V, which would give around 7.8dBm (or maybe a bit less) to a 50 Ohm load. Between the PLL and the LimeSDR Mini I have several metres of 75 Ohm coax and a 3dB splitter, so the clock input to the the LimeSDR mini is probably around 3dBm, perfectly within margins.

Finally, there is the matter of software. The LimeSuite driver needs to know about the reference frequency that you are feeding to the LimeSDR Mini. This is done by calling the `LMS_SetClkFreq()`

function in the LimeSuite API. Probably it is best to do this right after initializing the chip, before setting up the sample rate or LO frequencies. As an example, you can see here how I am doing it in my `limesdr_linrad`

software (which was described in this post).

These are all the steps needed to use an external reference with the LimeSDR Mini. Apparently it is possible to use any external clock between 10 and 52MHz just by changing a resistor and calling an API function. In particular, it is not necessary to modify the FPGA gateware. I understand that there is a NIOS CPU in the FPGA gateware that runs from the reference clock. This means that this CPU will run slower or faster depending on which reference frequency you use, but I don’t think it is a major concern.

]]>