You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ground station right now is not where it needs to be, so similar to pFS we will be pursuing a rewrite.
Overall Ground Station Goals
Telemetry
All telemetry from the satellite should be accessible to the general public, as our mission is called "Research and Education Vehicle for the Evaluation of Radio Broadcasts"
All raw messages should be stored, timestamped by received time, and easily accessible
All telemetry should be parsed from the raw message and be stored based on the satellite's timestamp
All telemetry should be easily visualized in the ground station software (graphs, charts, etc.)
All telemetry should be easily accessible for analysis (i.e. all the telemetry should be available to download as a large file for deeper analysis)
Only authenticated users should be able to add telemetry to the shared store
Commands
Only authenticated users should be able to add commands to the shared store to eventually send through the USRP
Critical commands should be sent automatically (e.g. antenna deployed confirmation)
Before sending, the commands in the store have to be validated to ensure that they are an available message to send.
System
In order to achieve all the goals, there will be three components to the ground station: a frontend, a backend, and a store.
Store
The store is how the frontend and backend communicate to each other. They both "monitor" the store, and when something changes they will get a notification. The store we will be using is Google's Real Time Firebase Storage. Using their SDKs/libraries it should be very easy to monitor/listen for changes in the database. If the backend puts telemetry in the database, the frontend should update in real time to show the new data. If the frontend puts a new command in the database, the backend should validate and send it in realtime.
Frontend
The frontend should be written with some frontend framework (e.g VueJS, ReactJS) with a boilerplate (e.g. https://demos.creative-tim.com/vue-black-dashboard-pro/#/dashboard). Eventually, this frontend will be publicly available at https://activities.tjhsst.edu/cubesat/groundstation. The frontend should actually look good and use graphs, tables, charts to convey the telemetry so its easy to comprehend and visualize. It should also give the ability to authenticate users. If the user is authenticated, they should have access to send commands. Both updating from and putting in the database should be done through JavaScript on the frontend with no GET/POST requests.
Backend
The backend will be written in Python 3.8. It will use the firebase-admin python package along with the built-insocket package to communicate with the store and the flowgraph. This backend will a pure python app and will not need to implement any web stuff (unlike the Flask backend before). Whenever it receives anything from the flowgraph, it will be responsible for both parsing the data, and putting the parsed data + raw telemetry in the store. Whenever it sees a new command in the store, it needs to put the command's parts together and validate it with a lookup table of regex expressions for valid commands (e..g TJ:C;APRS;SFR_time;122121; would be validated with all the regex expressions until it matches one like this one TJ:C;APRS;SFR_time;\d+;). If the command string turns out to be valid, then it will be put in another section of the store AND sent through the flowgraph. The backend will have to incorporate code to interface with firebase, the flowgraph, Iridium, and the APRS crowd sourced API.
Tasking
Between the people currently on ground station and the new members added to the ground station, you need to figure out who is responsible for which of the three components and work with me (Shreepa) and Anup (@abagali1) to make sure its done correctly. Anup has started working on the backend at rewrite-1 and we have designed the preliminary structure for the store. However, the people working on frontend need to figure out which frontend framework they want to pursue and learn how to use it.
The text was updated successfully, but these errors were encountered:
AkashBhave
changed the title
Ground Station Rewrite
Complete groundstation rewrite
Feb 20, 2020
Description
The ground station right now is not where it needs to be, so similar to pFS we will be pursuing a rewrite.
Overall Ground Station Goals
Telemetry
Commands
System
In order to achieve all the goals, there will be three components to the ground station: a frontend, a backend, and a store.
Store
The store is how the frontend and backend communicate to each other. They both "monitor" the store, and when something changes they will get a notification. The store we will be using is Google's Real Time Firebase Storage. Using their SDKs/libraries it should be very easy to monitor/listen for changes in the database. If the backend puts telemetry in the database, the frontend should update in real time to show the new data. If the frontend puts a new command in the database, the backend should validate and send it in realtime.
Frontend
The frontend should be written with some frontend framework (e.g VueJS, ReactJS) with a boilerplate (e.g. https://demos.creative-tim.com/vue-black-dashboard-pro/#/dashboard). Eventually, this frontend will be publicly available at https://activities.tjhsst.edu/cubesat/groundstation. The frontend should actually look good and use graphs, tables, charts to convey the telemetry so its easy to comprehend and visualize. It should also give the ability to authenticate users. If the user is authenticated, they should have access to send commands. Both updating from and putting in the database should be done through JavaScript on the frontend with no GET/POST requests.
Backend
The backend will be written in Python 3.8. It will use the
firebase-admin
python package along with the built-insocket
package to communicate with the store and the flowgraph. This backend will a pure python app and will not need to implement any web stuff (unlike the Flask backend before). Whenever it receives anything from the flowgraph, it will be responsible for both parsing the data, and putting the parsed data + raw telemetry in the store. Whenever it sees a new command in the store, it needs to put the command's parts together and validate it with a lookup table of regex expressions for valid commands (e..gTJ:C;APRS;SFR_time;122121;
would be validated with all the regex expressions until it matches one like this oneTJ:C;APRS;SFR_time;\d+;
). If the command string turns out to be valid, then it will be put in another section of the store AND sent through the flowgraph. The backend will have to incorporate code to interface with firebase, the flowgraph, Iridium, and the APRS crowd sourced API.Tasking
Between the people currently on ground station and the new members added to the ground station, you need to figure out who is responsible for which of the three components and work with me (Shreepa) and Anup (@abagali1) to make sure its done correctly. Anup has started working on the backend at
rewrite-1
and we have designed the preliminary structure for the store. However, the people working on frontend need to figure out which frontend framework they want to pursue and learn how to use it.The text was updated successfully, but these errors were encountered: