NefMoto

Anyone has any experiences to share with using USBtin:

http://www.fischl.de/usbtin/

for non-trivial custom CAN stuff? Like making own flashing interfaces, etc? Just curious.

I looked at it and thought it looked interesting if you could make use of its software.

A few things I didn't like the look of for performance:

PIC18F (slow with little memory to buffer)
MCP2515 (tiny receive buffer)
ASCII protocol (halves transfer rate)
Throughput tests only at 250Kbps

I ended up using J2534 for my project, but it has some weaknesses:

Easy to snoop
Polling instead of callbacks
Price is higher for a genuine product
Windows registry dependency but can be made to work on other platforms, but no examples with Android
Not usually wireless
Carries other capabilities I don't need hence price

Soon I'm migrating my project to a custom built ESP32 device with a CAN transceiver. Before I even started the project, I made sure I could tweak it so that it could deal with a full CAN bus with minimal latency (<10us the minimum I can measure with what I was using to test - Kvaser Leaf Light HS v2). Out the box, the sample drivers could not. The net effect on large transfers is considerable if your device is slower than your ECU.

From what I've seen of MED17, it transmits every 1ms for large ISO TP groups, and asks in its flow control for 2ms inter-packet spacing to receive but accepts faster. So you might not need the theoretical ~240us (depending on bit stuffing) reply time. Kvaser told me they only do 1ms best over USB.

I started building some of these but haven't programmed or tested them yet:

http://canable.io/

I think you can buy them readymade too, pretty cheap. I'm just cheap-er.

Since it is STM32, and has native socketCAN support (instead of just slcan [ascii]) should be better throughput. Not sure about latency, I'll have to test when i finish assembling mine.

Thank you both for input, I will look into all this.

The Cantact/Canable design looks very good/minimal.

There is another design somewhere that uses the STM32 but uses the USB clock instead of a crystal to pare it down even more.

USB2 has 125us polling, that's a hard limit you can't do anything about.
USB3 works differently and you can get down to 25us.

Most microcontrollers used in CAN interfaces don't seem to support the 125us microframes of USB high speed.

Well then USB3 is your best bet.

I am putting the latency sensitive logic in the OBD device and sending much larger packets with higher latencies through WiFi.

Yeah, it's probably the best way to go to have all the logic in the MCU and have a higher level protocol for computer comms vs. trying to send every packet from the computer.

Precisely what I did with Arduino Leonardo-CAN and got very good results in terms of performance. Nevertheless, the solution is software heavy - non trivial code on the Arduino that has to deal with MPC peculiarities, and corresponding code to package things on the PC before they are send to the interface. All in all, huge contraption that happens to work. One of the interfaces we are discussing would allow to just have socket based (I work on Linux exclusively) CAN connection and have a much cleaner design, software wise. Would have already bought this canable thing to test, if not for the shipping to my country being the same as the product price :/

I have been digging a bit into J2534 things, and I think I now understand what it offers. I have even localised this:

https://github.com/NikolaKozina/j2534

which is of great help. But, I am still not totally clear on the actual devices. I know the genuine stuff costs $$$, I have also found something called Tactrix Openport2.0 on Chinsese websites. Does this have any chance of working. Or, there is this Toyota Mini VCI cable popping up all the time when googling for J2534, is that anywhere near what I think it could be? Would it work for CAN 500kbs based protocols?

I have a genuine OpenPort 2.0 and Kvaser Leaf Light HS v2. I got the Chinese OP2 for $20 and a Toyota MVCI to try as I thought users might try them and wanted to know how bad they were and what issues would arise. The MVCI is very slow and the Chinese OP2 is dead, but initially worked like the genuine one.

The OpenPort 2.0 can happily flash at 500Kbps with a 75% full CAN bus. It is faster than the Kvaser at J2534, but the Kvaser has great development tools and utilities and they handle a 100% full CAN bus without errors for hours, which for some reason seems a tall order for CAN interfaces.

Main weakness of J2534 I see is that its drivers are single threaded and polling based. Both OpenPort 2.0 and Kvaser have bugs in their J2534 implementation too.

For distribution of software to end users, except for pros who are doing lots of cars, genuine/good J2534 is usually too expensive.

You are a gold mine of knowledge for this ;) You really ought to change your nick to something like CAN-Bus-Guru or something ;)

Why can't it be simple I wonder, it's not a rocket science to have a USB to CAN device. Many standards, proprietary hardware, what not.

Original products are not an option for this use case (not that I am against the principle or anything, quite the contrary), for personal use I already solved my issues with Arduino-CAN, but I was simply thinking about open-sourcing some of my developments (logger/flasher) for ME7.9.10, but I'd need some hardware people could just buy easily and cheaply. For logging ELM is sufficient, hell, I even managed to get ELM to work for flashing, but the complete procedure is 8 minutes instead of 1.5. And it has some really ugly hacks because of the older ELM version (and also most likely Chinese, never cared to check) that I have that does not support some things.

