Implement SLE Forward CLTU service

[tnogueira]

The implementation currently supports the RAF service. It would be great if we could also use this implementation for command uplink.

I would suggest to extend the current stack to implement the SLE Forward CLTU (FCLTU) service.

[milenko-s]

The following steps are required to implement the FCLTU Service:

• Testing of the existing ASN.1 mappings for CLTU PDUs from AIT-DSN and LibreCube
• Implementation of the FCLTU Service, similar to the RAF Service
• Extension of the data protocol and writing a client for testing purposes
• New RESTful management routes need to be implemented, manually for the provider and with the OpenAPI specifications for the user
• Testing with different reference user implementations
• Writing documentation and tutorials how to use the service
• Integration with hardware

We will review these steps in more detail and try to implement them as soon as possible.

[milenko-s]

Began to implement in #6 with first working example.

• BIND, START, STOP, TRANSFER DATA, PEER ABORT already implemented
• Provided UDP loop back client for sending CLTUs and receiving them again via a RAF client
• Example in QuickStartGuide was updated

[AdamElliott-AB]

Thanks for your work adding CLTU service support. Are there plans to add support for CLTU service status reports? I get the following error in sle-provider when trying to establish a CLTU connection from my SLE client:

ERROR:sleprovider.service.commonProtocol:PDU of type CltuScheduleStatusReportInvocation has no associated handlers. Unable to process further and skipping ...

[milenko-s]

There are plans, up to now there was just no need for our use case. What client are you using? Does it automatically schedules a status report once connecting to a service provider?

Since you need it, I will put it on my schedule and might even start working on it this week.

[AdamElliott-AB]

I am using https://github.com/yamcs/yamcs-sle
It does automatically schedule a status report when connecting to a CTLU service. Thank you for adding this feature to your schedule.

[milenko-s]

As requested I implemented:

• CLTU schedule status report invocation handler
• CLTU send status report

Please be aware that there is currently no check if the CLTUs are actually radiated since there is no actual baseband equipment connected.

Still missing:

• CLTU async notify
• CLTU get parameter
• CLTU throw event

@AdamElliott-AB please try the latest version to see if the implementation now suits your needs or if something else is missing to connect YAMCS-SLE.

[AdamElliott-AB]

Fantastic. Thanks for the incredible response time. I am now able to connect to CLTU successfully.
I did run into an issue when sending data:

File "/usr/local/sle-provider/sleprovider/service/cltuProtocol.py", line 180, in _transfer_data_invocation_handler
self.factory.container.data_endpoints[0].send_command('send-telecommand', [bytes(pdu['cltuData']).decode()])
builtins.UnicodeDecodeError: 'utf-8' codec can't decode byte 0xab in position 1: invalid start byte

sle-provider/sleprovider/service/cltuProtocol.py

Line 180 in 8953495

self.factory.container.data_endpoints[0].send_command('send-telecommand', [bytes(pdu['cltuData']).decode()])

[milenko-s]

Thank you for your feedback and good to hear that the connection works now.

I was able to reproduce your error and will fix it soon. It is caused by an encoding problem and was not discovered before because I used test data for CLTU starting with 0x01 counting upwards but not until 0xab.

[milenko-s]

#11 should solve your problem. Tested it with the loop-back client and a RAF client connected and was able to receive the CLTU containing '0xab'. I also updated the QuickStartGuide to cover that case.

[AdamElliott-AB]

It is working well now. Thank you.