Changes in Network and DB for satellites that violate frequency regulations

This is a post towards all our community about the recent developments that have been deployed for limiting observations for satellite that violate frequency ragulations.

After long discussions here in the community, in the matrix channels and in development meetings, the implementation takes into consideration these factors:

  • As community, we want some observations of frequency violators to be able to record these frequency violations, documenting them for posterity.
  • As community, we want observations of frequency violators to be able to contribute to Space Situational Awareness(SSA)
  • As station owners, we want to have the freedom to choose if we want our station to be scheduled for satellites that violate frequency regulations.
  • As Libre Space Foundation (LSF), we want to limit our resource usage for satellites that violate frequency regulations.

Having in mind all the above and also some technical limitations, these are the changes that have been deployed:

Note: “Violators” below is used as an abbreviation for missions that are flagged with frequency misuse. See here for more details.

  • For SatNOGS DB:

    • Remove “export data” functionality from violators pages
    • Expose frequency violation on Transmitter API for violators transmitters
    • Expose frequency violation on Satellite API for violators
    • Rate limit Telemetry API to 1 request per day for violators telemetry.
  • For SatNOGS Network:

    • Allowing station owners in station settings to choose who is going to schedule violators. Options are: Noone(default choice), Only Operators(check bellow), Everyone
    • An Operators group is created to schedule violators only for SSA purposes and for recording violations
    • A limit has been applied for scheduling violators, currently is 2 observations per day but it is configurable and it will be re-evaluated in the near future. This limit doesn’t apply for Operators group scheduling.

Notes:

  1. SatNOGS Network and 3rd party clients will be able to send freely data to SatNOGS DB for the violators via SiDS protocol
  2. For station owners, all the current stations have moved to the default option (Noone) for scheduling the violators
  3. For station owners, for SSA purposes and recording violations, please consider to change the option in your station settings from Noone to Only Operators. This will help us document cases of frequency misuse across the world.
    EDIT: As @mfalkvidd added bellow this can be done in https://network.satnogs.org/stations/edit/<your-station-number>/ (not in the satnogs-setup command line utility).
  4. The operators group is open to everyone who wants to help with scheduling, SSA and other operations of SatNOGS Network. If you want to join the group, please get in contact with the community
14 Likes

Excellent work! Striking a balance in this matter isn’t easy. Therefore I really appreciate the efforts made by the community.

One question, regarding

I think this applies to violators only? Or for all transmitters?

3 Likes

Currently the data in DB are not related with the transmitters but the satellites. So this is limited based on if satellite is flagged (has at least one transmitter flagged).

There is a plan for adding the transmitter information in data entries but it isn’t a priority for now.

1 Like

btw, might be worth noting that the scheduling setting is managed at https://network.satnogs.org/stations/edit/<your-station-number>/
(not in the satnogs-setup command line utility)

I have updated the setting for my station to allow operators.

2 Likes

I run the auto scheduler for my station. Since I am not part of the operators group, will the auto scheduler schedule a maximum of 2 violator observations per day?

I’ve just checked this and the behavior is that you need to set the option to Everyone for being able to schedule in your station. It sounds strange to not being able to schedule your station if you allow Only Operators to do so, I don’t remember if this was a quick decision during development or just not checking that. What do you think the right behavior should be?

1 Like

I think we should keep it as such. If you are operating your station as part of the SatNOGS Network you know that the policy of the Network is followed.

1 Like

I agree. Perhaps there should be an option to override, but I personally don’t need such an option.

1 Like