# About Cyphal serial transport and libserard **URL:** \ **Category:** Applications & Usage\ **Created:** [November 13, 2024, 9:54am UTC](https://forum.opencyphal.org/t/about-cyphal-serial-transport-and-libserard/2226 "2024-11-13T09:54:59Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Gabriele](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/gabriele/32/1610_2.png) [@Gabriele](https://forum.opencyphal.org/u/Gabriele)\ **Post date:** [November 13, 2024, 9:54am UTC](https://forum.opencyphal.org/t/about-cyphal-serial-transport-and-libserard/2226/1 "2024-11-13T09:54:59Z")
Hi, we have successfully integrated cyphal with libcanard in several of our products (small satellite radios). We are now looking into adding cyphal over serial (rs422) as a fallback transport, but we cannot find any working implementation of libserard or any other example. The only repository with some code is this: [GitHub - OpenCyphal-Garage/libserard: A compact implementation of the Cyphal/serial protocol in C for high-integrity real-time embedded systems](https://github.com/OpenCyphal-Garage/libserard) , but it contains only headers without any implementation. If a working/beta implementation of libserard is not available, could we implement that ourselves by following the specification ? We saw that yakut already supports serial transport and we can receive and decode the generated messages, but how do we pass the received frames to the upper layer ? Does exist something like a ‘canardRxAccept’ but for serial ? Thanks for any input/help on the issue 🙂 ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [November 13, 2024, 5:03pm UTC](https://forum.opencyphal.org/t/about-cyphal-serial-transport-and-libserard/2226/2 "2024-11-13T17:03:25Z")
Our very own @coder_kalyan has been working on the implementation in his fork of libserard: > **[GitHub - coderkalyan/libserard at v0-impl](https://github.com/coderkalyan/libserard/tree/v0-impl)** > > v0-impl He asked me to provide feedback on his work to eventually merge it into upstream, but I’ve been postponing that for a lack of time – sorry about that. I will pick it up as soon as time permits, but for now, consider using his fork as-is (YMMV). If you happen to have any feedback, feel free to open tickets and send pull requests. Sorry for the delays. ---
**Author:** ![Gabriele](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/gabriele/32/1610_2.png) [@Gabriele](https://forum.opencyphal.org/u/Gabriele)\ **Post date:** [November 14, 2024, 9:23am UTC](https://forum.opencyphal.org/t/about-cyphal-serial-transport-and-libserard/2226/3 "2024-11-14T09:23:19Z")
Thanks a lot for the quick reply 🙂 We plan to integrate and test the code next week. We are happy to try it and give feedback as soon as possible. ---
**Author:** ![mgimhof](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/m/ecb155/32.png) [@mgimhof](https://forum.opencyphal.org/u/mgimhof)\ **Post date:** [December 11, 2024, 4:55pm UTC](https://forum.opencyphal.org/t/about-cyphal-serial-transport-and-libserard/2226/4 "2024-12-11T16:55:21Z")
I got it to work for my use case of bridging between an OpenCyphal Can network and yakut on my laptop using a serial connection. I had to tweak one include and add an additional test before assigning an optional parameter in serardRxAccept. In the spirit of least surprise, I suggest to keep the different transport libraries as aligned as possible and stress differences in the documentation. Details are documented in [https://github.com/coderkalyan/libserard/issues/2](https://github.com/coderkalyan/libserard/issues/2) ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [December 11, 2024, 5:25pm UTC](https://forum.opencyphal.org/t/about-cyphal-serial-transport-and-libserard/2226/5 "2024-12-11T17:25:03Z")
> [@mgimhof](#): > > I got it to work for my use case of bridging between an OpenCyphal Can network and yakut on my laptop using a serial connection. That’s an interesting use case. Why not use a CAN adapter on your laptop? ---
**Author:** ![mgimhof](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/m/ecb155/32.png) [@mgimhof](https://forum.opencyphal.org/u/mgimhof)\ **Post date:** [December 11, 2024, 9:57pm UTC](https://forum.opencyphal.org/t/about-cyphal-serial-transport-and-libserard/2226/6 "2024-12-11T21:57:46Z")
Hey Pavel, the use case is two fold. First, I don’t have a can adapter yet for the laptop. Second, the serial connection will ultimately be replaced with a radio link. ---
**Author:** ![andy27182](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/andy27182/32/1725_2.png) [@andy27182](https://forum.opencyphal.org/u/andy27182)\ **Post date:** [October 23, 2025, 1:45am UTC](https://forum.opencyphal.org/t/about-cyphal-serial-transport-and-libserard/2226/7 "2025-10-23T01:45:30Z")
Hi I noticed that the serial link standard uses a message header of up to 24 bytes. Is this really necessary. And also does not support multi-frame transfer. Is it feasible if using processing logic similar to libcanard? ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [October 28, 2025, 12:48pm UTC](https://forum.opencyphal.org/t/about-cyphal-serial-transport-and-libserard/2226/8 "2025-10-28T12:48:50Z")
> [@andy27182](#): > > I noticed that the serial link standard uses a message header of up to 24 bytes. Is this really necessary. It is possible to shave off a few bytes, but it is believed that the benefit of using consistent headers across different transports outweighs the cost of the extra bytes. > [@andy27182](#): > > And also does not support multi-frame transfer. Is it feasible if using processing logic similar to libcanard? The serial transport does not need multi-frame transfers because there is no MTU limit. One could argue that the disadvantage of this approach is a worse performance in the presence of a priority inversion, where a long low-priority transfer can occupy the channel while a higher-priority transfer is waiting — the significance of this problem scales with MTU — but for the serial transfer we assume that the great simplification offered by the omission of multi-frame transfers outweighs the cost of the priority inversion mode.