F' and establishing a connection between ground and satellite on orbit.

[rawinza555]

This might be a stupid question and might not be 100% related to F'. Let's say I want to launch a generic cubesat with flight software developed on F' framework to LEO.
1.) Should the flight software start running before the launch or once it separate from the launch vehicle or any moment in between?
2.) was I correct to assume that once I have the ground station set up, I should know the ip address of that satellite on orbit and the machine running GDS itself? (Probably by assigning a static ip beforehand). If so, all I need to do is setting up the autostart sequence at specific time or trigger for the flight software code with a pre-set ip address and port right?

[Joshua-Anderson]

Should the flight software start running before the launch or once it separate from the launch vehicle or any moment in between?

Per the cubesat spec no power is allowed to flow on the satellite before deployment from the launch vehicle. Most cubesats have deployment switches on the rails that cause the flight computer to boot on seperation from the deployer.

There also may be launch vehicle requirements that prevent radio transmissions until some time after deployment.

was I correct to assume that once I have the ground station set up, I should know the ip address of that satellite on orbit and the machine running GDS itself?

For a cubesat you usually replace the TCP/IP communication driver with a radio driver and route all ground interface traffic out over the radio. The F' GDS is mostly intended for development and testing and not so much for actual operations. The assumption is that users select and integrate a full scale GDS solution for actual operations. However, the F' GDS could be used potentially be used if you wrote an plugin to interface with your ground station.

[Joshua-Anderson]

People have integrated both into F' in the past.... you can see some rough out-of-date prototypes in github.com/fprime-community

[rawinza555]

If one's were to replace TCP/IP with RF, where would be a good place to start. I guess the other word is do you have any guide or advice on how to do this? I'm thinking about using 915 Mhz radio that usually used with UAVs for a prototype (look something like this). My guess is rerouting everything to a UART driver that interact with a radio transceiver but I'm not 100% sure which file I have to edit to make this work.

EDIT: My prototype is running on Raspberry Pi 3B+ as a prototype on board computer and a laptop running ubuntu as a ground station. My colleague is working on getting OpenMCT to work with F', especially on sending commands.

[Joshua-Anderson]

This downlink chain looks something like this:

(from the framer docs here)

The framer takes in the F' data structure to be sent and converts it into a packet by adding the relevant header, footer, and other sorts of transformations. The raw bytes of the packetized data are then sent to a communication component. For the Ref app, this comm component is a TCP driver, but this can be easily swapped for a custom driver that takes in a series of bytes and sends them.

Uplink looks similar but in the opposite direction. A communication driver produces a series of bytes, which the deframer component deframes into individual F' packets.

To replace the default IP drivers for communication, you'll need to write a driver for whatever radio you wish to use that implements that standard interface. F' ships with a default framing/deframing protocol (the converter between F' data structures and raw packets and back), but you may also want to consider developing your own framing protocol for the radio if you want to optimize or tweak the format of the packets.

Starting by developing a uart driver that can interact with the transceiver is a great starting place, and then you can slowly integrate the radio driver into the rest of the downlink chain.

[rawinza555]

Thanks.
This is probably going to be my last question on this topic but once I'm done with this from flight software side, how do I get around and modify the current F' GDS to be able to receive tlm/events and send commands via the RF transceiver as well? I imagined that the comm components on the flight software side doesn't just create series of bytes out of the thin air, but rather receiving them from the GDS GUI.

This turned out to be more fun than I would have thought. I'm definitely going to write some guides on this process, similar to the one I did with I2C Tutorial.

[Joshua-Anderson]

The GDS side isn't as well documented, but it supports plugins for replacing the communication medium as well. There's already a UART driver which may work for your needs. If you use the stock F' framing all you need to do is replace the communication plugin and you'll be good to go.