| |
CX2SA > SATDIG 27.11.18 23:17l 1162 Lines 50220 Bytes #999 (0) @ WW
BID : AMSATBB13392
Read: GUEST
Subj: AMSAT-BB-digest V13 392
Path: IW8PGT<IZ3LSV<IK6ZDE<I0OJJ<EA2RCF<CX2SA
Sent: 181127/2109Z @:CX2SA.SAL.URY.SOAM #:59062 [Salto] FBB7.00e $:AMSATBB13392
>From cx2sa%cx2sa.sal.ury.soam@i0ojj.ampr.org Tue Nov 27 22:14:48 2018
Received: from i0ojj.ampr.org by i0ojj.ampr.org (JNOS2.0k.3b) with SMTP
id AA63548 ; Tue, 27 Nov 2018 22:14:48 +0100
Message-Id: <AMSATBB13392@ea2rcf.bbs>
>From: cx2sa@cx2sa.sal.ury.soam
X-JNOS-User-Port: Telnet (ea2rcf @ 94.177.237.192) -> Sending message
From: CX2SA@CX2SA.SAL.URY.SOAM
To : SATDIG@WW
Today's Topics:
1. Re: Visiting Australia (Eric Fort)
2. Re: VHF/UHF/Satellite items for sale (Tucker McGuire)
3. Re: PSLV launch Thursday 29th November (christy hunter)
4. Re: Doppler measurment of TCA (Zach Leffke)
5. AO-92 U/v or L/V mode????? (Vincenzo Mone)
6. Re: AO-92 U/v or L/V mode????? (Andrew Glasbrenner)
7. Re: Doppler measurment of TCA (Zach Leffke)
8. Re: Doppler measurment of TCA (Zach Leffke)
----------------------------------------------------------------------
Message: 1
Date: Tue, 27 Nov 2018 09:01:52 -0800
From: Eric Fort <eric.fort.listmail@??????????????.???>
To: Colin Hurst <cjhurst@???????.???.??>
Cc: amsat-bb <amsat-bb@?????.???>
Subject: Re: [amsat-bb] Visiting Australia
Message-ID: <8F760256-9A9B-41D6-8BD6-D9F1A503D230@??????????????.???>
Content-Type: text/plain; charset=us-ascii
This ought cover it:
https://www.acma.gov.au/Industry/Spectrum/Radiocomms-licensing/Class-licences/
overseas-amateurs-visiting-australia
Google - Arellano reciprocal licensing - above link
Sent using SMTP.
> On Nov 22, 2018, at 7:21 PM, Colin Hurst <cjhurst@???????.???.??> wrote:
>
> Franklin,
> Try this link
> https://www.wia.org.au/search.php?cx=003450235088133466407%3Atzhh7alkgzu&cof
> =FORID%3A11&q=reciprocal+licensing&sa=Search
> Colin VK5HI.
>
> -----Original Message-----
> From: AMSAT-BB [mailto:amsat-bb-bounces@?????.???? On Behalf Of Franklyn A.
> Ballentine, Jr
> Sent: Friday, 23 November 2018 13:37
> To: AMSAT-BB
> Subject: [amsat-bb] Visiting Australia
>
> Hi,Everyone,
>
> I got word from my employer that I'll be transferring to our Australia
> office next year, most likely in January,
> It will be on a two year temporary work visa.
> Is anyone familiar with process of applying for a reciprocal license?
> I have my Amateur Extra.
>
> Thanks and 73
> Frank B
> kb1qzh
> _______________________________________________
> Sent via AMSAT-BB@?????.???. 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@?????.???. 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
------------------------------
Message: 2
Date: Tue, 27 Nov 2018 12:21:36 -0500
From: Tucker McGuire <tucker@???????????.???>
To: John Geiger <af5cc2@?????.???>
Cc: AMSAT -BB <amsat-bb@?????.???>
Subject: Re: [amsat-bb] VHF/UHF/Satellite items for sale
Message-ID:
<CA+gmQJTUQPCPsdnZmbn-wT5RJPeiLUjN9YWi0itbdXdtS4XsTw@????.?????.???>
Content-Type: text/plain; charset="UTF-8"
Just so you know. You can buy a 2018 chart for $7 shipped. Or for free with
membership.
73,
Tucker
W4FS
On Tue, Nov 27, 2018, 11:29 AM John Geiger <af5cc2@?????.??? wrote:
> I have a couple of different items for VHF/UHF operations that I am
> selling. They can be put to good use on the satellites as well. Here is
> what I have available:
>
> 1. A Baofeng UV82 2m/70cm 5 watt HT. 1 month old, operates fine. Comes with
> all of the standard accessories-antenna, battery, drop in charger, ear
> piece, box, and manual. Has the same slightly longer antenna than the UV5R
> does. I am asking $25 shipped for it.
>
> 2. MFJ 916B diplexer with SO239 connectors. Splits HF-2m and 70cm and
> above. Great for using a dualband antenna with 2 rigs, or a VHF/UHF radio
> with 1 connector to 2 separate antennas. These sell new for $24 plus
> shipping. I am asking $20 shipped for it.
>
> 3. AMSAT satellite frequency chart. Nice laminated sheet with the current
> satellites and their uplink and downlink frequencies listed. These sell new
> for $8 plus shipping, I am asking $5 shipped.
>
> I can take paypal/check/MO.
>
> 73 John AF5CC
> _______________________________________________
> Sent via AMSAT-BB@?????.???. 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
>
------------------------------
Message: 3
Date: Tue, 27 Nov 2018 09:39:30 -0800
From: christy hunter <cchunter3@??????????.???>
To: amsat-bb@?????.???
Subject: Re: [amsat-bb] PSLV launch Thursday 29th November
Message-ID: <cd25fb4c-bebd-8fda-60cf-71ea55794723@??????????.???>
Content-Type: text/plain; charset=utf-8; format=flowed
hi All, Thanks Graham for the info on this additional Scheduled launch.
I found listed PRELIM TLE for Reaktor Hello World Sat
https://reaktorspace.com/reaktor-hello-world/????? .. go to amateur
radio link
listed as
Hello World
1 23002U 23002A 18333.26351736 0.00000000 00000-0 00000-0 0 9995
2 23002 97.4807 38.1324 0008229 288.8075 272.2161 15.22324998 00
they do not blow up my SatPc32.
they also have a twitter feed. https://twitter.com/RHW_Satellite
oh boy lots of Sats coming up!
73 Christy KB6LTY
------------ from Graham G3VZV
Hi All,
Just a few hours after the scheduled launch of many spacecraft using
amateur satellite spectrum on xthe Spaceflight SSO-A launch, there will
also be a PSLV launch from India on Thursday 29th November.
This includes four CubeSats, 3CAT1, FacSat-1, InnoSat-2 and Reaktor
HelloWorld, which are using 70cms downlink frequencies that have been
coordinated by the IARU. seehttp://www.amsatuk.me.uk/iaru/finished.php
for details
I dont have any orbit details but the approx lift off time has been
reported as 0400 UTC.
Happy chasing!
73
Graham
G3VZV
PS for the latest update on JY1SAT please check our website
https://funcube.org.uk/ - we will really appreciate all reports and
telemetry feeds to the Data Warehouse
---
This email has been checked for viruses by AVG.
https://www.avg.com
------------------------------
Message: 4
Date: Tue, 27 Nov 2018 14:53:37 -0500
From: Zach Leffke <zleffke@??.???>
To: amsat-bb@?????.???
Subject: Re: [amsat-bb] Doppler measurment of TCA
Message-ID: <9dc002cb-2cf8-0870-7cb6-56f465837185@??.???>
Content-Type: text/plain; charset=utf-8; format=flowed
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@?????.???. 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@?????.???. 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
------------------------------
Message: 5
Date: Tue, 27 Nov 2018 21:26:11 +0100
From: "Vincenzo Mone" <vimone@?????.??>
To: "Amsat - BBs" <amsat-bb@?????.???>
Subject: [amsat-bb] AO-92 U/v or L/V mode?????
Message-ID:
<!&!AAAAAAAAAAAYAAAAAAAAALgqrd2N1rRAiaQvRd7pgRDCgAAAEAAAALyTxI/j3NVIupkXN9WcaM
YBAAAAAA==@?????.??>
Content-Type: text/plain; charset="us-ascii"
Hi folks,
Please is there a method or a schedule to know when the AO-92
is on U/v or L/v mode?
Thanks
73 de Enzo IK8OZV
EasyLog 5 BetaTester
EasyLog PDA BetaTester
WinBollet BetaTester
D.C.I. CheckPoint Regione Campania
Skype: ik8ozv8520
*********************************
****** GSM +39 328 7110193 ******
***** SMS +39 328 7110193 *****
*********************************
------------------------------
Message: 6
Date: Tue, 27 Nov 2018 15:31:26 -0500
From: "Andrew Glasbrenner" <glasbrenner@??????????.???>
To: "'Vincenzo Mone'" <vimone@?????.??>, "'Amsat - BBs'"
<amsat-bb@?????.???>
Subject: Re: [amsat-bb] AO-92 U/v or L/V mode?????
Message-ID: <040a01d48690$2c22d580$84688080$@??????????.???>
Content-Type: text/plain; charset="us-ascii"
Read here: https://www.amsat.org/satellite-schedules/
" We will generally enable the L band uplink for ~24 hours during a early
Sunday UTC (local Saturday evening) pass. When you hear a command station
announce or attempt commanding, please stand by until given the all clear."
Look here: https://www.amsat.org/tlm/health.php?id=4&port=
Look for L-band uplink enabled entry under Radio tab.
You can also follow @????? on Twitter, where we always post the time of the
mode change when it happens.
73, Drew KO4MA
-----Original Message-----
From: AMSAT-BB <amsat-bb-bounces@?????.???> On Behalf Of Vincenzo Mone
Sent: Tuesday, November 27, 2018 3:26 PM
To: Amsat - BBs <amsat-bb@?????.???>
Subject: [amsat-bb] AO-92 U/v or L/V mode?????
Hi folks,
Please is there a method or a schedule to know when the AO-92
is on U/v or L/v mode?
Thanks
73 de Enzo IK8OZV
EasyLog 5 BetaTester
EasyLog PDA BetaTester
WinBollet BetaTester
D.C.I. CheckPoint Regione Campania
Skype: ik8ozv8520
*********************************
****** GSM +39 328 7110193 ******
***** SMS +39 328 7110193 *****
*********************************
_______________________________________________
Sent via AMSAT-BB@?????.???. 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
------------------------------
Message: 7
Date: Tue, 27 Nov 2018 15:54:29 -0500
From: Zach Leffke <zleffke@??.???>
To: amsat-bb@?????.???
Subject: Re: [amsat-bb] Doppler measurment of TCA
Message-ID: <c7014c17-01c1-6ffa-90a4-cc3875cb8565@??.???>
Content-Type: text/plain; charset=utf-8; format=flowed
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@?????.???. 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@?????.???. 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@?????.???. 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
------------------------------
Message: 8
Date: Tue, 27 Nov 2018 15:57:12 -0500
From: Zach Leffke <zleffke@??.???>
To: amsat-bb@?????.???
Subject: Re: [amsat-bb] Doppler measurment of TCA
Message-ID: <8cb50ffb-61b7-8d6e-5848-112a5fab4acb@??.???>
Content-Type: text/plain; charset=utf-8; format=flowed
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@?????.???. 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@?????.???. 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@?????.???. 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@?????.???. 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
------------------------------
Subject: Digest Footer
_______________________________________________
Sent via amsat-bb@?????.???.
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 member? Join now to support the amateur satellite program!
http://www.amsat.org/mailman/listinfo/amsat-bb
------------------------------
End of AMSAT-BB Digest, Vol 13, Issue 392
*****************************************
Read previous mail | Read next mail
| |
