###### tags: `FS` `Master` `PUSopen` `meeting` # PUSopen kick-off workshop :::info - **Date:** Nov. 12, 2020 01:00-03:30 PM (CET) - **Participants:** - Slavomir Petrik (SP) - Lead engineer 12G fs - Karl Khalil (KK) - Joaquim Silveira (JS) - Charles-Lewis Jaggi (CJ) - Jonathan Michel (JM) - **Host:** Zoom ::: ### PUSopen integration SP presents global view of how to use PUSopen with cFS. During our first call, we said that we were targeting cFS or F' and he only took a look at the first one. Hopefully the general concepts are the same. He suggests to develop two components: COMMS and TO/CI. The first one is responsible to encode/decode PUS frames and the second one processes PUS services and call custom handlers that the user has to specify. The only information PUSopen need is a timestamp from the system. There is different time sources in a S/C : - Mission time - Timestamp for packets communication - Relative time for task scheduling The is a time component in F', we'll see how it works. FESS is a synchronisation layer used in PUSopen, it defines the begining and the end of user data between packets. It has been hunderds times tested and could be used for our integration. Encryption is supported in this one if need. SP noticed that there is no active behaviour in the library (while loop, ...). It is our responsability to handle this. For payloads that will use CSP, we can make our own transalation layer or make it in the function handler. SP notices that the GS from cFS is in Pyhton and can be customized to support PUS. It allows to see the packets sent/received. We'll have to develop a simulated GS supporting PUS. The GDS from F' is also a solution. It has no protocol support for now but the sources are available. PUSopen is delivered with a configuration tool. It's a command line tool that generates .c files from a xml configuration file (~200 lines). It contains a list of definition for the used services, the critical events, the telemetry need, the messages that can be sent, ... This file has to be shared with the GS, we'll see with Elveti what kind of file they support. ### Uplink example 1. Receive 200 bytes from the radio 2. Goes to PUSopen stack to be unwrapped 3. Extract the telemetry and the telecommande 4. Respond diretly if it is a ping 5. If is a custom command, go to software bus ### Command pulse driver unit PS highly recommends to add a reset line allowing to reset the all satellite. One solution that exists is sending a wave from the GS (instead of binary data) that is detected by the COM system and reset all modules. There is probably solutions available on the market. ### PUS services SP never used Elveti but took a look on their website. We decided to consider that Eleveti will support the services implemented in PUSopen. We went through the PUS services list and PS gave us his opinion about each of them. His remarks are on the [Google Sheets document](https://docs.google.com/spreadsheets/d/1-p3NTMudU0DRecnIM4ZSyhEMGLmXXcOAm1-z367hkQs/edit#gid=0). **PS advices to keep thinks simple and avoid using to many services for nothing** #### cFS / F' PS found that cFS sounds more suitable for deep space mission than lower orbit mission. It is powerfull but complicated. In this specific case, they have ground stations all over the world and can send data and commands continuously. Our mission will have small communication windows and the functionalities need during these ones are simple. F' being smaller and simpler it is a better choice for our low orbit basic mission. He found the logic we set up for now correct for the kind of mission we have. If need, this is extensible for bigger mission in the future. ### Distribution Standard documentation with compiled library. The documentation contains: - How to configure PUSopen - Developper guide - Description of the supported PUS services and the layers implemented (with pictures) - Code example - Release notes ### PUSopen engagement model The library and the documentation are free for academic usage. We are in charge of the support we need from them : 50-70€/h depending on work kind. 10 hours packages are sold. To be able to go further, PS suggests to sign a NDA. It will protect us from any kind of leaks: for us, mission details and for him, PUSopen future development information. PS asks if we have tests/requirements/documentation standards. He suggests to do a workshop to explain ECSS processes and QA. I will allow to meet ESA requirements and find correct balance between documentation/processes and efficient development. ### Work packages We listed some work packages that we could do together. SP will send us an email with an estimation of the amount of work they require (and their cost). Then we can decide if we need them or not - PUSopen integration into F' - Virtual channel explanation - Workshop ECSS processes and QA - Service 13 uplink implementation - Service 19 implementation - PUSopen compilation for RISC-V - Project management ### Next steps - 12 Gfs will send us a NDA template that we'll have to transfer to CHESS and send back to 12GFS signed to have access to the lib + doc - Work packages have been listed, estimation of requirements for each of them will be made - On our side we'll do more tests with F' to understand each component.