Per-server telemetry enabling

[jharwinbarrozo]

When running the test script test.sh, it's also sending live telemetry to satnogs database. I'm not sure if this is really intentional but it looks to me like - this can have a big implication to someone monitoring their satellite for real telemetry.

I was actually surprised seeing my callsign in the satnogs db homepage and seeing my callsign decoded a satellite I haven't even tried decoding in the first place.

[daniestevez]

You're right. This isn't something that I had think of, but I get that it can be a problem.

gr_satellites will send telemetry to SatNOGS DB if both a callsign is set and submit_tlm = yes in ~/.gr_satellites/config.ini. Under these conditions, it will always send any decoded frames to SatNOGS DB.

The problem is that gr_satellites doesn't have a way to know if it's decoding live telemetry that it makes sense submitting to SatNOGS DB, if it's decoding a recording, which should be handled as indicated here to get correct timestamps in the DB, or if it's processing some test data that we don't want to submit to the DB.

The current fix is to set submit_tlm = no any time we want to do some tests to prevent submitting to the DB, and then changing it back afterwards.

I'm open to implementing another way to do this, but I don't see how to get around the problem that the user needs to specify manually whether they want to send telemetry for this run of gr_satellites or not.

[daniestevez]

@jharwinbarrozo do you have any feedback regarding this, or can we close the issue?

[jharwinbarrozo]

How hard to set a flag at the beginning of test.sh to disable the telemetry sending?

[daniestevez]

That's certainly possible, but I think that such ad-hoc solution doesn't solve the main problem, which is that a user that usually does both live capture and recording decoding will typically have submit_tlm = yes in ~/.gr_satellites/config.ini and will perhaps inadvertently send telemetry any time they decode a recording.

Perhaps it's convenient to add a command line option --disable_submit_tlm or similar?

[daniestevez]

Thinking about this again, I believe that an environment variable could be a good solution for the case of the test.sh script. It could be exported at the beginning of the script, then read by gr_satellites in order to disable telemetry submission.

Does this look like a good solution @jharwinbarrozo?

[jharwinbarrozo]

That's actually a clever good solution @daniestevez. As long as it prevents false telemetry sending to the actual satnogs database, we're good!

[daniestevez]

Just pushed a commit implementing the environment variable. The test.sh script should no longer submit telemetry to SatNOGS or any of the other servers. Please test if this works well for you, and if so I think the issue can be closed.

[janvgils]

In line with this change/enhancement, could it be made possible to have a per forwarder definition in ${HOME}/.gr_satellites/config.ini that would enable or disable forwarding.

The reason for asking is as follows, with the gr_satellites SatNOGS integration we now have the situation that duplicate frames are/can be send to the SatNOGS database. When submit_tlm=yes both gr_satellites is forwarding frames via SIDS but also the SatNOGS client that uses gr_satellites for decoding is forwarding.

With this situation it would make sense to set submit_tlm=no but then there are no frames forwarded to the FUNcube warehouse, PW-Sat2 repository nor the BME server.

So for now we keep it enabled, but it would be better to have a submit_tlm per remote server definition and maybe also a generic one.

[daniestevez]

Hi Jan,

Your suggestion seems quite good. I hadn't think before fully about the use case where gr_satellites is integrated with SatNOGS.

Since we have specific sections for each of the non-SIDS servers (as they require information about the station or login credentials), we could have an enable = yes|no field in each of them.

[janvgils]

Hi Daniel,

That would be a great add-on, there is only one other change, SatNOGS would need to have a specific section in the config.ini file. Maybe it would be a better idea to just call it SIDS forwarder and configure the endpoint in that specific section.

I don't know if the forwarder function is now using an array, I guess this add-on can be done fairly easy if that is the case.

Lets give it some more thought.

[janvgils]

Good evening Daniel,

Based on the new label good first issue is there a preliminary version available, if so please let me know so I can see if this is working.

All the best and enjoy the weekend.

[daniestevez]

Hi Jan,

"Good first issue" means that this task is something relatively simple, and that someone interested in contributing code to gr-satellites might want to choose to do to get more familiar with the project. If no one takes this up, I'll do it at some point when I have time.

In any case, updates will appear here, so you will be able to help with testing.

[janvgils]

Thanks for the update, maybe I will take a look but I am not sure I have enough python knowledge.