jlucas9
commented
1 month ago Hi @Simon9050, Apologies for the delay getting back to you. Let me try to answer these questions for you:
- RADIO : My understanding of RADIO interface is that "_radio" targets (for command or telemetry) flows through the radio component.
- That's correct. The Radio interface in COSMOS is actually connected to CryptoLib running in standalone mode (ground setup) which then talks to the radio simulator before going to/from FSW
- However, the cosmos counters (telemetry) stay at zero in my simulation for RADIO interface... Is it a normal behavior?
- That's correct, the radio interface initializes in the off state by default and can be enabled through the cmd("CFS_RADIO TO_ENABLE_OUTPUT with DEST_IP 'radio_sim', DEST_PORT 5011")
- Why are there 2 separate interfaces with the same targets (RADIO/DEBUG)? Would it be possible to have a single interface?
- The debug interface is setup as if you were somehow plugged directly into the spacecraft while the radio interface follows the more traditional route. It is certainly possible to remove one or the other depending on your needs. I've found the debug interface helpful during spacecraft integration and test as you typically don't want to always have the radio transmitting due to either RF power concerns or overheating.
- What is the scope of all the ports associated to RADIO?
- Uplink from COSMOS > 6010 CryptoLib Standalone > 8010 Radio Sim > 5010 FSW CI App
- Downlink FSW TO App > 5011 Radio Sim > 8011 CryptoLib Standalone > 6011 COSMOS
- Could you confirm (or not) that SIM_42_TRUTH interface is there only to plot on cosmos some parameters coming from 42?
- I can confirm that this interface is to allow confirmation that the "truth" value of the spacecraft in 42 can be compared to what is reported by FSW
- it is not fully clear to me what is the format of the packets that are exchanged... I suppose it is only SPP (of the CCSDS stack) as COSMOS seems to manage only this type of packets, however I saw some functions in the code working with Transfer Frames...
- COSMOS presently only does SPP by default. The debug interface sends on receives SPP packets. The radio interface sends SPP to CryptoLib which frames in TC to go off to the Radio Sim and then the CI app of FSW which then breaks it down into SPP which go on the software bus to it's final destination. The same works for radio downlink where the TO app generates TM frames it sends to the radio which forwards to CryptoLib where it breaks it back into SPP for COSMOS.
- Is the Transfer Frame layer also available for TC/TM ? (If yes, how it can be activated ?)
- It's enabled, but only for the radio interface presently. CryptoLib is also only really able to do authenticated encryption on the command link presently in NOS3.
- a question to rule them all... could you suggest some steps to create one single working interface (and maybe adding the TF layer) ?
- I'd simply repurpose the radio interface to suit your needs, disable debug if you'd like, and also add TO enable to the RTS1 if you'd like it to just be on by default.
I hope I answered your questions! Please follow up if you have others or if anything I captured here doesn't make sense or I just seem to be wrong in the setup.
Have a great day!
Hi,
I have some trouble understanding how interfaces are wired between fsw and cosmos and I would like to ask you a few questions :
RADIO : My understanding of RADIO interface is that "_radio" targets (for command or telemetry) flows through the radio component. However, the cosmos counters (telemetry) stay at zero in my simulation for RADIO interface... Is it a normal behaviour ? Why are there 2 separate interfaces with the same targets (RADIO/DEBUG) ? Would it be possible to have a single interface ? What is the scope of all the ports associated to RADIO ?
Could you confirm (or not) that SIM_42_TRUTH interface is there only to plot on cosmos some parameters coming from 42 ?
it is not fully clear to me what is the format of the packets that are exchanged... I suppose it is only SPP (of the CCSDS stack) as COSMOS seems to manage only this type of packets, however I saw some functions in the code working with Transfer Frames... Is the Transfer Frame layer also available for TC/TM ? (If yes, how it can be activated ?)
a question to rule them all... could you suggest some steps to create one single working interface (and maybe adding the TF layer) ?
Thank you for your help Kind Regards,
Simon