Check out my first novel, midnight's simulacra!

CANalyst II: Difference between revisions

From dankwiki
(kill duplicate text)
No edit summary
Line 1: Line 1:
[[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]] 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.].
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.]. 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). Note that the manual refers to ohms as "euros", which is pretty indicative of its quality overall.


I suspect there to be an [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.
==Internals and Interface==
 
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.
==Hardware==
[[File:CANalystII-test-setup.png|thumb|left|alt=Wiring diagram for self-test|Wired thusly, the CANalyst II can self-test both channels.]]
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 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"
|-
!Port !! Pin !! Name !! Function
|-
| picture | 1 | CAN_L | CAN_L signal wire terminal
|-
| picture | 2 | R- | Terminal resistance connector (connected to CAN_L internally)
|-
| picture | 3 | SHIELD | Shielded wire terminal (FG)
|-
|4 R+ Terminal resistance connector (connected to CAN_H internally)
5 CAN_H CAN_H signal wire terminal
==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. 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

Revision as of 08:19, 10 June 2019

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 Microchip Technology, Inc..

Internals and Interface

The CANalyst II presents an OPEN5 screw terminal suitable for mating with a DE-9 or ODB-II DLC. Two CAN channels are supported.

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.

Port Pin Name Function
1 | CAN_L | CAN_L signal wire terminal
2 | R- | Terminal resistance connector (connected to CAN_L internally)
3 | SHIELD | Shielded wire terminal (FG)
4 R+ Terminal resistance connector (connected to CAN_H internally)

5 CAN_H CAN_H signal wire terminal

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 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