[Help needed] Gpredict integration with SatNOGS DB

[csete]

@ta7w

I didn’t try to compare the contents… I get the full JSON file from the SATNOGS DB, so I toughed there’s no need to compare them. So what I do is, after a succesfull download of transmitters.json data, I delete the trsp files and re-generate them. Comparing will cost much more than re-generatng I think.

I didn’t mean comparing the contents, just whether you delete all .trsp files or just the ones that have data in transmitters.json?

My concern is if the user adds his/her own .trsp file for a satellite that does not have data in Satnogs DB, will this procedure then delete this trsp file or leave it in place?

[ta7w]

Now I got the point…
I will ccorrect the procedure as mentioned…

Thanks
Baris

[csete]

Just take your time because I’m busy the next two weeks anyway

Regarding your question to @pierros about next steps, I’m hoping we can merge / cherry pick this functionality into my main repository so that it becomes part of Gpredict.

[ta7w]

Ok… I cleaned up some more code… and now it does what you asked for.

I only delete the files that I will replace, others still remain in the folder…

73’s DE TA7W
Baris

[csete]

Hi guys,

Today I have merged the changes done by Baris @ta7w along with some fixes of my own (mostly of practical and cosmetic nature). Good work Baris and thanks a lot.

I have also disabled including of the .trsp files in the gpredict packages, so the primary frequency data source is now Satnogs DB. The files are still in the git repository for reference, in case we find some sats are missing from the DB, but they are no longer distributed with gpredict.

Now its time for a lot of testing

Alex
OZ9AEC

[csete]

PS: I was having a hard time finding this thread after a few weeks of inactivity. Could it be added to some category e.g. 3rd party software?

[pierros]

wow
Thanks a lot @ta7w and @csete ! This is a big step for SatNOGS DB. Let’s make sure testing is underway

@csete I would be more than happy to grant you moderator rights to SatNOGS DB if you are OK with it. Let me know and we can arrange it.

/me goes to compiling latest version

[csete]

@pierros

@csete I would be more than happy to grant you moderator rights to SatNOGS DB if you are OK with it. Let me know and we can arrange it.

Sure, I’d be happy to do my part in keeping the database up to date

[csete]

I had to revert the changes because we found a few issues that make it not quite ready for prime time…

1. The JSON file lists transponders one at a time and so the import code will have to merge different transponders for the same satellite. Currently, only the last transponder makes it to the .trsp file.

2. The mode in the JSON file is an “id” and not a human readable string. I wonder if this is an error at the database end, i.e. the code that generates the JSON file.

I wonder if it would make sense to group transponders together per satellite in the JSON file?

All changes that were reverted are now in a separate satnogsdb branch so we can continue working on it there.

Alex

[pierros]

@csete

The JSON file lists transponders one at a time and so the import code will have to merge different transponders for the same satellite. Currently, only the last transponder makes it to the .trsp file.
The mode in the JSON file is an “id” and not a human readable string. I wonder if this is an error at the database end, i.e. the code that generates the JSON file.

The “mode_id” is a key to a different table/endpoint accessible here: SatNOGS DB API (for sanity of data reasons).

@ta7w I am wondering if you can concat different transceivers with common norad_id in the same file, while resolving the mode_id to human readable format using SatNOGS DB API ?

[ta7w]

I saw the problem…

For the mode ID field, I forgot to commit my last code…

Let me do a final check and commit the changes… Sorry for confusion…

Baris
TA7W

[ta7w]

I will checkout from https://github.com/csete/gpredict/tree/satnogsdb branch and merge my code into it… I hope I will finish it soon…

[csete]

Ok Baris, sounds good. There is no rush since the master branch is now back unaffected.

[comzeradd]

@csete

The JSON file lists transponders one at a time and so the import code will have to merge different transponders for the same satellite. Currently, only the last transponder makes it to the .trsp file.

We currently have filtering per satellite on the transmitters endpoint. Does this suffice for gpredict needs?

eg. https://db.satnogs.org/api/transmitters/?satellite__norad_cat_id=40948&format=json

[csete]

That could be used too after the list of satellites was fetched.

Anyway, I don’t think it is a problem. It just means that the function in gpredict will have to do a little more than traversing the list once and writing data as it encounters it.

[ta7w]

Sorry for late response, I was too busy last two weeks…

I prepared the fixed version which includes

• MODE names are the descriptions from MODES API now,
• The mess of putting only the last transponder into TSRP file is fixed

@csete : do I have rights to push into satnogs branch ? If not, I can commit to my github fork and you may get the effected files…

73’s DE TA7W
Baris

[csete]

Hi Baris,

Make a fork, add your changes then submit a pull request with respect to my satnogsdb branch.

Alex

[ta7w]

I did…

If I have time this weekend I will try to d a code review myself…

Thanks
Baris

[pierros]

@ta7w Hey!

Did you have any chance to get any traction with this? We would love to see DB in gpredict! Thanks for all your hard work!

[csete]

Yes, there is an open pull request now that is waiting for me, but I am overloaded with gqrx at the moment and probably till the end of September, sorry.