Can not delete observations on my own station

If I make observations for certain reasons and then they are no longer required, I should have the ability to delete them. Also failed obs due to GS hardware/software issues. They are not necessary to be kept.

There are currently 2 open issues, Client #289 & Network #424, created over a year ago. Would be great to have them implemented and should be too hard.

Good Morning,

Please accept my apologies about that late answer back.
It was 02:00AM and I need to sleep (call of the nature).

Let’s clarify few things…

    @Zathras, please do not do it…This will make me very very sorry and do not serve the reason why we in here and why we participate the project…

  2. Dear @pierros, I was not meant to be aggressive when I wrote the message but in the mean time I am still back of this idea… Even I believe it is not an aggressive message when you evaluate it it total, not the sentences picked up in it…

  3. @KD9KCK, lets clarify your question…
    Think about you decide to contribute as a volunteer to your community for to use your truck on public work. They told you that you have no option to select what you carry on your rear bed… It is perfectly OK and all of us still doing it ( Are we OK @Zathras, eh?)… Then one day the you discovered your truck’s wiper arm is removed and when you asked why? One of the community management member answered you that you cannot wipe your front shield because they want to know how dusty your truck in the mean time… (Maybe the example is not 100% fit the situation and please use your imagination and help me… I did not get my morning coffee yet, OK?) What will be your reaction? Please think twice, OK?

  4. Dear friends, please DO NOT personalize this kind of things as you… We really do not know who you are… And -for me at least- this is NOT showing your success on this life for me…
    This is just a simple volunteer work that all we participate. DO NOT measure your ground station success with the the results marked “Good” or “Bad”… IT IS NOTHING… You really cannot control the most of the part of this system. Please DO NOT try to measure your success with results… There could be millions of other things can affect the results that you collect… And they are really not under your control… Are we clear on that?

At this moment may I offer something more meaningful -at least for me- ?
Let’s measure the success level of the ground stations with online hours… How many hours your GS is online?

Maybe we can extend this with how many other participants used your GS and leave jobs in it?

I will write little bit more on that subject later on but I need to go and prepare breakfast…

Be the peace with you…


I’ve long been an advocate of “station owner’s rights”. With that said, I would argue that the system owner SHOULD be allowed to delete any observations they want that were taken on their system. However:

A) This should NOT affect their performance statistics. I’m sure there is a way to keep that information and just ditch the audio and waterfall image.
B) Why would anyone really want to do this? The only reason I can think of is when there are system "Fail"s, of which you should keep the “Fail” as a statistic, but really there is no reason to keep a solid (or “missing”) waterfall or audio.

Finally, @ta2ank - your analogy for the pickup truck isn’t quite right. It’s more like if you lent your pickup truck to a charity organization to do work, and then after the work was done (lets say moving a load of diapers from a warehouse to a homeless shelter), you told them you wanted to move all the diapers back to the warehouse, because “it was your truck”.

Still not apples to apples, I know, but it never is. Anyhoo, I understand both sides of the argument. Keep in mind that we still commit to the project when we sign up - so there have to be SOME amount of rules we follow. Just my 2 cents. (American saying for offering mostly worthless thoughts).


No, this is exactly one point why observations should not be deleted! Maybe someone else relies on the data of this observation, not useful for the station’s owner meanwhile…

@Zathras @pierros @ta2ank

I would like to issue a formal apology for the tone of my recent posts.
I also don’t really have a position in this because I never use the Delete function except to remove future observations.
I now see some valid reasons why removing past ones would be okay.

1 Like

No, this is exactly one point why observations should not be deleted! Maybe someone else relies on the data of this observation, not useful for the station’s owner meanwhile…

If I make observations, for my own reasons, who else relies on this data? No-one, because I’ve done it for a specific reason. 99.9% of the time, these obs have NOT been scheduled by anyone else, hence of NO importance to them.
So therefore, I want the ability to delete. Simples.

