Why is Fredy Damkalis schedulling observation in all the stations?

Satellites & Observations
1

I don’t like to have observations without status, but I see in my station a lot of observations scheduled by Fred Damkalis without status.

Is it really need it to schedule observations for inactive satellites all around the world?

image
image2001×1561 366 KB

73 de EA5WA Juan Carlos

2 Likes
2

Hi @ea5wa,

the satellites shown in the screenshot belong into two different groups of scheduling:

  1. Satellites that haven’t been identified and they are near to LEOP, so I’m scheduling them to have observations for analyze them later
  2. Satellites that are identified but we, operations team (anyone who wants to join let me know), want to record/know their status (if they transmit or not).

Let me also add some thoughts and notes:

Vetting, currently checking if there is signal or not in waterfall, while it is helpful for checking the status of the satellite or the status of the station, isn’t obligatory for either the station owner or the author of the observations.

In other words, you shouldn’t feel bad if observations on your station or observations you scheduled haven’t been vetted, it’s absolutely normal especially given the volume of observations scheduled daily which is increasing and will be increased even more when auto-scheduling is going to be implemented in the Network.

While vetting isn’t the first priority of the operations tasks, there are people performing it systematically and thus we have around 50% of the observations’ waterfalls vetted (I’ve just checked that, to be honest I was expecting a lower percentage).

At this point let me also make clear and explain how statuses and vetting works. First let’s separate the waterfall status and the observation status. The first is the status of the waterfall (obviously :smiley:) which shows if the waterfall has signal or not or if it is unknown, this status can be changed by the user through the vetting process and affect also the observation status.

The observation status on the other hand shows a more generic status for the observation and it is the one that you can see with the color in your screenshot. This status is affected by the waterfall vetting but it is not the only case. Currently there are three more cases that affect the observation status:

  1. When there are data frames uploaded for specific modes, in this case the observations status changes to good (have in mind that they could be some false positives in this case)
  2. When the station fails to upload any artifact (audio, waterfall or data) after some time, in this case the observations status changes to failed, as we expect that there is an issue with the station.
  3. When the uploaded audio file duration is more than one minute different from the duration of the observation, in this case again the observation status changes to failed, as with such a difference probably something goes wrong with the station, usually buffer overflows or underruns

The observations with status different than “unknown” (orange colour) are currently around 80%, so around 30% of the observations where automatically assigned a status (which again I note that it may be a false positive).

So, someone would say, why not scheduling only what we can vet (either automatically or manually)? The answer is simple, we are trying to gather as much data as possible, which is something usual when you observe something, especially when this observation can not be repeated, for example there are tons of data gathered by telescopes that may take years until they are analyzed and used.

Vetting observations is part of the analysis of our observations, so it’s not necessary to be done quickly or to be done at all. However in some cases, like checking the status of the satellite, finding it’s orbit, checking the status of the station etc we need some observations vetted to proceed with these tasks.

This is why we keep vetting observations and keep improving the process as well as its automation. One of the plans that is high in priority is the “mutli-vetting” feature, with this we will attempt to transform vetting to a more crowd-sourced process that will open vetting to everyone (currently only station owners and some operators can vet) and also allow further automation in vetting, like bots(AI ones or not) participating in the process.

I hope this answers your question, let me know if you want me to expand on any of the above.

11 Likes
3

I would also add to @fredy 's post, that, especially at this moment when it comes to Bluebird sats (see this video ) ,SatNOGS can act as a monitoring actor of the use of the ham radio RF spectrum.

8 Likes
4

Perfectly explained.

Many thanks Fredy

73 de EA5WA Juan Carlos

6 Likes