9
$\begingroup$

When cubesats are first deployed it can sometimes take several days before they start appearing in official TLE distributions, and even then if many were deployed it may take a lot more work to decide which one is which.

Other Problems keeping track of satellites:

As far as I know, cubesats don't (yet) have digital license plates that can be read from the ground (easily). So in some cases it may be necessary to exchange some data before some TLE's can be associated with a specific satellite name. One way to establish that is to make radio contact with a given cubesat.

There may be other operational reasons as well for why you might want to start trying to talk to your cubesat as soon as possible.

Question: How do cubesat owners first find out their cubesat's initial trajectory? How do they point antennas at it before official TLEs start to appear? Do the launch providers share any trajectory informaion? If so, what is the format?

Improve this question
$\endgroup$

4 Answers 4

Reset to default
6
$\begingroup$

In my experience, there isn't currently a good solution for this, especially for amateurs, hobbyists, or small commercial operators. These groups often fly small satellites on rideshare missions. For smallsat rideshare, there are a so many uncertainties that removing tracking uncertainty is really important

Uncertainties

  • Is my satellite dead-on-arrival (DOA)?
  • If my satellite isn't DOA, is it surviving in space?
  • Did my antennas deploy?
  • Is my spacecraft communications system functioning properly on orbit?
  • Is my ground station functioning properly at my spacecraft's frequency?
  • Is my link closing? Directly overhead? At the horizon?
  • Where is my satellite? Which of the satellites deployed from the rideshare is mine?

On the last point, I first thought the official TLEs would be organized in deployment order, but they aren't. While the mass is definitely known, the drag coefficient probably isn't, and the density of the atmosphere the satellite flies through at the correct point in time definitely isn't well characterized. As a result, the order of the satellites in orbit may not match the order of deployment.

Satellite Tracking

With so many uncertainties, reducing the uncertainty around satellite tracking is really important, especially for rideshare missions. The best way to do that, is to begin attempting communications immediately after launch, when the satellites are still relatively close together. That way, you can point to one and be fairly confident that you're pointing to all of them. As days pass, the satellites separate and the total search area becomes unmanageable.

I've been involved in two separate CubeSat launches so far and both times we have been given state vectors after launch. I was loosely involved in the BYU PICs launch operations (I had graduated and left the team before) and my company, Care Weather, recently launched it's first satellite, Hatchling Veery. I'll include a few examples at the end of this post. Both times, immediately after launch, we manufactured TLEs. Both times, our TLEs had errors due to inane complexities in the definitions of the coordinate systems or epochs used.

Everyone I know involved in satellite communications produces TLEs from state vectors between launch and issuance of official TLEs. On the ELaNa XX mission with Virgin Orbit, we had an extensive email chain as people tried to iron out issues with their TLE calculation and the SatNogs forum was sharing manufactured TLEs for early tracking as well.

There is a lot of wasted effort and inefficient collaboration at this point in the process and it contributes to space debris by resulting in some satellites to never be identified. The BYU team actually had confirmation that PIC-A and/or PIC-B was not DOA as the satellites' camera flash was seen by the rocket camera. However, the PICs team dealt with all of these uncertainties (and more) and was unable to make contact in the early stage. They are still trying to make contact, but more than half of the ELaNa XX satellites were never identified, so there's like only a 25% chance that they're looking in the right spot. Combine that with most passes being low to the horizon and the chance of contact being made now, even if the satellites are still operational, is slim.

Potential Solutions

State Vectors

Here are a couple examples of state vectors as given by the the launch provider on each mission. There is no standard on state vector contents, so some were easier to work with than others, but some aspect of the delivery created headache for TLE generation on both missions.

Virgin Orbit ELaNa XX

The polar cube team shared their state vectors on the SatNogs forum right after deployment.

Rocket Lab "They Go Up So Fast"

Rocket Lab gave us their official TLEs shortly after deployment. They had given us predicted state vectors and a trajectory analysis document long before the launch.

State Vectors delivered by RocketLab to Care Weather

Improve this answer
$\endgroup$
1
  • $\begingroup$ +1 Thanks for your answer! It's great to have a first-hand account to complement the more speculative "oh it's easy" answers. :-) It's also very illuminating to see how different launch providers vary so much in what they provide. $\endgroup$
    – uhoh
    Mar 25, 2021 at 22:50
7
$\begingroup$

A cubesat without a propulsion system deployed from the second stage of the rocket using weak mechanical forces only just follows the trajectory of the second stage. Differences between the trajectories of the deployed cubesats and the second stage are very small.

So the cubesat owners may use the latest trajectory information from the launcher as initial trajectory of their cubesat before official TLEs start to appear.

A diagramm from EXOLAUNCH about the EXOpod cubesat deployer.

enter image description here

From the CarboNix User Guide page 19:

enter image description here

The tolerance of the spring energy of 25 % results in a speed error of about 12 %. For a separation speed of about 1.5 m/s this error is 0.17 m/s, the error after one 90 minutes orbit will be 0.92 km. Over a distance of 1000 km this will be a direction error of only 3.2 arcminutes.

