Email Detail

HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

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