Greetings!
Is there any mechanism (Social Media, etc.) where SatNogs announces when an object’s NORAD ID changes from the temp # to a permanently assigned number?
I ask because, not for the first time, I failed to have a large number of decodes ingested into the database because I was still using the temp ID# for the SIDS upload.
Thanks!
The announcement currently is done in each launch thread with either one message or a status table that list the satellite as identified.
In case that someone sent frames to the temporary NORAD ID after identification, in some cases they are merged in some other a new entry suggestions with this temporary NORAD ID will be created which will be eventually be merged.
For the latter scenario, unfortunately due to other tasks in LSF projects and some continuous launches, I didn’t have the time to check them and merge them. Hopefully in the next weeks, I’ll find some, however if you spot such a case, feel free to ping me here or in a pm, writing which temporary NORAD ID was used and for which satellite and I’ll check as soon as possible.
The above are for the current status. To mitigate this issue, there is a task in (slow) progress where we are going to leave behind the use of NORAD ID for sending frames, as a satellite can have 0, 1 or more possible NORAD IDs, and we will adopt getting data with the Satellite ID we use in DB. There will be a transition phase in order 3rd party observers/software to adjust in this new situation. More details as we moving on.
Thanks very much for the reply!!
I’m sure that managing this volume of data is a monumental task - and much appreciated!
If temp ID numbers are not going to be re-used, then perhaps the most useful path would be to leave the temp number connected to objects even after they pick up the permanent Norad ID.
Thanks!
More or less this is how is done.
Let me explain it:
With Satellite ID, on satellite can have one or more (merged, pointing to the primary) Satellite IDs. This requirement came from the experience we had until now and it seems that fits pretty well. For example you receive a satellite but you don’t have any idea which one is it, so you create an entry with, let’s say, Satellite ID “A”. Then you discover that the satellite was already in DB but with another Satellite ID, let’s say “B”, and maybe with a wrong transmitter frequency (that’s why you couldn’t match it with “A”).
So at the moment you discover that we are talking for the same satellite, you can associate the two entries by making the one primary and the other secondary. After merging both Satellite IDs are valid for this satellite.
So, in some cases when there is already a new satellite suggestion with the identified NORAD ID (someone send data to this NORAD ID before we identify it), then the two entries are merged, in this case we have two entries, one with the identified NORAD ID (the primary in the merge) and one with the temporary NORAD ID (the secondary in the merge). In this case when you use the temporary NORAD ID to send data, these are end up to the satellite.
If during the identification there isn’t any entry/suggestion for the identified NORAD ID, I’ve just change the temporary NORAD ID to the identified one, so only the entry with the identified NORAD ID will exist and sending data to the temporary one will end up as a new suggestion that will need merging.
Indeed an alternative would be to create another entry and make a merge so both temporary and identified NORAD ID exist but I’m avoiding this to create less merged satellites (no a big deal, just fewer entries).