SavvyCAN USB CAN Adapter: SocketCAN or GVRET?

Connect a USB CAN adapter to SavvyCAN by choosing the host path first: Linux SocketCAN, GVRET serial/network, a supported Qt SerialBus vendor plugin, or an offline capture. The enclosure name alone does not identify the path.

Choose the connection path before the adapter

On a narrow screen, scroll the table horizontally.

Prove the Linux SocketCAN path first

Use a controlled bench with a documented Classical CAN bitrate. Do not guess a bitrate on an active machine or vehicle, and do not reconfigure an interface owned by another service.

ip -details link show can0

sudo ip link set can0 down
sudo ip link set can0 up type can bitrate <known-bitrate>

ip -details -statistics link show can0
candump -L can0

The Linux kernel exposes supported CAN controllers as network interfaces. can-utils supplies candump for display and logging. Seeing the expected frames in candump proves the kernel-to-interface path under that test; it does not prove isolation, termination, timestamp quality or capture integrity.

Connect the same interface in SavvyCAN

1. Record the application build. Keep the SavvyCAN version, operating system, architecture and the downloaded asset name.
2. Open the connection settings. In V220-style builds, open the connection window and add a new device connection.
3. Select Qt SerialBus. Choose the socketcan device type and select or enter can0.
4. Leave Linux in charge of bit timing. SavvyCAN’s SocketCAN connection code notes that the interface speed must be configured with host commands.
5. Confirm raw traffic before decoding. Match one known CAN ID and payload between candump and SavvyCAN, then load a DBC only after the raw path agrees.
6. Retain the evidence. Save the original log, interface statistics, software versions, firmware identity and wiring note.

If candump works but socketcan is absent from SavvyCAN, check the SavvyCAN package and its Qt CAN-bus plugins before changing adapters. Qt loads CAN backends at runtime, so a plugin supported by Qt is not automatically present in every binary distribution.

Use GVRET only for a named GVRET device

SavvyCAN’s upstream README documents GVRET hardware and also supports Qt SerialBus paths. A serial port by itself does not prove GVRET: the connected board must run matching firmware and answer the expected protocol.

1. Identify the board and firmware. Record the PCB revision, firmware repository, commit or release, bootloader and update method.
2. Name the transport. Record serial device/COM port or network address and port; do not describe both simply as “USB CAN.”
3. Confirm channel and bitrate control. Prove the intended bus is enabled at the documented bitrate and that settings survive the required reconnect or restart.
4. Compare a known frame. Use the same controlled stimulus and expected ID/payload used for the SocketCAN acceptance path.
5. Test failure recovery. Unplug/reconnect, close/reopen SavvyCAN and repeat the capture without silently changing firmware or settings.

Do not buy on “SavvyCAN compatible” alone

Put the following fields on the supplier quotation and sample record:

• manufacturer, exact model, PCB revision, firmware name/version/hash and USB VID/PID;
• host operating system, architecture, SavvyCAN build and connection path;
• Linux driver and resulting network-interface name, or the exact GVRET/vendor transport;
• Classical CAN or CAN FD scope, supported arbitration/data bitrates, frame types and channel count;
• connector pinout, CAN ground/shield path, termination control and supplied cable;
• signal-and-power isolation boundary, component identities, protection parts and product-level test evidence;
• 10/50/200-unit price, sample cost, lead time, resale rights, compliance documents and warranty route.

Troubleshoot from the lowest proven layer

Run a purchase-acceptance trace

1. Identify. Photograph the sample and retain its revision, firmware, USB identity and quotation.
2. Enumerate. Prove the intended driver/backend and record the exact interface or port.
3. Capture. Receive a controlled frame set at each required Classical CAN bitrate.
4. Compare. Match retained raw frames between candump and SavvyCAN before applying a DBC.
5. Stress. Run the defined duration and load while retaining host counters, bus state and thermal observations.
6. Recover. Repeat after reconnect, application restart and a documented bus-off/recovery case when safe.
7. Decide. Accept only the exact revision tested; record unsupported features and failed conditions.

Name the SavvyCAN path in the pilot request

Include the host OS, SavvyCAN build, socketcan, GVRET or vendor backend, expected interface/port, bitrate, connector and quantity in the engineering pilot request. Continue with the Linux SocketCAN setup, the python-can backend guide or the local DBC workflow.

Primary references

• SavvyCAN upstream repository and README
• SavvyCAN upstream releases
• SavvyCAN Qt SerialBus connection source
• Linux Kernel: SocketCAN — Controller Area Network
• Linux-CAN: can-utils
• Qt CAN Bus plugins
• candleLight gs_usb-compatible firmware and limitations