Unique Satellite identifier definition in SatNOGS

(this post is based on latest discussions on this topic in IRC)

New Satellites in SatNOGS

SatNOGS has an identification of a new satellite of interest consisting of the satellite name and a set of transmitters (in edge cases only of the transmitter and not the satellite name) usually before the launch as provided by the satellite owners (or other sources) or shortly after the launch by scan observations.

NORAD IDs and COSPAR designators

JSpOC tracks new satellites and assigns a sequential 5 digit NORAD IDs to each of them. Each new satellite is also assigned a COSPAR designation, consisting of the year of launch, a 3 digit ID number, incrementing with each launch, and a 3 letter code as the sequential object identifier within each launch.
The NORAD ID and COSPAR designation are linked and are consequtive; the object with COSPAR designation C has a NORAD ID which is 2 higher than object A.
Neither the NORAD ID nor the COSPAR designation are temporary, and usually room is left in the NORAD ID associated with the expected number of objects to be catalogued for a launch (I.e. the highest assigned SSO-A NORAD ID from 2018-099 is 43799, while launch 2018-100 starts with NORAD ID 43823. In other words, they expect to still catalogue 23 objects).
Though the IDs and designators don’t change, TLEs are sometimes swapped between objects (on rare occasions they swap NORAD ID and COSPAR ID around to put the rocket body as the last in the COSPAR range of that launch (i.e. 18103D if A, B and C were payloads).

(this explanatory section was provided by @cgbsat, many thanks! )

IDs in SatNOGS

Currently the NORAD ID is used by satnogs-network and satnogs-db as the primary identifier for satellites. As the correct NORAD ID & COSPAR designation for a satellite is unknown until the satellite was officially identified (by JSpOC/TSKelso), SatNOGS assigns temporary NORAD IDs from the unused 99XXX range to unidentified satellites. When the official identification happened, this temporary NORAD ID is replaced by the correct official NROAD ID in satnogs-network and satnogs-db (@fredy could describe the details).


In order to stop the usage of temporary NORAD IDs and to be able to reliably sync satnogs-db and satnogs-network, we plan to introduce an unique identifier for each satellite tracked by SatNOGS. This identifier has to be available before the launch.
Subsequently we only associate a NORAD ID when a candidate TLE is available or after the official identification was done (already discussed implementation detail: for the former we introduce the field norad_track_id, for the latter the field norad_id in the db).

Open Questions

  • How should such an unique identifier for satellites be defined?
  • How we can implement it in the backend database in an elegant way that a single TLE (from external sources with a NORAD ID or directly provided by other means) to be associated with multiple satellites in SatNOGS?

Please add your comments and ideas!


Also include AMSAT designation for ALL appropriate satellites in ALL areas/lists, not just some.

1 Like

Thanks @kerel for opening this topic and all the details you gathered.

I’ll make a quick reference on the issues we have with the NORAD IDs right now:

  1. NORAD ID is not unique at least at the first days of a satellite. This creates other problems like the one described by @DK3WN at this tweet:

So using NORAD IDs for sending data in db feels to be wrong. Other issue is the automatic getting of TLEs based on a NORAD ID. This is solved for network with a temporary solution but it is not the right solution and also it doesn’t help users of db to know which is the “right” current NORAD ID they should follow for getting TLE for observing the satellite. In this case 99xxx temporary ids doesn’t help at all.

  1. Some satellites are not going to have a NORAD ID ever. Right now we have 6 satellites without NORAD ID assignment, and their temporary NORAD ID of 99xxx form will stay forever if we keep the current state.

I agree with the unique identifier before the launch that should be used from the db, network and people that contribute in db data with external tools like gr-satellites and telemetry forwarder.

For how to deal with NORAD ID I suggest two solutions, not sure if we decided in the irc meeting one of them, if yes let me know:

  1. Having two fields one for the NORAD ID and one for its fuzziness (checkbox- true/false). So the NORAD ID field it will start as blank and with fuzzy field being checked. After the first NORAD ID forecast it will get NORAD ID with fuzzy field still checked. Until its NORAD ID assignment is final we will keep updating the NORAD ID field and have the fuzzy field checked. After the assignment we will just uncheck the fuzzy field. NORAD ID field, if it’s not blank will be used for updating and getting TLEs.

  2. Having two fields both for NORAD IDs, one for the assigned NORAD ID which will stay blank until there is an assignment and the second one for updating and getting TLEs while there is no assignment.

I think the first solution is more clear, it uses less space, it avoids confusing user with a lot of NORAD ID fields and it will be easier to filter and calculate things about fuzziness and NORAD IDs.

About your open questions:

I guess any identifier schema could work. However I liked the idea, I think it was yours, about having an alphanumeric identifier that will be close to the satellite name, this will make easier to use and express the id. For example I think “irvine01” is much better to use than “asdf324few32”.

Already both network and db don’t have any issue on supporting the same TLE (not the same NORAD ID) for many satellites. So, two or more satellites can use the same TLE but not the same NORAD ID. I hope this answers your question.

@Zathras can you expand this, I’m not sure what is “AMSAT designation”.


@Zathras Thanks for reminding of this issue! As stated in satnogs-network#424 AMSATs OSCAR designation is already stored in the ‘alternative names’ field in db (but not always shown). As more cross references are introduced (NORAD ID becoming just one if them, possibly also the COSPAR designation) we might consider to add an optional field OSCAR designation to the db as well. I’ve create issue satnogs-db#247 to track this.

As the modification of Satellites in db isn’t crowd-sourced yet, adding AMSAT designation to the alternative names has to be done manually by the very few db-admins currently (which reduced their available time to implement new features in db, e.g. non-admin edit&review rights for Satellites). :wink:


@fredy: I like your second solution, Imo this is more clear. :sweat_smile:

The satellite model would have a set of cross-references (NORAD ID, COSPAR designation, OSCAR designation) which are populated when officially available, and empty otherwise. For the purpose of automated TLE management, we have a field which stores the NORAD ID to be tracked (this doesn’t have to be exposed in the Satellite view if the TLE is shown as well as it will be the same as the NORAD ID given in this TLE), lets call it norad_track_id as @pierros proposed in IRC. In this field temporary NORAD IDs will also be allowed.

A temporary NORAD ID will be generated and used only for our own TLE sets. This will allow us to update the TLE of all satellites with a single TLE at once (solves the second question, raised initially by @Acinonyx in IRC). This especially important in the light of such mass-deployments like SSO-A to reduce the required maintenance effort of db.


FancySAT-42/FSAT-42 and ErrorProneSAT-7/EPSAT-7 will be deployed together.

Before Launch:

  • Add FSAT-42, EPSAT-7 to db
    (leave all cross-reference fields and norad_track_id empty)
  • Add preliminary launch date and pre-launch TLE to db,
    use temporary NORAD ID 99923
  • Set norad_track_id of FSAT-42 and EPSAT-7 to 99923

Launch delayed / first post-launch TLEs available:

  • Update launch dates and add new TLE to db,
    use temporary NORAD ID 99923 again

Satellite identified:

  • Set NORAD ID & Co. according to official assignment
  • Unset norad_track_id

Sorry for the late reply.
First of all I would be interested to know how all the packets come into your database. I think you can difference the source e.g. from my telemetry forwarder or from your source. The reason why I ask is to minimize the effort on both sides.

I believe the only way is to use a temporarily NORAD ID - as it now implemented with the SSO-A launch. Someone of you SatNOGS guys must generate this list and I can easily implement those temporary ID in my forwarder software. As soon as the TLE assignement is stable you can easily copy all the packets from this ID to the final ID.

There are alway some NORAD ID’s which are never correctly assigned because the satellite was never heard - but these satellites can not generate a data record (at least not from my tlm forwarder). I forward only the records which are correctly identified by callsign, packet len and byte sequence.

73 Mike


A few random thoughts here:

  • technically, every satellite entry in db gets a unique primary id assigned to it for backend db purposes. (ie: ISS/Zarya, while NORAD 25544, is 8 to db since it was the eighth entry). I’m not suggesting that this become the defacto “SatNOGS ID”, just throwing it out as it may spur other ideas. (and note that the primary ID for a satellite entry in DB will not necessarily match what the primary ID is for a satellite entry in Network… we’ve always relied on NORAD ID to identify them)

  • @DK3WN I think we’ll always want to support NORADID as a way to submit data to db, if nothing else to be backward-compatible - and today it is implementing the SiDS protocol with one exception, we added a ‘satnogs_network’ boolean to differentiate packets coming from a bare SiDS endpoint vs from satnogs network. It defaults to False, and your clients do not supply it, so everything else with SiDS just works.

  • with those said, we could extend SiDS with a ‘satnogs_id’ that would allow for data to be submitted to a satellite entry before its NORAD ID is assigned, and continue to be submitted there indefinitely. Clients would either need to be written to support a satnogs_id as soon as it is created (pre-launch), or wait until an ID is assigned by NORAD. I’m going to defer to @dk3wn and @EA4GPZ for comment as the primary client developers aside from satnogs-network.

Let me offer an opposing opinion here. I like easy to remember names, and we can search those in the UI for db, network, etc… We are discussing a new “standard” for satellite identification, and if we go with something that aligns with the name of a satellite the expectation of a satellite name/identifier may be confused and differ across the entire system. One operator may say ‘irvine01’ and the next may say ‘foo1’. Suddenly, zero-padding is not consistent and left up to the operators. Trying to think of the future state here, with thousands of cubesats, operator-supplied names will have a greater chance of conflicting. There is no regulating authority standard for the name of a sat, so let’s imagine a hypothetical scenario where the first school to launch “bar1” to space wins a prize. Within days you have multiple sats reporting to be “bar1”.

So, while I agree with the “ease” of naming with this idea, the ease should be resolved at the app layer - and the backend identifier should be just that - an identifier that is absolutely unique to the sat. Doesn’t have to be crazy but in the “hundreds of thousands” scenario with picocubes, I’d say let’s future-proof this and make it something akin to a git hash.



For me it would be easy to modify the SiDS submitter in gr-satellites to support such an extension. Indeed, it saves me some work, as currently I add decoders before the final NORAD IDs are determined, so then I have to remember to modify the decoders when the NORAD IDs are final.

Other than this, by now I don’t have any clever idea to add up to what has already been said in this


This subject is being tracked in issue 245 of SatNOGS DB.