Check out my first novel, midnight's simulacra!
CANalyst II: Difference between revisions
No edit summary |
No edit summary |
||
(17 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
The Canalyst II is an affordable, well-built piece of very Chinese equipment, exposing two [[CAN]] | [[File:CANalystII-above.png|thumb|right|alt=Picture of the CANalyst II from above.|The CANalyst II, an enigma (for now).]] | ||
The Canalyst II is an affordable, well-built piece of very Chinese equipment, exposing two [[CAN bus]] transceivers to a USB CAN adapter capable of 7k fps, and megabit CAN networks. There is very little English documentation. It appears as USB VendorID 04d8, ProductID 0053 (04d8:0053), the space of [https://www.microchip.com/ Microchip Technology, Inc.]. Both channels come equipped with independently-selectable 120Ω resistors necessary for ISO 11898-2 High-Speed CAN buses (such a resistor should not be used with ISO 11898-3 Reliable CAN buses). It also offers baud rate detection functionality. | |||
Note that the manual refers to ohms as euros, which is pretty indicative of the documentation's quality overall. | |||
I suspect there to be a 16MHz [https://www.nxp.com/products/analog/interfaces/in-vehicle-network/can-transceiver-and-controllers/stand-alone-can-controller:SJA1000T SJA1000] chip inside, but have not verified this. | |||
==Hardware== | |||
[[File:CANalystII-test-setup.png|thumb|left|alt=Wiring diagram for self-test|Wired thusly, the CANalyst II can self-test both channels.]] | |||
The CANalyst II is powered entirely over its USB connection--there is no dedicated input for power. | |||
Upon being powered on, the red PWR LED lights up. The blue SYS LED lights once whenever the OS makes a connection to the device. A self-test capability is included on the device, which will see the blue LED light twice in succession on a successful test. The wiring diagram for the self-test mode can be seen to the left. The CANalyst II presents a senary [https://en.wikipedia.org/wiki/Screw_terminal screw terminal] suitable for mating with a [https://en.wikipedia.org/wiki/D-subminiature DE-9] or [https://en.wikipedia.org/wiki/Data_link_connector_(automotive) ODB-II DLC]. | |||
{| class="wikitable sortable" | |||
|- | |||
!Port !! Pin !! Name !! Function | |||
|- | |||
| rowspan="6" | [[File:6screwterm.jpg|thumb]] || 1 || CAN_H || CAN_H signal wire, channel 0 | |||
|- | |||
| 2 || SHIELD || Terminal resistance connector, channel 0 | |||
|- | |||
| 3 || CAN_L || CAN_L signal wire, channel 0 | |||
|- | |||
| 4 || CAN_H || CAN_H signal wire, channel 1 | |||
|- | |||
| 5 || SHIELD || Terminal resistance connector, channel 1 | |||
|- | |||
| 6 || CAN_L || CAN_L signal wire, channel 1 | |||
|- | |||
|} | |||
The Chinese manufacturer's site claims that the device is "similar to a [https://www.zlg.com/can/can/product/id/22.html ZLG USBCAN-II+]". What exactly is meant by "similar" here is not yet known. The USBCAN-II+ claims 14Kfps using both channels, which does match the claimed performance of the CANalyst II. | |||
==Linux== | ==Linux== | ||
[[File:Canalystii-iface.png|thumb|right|alt=Hardware interfaces of the CANalyst II|Business ends of the CANalyst II.]] | |||
The Linux kernel's preferred way to drive CAN adapters is via SocketCAN, which presents the device as a network interface. There does not appear to be a SocketCAN driver for the Canalyst II as of 2019-06-10. The <tt>mcba_usb</tt> driver, recompiled to use the Canalyst II's USB ID, definitely does *not* work. I'm planning to write a kernel driver; the GitHub project is [https://github.com/dankamongmen/CANalystII-SocketCAN CanalystII-SocketCAN]. The [https://python-can.readthedocs.io/ python-can] project contains a userspace driver, for which I've [https://github.com/hardbyte/python-can/pull/617 recently submitted patches] (it wasn't working when my Canalyst II arrived). This allows a Python program to use the device, which is nice, I guess. | The Linux kernel's preferred way to drive CAN adapters is via SocketCAN, which presents the device as a network interface. There does not appear to be a SocketCAN driver for the Canalyst II as of 2019-06-10. The <tt>mcba_usb</tt> driver, recompiled to use the Canalyst II's USB ID, definitely does *not* work. I'm planning to write a kernel driver; the GitHub project is [https://github.com/dankamongmen/CANalystII-SocketCAN CanalystII-SocketCAN]. The [https://python-can.readthedocs.io/ python-can] project contains a userspace driver, for which I've [https://github.com/hardbyte/python-can/pull/617 recently submitted patches] (it wasn't working when my Canalyst II arrived). This allows a Python program to use the device, which is nice, I guess. | ||
If the <tt>usbserial</tt> kernel module is told to use the Canalyst II's USB IDs via <tt>sudo modprobe usbserial vendor=0x04d8 product=0x0053</tt>, it does appear to successfully bring up an SLCAN device, which can then be exposed as a network device using <tt>slcand</tt> or <tt>slcan_attach</tt>. The <tt>usbserial</tt> module will create 6(!) <tt>ttyUSB</tt> nodes for the CANalyst II. Only the first device seems to have any effect when used with SLCAN. | If the <tt>usbserial</tt> kernel module is told to use the Canalyst II's USB IDs via <tt>sudo modprobe usbserial vendor=0x04d8 product=0x0053</tt>, it does appear to successfully bring up an SLCAN device, which can then be exposed as a network device using <tt>slcand</tt> or <tt>slcan_attach</tt>. The <tt>usbserial</tt> module will create 6(!) <tt>ttyUSB</tt> nodes for the CANalyst II. Only the first device seems to have any effect when used with SLCAN. To create a 125Kbps adapter, use something like: | ||
<nowiki>[schwarzgerat](0) $ sudo slcand -o -s4 -F ttyUSB0 | |||
[6] starting on TTY device /dev/ttyUSB0 | |||
[5] attached TTY /dev/ttyUSB0 to netdevice slcan0</nowiki> | |||
The generated net device cannot have its bitrate set using <tt>ip</tt>, like native SocketCAN devices. Instead, the <tt>-s</tt> argument must be provided to <tt>slcand</tt>, using the following table: | |||
{| class="wikitable sortable" | |||
|- | |||
!ASCII Command !! CAN Bitrate | |||
|- | |||
|s0 || 10 Kbit/s | |||
|- | |||
|s1 || 20 Kbit/s | |||
|- | |||
|s2 || 50 Kbit/s | |||
|- | |||
|s3 || 100 Kbit/s | |||
|- | |||
|s4 || 125 Kbit/s | |||
|- | |||
|s5 || 250 Kbit/s | |||
|- | |||
|s6 || 500 Kbit/s | |||
|- | |||
|s7 || 800 Kbit/s | |||
|- | |||
|s8 || 1000 Kbit/s | |||
|} | |||
==lsusb output== | ==lsusb output== |
Latest revision as of 02:07, 15 December 2020
![Picture of the CANalyst II from above.](/dankwiki/images/thumb/3/34/CANalystII-above.png/300px-CANalystII-above.png)
The Canalyst II is an affordable, well-built piece of very Chinese equipment, exposing two CAN bus transceivers to a USB CAN adapter capable of 7k fps, and megabit CAN networks. There is very little English documentation. It appears as USB VendorID 04d8, ProductID 0053 (04d8:0053), the space of Microchip Technology, Inc.. Both channels come equipped with independently-selectable 120Ω resistors necessary for ISO 11898-2 High-Speed CAN buses (such a resistor should not be used with ISO 11898-3 Reliable CAN buses). It also offers baud rate detection functionality.
Note that the manual refers to ohms as euros, which is pretty indicative of the documentation's quality overall.
I suspect there to be a 16MHz SJA1000 chip inside, but have not verified this.
Hardware
![Wiring diagram for self-test](/dankwiki/images/thumb/5/55/CANalystII-test-setup.png/300px-CANalystII-test-setup.png)
The CANalyst II is powered entirely over its USB connection--there is no dedicated input for power. Upon being powered on, the red PWR LED lights up. The blue SYS LED lights once whenever the OS makes a connection to the device. A self-test capability is included on the device, which will see the blue LED light twice in succession on a successful test. The wiring diagram for the self-test mode can be seen to the left. The CANalyst II presents a senary screw terminal suitable for mating with a DE-9 or ODB-II DLC.
The Chinese manufacturer's site claims that the device is "similar to a ZLG USBCAN-II+". What exactly is meant by "similar" here is not yet known. The USBCAN-II+ claims 14Kfps using both channels, which does match the claimed performance of the CANalyst II.
Linux
![Hardware interfaces of the CANalyst II](/dankwiki/images/thumb/0/05/Canalystii-iface.png/300px-Canalystii-iface.png)
The Linux kernel's preferred way to drive CAN adapters is via SocketCAN, which presents the device as a network interface. There does not appear to be a SocketCAN driver for the Canalyst II as of 2019-06-10. The mcba_usb driver, recompiled to use the Canalyst II's USB ID, definitely does *not* work. I'm planning to write a kernel driver; the GitHub project is CanalystII-SocketCAN. The python-can project contains a userspace driver, for which I've recently submitted patches (it wasn't working when my Canalyst II arrived). This allows a Python program to use the device, which is nice, I guess.
If the usbserial kernel module is told to use the Canalyst II's USB IDs via sudo modprobe usbserial vendor=0x04d8 product=0x0053, it does appear to successfully bring up an SLCAN device, which can then be exposed as a network device using slcand or slcan_attach. The usbserial module will create 6(!) ttyUSB nodes for the CANalyst II. Only the first device seems to have any effect when used with SLCAN. To create a 125Kbps adapter, use something like:
[schwarzgerat](0) $ sudo slcand -o -s4 -F ttyUSB0 [6] starting on TTY device /dev/ttyUSB0 [5] attached TTY /dev/ttyUSB0 to netdevice slcan0
The generated net device cannot have its bitrate set using ip, like native SocketCAN devices. Instead, the -s argument must be provided to slcand, using the following table:
ASCII Command | CAN Bitrate |
---|---|
s0 | 10 Kbit/s |
s1 | 20 Kbit/s |
s2 | 50 Kbit/s |
s3 | 100 Kbit/s |
s4 | 125 Kbit/s |
s5 | 250 Kbit/s |
s6 | 500 Kbit/s |
s7 | 800 Kbit/s |
s8 | 1000 Kbit/s |
lsusb output
usbutils 010, kernel 5.1.8, systemd 241.
Bus 001 Device 029: ID 04d8:0053 Microchip Technology, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x04d8 Microchip Technology, Inc. idProduct 0x0053 bcdDevice 3.24 iManufacturer 1 Microchip Technology Inc. iProduct 3 Chuangxin Tech USBCAN/CANalyst-II iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0066 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 12 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0001 Self Powered