OpenC3 Compatibility Issue

[vedantt21]

Description

Hi all,

I’m currently encountering an issue related to compatibility between OpenC3 and NOS3, and I was hoping to get some clarification.

I am developing a new NOS3 component called TCS (Thermal Control System) using NOS3 v1.7.3. I followed the documentation (https://nos3.readthedocs.io/en/latest/NOS3_Generating_Component.html) to generate the component and integrate it into the simulator. Initially, I used COSMOS to verify functionality, and everything behaved as expected. I was able to send commands and observe the corresponding telemetry updates, confirming that the component itself was operating correctly.

After this, I modified the tag in nos3_simulator.xml to switch from COSMOS to OpenC3, with the goal of operating the simulator through OpenC3 v5.

At this stage, I am able to successfully send commands to the TCS component through OpenC3, which suggests that the command interface is configured correctly. However, I am unable to view telemetry from the TCS component in the OpenC3 Packet Viewer. The images below showcase that the NOOP command is going through, hence increasing the CMD_COUNT however, it is not evident in the Packet Viewer.

Interestingly, telemetry from the Sample component is visible and updates correctly in the Packet Viewer. Since the TCS component was generated following the same process and structure as the Sample component, I would expect telemetry behavior to be identical. The discrepancy suggests that I may be missing a configuration step specific to OpenC3.

My question is:
Are there any additional configuration steps required to make newly created NOS3 components fully operational with OpenC3 (particularly for telemetry visibility) that may not yet be reflected in the current NOS3 documentation?

Any guidance would be greatly appreciated

Steps to recreate:

• Followed the steps given at https://nos3.readthedocs.io/en/latest/NOS3_Generating_Component.html exactly as provided.

OS

Linux (Direct Clone)

[msuder]

Note that you need to issue a TCS_REQ_HK command in order to request TCS housekeeping data which will then be displayed in the TCS_HK_TLM packet viewer window.

Sample HK telemetry is automatically being sent because the scheduler app (SCH) is configured to send it periodically (see cfg/nos3_defs/tables/sch_def_schtbl.c and cfg/nos3_defs/tables/sch_def_msgtbl.c).

Also note that receiving TCS_DATA_TLM requires the TCS device to be enabled (command TCS_ENABLE_CC) and then requested (command TCS_REQ_DATA).

[zlynch2]

Also, note, the most recent version of NOS3 includes an update to openC3 (version 6.4.0) and docker (version 28.5.2 ). It looks like your openC3 is running so you may be good to go there, but wanted to share the information if you are also interested in running the latest.

[vedantt21]

So the reason I was confused initially was when I ran this on COSMOS, it didn't require me to submit TCS_REQ_HK, and showed the data regardless. Despite that, I attempted the fix you suggested and it began working for TCS_DATA_TLM, however, the TCS_HK_TLM is still non-operative.

The images below showcase how I am able to send the enable command, however, that seems to only enable the data telemetry not housekeeping. TCS_REQ_HK command, didn't produce any reliable data that was visible in the packet viewer.

Any advice would be appreciated!

On a side note: I have to rebuild the NOS3 application sometimes because the 42 container stops working with a writing to socket error, not sure if this is expected?

[zlynch2]

I would double check in cosmos 4.5.

it looks like maybe your data tlm is correct or at least a duplicate of the sample component. Make sure you msgid is unique to your component. A quick check could to enable the sample component and see if you pick up tlm data in your TCS_HK above. if data starts coming in that just means your waiting for sample_HK not TCS_HK.

The msid for sample_hk is 0x08FA. But if yours is different make sure its unique to the TCS component.

In Cosmos 4.5, youll notice sample HK doesn't actually update until its enabled. This is due to adding the HK to the scheduler table in cFS.

Regarding 42, sometimes order matters when launching the containers. I would make sure when 42 is connecting to your sim over its TCP port that the sim has enough time to come up before 42 tries to connect to it. Usually resolved by adding the 42 TCP port code block to the end of the inp_IPC.txt file and launching your new component from the cfs_launch script last after the others.

[vedantt21]

Thank you so much, I believe there might have been an error in the message ID definitions as you suggested that helped immensely! Really grateful for all your support.

Just wondering however, sometimes when I am coding the repository locally, and I haven't connected 42 to my TCS component. 42 works initially, when I clone the repo new, however a day or two later, it ends up causing an issue. The issue is that the container crashes, returning an issue with error writing to socket in WriteToSocket.

This has been a consistent issue I have faced, and my current solve is to delete the repository entirely from my laptop, and restart it. Then, after cloning it from my personal git again, the issue becomes resolved. Would really appreciate your insight into this, and more than happy to provide any other information that could help you!!

Once again, thank you so much, your help has been pivotal in this!!

[zlynch2]

That's certainly interesting behavior, if 42 is crashing im wondering if you are using a different version of 42 than what currently is needed for the recent NOS3. I would personally double check the syntax used in the 42 config files and compare to what is being used on dev/main of the nos3 project. I say this based on the fact that you pulled in recent nos3 later.

I believe we updated 42 for version 1.7.3. In any case, if its crashing I would make sure its able to connect appropriately to each sim as this is sometimes the easy debug step. If not, try running make uninstall, make prep, make, make launch, with the recent clone of nos3. this will ensure you have the most recent containers.

Hope this helps!