Ground Sphere CubeSat Ground Station

The interchange on Gmail follows:

Aaron Harper

Oct 9

to Tim, Simmons, Scott, Jeremy, Greg

I probably won't be able to attend this week due to being on the road, and if I do show up it will be later in the evening. Because of this, I will post the biggest question here and now.

What are we doing about the doppler shift during the satellite pass, which can be as high as +/-20kHz off 915 MHz (http://vkradio.com/doppler.html)? The tracking software I use (http://gpredict.oz9aec.net/) can output the appropriate offset, but is not set up to do so by default, nor is the SDR# software set up to tweak the frequency based on an outside data source from what I have seen. Can we link and/or bundle the two to do so? One of the best papers on doppler issues pertaining to LEO satellites is attached to this email.

Best,

Aaron
...

Tim DeBenedictis

Oct 9

to me, Simmons, Scott, Jeremy, Greg

Aaron-

This is one of the very few areas where my coding abilities can actually help you.

I've imlemented a super-lightweight implementation of the SGP orbit model in C. If you know the satellite's orbit (i.e. if you have TLEs) then you can compute its position/velocity relative to ground, and hence doppler, at any time. Presumably, this can be used to "tweak" the frequency that SeeDeR is listening on, as the satellite zips over, on the fly.

It's going to be some amount of work to integrate the code pieces, but I'm happy to donate my SGP orbit implementation to the project.

-Tim DeBenedictis

--

"Success is the ability to stumble from failure to failure with no loss of enthusiasm." -Winston Churchill

...

Aaron Harper

Oct 9

to Tim, Simmons, Scott, Jeremy, Greg

That would be awesome, particularly if we could code the doppler compensation algorithm into the SDR software.

This would mean that we would have to have a method of updating the sat's TLE over the net when it is known... having the software check a small file on an unlinked page of a website on execution would do the job.

Best,

Aaron
...

Scott Cutler

Oct 9

to me, Tim, Simmons, Jeremy, Greg

My SeeDeR program handles a pretty wide range of allowable input frequencies. And we can conceivably tweak it to accept input from GPredict (or use use Tim's software).

There is another problem, which is that in non-telemetry tweet mode we don't send preamble/postamble flag bytes. I use these to get a lock on the frequency (among other things) before the actual data comes down. It works fine for telemetry tweets and general purpose data, which both use the bytes. But without the flag bytes the data is lost before I get the lock.

I have some ideas on how to solve this (basically use a large bank of detectors), but I'm pretty far away from having the time to work on that.

-Scott

...

Aaron Harper

Oct 9

to Scott

Since we would be grabbing the TLEs from an online source, all client machines would need to connect to the net... therefore, in addition to giving the person access to the received data, the data can be concatenated to the same server the TLEs are available from, giving you the large bank of detectors you seek to get the lock. It would also act as a failover to those with the software to receive tweets when the sat is over another client's head, though not theirs. This could be a feature of the next software rev.

Best,

Aaron

So, it sounds like getting the TLEs from GPredict's source is in line with what others are thinking, I just missed it when I was reading the thread.

I think the most elegant solution would be for the software to both account for doppler and predict the pass. This is done with largely the same data and basic calculations anyway, and the integration of all the data in a single application window would give the final result more polish.

Aaron,

While I agree in concept that predicting the pass and accounting for doppler shift in the same code base is the most straight forward solution, in practice I believe this creates undo burden on the project team. Part of the reason so use GPredict for our pass prediction requirement is it is feature complete. It has a powerful GUI and its ground track and flyover prediction features are well tested. If we wanted to unify radio control with pass prediction we would either have to integrate the radio control with GPredict (which I am sure is possible, but adds complexity to our work) or reimplement major features from GPredict in the radio control software. Plus, Southern Stars reports that they already have code which can handle the doppler shift given the TLEs, so we are actually very close to implementing the solution separately.

Now, do I think we should revisit this discussion in the larger context of ground station architecture. Oh, yes! But, there are lots of things to discuss about overall architecture, and I don't want an already tight project timeline to get bogged down by discussions which are about a higher level of our work. So, I would like to see us put the discussion about integrating the various software features on hold for a while.