# Alternative transport protocols in UAVCAN

**URL:** <https://forum.opencyphal.org/t/alternative-transport-protocols-in-uavcan/324>\
**Category:** Development & Maintenance\
**Created:** [January 11, 2019, 8:44pm UTC](https://forum.opencyphal.org/t/alternative-transport-protocols-in-uavcan/324 "2019-01-11T20:44:36Z")\
**Posts on this page:** 1\
**Showing post:** 30

<div class="post-metadata">

**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:** [June 28, 2020, 7:14pm UTC](https://forum.opencyphal.org/t/alternative-transport-protocols-in-uavcan/324/30 "2020-06-28T19:14:41Z")

</div>

> [@JediJeremy](#):
>
> Basically, I’ve written about 3500 lines of code and have a _very_ pre-alpha library which implements UAVCAN/Serial over USB and WiFi TCP/IP for the ESP chips using the Arduino SDK.

You should be aware that recently a design flaw was identified in the UAVCAN/serial packet framing (credits to @VadimZ); see the thread [UAVCAN/serial: issues with DMA friendliness and bandwidth overhead - #28 by scottdixon](https://forum.opencyphal.org/t/uavcan-serial-issues-with-dma-friendliness-and-bandwidth-overhead/846/28). We are going to be replacing the current byte stuffing logic with COBS. That will allow us to gain a near-constant overhead of ~0.4% instead of the variable 0~100%. Vadim doesn’t seem to be available at the moment to replace the [framing logic of the UAVCAN/serial implementation in PyUAVCAN](https://github.com/UAVCAN/pyuavcan/blob/master/pyuavcan/transport/serial/_frame.py), so we could use help here.

---

_[View the full topic](https://forum.opencyphal.org/t/alternative-transport-protocols-in-uavcan/324)._