Third party decoders trigger new satellite creation when using old temporary NORAD ID
After the merge of a satellite (e.g. LEDSat), third party decoders like getKISS+ will trigger the creation of new satellite entries in DB when still configured to submit with the old temporary NORAD ID. The consequences of this has been first reported in this tweet by PU7ORD for LEDSat (thank you!).
Temporary NORAD ID of LEDSat in DB was 99670, final NORAD ID is 49069.
The original LEDSat entry in DB with 99670 (SatNOGSSatID unknown to me) was merged into the new entry with 49069/ (edit: explanation wrong, correct explanation follows)JLZT-...
. The first KISS submission to the old temporary NORAD ID after this merge then triggered the creation of MUTW-
.
The NORAD ID of the LEDSat entry in DB JLZT-...
was changed from originally 99670 to the final 49069. The first KISS submission to the old temporary NORAD ID after this change then triggered the creation of a new satellite suggestion, MUTW-
.
Two solutions spring to my mind for improving the handling of KISS submissions for old temporary NORAD IDs:
-
Reject them. In this case the user should get an explanatory error message, e.g.
ERROR: Old temporary NORAD ID used. Please configure your telemetry forwarder to use xxx instead.
- Associate them with the correct satellite in DB. This would require DB to remember old temporary NORAD IDs & will not incentivize the user to update their configuration.