Check out my first novel, midnight's simulacra!

CANalyst II: Difference between revisions

From dankwiki
No edit summary
No edit summary
 
(4 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 bus]] 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.].
[[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.


==Internals and Interface==
Note that the manual refers to ohms as euros, which is pretty indicative of the documentation's quality overall.
The CANalyst II presents an OPEN5 [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]. Two CAN channels are supported.
 
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].


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.
{| class="wikitable sortable"
{| class="wikitable sortable"
|-
|-
!Port !! Pin !! Name !! Function
!Port !! Pin !! Name !! Function
|-
|-
| picture | 1 | CAN_L | CAN_L signal wire terminal
| rowspan="6" | [[File:6screwterm.jpg|thumb]] || 1 || CAN_H || CAN_H signal wire, channel 0
|-
|-
| picture | 2 | R- | Terminal resistance connector (connected to CAN_L internally)
| 2 || SHIELD || Terminal resistance connector, channel 0
|-
|-
| picture | 3 | SHIELD | Shielded wire terminal (FG)
| 3 || CAN_L || CAN_L signal wire, channel 0
|-
|-
|4 R+ Terminal resistance connector (connected to CAN_H internally)
| 4 || CAN_H || CAN_H signal wire, channel 1
5 CAN_H CAN_H signal wire terminal
|-
| 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==
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.
[[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.


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:
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
  <nowiki>[schwarzgerat](0) $ sudo slcand -o -s4 -F ttyUSB0

Latest revision as of 02:07, 15 December 2020

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 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
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 screw terminal suitable for mating with a DE-9 or ODB-II DLC.

Port Pin Name Function
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 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
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 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