For example if you scheduled a satellite and someone found that observation later while searching for observations of that satellite. (Even people that don’t have a station can do this.) They may rely on data of the observation even if they did not schedule it. (Like hearing yourself on a satellite after a QSO)

I have at times gone back to multiple observations not made by me on different stations to collect data from satellites at specific times. (For example to try and figure out what happened during a period of time)

I am just providing an example of what @DL4PD means.

1 Like

I think people (including me - and I believe station owners should have the right to delete their own observations) are still baffled as to why you would want to delete the observation. It’s a historical record of the satellite - why delete it?

I’ll give a scenario that has happened to me a couple of times: the rotation of my antennas loosens a coax at the diplexer, causing it to come disconnected. This causes days of waterfalls and audio with no real data in them until Dimitris notices and emails me. For a station that is normally good at producing results and a satellite that is known to be transmitting, is that an accurate historical record for the satellite? By our guidelines, they should be marked “Bad” even though as a station owner I know they “Failed”, yet to another visitor (or the observer), marking them as “Fail” is confusing when results were in fact produced.

…best to just delete them, IMO

(ideas for securing PL-259 connectors welcome, keeping in mind I end up needing to change them from time to time)

1 Like

Exactly, that’s all it is. Doesn’t matter if you do or don’t, it’s the right to do so. Not to have other people dictate what you can or can’t do.
Simple. So bring it back and all will be good.

@cshields is spot on the money :slight_smile: :slight_smile:

Well, Corey’s example is more of an argument for a change to the vetting results options. There really should be some sort of option that indicates a questionable result. Or, as I’ve suggested in the past, room for a very quick note where the vetter can write something like “station observed silence as there was a break in antenna feedline”.

edit: Isn’t the whole reason for PL/SO connectors that they shouldn’t loosen? The engagement teeth should limit rotation to a very small amount and prevent complete disconnect, no?

For stuff I’ve deleted in the past, I would be satisfied with a “recycle bin” model. The “delete” function removes the obs from searches, stats, etc. and if someone really wanted to go looking at the trash, its there.

I agree that this is/should be a greater conversation about vetting options. I’m sure station stats matter more to some people than others, so what does a “fail” mean and should it involve automated owner notification right away so they don’t stack up?? We are also unclear in the UX as to the impact of a “bad” observation to a station’s stats, so some people may avoid satellites that have not functioned well in the past to avoid a bad station stat which may have led people to delete in the past where “historical record of the satellite” applies.

constant movement day and night slowly loosens the sleeve enough that the teeth disengage. My thought to fix this is to mount the diplexer horizontally (or flipped vertically) but its in a prohibitive box at the moment.

I guess I shall learn this soon enough. My rotator system is probably a few weeks away from going online…

I’m new myself and have been following this thread. I can’t see what the problem is.
I notice other people scheduling lots of observations on my station. If I decide I don’t like this, I have the option of putting my station in testing mode or shutting it down if I don’t want to share my resources. It’s voluntary.

If I don’t want to share my captured data then why store it on someone else’s data base (SatNOGS) and use their resource? Like fakebook, if you don’t want the world to see what you post, DON’T post it! Once you give your data to the internet, it’s no longer yours.

If you want to make personal observations which you don’t want to share you would actually be better of with a stand alone system like Gqrx + RTL-SDR.

My tuppence worth (The Aussie way)

1 Like

Of course there is an issue, rights have been taken away.

When GS’s fail, and they do from time to time, what is the point of saving blank/corrupted observations? NONE at all. So, we should be able to delete these. How hard is that to understand?
No point keeping the obs and having a ‘explanation note’. Pointless.

Now, even a GS in ‘testing mode’, will not allow obs to be deleted. Sheer nonsense. Station is being tested, so you can guarantee some of the obs will not be valid. Why not delete them?

So 2 simple reasons why the delete needs to be brought back. That’s all I want, so I rest my case.

I doubt my 2 GS’s will be missed.

The intention of this change, from my point of view, is not to take away rights. The intention is to protect already uploaded data from (accidental or not) deletion in order to provide an accurate dataset to anyone who use it or will use it in the future (and there are already projects, like polaris, that use it).

