(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).
Proposal
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?
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.
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:
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.
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).
@fredy: I like your second solution, Imo this is more clear.
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.
Example
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
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.
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
thread.
