[Help needed] Gpredict integration with SatNOGS DB

Gpredict
1

Hello everyone!

Gpredict is a fantastic tool written by @csete which we use extensively for simple operations and debugging of our stations. There are many HAMs and satellite enthusiasts that use Gpredict for their own operations and we would like to make sure they benefit from SatNOGS DB data.

Gpredict already has the functionality for fetching Satllite TLEs from network, and we would like to see a similar functionality for frequency data. The concept would look something like:

  • User selects ā€œUpdate frequency data > from Networkā€
  • Gpredict fetches data from SatNOGS DB API
  • Gprefict updates local satellite frequency data

Our understanding is that someone coding in C would be able to pull this off quite easily. Any people willing to help on this?

@csete your input would be tremendously helpful too :slight_smile:

1 Like
2

Hi @pierros

Good idea! It would be nice to have this feature integrated and I think the concept you outline may provide the easiest integration.

My only firm request is that we do not add a bunch of new monstrous dependencies. I guess the only new dependency needed is a JSON parser, so a small, light weight and embedable C library like JSMN could be used.

2 Likes
3

Hi

I have a few questions before volunteering :wink:

Where will we host the frequency data ?
What should be the format (content) of this data ?

73ā€™s de TA7W baris

4

My question was too early before reading the link you providedā€¦

I started reading the DB API, but the second question still remainsā€¦ What details should we have for the frequency definition ?

Struct in my mind is :

  • Beacon FRQ
  • Beacon Mode (CW, FSK, AFSK, Carrier, erc)
  • Radio Type (Simplex, Duplex, Transponder)
    ā€“ Simplex FRQ
    ā€“ Duplex RX FRQ
    ā€“ Duplex TX FRQ
  • Transponder RX FRQ start
  • Transponder RX FRQ end
  • Transponder TX FRQ start
  • Transponder TX FRQ end

(

ā€œtransmittersā€: ā€œhttps://db.satnogs.org/api/transmitters/ā€ Provides :

    uuid,
    description,
    alive&quot,
    uplink_low,
    uplink_high,
    downlink_low,
    downlink_high,
    mode_id,
    invert,
    baud,
    norad_cat_id

and comments ?

5

gpredict holds all transceiver data in a configuration folder named trsp
In there there are different files per satellite, named as <norad_id>.trsp
In each file there is a structure to display multiple transceiver/transponder information as follows:
ps. I am putting the SatNOGS DB names of it in {}

[{description}]
UP_LOW={uplink_low}
UP_HIGH={uplink_high}
DOWN_LOW={downlink_low}
DOWN_HIGH={downlink_high}
MODE={mode_id}

Each file could contain as many blocks like the one above as needed (there are multiple transceivers per satellite sometimes.

We should probably amend MODE with not only {mode_id} but also with {invert} and {baud}. @csete?

So basically, Gpredict fetches info in JSON format from SatNOGS, parses them and creates/updates files in the above specified format.

6

Hi,

I just read your explanation after finishing my ugly and fast implementation. I used mjsn as @csete offered to parse json filesā€¦
I forked gpredict to my github http://github.com/barisdinc/gpredict ā€¦

I uploaded a video of the current status to youtube

I think it is a better way to follow your explanationā€¦ I need a few days to come up with a new versionā€¦

1 Like
7

wow, great work @ta7w! Fixing it to follow the tsrp way of doing things would be the final touch to make it perfect :slight_smile:

@csete what do you think?

8

Where we see the ā€œtrspā€ file output in gpredictā€¦ I had to add this info to satellite information windowā€¦

What is the way of gpredict to display this information ?

9

Double clicking on a satellite opens a ā€œSatellite Infoā€ window. There are two tabs there. The second is ā€œTranspondersā€. information gets displayed there, but also is used by Radio Control panel when controlling a rig (super useful).

10

Can be a silly stupid question, but, where this information come from originallyā€¦
I can see that if I download the required information from SATNOGS DB and put it here accordingly, everything will work fineā€¦

Are these files I have here are STATIC files originally? I donā€™t want to read the code to figure it outā€¦ :sleeping:

11

Originally gpredict ships with some .tsrp files of some basic radio amateur satellite information. Fetching from network (SatNOGS DB) should replace existing with new information on those files and/or add new files, same way fetching from network does for TLEs.

12

OKā€¦ I got itā€¦ That will make my implementation much more simplerā€¦ :slight_smile:

13

Ideally, the mode string should be compliant with the Hamlib interface, but I think already today that is no longer the case. I have been accepting new .trsp files containing all sorts of descriptive mode strings.

14

Indeed.

Back in the old days, it seemed like a good idea to ship TLE and transponder files with gpredict, but today it is pretty silly. So we have a chance to do it right with the trsp files, then also fix it with TLE files later.

If we do it as suggested above by @pierros, I will remove the TRSP files from the repository and the distribution. In a second round we could add an option to load TRSP data from a local JSON file.

15

@ta7w Looks good so far :slight_smile:

16

@csete Which is the better way of doing this :

a) Download SatNOGS JSON transceiver files and convert them to trsp files on the fly, no modification for the rest of gpredict
b) Download SatNOGS JSON transceiver files and save them as json files, but need to modify the gpredict satellite info loader part

I think I will prefer the first oneā€¦

17

You raise a good point.

Itā€™s probably best to keep the current trsp file format for compatibility reason and as you say, less change.

18

I think now I have a better implementation at http://github.com/barisdinc/gpredict

It deletes the old trsp files and downloads/generates new ones from SATNOGS DB

I used nxjson library (nxjson.{c,h} added to project} for json parsing

question @csete : I had problem with locales (the comma and dot delimiter for numbars), so I needed to change the locale to ā€˜Cā€™ within frq-update.c , Do you have any comment ?

Files changed :

src/Makefile.am
src/menubar.c

Files added:

src/frq-update.c
src/frq-update.h
src/nxjson.c
src/nxjson.h

Things to be done :

  1. Correct the locale problem
  2. Finish local file support
  3. Update MODE variable in another query
  4. Better progress indication

@pierros : What will be our next step, should I go on commiting to my own repository, or will we have a common repository (e.g. a branch to cseteā€™s) ?

73ā€™s de TA7W Baris

19

Hopefully it does not delete all files, just the ones that there is new data for?

As long as the setting is local and does not affect the rest of the application I donā€™t care, but where do you need this? As far as I remember, gpredict uses the frequency in Hz, so no decimal is required there.

As you may guess from my comments, I havenā€™t done a thorough review of the source code yet. I have too many things on my mind at the moment but Iā€™ll be happy to check it later when you think it is ready.

20

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 will try to make it local to my partā€¦
ā€œbaudrateā€ in satnogs DB is double and the delimiter is ā€œ.ā€ e.g. :0.0 1200.0

I didnā€™t dive in details of nxjson library, I may correct the problem there, but quick fix was to make the locale ā€˜Cā€™, Iā€™ll fix itā€¦

Yes I read your commentsā€¦ Bu to be honestā€¦ You did a great job ā€¦ The quality of the code I added can not be compared with yours, but I hope if this new function becomes useful, you may correct itā€¦

73ā€™s DE TA7W
Baris