In detail:
Removing a “Good” observation doesn’t allow satellite teams and other researchers to know that at the time of the observation the satellite was transmitting and to extract any other useful parameters from the waterfall and audio. And if the observation had demoded/decoded data then we lose these data too.

Removing a “Bad” observation doesn’t allow satellite teams and other researchers to know that at the time of the observation the satellite wasn’t transmitting and to extract any other useful parameters from the waterfall and audio.

Removing a “Failed” observation doesn’t allow community and other researchers to understand how the whole network works and to extract info like how often a station gets offline or has hardware or software issues. This is very useful feedback in order to be able to prioritize hardware and software development in order to improve stations and the network and also useful to know how stable the network is.

I’m not sure if it is pointless, for now there is the discussion button that somebody can open a discussion and add comments for an observation. However this doesn’t get into the metadata of the observation, maybe while moving to the artifacts schema we can add a field for notes/comments.

All the stations are important for the network, without them the network wouldn’t be a network, with all the consequences that this can have in helping LSF’s vision for an open and accessible space. I can not express how happy and grateful I am when I see a new station and how sad when a station goes offline and stays in that status for a long time, especially if it was very active before.

Kind of offtopic but related:

I’ve seen in other posts that some people maybe worry about the stations stats. As I’ve commented on an irc/matrix discussion we had about this matter, I want to point out that given the open discussion we have around vetting, it’s clear that vetting it’s not a simple process and it is also in some cases a subjective one, plus that we have many cases were the data weren’t vetted right (either automatically or manually).

So, wrong vetting means wrong stats in stations page. But it’s not only the wrong stats for stations, from discussions I had with other community members, these stats doesn’t show at all the quality of a station, so we need to find new ways and metrics for getting these info. And this is one more reason to reform vetting.

And the question is if these station stats are not correct, why they are there. The answer is that we quickly added this metric for stations in order to have a quick and a rough idea about how the station performs. It was added 3 years ago when the active stations weren’t more than 10 and the needs and priorities were a lot of different than what are today. In other words, it needs to be changed, how and what would be the new metrics is an open discussion.


I will say this… for a “community” of volunteers, a lot (most? all?) of the decisions are being made by a very small amount of informed people. This may not be a huge problem now, but it will get bigger and bigger as the network grows.


Who is going to use blank or corrupted obs? How are they accurate?
Be real here. These obs are of no use, so should be deleted. Let the GS owner have control, not solely in the hands of the SatNOGS team.
Seems like a power play for complete control, regardless of validity.

I’ve recently asked for help regarding hardware/software issues and all I got was 2 responses, with 1 stating what I’ve already tried. The other was just a question. There’s been no other responses even after an answer to the question.

Well be doubly sad, my 2 GS’s are offline. Should the delete decision be reversed, the status would change.
I’m out …

Sorry to say, but you seem to be missing the bigger picture here. Observations that are failed are for the very least useful at checking the overall health of the network. Think of it from the Network perspective, trying to answer questions like:

  • “What is the probability of a failure of a scheduled observation?”
  • “How often ground stations fail to return artifacts/results”
  • “Is there a common trait for the fails? Perhaps client version? gr-satnogs version? time of the day?”

Answering those questions is crucial on tuning auto-schedulers (e.g. for observational overlap based on probability of an observation being failed)

Unless SatNOGS has all the observations, including the failed ones, there would be no way to answer those questions.

I commit on explaining in more detail how SatNOGS works as an open source, non-profit, collaborative project, what is the role of LSF and of various people, because based on your comment and the unfortunate comment of @K3RLD there seems to be a misunderstanding there.

And what would be the reason behind that? You think that @BOCTOK-1 that noticed the extend of deletions and raised a flag, @fredy that coded the change and myself (in this case) that approved it, woke up 3 days ago and said: “gs owners have more control than they should… let’s remove some to make a point!” :wink: