[amsat-bb] Doppler measurment of TCA

Tue Nov 27 20:54:29 UTC 2018

I should also mention two additional points/ideas:

1.  Everything I wrote about in the long email is based on a single pass 
TLE matching technique.  A further improvement/refinement I want to 
include is being able to process multiple passes worth of measurements, 
again to refine the accuracy of the estimates.

2.  The extension of the above idea is to incorporate these ideas into 
something like FoxTelem to 'crowd source' the TLE match.  I think there 
already exists a doppler measurement feature if you are using FCDPP 
directly in FoxTelem (audio loopback doesn't work, need the IQ).  I also 
know a few folks have looked at using the 'FoxTail' in the downlink as a 
reference for beacon measurement (Douglas!).  The python code (or at 
least the TLE comparison technique, not my steaming pile of code...) 
could be implemented on the Fox Server side to do the TLE matching.  
This way, by participating in telemetry collection, the entire community 
could help identify 'our bird' just by collecting TLM and forwarding to 
the server.  This probably won't happen for Fox (definitely not Cliff, 
maybe E......), but maybe if we plan ahead for GOLF..........GolfTelem?

3.  Having multiple *simultaneous* collections from different ground 
stations leads to the potential for more direct orbit determination.  If 
we can get something like what I mentioned in #2 going.....at least the 
part about forwarding doppler measurements with time stamps, then we 
could come up with an orbit determination technique that doesn't rely on 
pre-launch TLEs for the 'synthetic' data we are comparing to the 
measured doppler curve.  We could instead generate our own TLEs directly 
(and continuously, not just for post-launch identification).  The range 
rate information and TCA information could be used in conjunction with 
existing geolocation techniques (like GPS, but flipped) and existing 
orbit determination and orbit estimation algorithms. Lots of caveats and 
such to make that system realizable.........(controlling timestamps, NTP 
quality, FCDPP drift, other SDRs contributing, etc......).  Again 
probably a very 'would be nice' type feature........

-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:53 PM, Zach Leffke wrote:
> 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
>
> _______________________________________________
> 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