[amsat-bb] Doppler measurment of TCA
Zach Leffke
zleffke at vt.edu
Tue Nov 27 20:57:12 UTC 2018
I can't count.....3 additional points (though 2 and 3 are linked, and
started as one idea).
-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 3:54 PM, Zach Leffke wrote:
> 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
>
> _______________________________________________
> 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