Linux TmTcUnixUdpBridge #125

New Issue

muellerr · 2020-07-06T13:16:40+02:00

muellerr commented

2020-07-06 13:16:40 +02:00

To enable testing of device handlers or other software components without hardware, I am implementing a TMTC bridge which creates a socket on localhost to send TMTCs with some other software (or possible internally with another FSFW component).

THe first version will use UDP datagrams.

The Tc reception will be handled in a separate software task as it will propably be a blocking call to poll telecommands.

To enable testing of device handlers or other software components without hardware, I am implementing a TMTC bridge which creates a socket on localhost to send TMTCs with some other software (or possible internally with another FSFW component). THe first version will use UDP datagrams. The Tc reception will be handled in a separate software task as it will propably be a blocking call to poll telecommands.

muellerr added the

feature

label 2020-07-06 13:16:40 +02:00

muellerr changed title from ~~WIP: Linux TmTcUnixUdpBridge~~ to Linux TmTcUnixUdpBridge

2020-07-08 18:57:00 +02:00

muellerr commented

2020-07-08 18:58:50 +02:00

UPDATE: The TMTC bridge is working. There were some issues with the IP address in the reception socket being different from the one in Python, but the current version is working with the TMTC script used by SOURCE.

Any TMTC software can be used, the telecommands are simply sent as udp datagrams to localhost on the port 7301.

The telemetry can be received from any address on port 7302.

I will create a pull request soon.
Those will also include some small changes to the generic TMTC bridge:
A default implementation of handleTc is provided and receiveTc was deleted.
In most cases I have seen so far, the TC reception is handled in a different (polling) task anyway. This was also the case for the UDP reception: There is a TcUnixPollingTask and the TmTcUnixUdpBridge which handles TM sending. The TMTC Bridge will simply forward the messages to the TMTC distributor objects directly, so I implemented that.

UPDATE: The TMTC bridge is working. There were some issues with the IP address in the reception socket being different from the one in Python, but the current version is working with the TMTC script used by SOURCE. Any TMTC software can be used, the telecommands are simply sent as udp datagrams to localhost on the port 7301. The telemetry can be received from any address on port 7302. I will create a pull request soon. Those will also include some small changes to the generic TMTC bridge: A default implementation of handleTc is provided and receiveTc was deleted. In most cases I have seen so far, the TC reception is handled in a different (polling) task anyway. This was also the case for the UDP reception: There is a TcUnixPollingTask and the TmTcUnixUdpBridge which handles TM sending. The TMTC Bridge will simply forward the messages to the TMTC distributor objects directly, so I implemented that.

muellerr referenced a pull request that will close this issue

2020-07-13 13:34:56 +02:00

new tmtc unix udp bridge #141

taheran closed this issue

2020-09-08 14:14:00 +02:00

Sign in to join this conversation.