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

[kitty99099]

What do 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 can I 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 have I 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.

Below is the hub pattern architecture.

I saw a discussion which 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 have I 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.

[kitty99099]

Thank you @zimri-leisher for your insights. You gave me an easier architecture. I will figure it out how to develope without a second deployment on the ground. But do you know how to specifically modify the fprime native components to make it come true? I'll be grateful for your further advice.

[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.

[kitty99099]

Thank you @Joshua-Anderson for your advice. I used to figure nothing out why fprime-gds is only suitable for lab test not until you gave some example about what useful functionality it may be missing. I'll reconsider about using other ground systems. Thank you!

[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.

[kitty99099]

Thank you @ReggieMarr for your comments. I will try yamcs. Do you know how to swap TCP/UDP comms driver for my RF driver? Is this the TCP/UDP comms driver? Should the RF driver be developed by myself? Thank you for your guidance. I'm not familiar with these, but I have strong energy to learn.

[ReggieMarr]

Take a look at the Ref instances.fpp and topology.fpp, if you need a visualization I've linked the view that can be generated using fprime-util visualize in fprime/Ref/Top.

Note that the comm instance is the end of the chain both for sending and receiving and the Ref is using a TCPClient instance (which would also be a fine starting point).

Uplink:

Downlink:

You then need to create a driver/component which conforms to that interface; AKA provides implementations of those ports which are defined in the TCPClients fpp file (see this reference to the ByteStreamDriverModel for more details).

Note that conformance to the interface just means that you have to have at least those ports/associated functions implemented.
You can always build more on top of it should your RF driver require it and the use of the include directive is useful here for that reason.

As an example you could take a look at the loopback component I created which implements both the receiving and transmitting end of a mock comms driver which makes things easy for testing purposes. This can be seen in its visualization:

Keep in mind that example is something I hacked together for a non-production proof of concept and has a number of known issues so don't take it as an example of a "good component" just an example of something which conforms to the interface.

As a next step I'd suggest you could create something similar, and then try and break things out with the hub model so you have 2 deployments talking to one another.
Also to clarify my previous comment; The reason I suggested using the UDP interface for this is a) it's different than the usual TCPClient so will force you to think about what you're doing a bit more deeply and b) UDP is a connectionless interface which will be one step closer towards the nature of your RF link.

Hope that helps, and let me know if you get something working !