Thanks very much for the reply. And the hint on topic.
I think the Doppler problem is easier than you describe. And I'd note
it's not a perigee estimator it's a TCA calculator as below.
The problem we are trying to solve is that when a rocket launches with
multiple payloads (two in the past two weeks with about 40 and 64
respectively) it becomes difficult to figure out which set of orbital
elements belongs to which satellite. We all rely on the Air Force Joint
Satellite Operations Command (JSPOC) to target the satellites with
various radar and optical sensing resources then create a set of values
that define the orbit of each satellite (commonly called NASA 2 line
elements sets, or Keplarian elements, or keps). When you read those
into satellite tracking software it shows you where the satellite is and
when it comes over your location that software points your antennas at
the satellite. Many of these satellites look identical to the sensors
(they are "cubesats") so the JSPOC can't tell them apart. They start
out very close together (at most a few seconds different in when they
come over the horizon) and over a few weeks drift apart. You need to be
able to point your antennas at the satellite to receive data from it and
command it. Which means you need to use the set of keps that matches
your satellite.
In the period from a few days after launch to perhaps a month after
launch, when owners are talking intensively to their satellites to get
them up and running (commissioning), JSPOC is distributing a list of
keps, one for each satellite, but no identification of which is which.
It's up to the owners to figure that out so a namecan attached to each
set of keps.
The satellites transmit either short bursts of data or longer
transmissions containing lots of data as they pass over. The radio
frequency changes during a pass because of the Doppler effect. For a
satellite transmitting on UHF (about 440 MHz) the signal as received on
the ground starts out about 10 Khz above the actual frequency and ends
about 10 Khz below it. If you plot frequency vs. time you get a COS
curve (you can find lots of these by Googling Doppler shift). Each
satellite is coming over at a slightly different time. So the frequency
vs. time plot for each will be different.
If you curve fit the plot of points (or nearly continuous signal) you
get a COS curve. The point at which the curve is steepest is the point
in time when the satellite was closest to your station (TCA, Time of
Closest Approach). If you put the keps from all the satellites that
were launched together - any one of which may be yours - into a tracking
program that program will calculate (and show on real time world map)
the TCA for each. (see http://gpredict.oz9aec.net/) So the solution to
figuring out which set of keps is your satellite can be solved by
matching your observed TCA with the calculated TCA for each set of keps.
As noted, figuring that out in that first month or so is critical
because satellites need some care and feeding initially to get them
pointed at the sun for battery charging, get them into their science
data collecting mode, etc. And that time period is when everyone is
scrambling to figure out which set of keps is for their satellite so
they can point their antennas properly.
The calculation / math problem can I think be tackled in two steps. The
first is to curve fit a COS equation to the recorded set of time vs.
frequency points during or after a pass. The second step it to find the
point on that curve where the slope is highest (most up and down) which
is the time of TCA. One could then manually/visually match that time to
the TCA calculated/displayed by the tracking program for each set of keps.
Many folks are using SDRs to talk to their satellites now and most are
using GNURadio with the SDR (in the current case we are using an Ettus
B200). Our GNURadio flow graph provides a spectrum analyzer display
where we can see the signal along with a real time output to a telemetry
decoder program which shows what's happening inside the satellite.
The first step would seem to be a block that plots in real time
frequency vs. time of each burst of data from the satellite. The display
would be a rectangular X/Y plot that would look much like the Doppler
curve plots you can Google for. That could then be advanced by doing a
real time curve fit to those points and overlaying it on the plot. And
the last step would be to calculate in real time (or after the pass) the
steepest point on that curve.
One might wonder how often this would be useful. 5 years ago I would
have answered about once every couple of years. But the number of
launches of flocks of tiny satellites is growing exponentially as
evidenced by three launches of a combined 100+ satellites in the past
three months. That pace won't keep up but 4 or 5 multiple payload
launches a year is likely. And in some cases solving this problem for
the owners can mean the success or failure of their satellite project,
many of which are built by universities and even high schools.
I hope that's a better explanation of the problem and how it might be
solved. I had hoped existing code/blocks would be available that might
be combined to implement this function. Perhaps with this explanation
something might be found that will work.
Thanks again,
Jim
On 12/5/2018 4:41 AM, Müller, Marcus (CEL) wrote:
> Hey Jim,
>
> welcome to the community!
> A quick hint beforehand: When you change the subject line (as the mail
> you responded to suggested strongly), then people can more easily guess
> whether they should be taking the time to read your mail. I was about
> to skip it, and that would've been a bummer!
>
> So, an eye pattern display is currently not available in GNU Radio
> itself. We "only" have the QT GUI Time Sink, but that has no
> "persistence" setting as of now. It's on our list of things to
> implement for halfway feature-completeness. I'm optimistic we can come
> up with a solution to that together. Can you talk a bit about your
> specific use case? Is your GMSK reception already synchronized?
>
> Regarding TCA: hm, I'm not overly familiar with the math involved, but
> sounds like you'd observe the Doppler development over time to estimate
> the slope of a set of tangents to the elliptical orbit of the satellite
> and then solve for the time where orbit intersects with the main axis.
>
> So: a bit of a math problem :) which could be relatively nicely solved
> by first implementing a Doppler estimator (how definitely depends on
> your system's characteristics and speed needs), and using the velocity
> data that spits out either in post-processing of recorded speeds, or in
> a python GNU Radio block that accumulates these velocity estimates and
> estimates a TCA based on that.
>
> Best regards,
> Marcus
>
> On Tue, 2018-12-04 at 10:15 -0700, Jim White wrote:
>> Very new to GNURadio here...
>>
>> Is there a block available that will display an eye pattern for
>> digital
>> modulation for a GMSK or FM receiver? I'm using a USRP B200 and
>> have
>> built a couple of simple flows for it including a spectrum
>> analyzer.
>> I'm looking for something that will show the eye pattern.
>>
>> Also hoping for a block that will calculate the time of closest
>> approach
>> from the Doppler curve after listening to and recording a satellite
>> pass. This is about finding the TCA then matching it to calculated
>> TCAs
>> provided by tracking programs. The objective is to match observed TCA
>> to
>> TCAs from several sets of keps to match them up and determine which
>> set
>> of keps is the satellite we are working with.
>>
>> Jim
>>
>>
>> On 12/4/2018 10:00 AM, discuss-gnuradio-request@gnu.org wrote:
>>> Send Discuss-gnuradio mailing list submissions to
>>> discuss-gnuradio@gnu.org
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> or, via email, send a message with subject or body 'help' to
>>> discuss-gnuradio-request@gnu.org
>>>
>>> You can reach the person managing the list at
>>> discuss-gnuradio-owner@gnu.org
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Discuss-gnuradio digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>> 1. Fwd: [hamsci-swstation] A Little Fun with Digital RF
>>> (Michelle Thompson)
>>> 2. Re: SDR for beginners (if not quite "dummies") (Bruce
>>> Ferrell)
>>> 3. Call for Participation FOSDEM & pre-FOSDEM Hackfest (Andrej
>>> Rode)
>>> 4. Looking for other users of the XTRX SDR (Markus Wirsing)
>>> 5. Re: Looking for other users of the XTRX SDR (Matthias
>>> Br?ndli)
>>> 6. Re: Looking for other users of the XTRX SDR (Markus Wirsing)
>>>
>>>
>>> -----------------------------------------------------------------
>>> -----
>>>
>>> Message: 1
>>> Date: Mon, 3 Dec 2018 16:05:20 -0800
>>> From: Michelle Thompson <mountain.michelle@gmail.com>
>>> To: GNURadio Discussion List <discuss-gnuradio@gnu.org>
>>> Subject: [Discuss-gnuradio] Fwd: [hamsci-swstation] A Little Fun
>>> with
>>> Digital RF
>>> Message-ID:
>>> <
>>> CACvjz2U7vcCb2i1O=nwjaOnmGvbSmxDdnrJBkfibpbRb-CJP+w@mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> I enjoyed reading this writeup from a GNU Radio user, and wanted to
>>> share
>>> it.
>>>
>>> -Michelle W5NYV
>>>
>>>
>>>
>>>
>>> ---------- Forwarded message ---------
>>> From: Greg KF5N <soapy-smith@comcast.net>
>>> Date: Sun, Dec 2, 2018 at 5:01 PM
>>> Subject: [hamsci-swstation] A Little Fun with Digital RF
>>> To: hamsci-swstation <hamsci-swstation@googlegroups.com>
>>>
>>>
>>> I had a great time at the TAPR Conference in Albuquerque, and I was
>>> especially intrigued by the Space Weather discussion in the Sunday
>>> seminar.
>>>
>>> Nathaniel's description of "Digital RF" really got my attention,
>>> and I
>>> decided I wanted to experiment with it.
>>> That took some doing, because I had to get a receiver and come up
>>> to speed
>>> on GNU Radio.
>>>
>>> So about 3 months later playing with radios, computers, and
>>> software here
>>> is a report on my experiments:
>>>
>>> https://github.com/Greg-R/explore_digital_rf/blob/master/docs/explore_digital_rf.pdf
>>>
>>> The top of the repository is here:
>>>
>>> https://github.com/Greg-R/explore_digital_rf
>>>
>>> I want to do more experimenting using HF band
>>> signals. Unfortunately I am
>>> in a hostile RF environment.
>>> I've got my hands on a broadband loop antenna, so getting that
>>> mounting and
>>> working is next.
>>> I hope I can pursue further experiments with the combination of GNU
>>> Radio
>>> and Digital RF.
>>> Cool stuff!
>>>
>>> 73 Greg KF5N
>>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment