Comments on: EasySync USB-CAN Bus Adapter – Works great in Ubuntu after some fiddling

By: Madox

Madox — Mon, 30 Aug 2010 05:08:52 +0000

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…

By: AGW

AGW — Sun, 29 Aug 2010 18:06:47 +0000

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 0×0403…
Any how, now up and running thanks 2 U.

Regards from Sweden.

/AGW

By: walter

walter — Thu, 29 Jul 2010 08:07:18 +0000

hey Madox,

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

By: Madox

Madox — Fri, 02 Jul 2010 12:20:18 +0000

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

By: walter

walter — Fri, 02 Jul 2010 07:19:39 +0000

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?

thx

By: Madox.NET » Reverse Engineering the Mazda CAN Bus – Part 2

Madox.NET » Reverse Engineering the Mazda CAN Bus – Part 2 — Sat, 24 Oct 2009 13:03:54 +0000

[...] is probably the most ridiculous way to reverse engineer something to date… a Chumby, an EasySync CAN Sniffer, PHP and JavaScript… but it [...]

By: Jim Boemler

Jim Boemler — Wed, 22 Jul 2009 01:49:30 +0000

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.

By: Jim Boemler

Jim Boemler — Wed, 22 Jul 2009 01:40:58 +0000

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.

By: Jim Boemler

Jim Boemler — Tue, 21 Jul 2009 21:44:54 +0000

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.

By: Jim Boemler

Jim Boemler — Sun, 19 Jul 2009 21:08:59 +0000

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.