Need some guidance on the right protocol I should be using for an instrument where it's telemetry response is purely command driven.

[rogueWookie]

Target Background

Hi ~ I have a target that I'm communicating with over serial. This target accepts commands which may be a single byte or several bytes but there's no header, sync, crc or delineation of any kind. If the target can correlate the byte stream to a command it executes it, if not, it throws it away.

Furthermore, the target is designed where it only sends telemetry upon receiving a command. Pretty dumb interface. The telemetry doesn't have a header, sync, crc or any type of delineation either.

Understanding Built-In Protocols

I've read through some of the built-in protocols but I'm not sure any of them apply. Burst says it relies on a regular burst of data. Since the user initiates a telemetry response by sending a command then this isn't really what I would call regular burst, right?

Both fixed and length protocols both require a sync pattern and id. My target's commands nor telemetry responses won't have a sync pattern or id. Also different commands generate different size responses as well.

Terminated requires a termination character which I won't have to go on either. At first, I thought the template protocol might work but then it says that it requires a termination character as well which I won't have.

Conclusion

I noticed in your protocol documentation you mention the following ...

With serial connections, it is very likely that when you open a serial port and start receiving data you will receive the middle of a message. (This problem is only avoided when interfacing with a system that only writes to the serial port in response to a command)

What you're indicating there in parenthesis is kind of how my target is, it responds with a byte stream from sending a command. Is my target a perfect example of needing to define a custom protocol? Or did I misunderstand something w/ your built-in protocols that I could possibly adopt here w/ my target? Appreciate any direction you might have.

[ryanmelt]

Burst would probably work, but it just reads whatever is currently available, and with a slow serial port, it might just get the first byte and call that a packet.

I think I would recommend a custom Interface for this case, you'll need to override the write() method, and have it write and read the response. The read() method should then just return the response (typically pulled off of a Queue that the write method put the response onto).

[rogueWookie]

@ryanmelt
Hi Ryan ~
As I'm reading through the Custom Protocol Guide I'm not quite following how I add a custom protocol. By that I mean, where I place my <my-special-protocol>.rb file.

My best guess is I add it to the same directory path that all the other protocols are in (e.g. cosmos/openc3/lib/openc3/interfaces/protocols/)? However, after downloading the cosmos-project (per the quick start guide) I don't see any such path. Might need a bit more guidance if you would be so kind.

Perhaps I add it in my custom plugin somewhere (e.g. cosmos-project/<my-plugin>/targets/<target>/protocols/<my-special-protocol>) and then I just call it out in plugins.txt and bobs your uncle?

...
INTERFACE <%= rpi_target_name %>_INT serial_interface.rb /dev/ttyUSB0 /dev/ttyUSB0 115200 NONE 1 nil nil MY_SPECIAL_PROTOCOL <ARG1> <ARG2> <ARGn>
    MAP_TARGET <&= rpi_target_name %>

If you could guide me through that I would appreciate it. I'm hoping it's easy to do. Also beautiful work w/ v5. I recall working w/ v4 back in the day when everything was Qt based.

[ryanmelt]

@rogueWookie I would recommend putting the custom protocol in a top-level lib folder in your plugin.
<my-plugin>/lib/<my-special-protocol>

[ryanmelt]

Also see #1017