Feature suggestion

[oe6rke]

Hello people,

because of playing more with your great software i found some additions which would be great to have:

i would like to have a field, where i can annouce scheduled downtime of the ground station.
also some sort of deletion or cleanup function for bad recordings would be nice to have.
same with dedicated recording job for a particular station (as like as when i test a station i would not disdurb other records.

thanks if such addtions could be made,
br Robert, 73 de oe6rke

[oe6rke]

sorry, forgot one important one.

to edit the encoding for the scheduled recording would be nice.i try to record usb or cw signals. and if such mode is part of the job info i could bring the rtl_fm into the correct more (by manual those modes and even raw iq would be possible ).

[pierros]

Hey Robert! Thanks for the suggestions I will try to answer inline.

@oe6rke

i would like to have a field, where i can annouce scheduled downtime of the ground station.

This could be totally possible using our current model (and probably an easy coding task). It might need celery tasks on the backend though @comzeradd?

@oe6rke

also some sort of deletion or cleanup function for bad recordings would be nice to have.

You probably mean observations. This indeed makes sense. Probably only for the observation author (the one issued it). Currently you can delete a scheduled (future) observation (given it is not within 10mins of execution).

@oe6rke

same with dedicated recording job for a particular station (as like as when i test a station i would not disdurb other records.

Same as above but for a particular job. Still possible, and I would say that still the author of the observation should do it. (not the ground station owner)

@oe6rke

to edit the encoding for the scheduled recording would be nice.i try to record usb or cw signals. and if such mode is part of the job info i could bring the rtl_fm into the correct more (by manual those modes and even raw iq would be possible ).

This is probably already addressed by deleting the observation (future one) and adding a new one. That works?

Also, feel free to add anny feature suggestions, on top of discussing it here on the github repo as issues here.

[comzeradd]

@pierros

@oe6rke

i would like to have a field, where i can annouce scheduled downtime of the ground station.

This could be totally possible using our current model (and probably an easy coding task). It might need celery tasks on the backend though @comzeradd?

Right now we have an operational flag exposed on the “Edit Station” form. If you set this off the station is not visible during observations scheduling (even if it polls the API). This of course doesn’t cover the case of scheduled downtime, but we can probably tweak this to have date range if we think it’s something that will be used a lot by stations operators.

@oe6rke

also some sort of deletion or cleanup function for bad recordings would be nice to have.

In the spirit of open access we want observation data available to all people, not just to the one scheduling the observation. My concern here is that this will give the right to an observer to also delete good observation data. An idea would be to have some sort of marking recordings, like ‘report as invalid’, or the other way around ‘mark as verified’.

@pierros

@oe6rke

same with dedicated recording job for a particular station (as like as when i test a station i would not disdurb other records.

Same as above but for a particular job. Still possible, and I would say that still the author of the observation should do it. (not the ground station owner)

Yeap, I agree. Issue already opened.

[oe6rke]

thanks for discussing my request/ ideas.

re scheduled downtime:
during my setup phase i thought that it would be quite usefull for the observer if a station can record a session. this would be also very handy to identify stability of the system because of unplaned downtimes.

re deletion of observation data:
i think all stations here share the openess of providing their station to gain data. but also during test and setup phase many useless data is created. and therefor some sort of “bad data” flag for filtering or deletion method should exists.
this would be very useful to identify good data for reference and more. i think some form of annotation would be a great addon. this would help to mark recordings with meanful info as like as “ARISS school contact with xyz”. maybe also some sort of “voting/ranking” of recordings could be helpfull for beginners too.

re editing observation job:
even for deletion the job 10 mins before it starts a chance to edit params for the observation would be helpful. In my case i was playing around with fm, lsb and usb modulation for funcube data beacon. because there was no modulation defined in the channel database the system fell back to the fm default and i had to alter manually the receiver.py to fulfill my tests. if there is the chance to change this via observer job webmask i would be very happy.
additional ticks as like as “do automatic decoding with” and selectable types like afsk1200, fsk9600 would be a nice feature to ease post processing and take complexity of dealing with satellite data.

so many thanks for considering the ideas,

br Robert, 73 de oe6rke

[cshields]

@oe6rke

re deletion of observation data:i think all stations here share the openess of providing their station to gain data. but also during test and setup phase many useless data is created. and therefor some sort of “bad data” flag for filtering or deletion method should exists.this would be very useful to identify good data for reference and more. i think some form of annotation would be a great addon. this would help to mark recordings with meanful info as like as “ARISS school contact with xyz”. maybe also some sort of “voting/ranking” of recordings could be helpfull for beginners too.

This (mixed with @pierros idea of flagging a reception) could be tied in with the feature request for commenting observations: https://github.com/satnogs/satnogs-network/issues/140

Ideas for observation tagging: “testing”, “reviewed good”, “reviewed bad”, “needs review”

Maybe have everything tagged as “needs review” by default - think of this being at large scale where we have daily observations from dozens of stations globally - reviewing the data will be as much of a chore for the community as running the stations. Then, a user preference could be set to not show “reviewed bad” observation data by default.