Has anyone used the prop1 to convert USB to CAN highspeed (ISO 11898-2)
turbosupra
Posts: 1,088
I am looking at buying a piece of equipment that strongly recommends using the Kvaser Leaf Light HS USB to CAN Bus Interface. If you google it, you'll see it sells for $350 an on up, which to me is absurd for a cable. This reminds me of the cost of HDMI cables when they first came out.
From looking at it for only a few minutes, it appears to just be a simple bit conversion from the USB protocol to the can protocol, but things are usually more complicated than they appear.
Thanks for reading.
https://www.google.com/#q=kvaser+Leaf+Light+HS&tbm=shop
http://www.beyondlogic.org/usbnutshell/usb3.shtml
http://www.ni.com/white-paper/2732/en/
From looking at it for only a few minutes, it appears to just be a simple bit conversion from the USB protocol to the can protocol, but things are usually more complicated than they appear.
Thanks for reading.
https://www.google.com/#q=kvaser+Leaf+Light+HS&tbm=shop
http://www.beyondlogic.org/usbnutshell/usb3.shtml
http://www.ni.com/white-paper/2732/en/
Comments
My code for the MCP2515 is here:
-- http://obex.parallax.com/object/314
Thanks. I'm beyond green with CAN, it all seems mysterious at this point. Your pdf did seem simple
Based on your experience, can you speculate if there is there any practical reason a cable like pictured below would retail for $500 and be sold for at least $350?
I'm trying to figure out if there is something special to this cable, or if I can build it for far less.
Thanks
Kvaser Light Leaf HS
I imagine they don't sell billions of these like other USB gizzmos so the price may never come down to consumer levels.
There is some kind of USB driver for the Propeller. I never worked out if it was finished or how well it worked.
JonnyMac seems to be onto the right idea there. Use USB to serial to talk to some Propeller board and have the Prop drive the CAN bus.
Exactly -- nice pun, BTW.
The parts don't add up but in the business world one must include production overhead in the equation; these are not mass-market items hence will tend to be more expensive than we'd like.
I was lucky enough to be provided a CAN-to-USB adapter by a client; it was in that same price range. At its core was a microcontroller and and the MCP2515 chipset, the same thing I used in my project. That said, it also came with a very nice piece of software. My object includes a Propeller program that is a CAN buss sniffer. I actually needed this with the client project as we were having to reverse-engineer the CAN codes used in an older device (their internal documentation had been lost).
CAN is interesting and the MCP2515 makes it easy with the Propeller.
Lol!
Thank you. This is encouraging and lets me know I had a reasonable high level view of this. The CAN bus sniffer sounds pretty awesome, I wouldn't mind using that either.
This is an important concern and good point. I am going to ask this question to the software creator.
I hope to find out the software uses a generic usb driver and then try to use the MCP2515 and MCP2551 as JohnnyMac did to be able to save myself $300+ dollars.
Is this an adapter for general CANbus use, or are you trying to connect with an existing automotive CANbus network?
You can definitely save big bucks via the Propeller and MCP2515 for a general use, but the automotive CANbus is chockful of proprietary code and trade secrets.
For automotive...
A. Snooping is the easiest. But you do have to determine the transmission rate of the CANbus in operation. Automotive CANbus might use something odd for the sake of proprietary.
B. Active participation presumes that you have something that knows what addresses and what formats will work with the automobile you want to use it for. If you don't have that information, you might spend an enormous amount of time attempting to reverse engineer the code.
CANbus intentionally made millions of address combinations possible... just to allow the automobile makers to create and protect their own proprietary turf. Only the larger long-haul trucks and public transport vehicle coding are requires to be available in the public domain. So you might be paying extra money to have an interface that will play nice with your particular vehicle.
If the USB to CANbus is just a pass-through device and NOT directly involved with the proprietary data, it still is converting CANbus packets into coherent serial packets for the end device.
There is some buffering involved and the end-device expects a certain 'translated CANbus format' (maybe a simple serial terminal program on a PC). You may have to create some code for that. The links you provided have some information... maybe all of what is required.
I'd certainly try the Propeller and MCP2515 to see what it can do. But I would also consider that I might hit of wall due to lack of specifics for the targeted vehicle. Or a lack of specifics about how to shift the CANbus packets to the USB format and vise-versa.
Automotive CANbus has some very shrewd equipment providers that are hard to by-pass with a generic hookup.
Not much development can be done unless you have at least two CANbus nodes (one as a Master, another as a Slave). So you may start out with two Propeller + MCP2515 setups to learn how to fully deploy.
Personally, I have used CANbus with the MCP2151 and the BS2. I have yet to work with the Propeller. But once you have the device intialized, it is quite easy to use.
This is the ECU ... the ECM555-48, ECM-563-48 and ECM565-128.
http://mcs.woodward.com/products/ControlCore/ECUhardware/
http://mcs.woodward.com/support/wiki/index.php?title=Modules
It is likely that the MCP 2151 / MCP2551 chip set will offer you more options.
The only item that may be lacking is firmware that automatically seeks the right bit rate for the CANbus.
I really wonder what is attached to the USB side of the device. You may have software for a laptop, but in might include a proprietary USB driver.. not the FTDI interface. It would seem that the product as a microprocessor included and that might be one that has a built-in USB interface that requires specific supplied drivers to work with it.
Lots of question marks here.
Here is the link to the PDF.
http://www.kvaser.com/datasheets/kvaser_datasheet.php?ean=73-30130-00411-5
Is there any way to tell from the installer software? Maybe by what is unpackaged, or what is assigned by the OS as a driver for the serial device? Without the ECU, I'm not sure how I could see which driver it uses, but maybe I could ask someone to hook their laptop up and then see which driver Windows will have assigned to in, in the device manager? Would that help answer some questions?
Here is the software
http://download.proefi.com/ProEFI_SetupV3.exe
http://www.neweagle.net/support/wiki/docs/Other/Woodward-CAN_Training.pdf
A quote from page 4 says the following, and I believe answers one of the questions.
Unfortunately, I am a Linux user... so a .exe file is of no use to me.
The MotoHawk device appears to just be CANbus interface in snoop mode. You will gets lots of data, but likely be left wondering what it all means. The good applications tell you things like "brake pedal down", "steering wheel to left", and so on.
ProEFI.com is a site for vehicle specific support that interfaces through a CANbus. That is the expensive stuff and virtually impossible to hack.
It seems the Swedish company that makes your Leaf device has a User's Manual Download that either won't work in Linux or won't download to Taiwan.
What are you wanting to do? Do you just want to snoop CANbus? Or do you want to use CANbus to service a personal vehicle? There is a big difference in what you need.
You can go to their site, register, and get the Manual, the Drivers (yes, there are special drivers for this device.. for Windows, not LInux of course), and other documents.
I need to see the documents to determine if the Leaf can be cloned with a Propeller, the MCP 2551/2151 chip set, and a generic serial port interface via an FTDI USB chip (what the Propeller uses). But I have serious doubts that trying to do so with going to work out.
I wouldn't get my hopes up are you are definitely trying to adapt for a software application that is intended for the automotive market... this has long been sacred ground the the high-priced black box CANbus world.
I personally wanted to use CANbus for home automation and have ignored trying to hack into their castle. Years ago I produced a circuit board for the MCP 2515/2551 that will work with any CPU and was hoping to sell it. But I gave up as it seemed almost everyone wanted me to help them hack into automotive setups.
Hacking automotive by snooping an existing CANbus in a car is rather absurd. There can be multiple masters and multiple slaves active. To hack, you would likely have to disconnect all but one slave and mimic the master to determine its addresses and responses. And then you would have to do this over and over again until you got the whole system hacked.
I like CANbus. One can easily have 25 active nodes on one twisted pair of wires that are low voltage. That is ideal for automotive and household due to the extremely low fire hazard and the simplicity of using much less copper. Distance of 1000 meters are possible as well. And so is an extensive security system with multiple perimeters.
I just thing that CANbus and Bosh (or Seimens) managed to build a very strong proprietary moat that made the passenger automotive industry very happy.
It is bad enough to have to hack the CANbus code from a particular make and model of auto. But it seems even more difficult to have a proprietary application in your PC that also has to be hacked from the other end,
The car makers understand that the average mechanic and service department will just pay for the complete package and pass the cost through to the customer. After all passenger cars are the world's #1 consumer product in total dollars spent world-wide.
I want to replace that $350 cable with a $35 propeller cable. Then I can take my PC and write to the ProEfi ecu with my $35 cable, using the software and drivers in windows, interfacing through the $35 cable and writing to the CANbus of the ProEfi ecu.
Did you want me to register and get copies of the drivers and such and send them to you? Maybe automotive hacking is where your "selling" of a product can occur?
Keep in mind that you're going to need a Propeller board (cheapest is QuickStart at $30), and then build a shield for it (my circuit does work, though I never connected it to a car -- just to an industrial HVAC system), then you get to spend a lot of time sorting things out with the software.
In the end, you might conclude that $350 is not a lot to spend if you're dead set on manipulating your car's ECU.
But it wll be up to you to decyper the meaning of all those codes and how to make them work for you.
MotoHawk 'does not define protocol' seems to indicate it does about the same as the Propeller solution, with an added plug to make connection easy to the ECU.
I don't own an auto, and have never tried to keep up with all the specifications and documents. Every major brand passenger car tends to have a different ECU code set and likely to come with some handshaking to identify that it is talking to a unit that is licensed by the manufacturer to modify the ECU.
Your link to ProEFI seems to offer the whole package. If you really want to tweak ECUs to improve an auto's performance.. it is likely you require the software that bridges from RAW CANbus codes to actual meaningful information and commands.
I am a bit wary of what Woodward provides.
Sending me (or us) all the documents and hoping that I (we) will provide the cheapest solution is not going to happen. It is a huge project just for one make and model of auto. And the manufacturer's legal department is likely to put a stop to any cloned products that do not pay royalties.
If you do buying ProELF software, the Propeller with CANbus might work well and save you money, but there is a learning curve and some 'sweat equity' will be your contributions to saying money.
I don't work for Parallax, I just enjoy using their products.
ProELF seems to read and display interpreted RAW data in real time in a Windows environment. The jump from the USB port into their software may only play nice with USB to CANbus devices that they recommend. It ALL depends on their business policy.
They can make it easy to DIY a generic cable, or they can make it nearly impossible.
Cloning the Leaf is another foray in another company and how they feel about protecting their product. It may be quite easy, or very hard. But it will require studying what they do and replicating it in entirety. The fact that they have their own Windows drivers for thier products and NO Linux drivers indicates that they really don't want people to easily clone their product.
I wasn't asking that of you, it sounded like you wanted to look at the documentation and I was willing to email it to you if you wanted to give it a quick look.
As for legality, there is no problem with the legality that I see. Here are the components:
Laptop with licensed software --> Any USB to CAN cable --> Mototron ECU
I am legally purchasing and paying for the licensed software and Mototron hardware, the cable in between them is not proprietary, but is recommended because it is the "most reliable" of the ones tested, by the company ProEfi. Assuming there is not a proprietary driver that the software uses to communicate with the cable, than indeed any cable will work as it is just a translator of bits from one format to another using generic drivers.
This cable is priced and rated for life dependent medical equipment, something of more importance than what I'm doing with it.
But if ProEFI and Leaf are happy to make it difficult for generic devices to work, they can do so. And they may be very hostile to clones.
I dislike the fact that some vendors create high prices by such manipulations, but that is the world we live it. MS and Windows has always supported these kind of niche markets.
Without a clear statement from ProEFI of how it communicates via USB, you could hit all sorts of snags. The Leaf device might be capable of buffering the CANbus data and repackaging it into proprietary packets. The Windows driver for the Leaf device could be streaming packets in both direction with special firmware that makes it all happen seamlessly.
It all goes back to what ProEFI has decided and how much they really need Leaf's enhancements to do a beautiful job.
What you see as a simple adapter from USB to CANbus might have all sorts of quirks that drive the market place to buy the darned $500 USD device. Just the fact that they want $500 retail indicates this is the case.
The only way to really know to to gamble and set up a Propeller with CANbus and try it with an FTDI driver.
Yes, I was willing to look at the documentation... still am. But the fact remains that it likely will not address how to DIY a USB to CANbus. It might just point you towards the 'recommended devices'.
It just becomes a slippery slope where you buy the components to make this work with a Propeller and then are upset that it can't achieve what you desire. CANbus for high-performance automotive has long been a high-cost black box industry.
The ProEFI documentation would be far more helpful than the Leaf documentation.
And ProEFI does have a Forum that might really give you much better solutions that we can. It is their product that you want to get the best use from. And you are their customer.
http://proefiforum.forumakers.com/
I actually did get a User's Manual download for the Leaf. It just was slow to arrive.. a bit odd.
The Leaf inserts a 32 bit timestamp, somehow and somewhere. That may be the snag. Also the data rates seem a bit fast at 12Mbits per second.
The timestamp may just be inserted every 100us. One unit is software controlled. And it seems the more you pay for, the faster the response.
The FTDI USB that Parallax uses is set up for 8bit serial, and I suspect this device is sending and recieving 32bit serial.. but I cannot exactly prove it. It just makes sense as the time stamp is 32 bits or 64 bits. Breaking all USB data down to 8 bits would just make everything go slower.
UG_98035_kvaser_leaf_userguide.pdf
I have been pondering this USB to CANbus device.. as a generic project.
I am thinking I can create something that I can use in Windows or Linux with GForth. That is worth the effort for me to start building and testing stuff.
While I can not guarantee that such a device will work with ProEFI or your Moto-Hawk ECUs, I can build a Propeller based interface that will pass CANbus in both directions initially via a Serial Terminal application such a Teraterm or PuTTY.
So I can have something that proves it is working and communicating in both directions.
Baud rates of 9800 or 19200 are common, even 115,200 -- which I can do, but the Leaf seems to want' to generate a non-standard 'bit rate' of 12M (I presume that is 12,000,000 bits per second or 12,000,000 baud) or is hiding a standard baud rate from the user. That is just one of the reasons I am wary of the ProEFI/Leaf solution being easy to replicate.
I can even have the Propeller generate a 32 bit timestamp every 100useconds if that is useful, or I can leave it out.
But I can NOT be sure of two items.
A. That the ProEFI software will ever directly recognize the FTDI USB driver and a standard baud rate with RS-232 full-duplex at 8-n-1. (Why so? Well this guys are vague in their documents).
B. That the unit will able to configure properly to any ECU, unless the CANbus information on which addresses, masks, and proper bitf rate are openly available to allow proper configuration of the MCP 2551/2515 chipset.
+++++++++++++++++
Since I have multiple MCP2551/2515 boards of my own design that will work with the Propeller, I can get something that works (and that will be useful for me in other projects).
It will be a working and configurable USB to CANbus device. I just can't promise that it will work in the context you want to use it.
What might that be good for?
All sorts of industrial applications. I am even thinking a Haunted House for Halloween might find CANbus an ideal way to minimize the amount of wire to all the special effects throughout. After all, this is RS-485 driven and that means it can go 4000 feet on a pair of tiny wires.
In other words, this is an ideal solution for building your own amusement park, or brewery.
JonnyMac's code makes getting started rather easy, but it is configured to primarily operate in Snoop Mode. In the context of an automotive ECU, you will definitely have to use Active mode.
Snoop mode will watch traffic between two other units that are conversing on a CANbus. It is very useful to get the specific bit rate required for communications. But since it seems to me that there are NOT two other units in this context, at best it might see one peep out of the ECU. And at worst, the ECU might expect it to talk first and remain silent.
Of course, that presumes that the ECU is not just providing a port that listens to all the other things connected to it. If it allows you direct linkage into the whole of the ECUs connection to other CANbus devices, there might be a huge amount of activity.
There is no way of knowing without actually hooking up to an ECU and seeing what it does.
++++++++++++
Other stuff,
The MCP2515 offers multiple TX and RX channels. That might be useful in some contexts; but to start out, you only need one of each. Keep it simple and it will get easier to manage.