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 [email protected]. 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 [email protected]. 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

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 [email protected]. 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 [email protected]. 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 [email protected]. 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 [email protected]. 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