Modification of ci_custom.c not taken into account

[girardja]

Hy, I am trying to make modification in ci_custom.c in order to implement Inter Satellite Links.
Hereafter is one of my modifications: (starting at //STARTISL)

void CI_CustomMain(void)
{
int32 size = 0;
CFE_MSG_Message_t * sbMsg;
CFE_SB_MsgId_t msgId;

if (g_CI_CustomData.udp.sockId < 0)
{
    CFE_EVS_SendEvent(CI_CUSTOM_ERR_EID, CFE_EVS_EventType_ERROR, 
                      "CI: Socket ID not set. Check init. "
                      "Quitting CI_CustomMain.");
    return ;
}

sbMsg = (CFE_MSG_Message_t *) &g_CI_CustomData.buffer[0];

while(size >= 0)
{
    size = IO_TransUdpRcvTimeout(&g_CI_CustomData.udp,
                                 &g_CI_CustomData.buffer[0], 
                                 CI_CUSTOM_BUFFER_SIZE,
                                 IO_TRANS_PEND_FOREVER);

    if (size > 0)
    {
	  // STARTISL
	  uint16 destSpacecraftId;
	  CFE_MSG_GetSystem (sbMsg,&destSpacecraftId);
	  CFE_EVS_SendEvent(CI_CMD_INF_EID, CFE_EVS_EventType_INFORMATION,
				  "IRRTCSS Command received for spacecraft %d\n", destSpacecraftId);
	  if (destSpacecraftId != (CFE_MSG_System_t)CFE_PSP_GetSpacecraftId()) {
		  CI_ForwardToISL (sbMsg,destSpacecraftId);
		  return;
	  }
	  // ENDISL

It seems that I never enter in this piece of code.
I expected to see some events in the fsw terminal when I send a command to the spacecraft. It is not the case.
I have also tried printf, file creation ... none has worked as expected.
I know my code is compiled because if I introduce an error it does'nt :-)
I have seen in the fsw terminal that CI_LAB_APP is correctly initialized (not CI)

Any idea ?

[girardja]

In addition I would like to share the implementation of Inter Satellites Links that I foresee. I am interested in all remarks or alternatives.
feeders et ISLs et 8 spacecrafts v2.pptx

[jlucas9]

Hi @girardja,

Looking at the provided power point implementation overview it seems similar to Delay or Disruption Tolerant Networking (DTN) where you're using the spacecraft ID (SCID) to determine how to route the packet to the final destination and leveraging the existing spacecraft frames TC/TM instead of bundle protocol. I haven't worked on DTN in quite a while, but know that a number of folks are looking at High-Rate Delay Tolerant Network (HDTN) these days which may be interesting to you. I'd be interested in integrating this into NOS3 and I think still have an issue related to it that we haven't had time to work #178.

Backing up - can you confirm you're editing the correct custom files? Looking in the latest dev branch of NOS3 the ./nos3/cfg/nos3_defs/toolchain_amd64-linux-gnu.cmake actually configures the desired transport to be used. Currently for CI we use udp_tf and for TO we use udp;

• ./nos3/fsw/apps/ci/fsw/examples/udp_tf/ci_custom.c
• ./nos3/fsw/apps/to/fsw/examples/udp/to_custom.c

Additionally some generic radio functionality exists to send data to what we called "proximity" as a proof of concept for multiple spacecraft:

• Multiple Spacecraft Demonstration - Phase A #96 (comment)

Sorry for the wall of text. Please feel free to follow up here and I'll answer any additional questions you may have!

[girardja]

Thank you very much Lucas for your answers.
Reading these pieces of information I realise that there shall be a dedicated ISL component, physically connected to optical or RF hardware.
For that reason I have modified the ISL implementation proposal in the new joint power point.
feeders et ISLs et 8 spacecrafts v3.pptx

Concerning ci_custom.c that I use, I will check on my server. I taught I used UDP version because if I introduced malformed code in it nos3 didn't compile anymore.

[girardja]

I checked and in the config file toolchain-i386-linux-gnu.cmake I have the lines
set(CI_TRANSPORT udp)
set(TO_TRANSPORT udp)

I would like to be sure, where the output of
CFE_EVS_SendEvent(CI_CMD_INF_EID, CFE_EVS_EventType_INFORMATION,
"IRRTCSS Command received for spacecraft %d\n", destSpacecraftId);
shall appear ?
In which terminal ?

[girardja]

Actually I have no ci_custom.c in nos3/fsw/apps/ci/fsw/src directory
Should I have one ?
I looked at setup.sh in nos3/fsw/apps/ci/fsw/examples directory.
I tried to copy

ci_custom.c (udp version) in nos3/fsw/apps/ci/fsw/src
MISSION_ci_types.h (udp version) in nos3/fsw/apps/inc (a new directory that I had to create)
ci_platform_cfg.h (udp version) in nos3/fsw/apps/ci/fsw/platform_inc
Then make real-clean
and make
This leads to "Multiple Definition" errors for all functions declared in ci_custom.C
I really would like to know how to solve this problem. Maybe my code is correctly executed but I am not able to see it (see my previous post)
I recall that initially I tried to put some printf or file creation (in /tmp) in my piece of code in order to get some proof of execution but I didn't see anything.
Jacques

[girardja]

I tried to add the following lines at the begining of CI_AppMain:

#include <stdio.h>
{
FILE *f = fopen ("/tmp/hello.txt","w");
fprintf (f, "%s\n", "Hello World !");
fclose (f);
}

After compiling, and launching nos3, commanding some equipment, I have no hello.txt file in /tmp
So it is no more linked to ci_custom.c but to whole CI app.
There is definitely something that I miss.
Jacques

[jlucas9]

Hi @girardja, do you have a fork of NOS3 with these changes that is public I could take a look at directly? Additionally which version of NOS3 are you using? I'd recommend upgrading to the last release 1.7.0 if you haven't already.

[girardja]

Dear John, I finally found what was wrong with my code:
I wanted to retrieve the SystemId field from the extension of the primary header of CCSDS message.

I initially invoked CFE_MSG_GetSystemId which did not compile and suggested CFE_MSG_GetSystem instead.
Thus I invoked the function CFE_MSG_GetSystem (sbMsg,&destSpacecraftId);
It compiled but unfortunately, this function is not available at run time.
There was an error in fsw terminal that I didn't notice.

Anyway, I just commented this call and now I see my text file created. :-)

Lessons learnt:
Be careful: A code that compiles correctly may have issue at run time. Look carrefully at messages !
The header file default_cfe_msg_hdr_priext.h is malformed (lack of one bracket at line 70) .

Way forward:
select the option to have the extended primary header for CCSDS messages.
start implementing ISL

Thank you very much John for your support.

Did you look at the ISL implementation that I plan to do based on an application similar to Radio named ISL in my slides ?

Jacques

[jlucas9]

@girardja good catch! The implementation appears solid, I would just be sure you capture the assumptions as you go along. For example with DTN they store and then forward the data when the link is available, but it seems ISL requires a constant link between parties and a known routing between the connections.

Excited to see this develop! Please feel free to reopen this or create new issues as you run into problems!