XML and JSON interfaces to satellite database

[g4dpz]

Hi,

Yes, it's perfecly possible to get updates from Space-Track on a daily basis. They have an API specifically for doing it.

Unfortunately, they do not explicitly catagorise CubeSats. We would need the catalogue numbers.

I do a similar thing (weekly updates) using CelesTrak for FUNcube position determination.

- Dave

[g4dpz]

Hi,

I've shared the beginnings of the project I started a while ago on GitHub:

https://github.com/FUNcube/SatInfoService

- Dave

[g4dpz]

Hi,

Suggest we start a separate thread to discuss the schema and split out other topics as we need them.

Otherwise the discusssion will get noisy.

- Dave

[pa3weg]

Sure, I will split the topic already as needed, the rest will move to a new topic here:

[Pb0ner]

Hi all,

Interesting enough I have been thinking about this due to te fact that I have started to create a new sat tracking software package for amateur use. I have evaluated all software but found most of them somewhat outdated, incompatible with my wishes and as a OS X user with my preferred OS.

Personally I am somewhat disappointed that a lot of software is Windows only (sorry guy's including the FC dashboard) and I am making it platform independent.

One of the issues is that it is hard to get started with satellites due to the fragmented and often outdated information. One of those is the issue discussed here. I have not looked into the XML format yet and I have to dig a bit more into it so I will not comment just yet.

The only thing I can think of just now is a way to distinguish between 'moving' and geostationary objects as for those there is no Doppler.

I also would like mention that I'm interested in spending some time to get this supported into my software and if appreciated to create or help with the online database spoken about in this discussion.

Please feel free to contact me for any reason!

Kind regards,

Martijn

[pa2eon]

Hi All,

To keep a central database with actual (cube)sat info is not easy.
So I think the database can be up 2 date if more people can give their (actual) information with a minimum of 1 control 'partner'.
I mean a user will bring in data of a sat like, Freq - FSK mode - pictures, weblinks, used applicatons etc.
The information will get the ' draft' state and need to be 'checked' by another HAM sat spotter.
If so he/she can send the confirm button, with a realtime spot(picture) or actual kiss file.

In this way of working you can check also if an 'older' sat is out of order or is changed by frequency.

The main information on the database screen must have enough data to use for beginner and 'professional' radio HAM to collect the sat data.
In basic the TLE, received frequencies and modes, link to hardware builder, picture , a sample sound (if recorded), a visual picture of the (SDR) datastream.
It will be great if the database can ask the user his/her QTH locator and from this start(view)point the sats who are in the ground-track area will be shown.
Another great thing this wil be a up 2 date LTE file with al the active ' Oscar sats' and sats with TX equipment on board to give the user easy selection to make a choice from.

To fill the information in the database you have to register to the database manager.
To get the information it will be free for everyone.

At last .. if the database is in use.. apps will be send their results direct to the database in standard (kiss) format .. so hardware of school students can collect their started data in the database.
This as start .. if you have more ideas you can give your own feeling about the use and build of a central (cube)sat database.

Regards,
Eric - PA2EON

[pa2eon]

As update the result screen can look like:

http://www.pa2eon.nl/cubeinfo/uwe3.htm

[pa3weg]

I am afraid we are now mixing apples and oranges!

There are several "applications" and "databases"
terminology is differrent, but we need:

IARU Freq Coordination application and database. The IARU could use something to register and make frequency coordination easier that would contain contact details, Sat name, scheduled or actual launch date, Launch(/Service) provider, Type of Sat, Frequency/link details, Operational Status, Sat cat no, Sat object no, Request Status, Mission details etc etc

An application providing "Dcarr" functionality to the whole community, and database

An application providing a list of active satellites for the users and satellite frequencies, and database

An interface that allows direct interaction between the database(s) and applications
We are discussing this interface here

But we also need to think about these databases and their interaction.

Processing data, kiss files etc etc should be handled by the teams. But if its FUNcube format data, we have a warehouse. If its Delfi-C3 data, there is a warehouse. And so on...

Standardizing this only makes sense within AMSAT, and we have this solution at least for AMSAT-UK/NL

[pa9tv]

I think the development should be requirement driven, so we need to find the 'customers' who will define the requirements.

Are there any reading this topic?

If there are, i hope they can formulate their specific use-case. After we have a few use cases, we could define an interface for providing this data.

Please feel free, to specify any preferences in format, json, xml, others? Please specify frequency of retrieval, and if the interface query is in bulk (all), subset or individual satellite.
Also please specify your data requirements in order of importance.

Gr. Simon

[pa3weg]

exactly why I created the use case thread, so lets see!



We do need to talk about the interface as well, but the data base should basically allow any kind of interface if needed.
I would say both JSON and XML should be supported.

It is clear that the main purpose of the interface was to allow tracking programs to fetch the data they need. But this database interface can consist of so much more...

Wouter