[amsat-bb] Doppler measurment of TCA
Zach Leffke
zleffke at vt.edu
Tue Nov 27 19:53:37 UTC 2018
Hi Jim,
This is a topic I have a LOT of interest in, but only a limited amount
of experience in. Here comes one of my long emails, apologies in
advance and I tried to break it into a short version and a long version
(read the long version for the caveats):
Short version:
I've got some GNU Radio flowgraphs here that might be a good starting
point...maybe:
https://github.com/zleffke/flowgraph_sandbox/tree/master/fox1d
And some python scripts for computing TCA from measured data (from GNU
Radio) and comparing TCAs generated from TLEs to find the closest
match: The code can be found here (warning: VERY kludgy, but worked for
Fox-1D): https://github.com/zleffke/tle_match
Longer version:
First off, I should mention around the launch of Fox-1D I attempted to
tackle this and the result is a big steaming pile of.....code....but it
worked and identified Fox-1D in the sea of deployments from PSLV-40.
The reason I know it worked, is that by the time I finished writing the
scripts, the answer had already been found by Nico, PA0DLO and posted to
the BB.
The code can be found here: https://github.com/zleffke/tle_match
Basically, that link is a couple of python scripts that take in doppler
measurements generated by a GNU Radio flowgraph, and performs a
regression to get the equation for a doppler 'S-Curve' from the
measurements of an actual satellite's downlink. A different script
takes all the TLEs from PSLV-40, and given the known downlink center
freq of the target, generates doppler curves / equations for all of the
spacecraft (using 'pyephem' for the TLE processing). The final script
takes the measured single equation and the generated 28 equations (from
PSLV-40) and finds Time of Closest approach to determine which
spacecraft most closely matches, then prints the answer.
Lots of planned improvements for this......not really a 'finished
product' more of a rapid hack.
For the measurement I used GNU Radio. The core of the flowgraph used an
'FLL' block to lock onto the downlink. The block outputs the error
offset....which after a bunch of conversions to units of Hertz, is
written to a file at a rate of 10 Hertz. retaining 'time' in some form
is very important and the flowgraph I used does this by encoding the
start of the recording in the filename in UTC format to the milisecond.
Everything after that is done using conversions relative to the initial
timestamp (also VERY kludgy). Another very important note is that in my
case I recorded the downlink during one of the first high speed mode
camera tests, so very strong and continuous downlink. For bursty
signals (like short FM transmissions, or a CW beacon) the flowgraph I
used would not be ideal and probably wouldn't work at all.
Its been so long since Fox-1D deployed, I can't remember if i retained
the actual flowgraph I used for this on github. Best bet is to look here:
https://github.com/zleffke/flowgraph_sandbox/tree/master/fox1d
If the specific flowgraph isn't there, its lurking on a laptop somewhere
waiting to be found and pushed to github.....
Future Improvements I want to make (though once again have run out of
time since the countdown is now in hours for FOX-1Cliff) include a few
things. First, the measurement technique relies on a strong and
continuous downlink signal to lock onto. I'm looking at using some of
the blocks for handling bursts (like gr-eventstream) to not have to rely
on the continuous downlink. Second, the way I retain 'time' by encoding
in the filename of the capture is a total kludge. UHD takes a few
seconds to start up, so at best I'm maybe a few seconds off with with
the timestamp. Also, this assumes that NTP is working and the host OS
time is relatively accurate, so being able to tie into UHD directly and
GPSDOs for the time stamping should be way more accurate. Third, my raw
10 Hz dump to file technique is OK, but could be a lot better. I'm
looking at changing this out for 'gr-sigmf' blocks to retain all
metadata associated with a pass, more specifically using the
'annotations' objects to log off the doppler offset measurements (sigmf
is an open standard for signal metadata file formatting, based around
JSON). Overall improving the collection method and the metadata logging
should go a long way to improving the accuracy of the timestamping,
leading to better results.
Finally, concerning the actual TLE matching.......comparing TCA only is
not the most robust technique, especially if there are frequency offsets
in the downlink center freq. TCA is a magic moment for satellites and
ground stations. not only does it yield the moment when range is a
minimum, it can also tell you the exact downlink center frequency of the
satellite, assuming you trust your receiver center frequency (in the
VTGS we use a GPSDO to discipline the SDR, so I do 'trust' my frequency
measurements). On Fox-1A there was a slight offset from the planned
downlink center and the actual downlink center. So looking at TCA can
reveal the ACTUAL downlink center freq to shift the S-Curves generated
from the TLEs to be more accurate. This might matter for those few TLEs
that are VERY VERY close to each other (like 3 1Us in the same deployer
a few days after launch).
TCS is not a perfectly straight line (pretty close to one though), but
is actually and inflection point. So derivatives and double derivatives
of the regression polynomials can yield the exact TCA. And speaking of
polynomials........they aren't the best way to do a regression of the
measured data or to rpresent the generated data. A student I work with
and I have just written a paper for IEEE Aerospace Conference where we
examined this in more detail and the 'Logistical Curve' appears to be a
better form of equation than a polynomial. We did that for the purposes
of a satellite simulator for GNU Radio, but the same curve fitting for
the logistical function rather than a polynomial should yield more
accurate results as well.
Finally, getting back to comparing TCAs only.....I'm not convinced this
is the best way to do it. I'm not a mathemetician, so please forgive if
I use the wrong words here. Doppler curves have 'shapliness' based a
number of factors (orbit, gs, relation between the two, pass geometry
max el, etc.). Comparing TCA only is a single instant in time, which
may not be an actual data point that was measured or computed, and may
be based on regression or interpolation between adjacent data points
(this is why a logistical regression that I "think" is more accurate
than a polynomial regression matters). There should be a way to compare
the entire window of data between measured doppler and TLE generated
doppler to compare the 'sameness' of the two curves based on their
'shapliness' (again, apolgies for not having the right terminology
here.........things like minimum mean squared error might be a more
accurate wording or at least a step in that direction). This may offer
things like a robustness against frequency errors in the measurements.
If you don't 'trust' the received frequency, or if there is an
unaccounted for error in the transmit frequency (like an offset of
around - 2.5kHz that happened on fox-1a) that might throw off the TCA
computation, thus affecting your guess at the match. If instead you can
compare the shape of the entire window of data and find two that have
the closest 'shape' then it might not matter if one of them is offset a
bit in frequency since your not looking for a zero crossing that might
be at wrong value.
OK, I'm done typing. I love this stuff! One day when I find time I
want to refine all these scripts and flowgraphs to have a better system
for all this...
Hope this helps!
-Zach, KJ4QLP
Research Associate
Aerospace Systems Lab
Ted & Karyn Hume Center for National Security & Technology
Virginia Polytechnic Institute & State University
Work Phone: 540-231-4174
Cell Phone: 540-808-6305
On 11/27/2018 2:18 AM, Armand SP3QFE wrote:
> Hi Jim, Hello Everyone,
>
> Jim as you wrote... at TCA, the Doppler shift is equal to zero.
>
> You can try to find this point directly from your screen when the
> frequency is equal. However, it is worth to remember that the
> transmitter on the satellite has a shift (the VFO) or your frequency
> scale in your SDR is not perfectly calibrated.
>
> For that reasons, I suggest to write down as much as possible points:
> the value of frequency and its time. After that, you can plot the
> diagram, which should be more or less similar to "S" (or it's mirror).
> The shape of the "S" depends on the maximum elevation of the satellite
> for your location and sometimes it can be straight line "/" or "\".
>
> Then on the plot, you can very easily find the symmetry center of this
> plot. This point is for the TCA.
> PS. For straight line you should not have the antena obscurations to
> find "the center".
>
> 73, Armand SP3QFE
>
> On 2018-11-27 01:47, Jim White wrote:
>> Wednesday's launch of a large batch of satellites seems an opportunity
>> to try the Doppler shift method of matching a satellite to a set of
>> keps.
>>
>> In reading a few blogs and posts it seems the method is to use an SDR
>> and GNURadio tools to determine the time of TCA for a downlink signal.
>> Then use a tracking program to provide the TCA time for several sets
>> of keps. And finally to match the observed/calculated TCA with one set
>> of keps. Can anyone provide a pointer to a GNURadio flow diagram that
>> includes a tool to calculate TCA time from the signal received during
>> a pass? I'm pretty new to GNURadio so finding such resources is still
>> a bit of a mystery for me.
>>
>> Jim
>>
>> _______________________________________________
>> Sent via AMSAT-BB at amsat.org. AMSAT-NA makes this open forum available
>> to all interested persons worldwide without requiring membership.
>> Opinions expressed
>> are solely those of the author, and do not reflect the official views
>> of AMSAT-NA.
>> Not an AMSAT-NA member? Join now to support the amateur satellite
>> program!
>> Subscription settings: http://www.amsat.org/mailman/listinfo/amsat-bb
> _______________________________________________
> Sent via AMSAT-BB at amsat.org. AMSAT-NA makes this open forum available
> to all interested persons worldwide without requiring membership.
> Opinions expressed
> are solely those of the author, and do not reflect the official views
> of AMSAT-NA.
> Not an AMSAT-NA member? Join now to support the amateur satellite
> program!
> Subscription settings: http://www.amsat.org/mailman/listinfo/amsat-bb
More information about the AMSAT-BB
mailing list