As David Hammen commented, the deployment vector is not random, the cubesat launcher is responsible for direction and speed of deployment. The actual deployment speed of the cubesat depends on its mass, but the mass of the cubesat is precisely known.

Improve this answer
$\endgroup$
19
  • 1
    $\begingroup$ @ChrisR which ground stations available to cubesat owners actually provide scanning patterns for them? Is this really true? Wouldn't passes over any given ground station be rare in the first few days, and all the cubesats be passing over at roughly the same time? Sounds like a very unlikely scenario to me. $\endgroup$
    – uhoh
    Mar 24, 2021 at 23:33
  • 1
    $\begingroup$ @ChrisR are the DSN dishes operated in "LEO search mode" very often? Those tiny FOVs and slow slew rates must make that quite a challenge! $\endgroup$
    – uhoh
    Mar 25, 2021 at 0:22
  • 1
    $\begingroup$ -1 because 1) this is pure speculation, there is nothing here about what information launch providers actually supply. 2) even if possible to derive, the relative velocity is useless until an accurate TLE for the 2nd stage is provided. Can you add some facts as to when that actually happens? 3) In order to to use a deploy velocity, you need to know its direction. Even 1 m/s means in 24 hours it can be as much as 30 seconds ahead or behind the 2nd stage (retrograde/prograde deploy), and they usually deploy backwards/forwards on purpose to maximize spreading out to make early tracking easier. $\endgroup$
    – uhoh
    Mar 25, 2021 at 1:20
  • 2
    $\begingroup$ @uhoh - I disagree with your disagreement for two reasons. One is that the deployment is not random. It is performed in a fairly well known direction and with a fairly well known magnitude.The fairly well known deployment time and deployment mechanism behavior combined with the second stage's fairly well known orbit provides the ability to predict an expected state. There is an uncertainty in this, and that is what Uwe wrote about. $\endgroup$
    – David Hammen
    Mar 25, 2021 at 2:33
  • 2
    $\begingroup$ The second reason is that the cubesat operator will start looking for the cubesat shortly after it first appears above the horizon rather than when it is directly overhead. The angular difference is much smaller at that much larger distance and mostly manifests itself in an error in acquisition time. Once locked on, a tracking antenna will follow where the satellite is rather than where it is predicted to be. $\endgroup$
    – David Hammen
    Mar 25, 2021 at 2:35
6
$\begingroup$

I've done this before, on the latest Falcon Heavy launch. Although the satellites we were working with were a good bit larger than most cubesats.

Essentially, the launch provider gives you state vectors, and then someone in the chain needs the STK ODTK to turn the state vectors into TLEs. Unfortunately I think the license for that is around $60k. I would be very interested in an open source solution to do the same thing, as ground systems almost always take as input TLEs.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thanks for your answer! One way to get things started on that would be to post a question, something like "What are the challenges to writing an open source LEO state vector to TLE converter?" Asking it this way will cover all types of challenges, informational, mathematical, regulatory (if any) etc. $\endgroup$
    – uhoh
    Jul 21, 2021 at 22:40
  • $\begingroup$ Your question How to generate TLEs based on a set of observation points (location, azimuth, elevation… no range) is somewhat a superset but a poor one, as answers will require both converting a short span of ground observations (60 seconds) to a state vector and then conversion of a low accuracy state vector to an inevitably low quality TLE. Here you are given much, much more accurate state vectors so the challenge for the TLE converter is much larger. $\endgroup$
    – uhoh
    Jul 21, 2021 at 22:51
3
$\begingroup$

The launch provider provides the state vectors, based on the deployment force, angle, and the state vector of the rocket stage when the cubesat was deployed. The exact format may vary, it could be a TLE or a state vector or something like that, in any case it will be something both the provider and the customer will agree on well in advance.

Improve this answer
$\endgroup$
5
  • $\begingroup$ is there some way this can be established as true based on sources? Does this come from personal experience? Is there some blogpost or article or mention of this somewhere? $\endgroup$
    – uhoh
    Mar 25, 2021 at 13:16
  • $\begingroup$ This is from personal experience. I can't speak to all providers, but I do know the ones that I have worked from this is the case. $\endgroup$
    – PearsonArtPhoto ♦
    Mar 25, 2021 at 14:29
  • $\begingroup$ When a cubesat customer plans the mission carefully, he has to deal with communication to the cubesat immediately after deployment. So he has to think about the state vectors of the cubesat provided by the launcher and the exchange format. Of course the uncertainity of the state vectors should be considered. $\endgroup$
    – Uwe
    Mar 25, 2021 at 17:47
  • 1
    $\begingroup$ @PearsonArtPhoto Have you received a TLE from a launch provider before? I haven't seen a launch provider do that. It would save a lot of headache in working with gpredict. $\endgroup$
    – Patrick Walton
    Mar 25, 2021 at 21:44
  • 1
    $\begingroup$ A company I worked with in the past received equivalent information from the launch provider. I didn't personally look at it, but I was aware that it was received. Can't say a lot more than that really, but... $\endgroup$
    – PearsonArtPhoto ♦
    Mar 25, 2021 at 22:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.