Skip to content

What is Sockcan?

Sockcan is a Python library designed to offer a performant and flexible interface for CAN (Controller Area Network) communication. It aims to provide a compatible API with the widely used python-can library but with a focus on speed and cross-platform capabilities through a userspace implementation.

Key Features

  • High Performance: Optimized for faster message processing and lower latency compared to traditional python-can setups.
  • Userspace Implementation: Enables CAN communication on platforms like Windows, where native SocketCAN is unavailable, by simulating SocketCAN behavior in userspace.
  • python-can Compatible Interface: Minimizes migration effort for existing python-can applications.
  • Concurrency: Supports concurrent access to the CAN bus, allowing multiple parts of an application to send and receive messages simultaneously.
  • Virtual CAN: Facilitates the creation of virtual CAN interfaces for development, testing, and simulation without physical hardware.
  • CAN to TCP/UDP bridge: the userspace SocketCAN server provided by this package can bridge to both TCP and UDP communications, depending on your configuration.

Use Cases

  • Well-suited for performance constrained environements. Embedded systems running Linux (e.g., Raspberry Pi) might not even be able to process a full bus-load without having CPU throttling with python-can.
  • Ease porting Linux implementations to Windows: can allow running a Linux SocketCAN's based application on Windows by simply running the userspace SocketCAN server provided by this package on top of the real bus. This can enable bus concurrency and virtualizaion on Windows, which are not available natively with PeakCAN drivers.

Limitations

  • Timestamps: Timestamps in SocketCAN rely on socket ancillary data, which does not exit on Windows. Thus, to keep compatibility with SocketCAN, built-in timesdtamps (which in SocketCAN would be coming from the CAN driver directly) have to be disabled, and timestamping is done at the netowrk-level (thus less accurate, and also subject to any lag in the reception chain).
  • Filters: CAN filtering is currently only partially supported. You should make sure you application logic can reject properly unwanted messages.
  • Blocking policy: custom timeouts in receive methods are not support yet. When using selector protocols over the socket, receive is only non-blocking if both sides implement properly the protocol, and might currently end-up blocking in case of unexpected payload.