The toys just keep coming in! Another one of those wallet killing impulsive orders whilst I was sick in bed last week just arrived today, a USB-CAN bus converter module by EasySync that promises a great interface and should work in Linux! This will give a little bump start to my Mazda CAN Bus / mChumby projects.
Note : EasySync UK’s online form doesn’t allow international shipping but a short E-mail or two managed that. There is a US subsidiary with US and international shipping, but the international shipping rates on the US site is plain ridiculous [$68USD to ship a $88 device to Australia].
Note 2 : I hear the interface is mimicking the Lawicel CAN-USB interface…only hearsay…
Plugged it in – didn’t work. Doh! Took a peek at the manual and website, nothing on Linux other than “Linux drivers provided”… So much for the marketing material, guess I have to try make it work myself. (Yes I got it working, read on for the quick run-down post aimed at helping others)
Now with the photos out of the way, a little bit of detective work is ahead of us… why doesn’t this thing work… I paid so much money for it to replace the qprotos adapter!
A little bit of lsusb (or cat /proc/bus/usb/devices if you’ve got usbdevfs) sleuthing later…
Bus 003 Device 004: ID 0403:fac6 Future Technology Devices International, Ltd Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0xfac6 bcdDevice 6.00 iManufacturer 1 EasySync iProduct 2 USB2-F-7001 CAN-Plus Adapter iSerial 3 ESNFWLPL bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 150mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 2 USB2-F-7001 CAN-Plus Adapter 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 0 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 0 Device Status: 0x0000 (Bus Powered)
Yup definitely a FTDI device, even with the FTDI vendor ID (Did I mention I love FTDI?). Looks like EasySync decided they wanted their own unique product ID, unfortunately that means the vanilla ftdi_sio drive won’t pick it up without a little bit of coercing.
The little bit of coercing goes like…
modprobe ftdi_sio vendor=0x0403 product=0xfac6
[ 6372.229046] usb 2-2: new full speed USB device using uhci_hcd and address 3 [ 6372.437247] usb 2-2: configuration #1 chosen from 1 choice [ 6372.439834] ftdi_sio 2-2:1.0: FTDI USB Serial Device converter detected [ 6372.439872] usb 2-2: Detected FT232RL [ 6372.439934] usb 2-2: FTDI USB Serial Device converter now attached to ttyUSB0
Using putty to connect to ttyUSB0 at 115200, and typing “H” followed by “Enter” gives us
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2009.06.30 21:23:18 =~=~=~=~=~=~=~=~=~=~=~= H List of Supported Commands O - Open CAN Channel C - Close CAN Channel t - Transmit Standard Frame T - Transmit Extended Frame F - Read Status Flag V - USB2-F-7001 Version N - Serial Number of USB2-F-7001 Z - TimeStamp Option On/Off S - Set CAN Bit Rate s - Set BRGCON Registers m - Set Acceptance Mask M - Set Acceptance Filter B - Enter Bootload Mode L - Set Listen Mode E - Clear Buffers and Echo Char R - Reset USB2-F-7001 H, ? or h - Help on USB2-F-7001 Commands
Only problem is that its Mac style line endings. Even the append CR to LF option in putty is useless because the stream seems to be CR without LF… Doesn’t hurt too much except displaying it is a bit annoying.
The EasySync USB-CAN adapter’s pinout is pretty much standard DB9 for CAN Bus and all I had to do was connect my existing J1962 (aka OBD-II aka DLC-2) cable on and onto the car I went.
A couple of short “S6” (500kbps) “L” (Open connection for listen mode) commands later, I had CAN data being spat back at me
t04680601FF0000000000 t04680601FF0000000000 t04680601FF0000000000 t04680601FF0000000000 t04680601FF0000000000 t20F8FFFF27104000FF01 t2118FFFF000040000001 t4B082710271027102710 t19080000000000000000
All is good…except I just deleted my Chumby Development Virtual Machine a few hours ago…ooops…another day before I use this neat little adapter for mChumby.
26 thoughts on “EasySync USB-CAN Bus Adapter – Works great in Ubuntu after some fiddling”
Did you ever work with the Windows Driver?
No, they had a windows driver available online for download…doesn’t that work?
The Windows Virtual COM driver works, but the speeds are not up to par with my application. The USB drivers seem to be quite underdeveloped. It seems that the device accept some Identifiers even though they are valid. In reading the CAN Documentation, bits 4 through 10 of the 11 bit identifier cannot be all recessive, and that is the only valid reason to reject a CAN identifier.
Anyways, I’ve been in correspondence with Easy-Sync, but been stuck on this for about a month now.
While you’re at it ask the why they’re so averse to ‘LF’… it was driving me nuts. Not only do all status come back from the device with just ‘CR’ and no ‘LF’, putting any ‘LF’s in the commands gives you a nice beep (‘BEL’) back…gah…
What do you mean the device accepts ID’s even though they’re valid?… invalid? Masked?
PS : What speeds are you running at that the V Com isn’t coping with? 2Mbps?
From memory (vague) of Windows, I had V COM drivers up to 1Mbps so it was all good there.
You can try downloaded the FTDI drivers and modifying them as per the FTDI website.
As for the speeds question.
I have an board sending out about 1Mbps. 10 frames every 2ms. And I am only able to pick up 3 of them on average.
According to my calculations this is around 160 Kbps.
This is using Java’s RXTX library which replaced java.com for communicating with the device.
Were you able to test the 1Mbps capabilities? and how so?
Almost all that CAN/OBD stuff is FTDI-based. It’s usual thing. I use ELM-327 box, it’s also FTDI-based.
There are a few adapters though that are based on microprocessors with both USB and CAN….and those tend to be a pain to interface to 🙁 [Hello qprotos!]
I rapidly gave up on using TTY with the thing, and started writing a (Windows) C++ program to do some logging. Then some off-line processing software to search the logs for meanings. I’m just at the point where I can do some meaningful research, I think.
On EasySync, I found a lot of little problems, in addition to the quirks you’ve mentioned. For instance there’s ONE command (E) that echos the command back to you! The rest don’t. Somebody wasn’t thinking. I also had trouble finding the right data rate, since the device likes to frame up totally illegal stuff — frames that are hundreds of bytes long, for instance.
It also won’t handle remote frames, although they say that may come in a firmware update next quarter. Not needed for OBD-II, but who knows if Mazda uses any, unless the device can detect them?
Hi Jim again,
Its quirky alright, really quirky up to including which CR/LF it takes before accepting a command (I don’t think I’ve mastered it but my program spams it with every kind of command as a temporary hack so it works :P). Its actually stated that none of the commands actually echo and you’re meant to set your terminal program to echo.
Have you had a look at the Test Run post (http://www.madox.net/blog/2009/07/15/mchumby-test-run/) with the two videos I posted? Kind of works 🙂
Had the problem you mentioned with weirdo frames, those started with a capital ‘T’ rather than the usual ‘t’ for me. What is a remote frame?
Sorry I never answered your last question above. A remote frame is really a query from one CAN node to another, timed so that it at least “could” happen within the same CAN frame. The requester essentially sends the ID, and the answering node fills in the data, all in the same frame.
Initially I assumed that OBD-II under CAN would use this mechanism, but it doesn’t. In practice it’s probably only useful on very specialized equipment, since the latency requirements on the answering node are so high. It makes sense that they didn’t use remote frames, but it took a while for me to realize it.
From the EasySync’s point of view, they claim they will be supporting it later, but I kind of doubt it — at least not in the one-frame mode that the designers intended. To do so, the EasySync would have to be sent a response in advance, and I think their little box isn’t intended to be so sophisticated. I wouldn’t blame them for just not implementing that feature.
The capital-T frames are in themselves legit. The incoming frames are formatted like the outgoing transmit frames (although they never bother telling you that…) — the ‘t’ frames are standard CAN frames with 11-bit IDs; the ‘T’ frames are extended frames, with 29-bit IDs. My guess is that if a frame does match ‘t’, they just shove it out as ‘T’, without any error-checking.
Not sure about the CR-LF ambiguity you’re seeing. I always send out CR, never LF, and it seems to accept all the commands I’ve tried. The “E” return is indeed mentioned in the docs.
Another one. When you transmit a frame, it returns either ‘z’ or ‘Z’. Not real useful when you’re buffering the input, and the input and output are asynchronous. 🙁
Another interesting “feature”! When the car (Mazda MX5 in my case) is under hard acceleration, the ECU stops answering OBD requests — probably too busy with its own work. But the interesting thing (about the EasySync) is that CAN frames often come in out of sequence during that time! I turned on the EasySync’s timer, and the timestamps show a different order than the receipt of the frames. Kinda weird, actually.
I don’t think it hurts anything (at least anything I’m doing), but you have to wonder about the firmware in there.
hi, what version of ubuntu did you use?
I have the same CAN-adapter, but its not working. I’m using Ubuntu 10.04, kernel 2.6.32-23-generic
all I get is:
[ 3504.440258] usb 2-1.1.2: new full speed USB device using ehci_hcd and address 13
[ 3504.540766] usb 2-1.1.2: configuration #1 chosen from 1 choice
no ftdi stuff
but if i plug in a usb2rs232 adapter, ftdi_sio is showing up
[ 3670.576139] usb 2-1.1.7: new full speed USB device using ehci_hcd and address 14
[ 3670.675374] usb 2-1.1.7: configuration #1 chosen from 1 choice
[ 3670.677982] ftdi_sio 2-1.1.7:1.0: FTDI USB Serial Device converter detected
[ 3670.678041] usb 2-1.1.7: Detected FT232RL
[ 3670.678047] usb 2-1.1.7: Number of endpoints 2
[ 3670.678053] usb 2-1.1.7: Endpoint 1 MaxPacketSize 64
[ 3670.678058] usb 2-1.1.7: Endpoint 2 MaxPacketSize 64
[ 3670.678063] usb 2-1.1.7: Setting MaxPacketSize 64
[ 3670.678360] usb 2-1.1.7: FTDI USB Serial Device converter now attached to ttyUSB0
any idea whats going on here?
You didn’t read the post did you? 🙂
The little bit of coercing goes like…
modprobe ftdi_sio vendor=0×0403 product=0xfac6
The device doesn’t use a standard vendor/product ID so it is not recognised by the driver. You’ll have to modprobe with the correct vendor/product ID (above) to get the driver to load.
Hope that helps you 🙂
of course i read your post, several times ;), and it works on my laptop
its just: it works on 1 machine, and not on the other ( mac mini running ubuntu 10.04 ), and i can’t figure out why…. damn apple….
but thx anyway….
Tnx Madox, I’ve been fiddling with this all day with no success at all. Finally I noticed that your “modprobe ftdi_sio vendor=0×0403 product=0xfac6” was not for copy/paste. 0×0403 should read 0x0403…
Any how, now up and running thanks 2 U.
Regards from Sweden.
Wow nice pick, sorry about that but it is a WordPress thing! Just went to try change it but it is ‘x’ for xylophone instead of multiplication in the original…
When I was reading that I have an idea come to my mind. I have standalone ECU that allows me to talk through CANBUS or ethernet ply. I can remap types of datas should the ECU stream through CAN BUS. So I mean datas are not encrypted. This feature to communicate motorsport dashes like that
Hi please suggest linux driver link anf sample utility to check the data stream.
Does it manifest as CAN0/1? I ‘ve got the “Bus 001 Device 005: ID 0403:fac6 Future Technology Devices International, Ltd USB2-F-7001 CAN-Plus Adapter”, but the ifconfig -a show no CAN interface. How to do that. Would anyone help please?
Why do you expect it to come up as an if? Why don’t you look in dmesg and see what device it gets attached as, since it is from FTDI I’m going to guess it probably is a CAN-Serial device on /dev/ttyUSBx?
how can i download windows driver for this product