Upcoming SatNOGS DB release (1.75) - Breaking and Notable Changes

SatNOGS Software
1

Hello everyone,

Not earlier than 9th of July, we are planning to release the next version of SatNOGS DB software, the version 1.75. Unfortunately we don’t have the exact date of the release, as this time it needs to be released at the same time with the next version of SatNOGS Network, which currently is still under testing.

In this release there are several bug fixes and small enhancements in the UI and the API, most of them are around the feature of satellites and transmitters suggestions, which was landed on the last big release.

Except of these changes, there are three notable changes and one of them needs some attention as it breaks the satellites API endpoint:

  1. Starting from the breaking change, we are changing the values of the Satellite status. Until today there were 4 statuses, future, alive, dead and re-entered.

    The reason behind this change was the definition of a dead satellite which can have a lot of different interpretations and in some of them it doesn’t guarantee that the satellite couldn’t be active (by accident for example).

    Thus we decided to leave/move the “activity” of a satellite in the transmitters/transmissions entries instead of the satellite information. Thus the Satellite status now will have these values: future, in-orbit, launch failed, re-entered.

    With this change, the values in the status field in the satellites API endpoint will be changed and break the backward compatibility, so please make sure if you use this endpoint that you will be ready for this change.

  2. The second notable change is the feature of “transmitter parameters”, while it will be experimental for the next period, it is a significant step towards describing transmissions/transmitters of a satellite.

    In this release, we have added a json field in Transmitter entry, allowing a structured description of any transmitter parameters.

    Currently this is json field can get any valid json structure, however is in progress a schema that will organize and limit its structure and define a better way to describe transmitters.

    This parameters are planned to be passed in Network observations and be used by the Client and the Radio part for creating dynamic flowgraphs and allow better support of satellites (like more decoded frames and supported modes). For those familiar with gr-satellites, it will be something similar with .yaml files.

    Not able to say when this feature will be complete, as there is a lot of work (designing and development) to be done, especially on the Client and Radio parts, however is in progress and relatively high in priorities.

  3. The third and last notable change in this release is the Launches feature. This is still an in progress feature but with this release it starts getting a shape.

    Launches feature is/will be our organizing solution of information and data around launches. The current solution are the launches forum threads where except from discussions we publish useful data about the launch, like the number of launched satellites or their deployment/reception/identification status etc.

    So, our goal is to have a separate section in the SatNOGS DB that someone will be easily overview the status of (the satellites of) a launch without the need of searching in a big thread with many non-related posts.

    Same with the previous feature, this is still in progress, so not ready to use but there are some basic changes that will allow us to implement the next steps and perform some experiments.

    As part of the above changes for the Launch feature, there are introduced two new fields in the Satellite entry, the Reception Status and the Reception Evidence URLs.

    The values of the Reception Status will be:

    • Unknown (default): No claims of reception
    • Unverified: Claim of reception without public evidence
    • Partially Verified: Claim of reception with partial evidence, for example evidence of transmission on expected frequency or expected type of transmission or expected transmission interval etc
    • Verified: Claims of reception with evidence that identifies without a doubt the satellite, for example demodulated/decoded frames or a strong combination of partial evidence that can not be challenged

    The Reception Evidence URLs, will be a list of links that support the Reception Status value. These could be links to observations (of Network or 3rd party), to forum posts, to mission sites/announcements or to news sites etc. These links will be listed in the Satellite page to everyone use and verify the reception status.

These are more or less the upcoming changes. While their nature is mostly around maintenance, they build the foundation of next changes and features that are planned. If you have any questions or comment, please reply to this thread.

10 Likes
3

Thank you fredy for the detailed information about the three notable changes.

I totally agree with the change explained in number 1.
A satellite cannot be alive or dead, it’s the transmitter(s) on it. Therefore it’s logical to handle alive or dead in the transmitters section.

Staying in the transmitters section, is there a way to mark the two IARU fields as mandatory if the entered frequency/ies lie(s) within (an) amateur band(s)?
And if it’s not the case, how about just not showing those two fields?

Additionally, there have been and still are cases were a satellite team submitted their request for coordination but IARU has not completed it yet.
Currently there is only one suitable option for that: IARU uncoordinated.
I don’t like that because it’s usually used for the case where the team didn’t submit a request at all.
So, how about adding another option like IARU Coordination in progress?

Looking again back to the satellites sections.
How about changing the fields Norad ID and Followed Norad ID?
Norad is only for historical reason and was last entrusted with this over 50 years ago.
Since then it’s just a satellite catalogue number SATCAT.

Finally, the field Owner/Operator should be separated since the owner is not always and automatically the operator.

4

Wanting to be ‘better safe than sorry’, just to confirm…

Are there any changes in the fields or syntax required for manual SIDS uploads (of telemetry decodes)?

Thanks!

5

Yes that should be a good feature, I’ll open an issue about it.

That could be an option too, hiding them if the set frequency is outside the radio amateur bands.

Technically, if is still in progress that means that the satellite is uncoordinated, on the other hand it may be confusing, so we can explore this option, I’ll open an issue too.

Unfortunately for technical reasons, compatibility issues and global recognition and use, I think we can not leave NORAD ID fields right now. However we can check adding SATCAT as an extra one. Again I’ll open an issue to discuss further this.

Another good point, actually we don’t use a lot this field as it gets specific values, we need to update it and improve it, and why not separate these two proeprties (owner and operator).

I confirm it, no change on SiDS uploading endpoint in this release.

2 Likes
6

Will the update come out before the end of July?

Is anyone looking at transmitter suggestions?
7

Yes, due to the Transporter 17 launch, it is postponed at least for one more week to 10 days.

1 Like
8

Okay thanks