Seems the next step would be to try the cloned OP (it I could only buy it in Europe, Sweden is now hard on imports and duties have to be paid on essentially everything, not a financial problem, but it also equals months of waiting time for delivery, seriously).

How much slower are we talking about for MVCI?

MVCI was crazy slow, like ELM327 speed.

Kvaser is Swedish :)

Chinese stuff from AliExpress takes about 3 weeks to UK with no import duty for this stuff.

I am doing an ESP32 device in a tiny OBD enclosure presently, but it is a commercial project. It does four CAN packets in a millisecond, but has been tweaked endlessly and doing the same with ISO15765 now.

Once everyone involved gets their cut it not be cheap but with new features. Unless you sell loads or give away your real time and costs, it does not surprise me that genuine J2534 stuff cost €200+.

Drop us a link once this ESP32 device of yours is more available ;)

Kvaser might be Swedish, I am not, only happen to live here at the moment. Just checked this product you quoted, looks very solid piece of hardware, just the price is probably more than my complete spending on the Flex Fuel development so far.

And what is going on with the post and duties is currently crazy here, it is not about postage time, but the totally choked duty collection system and post's inability to deal with it. Seriously, this is beyond Monty Python level... ;)

Hi all! An alternative option could be this: https://www.macchina.cc/ (https://www.macchina.cc/). It has 2 CAN inetrfaces, SWCAN, K-Line an J1850, and also one optional ESP32 module for WiFi.

So for the better part of last week I engaged into developing an slcan protocol for the integrated Leonardo-CAN device I mentioned earlier (and that I have already fully working otherwise). I first used a ready Arduino project for this some good soul made, but then had to optimize things for speed and I ended up essentially rewriting the whole thing. All this so that I can use / test serial based socket CAN interface for my flasher. It now works and it seems I have hit the serial throughput limit (the device happily connects at 2Mbaud, but it seems the real speed is never higher than 115200). I think we already established that the slcan protocol is wasteful - two characters for each byte to be transmitted, not to mention continuous sending of extended CAN ids with each frame. All in all I got it down to 1:54 for complete flash of my 850k file vs. the 1:19 when I do it with my own waste-less serial protocol. The math also tells me I won't do better than ~1:50 over 115200 baud with slcan.

To the point, motivated by the canable device mentioned earlier that works either in slcan mode, or as a native socket CAN device with candlelight firmware faking gs_usb CAN device, and dealing with the Leonardo's 32u4 chip that supposedly has native USB capability, I am inclined to try the same on the Leonardo-CAN. There are some native USB examples for the hardware capable Arduinos, but the problem is I know total JS about native USB programming (so far), so I am not even sure if that's possible. I was wondering whether somebody has any experience that would help, or simply would like to help develop this. The stuff I did for slcan I plan to release sooner or later.

It is doable, I now have a skeleton code that makes a proper CAN-USB device out of my Arduino, makes it recognisable as a gs_usb device on Linux, and I can now receive fake CAN messages with candump generated at the Arduino end. Now what remains is to interface it neatly with the MPC_CAN library, seems to be a piece of cake to finish this.

The bad news is that it required reprogramming the Arduino core, cannot be done as a PluggableUSB library. In practice the core now reads one of the board pins to decide if it wants to be a gs_usb device or the regular Leonardo/ACM device. That is not super elegant, but working. The other alternative is to write a custom Linux kernel module, I looked into this too, but that outgrew me for the moment.

So I managed to make a proper native USB driver for this device, link again for the lazy ones: http://www.hobbytronics.co.uk/leonardo-canbus. I got rid of all Arduino dependencies and made it a clean AVR C implementation. It's fast too. Previously the best I could do was 1:18 time for flashing my ECU using the same device, but with a custom optimised serial to CAN Arduino sketch (or a socket CAN interface on CAN-BUS hat equipped RasperryPI, all the same). Now the time is 0:56, that's almost 30% increase in speed. On an empty bus, on a loaded bus it is previous ~1:30 vs. new 1:04. The file size is 832K and looking at the frame times reported by Linux I won't be able to do much better than this. I tested it enough to be confident and it will be published eventually, only that the C code still needs some TLC, and more importantly I need to identify all licences, people, and such that I stole from writing the code, this will take a while.
 

Fast write speed. my kess v2 via OBD says at least 5 minutes or more. When setting up the motor on the stand was very uncomfortable and lost a lot of time

If we talk about ME7.9.10 I think even the cloned MPPS can do better than this on CAN. I suspect that your setup is the older K-line ECU, in which case 5 minutes is not unreasonable, still slow however, here I was also able to do around 3 minutes (do not remember if less or more, did not record this) on regular KKL to serial connection. And that in theory could be improved - the ECU accepts even faster K-line speed settings (ASM source tells me so), but I couldn't get it to work, the fastest baud that worked for me was 115K.

Yes, K-line

If any one cares: https://github.com/woj76/gs_usb_leonardo

Thanks, maybe someday I'll come to that