Feasibility to use whole Fprime (FSW and GDS) in real satellite operation

[kitty99099]

What I want to do?

Hi! I'm a satellite enthusiast. I started to learn Fprime since I want to group a college team to build a real CubeSat to be launched to LEO. Below is my preliminary blueprint.

What I can do now?

I learned Fprime for almost half year. Now I think I have a certain kowledge of Fprime' basic running. Below is what I can do now. I used a RPI as the OBC and make sure the PC and the RPI to be connected to the same Wifi. Therefore I can use GDS interface supplied by Fprime to send command to and read data from the ADCS. I think I already have the ability to integrate more subsystems that a satellite needs, like EPS, TT&C, and Payload, as long as I have their user manual.

What I have surveyed?

I haven't seen any CubeSat mission case keeping whole Fprime. In my observation, they might cut the fprime-gds which can be referred to Ground Interface Architecture and Customization and connect to other ground station software like OpenMCT or Cosmos. However, I think that it would be too many works to do, so it may not be our first priority.

What's my further blueprint now?

I referred to Hub Pattern and then designed the architecture below. I would like to build two deployments in which the CubeSat will be Node A and the ground station PC will be Node B, but I'm not sure its feasibility particularly I don't know if I can use RF as the transportation between two hubs. I would like to inquire your thoughts and advices. I will appreciate your any comments.

I saw a discussion whice seems trying to solve the problem similar to mine, but there seems to be a little difference. Any comment or idea is appreciated!

I'm still learning OSI layer but not familiar with... Should it be known before the development?

What I have known now? (Any advice or comment is appreciated)

1. I need to implement Communication Adapter Interface to transmit framed data to and received framed data from my radio component.

[zimri-leisher]

RF is just a way to transmit arbitrary data, so yes, you could use two deployments and have the communicate via RF.
However, I do not see the need for a second deployment on the ground. The fprime-gds tool should be able to directly work with the output of the TlmPacketizer or TlmChan components, without any components in between. So usually, people send the output of the TlmPacketizer/TlmChan in the form of bytes straight to the radio -> antenna -> RF -> dish -> modem, which outputs bytes again, which are sent to fprime-gds.

[Joshua-Anderson]

I haven't seen any CubeSat mission case keeping whole Fprime. In my observation, they might cut the fprime-gds which can be referred to Ground Interface Architecture and Customization and connect to other ground station software like OpenMCT or Cosmos. However, I think that it would be too many works to do, so it may not be our first priority.

fprime-gds is designed with a lab environment in mind (i.e. talking to your cubesat in a lab or maybe some prototype hardware) so that you can hit the ground running and test your fprime application before you have a full ground software environment setup. It's missing very useful functionality like logging downlinked telemetry to a database and advanced telemetry plotting.

Generally projects swap out fprime-gds and integrate their chosen ground system like COSMOS. I'm not sure any project has used the fprime GDS for actual operations, but it's not uncommon to use some of the fprime-gds libraries as part of the integrate code needed to help handle the parsing and encoding of data heading to and from the spacecraft.

[ReggieMarr]

Looks like a great outline, I've actually been working on a project which has some overlap here so I can add some comments.
First off I can join the chorus and say yes absolutely you can use RF here. As you mentioned here you can just implement your drivers as something compatible with the communication adapter interface and you should be able to easily swap out a TCP/UDP comms driver for your RF driver.

I would also say having a firm grasp of the OSI model is going to be very important here. That being said keep in mind the "all models are wrong, some are useful" quote here. That is, it's a model that provides abstractions so you can get your head around the idealized separation of concerns but most (RE: all) protocol implementations will not necessarily map neatly onto the models layers.

WRT fprime-gds I will also chime in and say it's fantastic for prototype development and can get you going with minimal effort. That being said there are better, more robust options to use (such as the as of yet unmentioned yamcs).

As far as your topology goes I actually think the hub model is a good play here. I'm currently building off some existing work and developing data link support for CCSDS and one of my near term goals is to use that approach as part of the proof of concept/prototype tracked here so keep an eye out for when I make an MR.