[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