CAN bus

Lots of technical info on the compatible "USB CAN Adapter" from Grid Connect:

http://www.gridconnect.com/usbcanin.html

Good luck, I've found it difficult to do much with the info coming from the CAN bus. Perhaps with a concerted and shared reverse-engineering effort, we could learn enough to do something useful. I'd love to see folks with CAN programming experience chip in, it can't be *that* hard. But I have to admit, I'm over my head in this realm.

Arlo

If the D-sub connector is wired as per the standard, then we will have this:
9 Pin (male) D-Sub CANbus PinOut
Pin # Signal Names Signal Description
1 Reserved Upgrade Path
2 CAN_L Dominant Low
3 CAN_GND Ground
4 Reserved Upgrade Path
5 CAN_SHLD Shield, Optional
6 GND Ground, Optional
7 CAN_H Dominant High
8 Reserved Upgrade Path (error line)
9 CAN_V+ Power, Optional
...So should be: signal Hi and signal low on 7 and 2 respectively. pin 3 as ground and 12v on pin 9.

all unconfirmed as yet.

I am assuming that the D-sub connector you are referring to is the one at the back of the glove box. If so, then it does not appear to be wired in a standard fashion. There are three wires connected to the back of the connector and they are buried under a glob of silicon mastic (presumably to keep water / damp out).
It is my impression that this connector is being used in the same way as the 'old' series computer connector. I have seen this connection method used on Closed Circuit T.V. multiplexers for the purposes of 'Customising' the internal software to suit a customers specific needs. The only computer requirement was a simple Comms programme such as Procomm or Telix and a cable and serial port on the computer.
Quite how this ties in with a can bus I don't yet know.
Sandy

Does anyone know what exactly is possible when dealers connect their computer to it?
I guess they can
-upload/install new firmware
-read out log files (?)
-?

I had a chance to see the service guy working with his laptop on my Vectrix. The laptop had a software running that displayed lots of red and green fields. It seemed like that the software displayed real time sensor readings, voltage, temperature, lights, controls....
The software was used to upload new firmware and I guess to download log files from the vectrix.

The Vectrix software does not allow the technician to download very much from the bike. It has realtime displays for battery and m/c temperatures, voltages and what software is on the bike and not a lot else - the programmers can access more info but the tech guys do not get told much. They can download information about the state of the batteries and how far you travel on a charge. If there is an intermitant fault the software will not show it unless it happens while the computer is attached.

I had a chance to see the service guy working with his laptop on my Vectrix. The laptop had a software running that displayed lots of red and green fields. It seemed like that the software displayed real time sensor readings, voltage, temperature, lights, controls....
The software was used to upload new firmware and I guess to download log files from the vectrix.

I'd steal that guy's laptop the first minut he'd turn his back to me hehehe I'd kill to have my hands on software like that (not really,...or would I??)
I'd probably attach a netbook permanently to the dashboard, it would look even weirder than the Vectux HAH

I had a chance to see the service guy working with his laptop on my Vectrix. The laptop had a software running that displayed lots of red and green fields. It seemed like that the software displayed real time sensor readings, voltage, temperature, lights, controls....
The software was used to upload new firmware and I guess to download log files from the vectrix.

I'd steal that guy's laptop the first minut he'd turn his back to me hehehe I'd kill to have my hands on software like that (not really,...or would I??)
I'd probably attach a netbook permanently to the dashboard, it would look even weirder than the Vectux HAH

I can already see the headlines: "Vectrix engineer kidnapped and laptop stolen during standard bike maintenance". Vectrix beware, your service guys are very much wanted.

The Vectrix software does not allow the technician to download very much from the bike. ... They can download information about the state of the batteries and how far you travel on a charge. If there is an intermitant fault the software will not show it unless it happens while the computer is attached.

Can it be used to "calibrate" the meters, indicators or other devices?

Here's the project that inspires me to think it should be possible to reverse-engineer the Vectrix:
http://www.vassfamily.net/ToyotaPrius/CAN/cindex.html

All of the various subsystems on the vectrix are interconnected using the serial CAN bus. This is how all modern vehicles work, it dramatically reduces the vehicle's weight by eliminating huge wiring harnesses. Each of the subsystems has a microcontroller that talks to various "local" sensors and communicates to the main system controller via the bus. On the Vectrix, this includes the motor controller, battery charger and monitors, a main system controller board, and possibly another dedicated to the instrument cluster. Not sure if these are each on separate physical boards, but logically, at least these are separate subsystems, there may be more.

There are two ways to hack this architecture to change a vehicle's behavior. The more difficult one is to update the code on the microcontrollers to implement new programming. (Acceleration, top speed, etc.) The other is to intercept the signals at the system interconnects, filtering and/or injecting modified CAN signals to change the vehicle's behavior.

Either approach requires significant understanding of the signals on the bus, but as the Prius project has shown, the latter is iminently doable given enough data collection, analysis, and gear. I can imagine using a Linux microcomputer that records CAN activity, and some way to correlate with the timeline of each ride.

Good luck, guys!

Arlo

"Can it be used to "calibrate" the meters, indicators or other devices?"
The battery level display can be calibrated but the new software does that.

"I'd probably attach a netbook permanently to the dashboard"
apart from being able to see the power consumption you would not gain much, the biggest danger would be if the connection was broken you might need a new motor controller as it could need 'low level' reprogramming.

Here's the project that inspires me to think it should be possible to reverse-engineer the Vectrix:
http://www.vassfamily.net/ToyotaPrius/CAN/cindex.html

THAT's what I'm talking about (look at the movie!)! And as you can see, it must be doable with reverse-engineering.

What I'd like to see is i.e.
- AMPS
- Battery state of charge, voltage and temperature
- RPM
- Brake values.
- record "blackbox" style
-..

Is it usefull?? probably not, but I'm just that kind of weirdo I guess
I bet it won't take long for somebody to come up with a solution for this :p

Did a little research on the Can bus and some prereq's exist.
One happens to be the format that is used to communicate. The
can bus architecture has several different formats. Early it was
1.x which was updated to 2.0a (11 bit ID) then 2.0b (29 bit ID)
without going into too much detail, it is not possible to use a
comm's program (i.e. Procomm, hyperterm or any other) to read
what is going on the Can bus. There is a definite framing protocol
that needs to be interpreted. So one must have a can bus adapter
and an analyzer type of program. Then as previously indicated
one will need to figure out the id's for each of the devices on
the net so that the associated data in that packet can be interpreted
and given some meaning. I also found a really interesting program
called "CanCapture" - seems like a comprehensive suite but the
cost is rather intimidating at 995.00us.

I did some deep digging in the treasure trove to help the CANBus discussion along....

On March 19th, 2008 my scooter had these versions installed:
ICM: REV 1007
Instrument Cluster: Rev D
Battery Charger: REV 2010
Motor Controller: REV 1012

http://visforvoltage.org/forum/2206-vectrix-owners-new-amp-prospective#comment-18266

Wonder how I knew these details?

Because I took some photos during the fuse repair and software update!

(Click photos to enlarge)

You can see some of the options and functions available in the Scooter Diagnostics Program.

And I believe that it is perfectly legal to publish these photos and use the information gleaned from them...

If the moderators disagree with this opinion of mine, then please feel free to delete the links to the photos.

One important detail obvious from the photos is that the software transfers .hex files from the computer to the scooter. That might give those readers with CANBus programming experience some useful ideas, I hope.

Nice one Mik!

take a look at this:

http://www.hexworkshop.com/

Guys - I don't think Hex is significant.
Hex is short for hexaDecimal - or base 16
Simply means you can represent a number below 16 in a single digit
(beyond nine instead of going to 10, a one in the tens column and zero units, you use A, decimal 11 is hex B, up to F for 15)
Hex is simply a way of representing numeric values.
It is probably a machine code file, directly executed by a microprocessor.

take a look at this:

http://www.hexworkshop.com/

That is interesting. But I do not understand this stuff yet...

Could the Hex files be reconstructed by datalogging the CANbus traffic whilst charging or riding the scooter? I doubt this, but don't know.

And if one did have a correct Hex file, would it be possible to decipher what it means and how it could be changed without breaking stuff? Could data gained from a data logger during operation of the scooter be used to decipher the hex files? Or would they be quite meaningful to a programmer anyway?

It appears very likely that not only the ICM programming is contained in a hex file, but also the charger and motor controller instructions and instrument cluster programming.

I don't know why the "Battery Monitors" 1 and 2 are not available.

The red "Fuel cell" and "Tilt Controller" are obviously related to not yet existing models.

Please chime in if you have any idea about CAN programming!

Guys - I don't think Hex is significant.

Quite the opposite, as Wikipedia explains:

A hex is a magical spell, usually with malevolent purposes such as a curse. The term is derived from the German word Hexe for a witch.

Now, THAT explains a lot! HAHAHAHA!

But maybe this one is closer to the truth:

Intel HEX is a file format for conveying binary information for applications like programming microcontrollers, EPROMs, and other kinds of chips. It is one of the oldest file formats available for this purpose, having been in use since the 1970s.[citation needed]

The format is a text file, with each line containing hexadecimal values encoding a sequence of data and their starting offset or absolute address.

There are three types of Intel HEX: 8-bit, 16-bit, and 32-bit. They are distinguished by their byte order.

I know nothing about the Vectrix, but I am a firmware programmer by trade and spend all day hip-deep in protocols so perhaps I can shed some light.

CAN bus is a way for various components in a vehicle to exchange information much like the postal service exchanges letters. The postal service doesn't care about the contents of the letters only where they are coming from and going to. CAN bus cares a little more than this in that the messages must be exactly 8 bytes long as if the postal service had imposed a rule that each letter can only be 8 characters long, but on the other hand you can send as many as you like as fast as you like for free. Given enough messages I could send you the Oxford English Dictionary.

If you did hook up an analyzer to the bus and watch the letters go by the analyzer would be able to display the contents of the letters, but the postal system you are looking at happens to be in 12th century Rome so unless you speak Medieval Latin you're out of luck. It is up to each manufacturer of a CAN bus device to publish a Medieval Latin to English dictionary so you can understand the messages. Maybe with some tenacity you could decode some of the messages on your own. For example by isolating the throttle, assuming the throttle is a CAN bus device, you could watch the CAN bus messages as the throttle was twisted and perhaps learn what a "throttle position" message looks like and what it means. The easiest thing for the analyzer to do, however, is just to dump the raw information to the screen. The language common to all computer communication is numbers and computer types are most comfortable with numbers is base-16 or hexadecimal. For example you could see: 0x64617665 in a message. (It could just as easily be written in decimal: 1684108901.) It's just a number. If you knew this was numerically encoded English you might discover that it is actually: "dave". To CAN bus, though, its just data. Without the decoder ring for your particular CAN bus device you're not going to be able to understand very much.

Some of the devices on the Vectrix are assuredly micro controllers. These will be little computers running little programs stored in their own little brains. I suspect these stored programs can be changed through the CAN bus. There is likely a message such as "begin brain surgery". The messages that follow contain a new program for one of those micro controllers. When it comes to a computer brain, however, there is only 1 bit difference between Einstein and a doorstop. Does this sound like the sort of thing you want to be messing with? (To throw more confusion into the mix, these programs once compiled and encoded tend to be stored in files called .bin or .hex. This might be the "hex" the original poster was referring to.)

I do this sort of programming on a daily basis and I still get it wrong much more than I get it right. The advantage I have is I can make a copy of the old brain before I get started. If I had a Vectrix I wouldn't go anywhere near that bus. Without buying a package from someone who has done this before you're odds of making anything better are very low. Your odds of turning your Vectrix into a very heavy push-toy are much higher.

nice one dave .kev

Hello Mik, your bike has older temp. sensors - the newer ones show up on the Scooter Diag screen. The ICM, m/c and charger are all hex files the instrument cluster is not. The tilt controller is fo the 3 wheel bike which has different software.

Excellent, DaveW, thanks for translating into English. Most of us do not have the background or skills to do *anything* with this data, so it's a waste of $260+ to even purchase a CAN-USB adaptor. But I'm hoping that there will eventually be a few Vectrix riders with enough technical knowledge and motivation to reverse-engineer this protocol and figure out how to do approach #2, above.

I agree completely that it would be insane to think that we could copy and/or modify the existing firmware (hex) to do anything useful without access to the developer's tools used at Vectrix engineering. But to understand and filter CAN traffic at the interconnects between the various controllers is iminently possible, and much less risky.

I guess we need to wait 'til DaveW gets a Vectrix to begin. We can have a fundraiser and help him out!

:-)

Arlo

Based on what Davew said (thanks Dave!),
I guess we'll have to wait for one of the Vectrix-service-guys to accept a bribe (or how do you say that?) and just give us the software :-)
But then again, I wonder how the guy with the Prius did what he did...

I believe that, as early adopters, taking the risk and all.. we should be granted the software anyway!! :-p
(dreaming out loud that is..)

Thank you for these excellent explanations, Dave! Well done.

I have some more specific questions, now, if I may:

the messages must be exactly 8 bytes long ..

Does this mean that the hex file must also be the 8-bit type? Sounds like it to me when I read the part of the Wikipedia entry I quoted above:

There are three types of Intel HEX: 8-bit, 16-bit, and 32-bit. They are distinguished by their byte order.

the postal system you are looking at happens to be in 12th century Rome so unless you speak Medieval Latin you're out of luck. It is up to each manufacturer of a CAN bus device to publish a Medieval Latin to English dictionary so you can understand the messages.

Am I right assuming that the addresses in medieval Rome can be deciphered, though? And that a map could be constructed that shows all the delivery points and how many letters they send to whom and when? And who has priority to send letters first if the postal service is busy?

Without the decoder ring for your particular CAN bus device you're not going to be able to understand very much.

What is the "decoder ring"? The Canbus devices in the Vectrix (or at least some of the ones in the Vectux) can be inspected. Below are some examples from the Temp sensor PCB's located in each battery (the one shown also does some voltage splitting for battery voltage monitoring):

It's a bit hard to see on the photos, so here is a transcription:

PIC16F677 -1/SO (e3) 0712208 -------- (next to temp sensor cables, 10 pins x 2)

MCP2515 I/O(e3) 07145C2 --------- (9 pins x 2)

R100BTB71 --------- (Silver oval object)

MCP2551I SN(Symbolincircle)0710 (Symbol)1Y9 ------- (4 pins x 2)

This has been discussed a bit on Endless Sphere as well, people interested might want to read this thread: http://www.endless-sphere.com/forums/viewtopic.php?f=7&t=8136&start=0 It also contains links to pages where a similar CANBus project for the Toyota Prius is described/developed.

Some explanations regarding these chips from ES:

looking at those chips.
MCP2551 is a buss driver, it generates the proper voltages and currents to drive a CAN buss.
MCP2515 looks like it handles all the low level packet formatting, acknowledges, retry, CRC, etc. (assuming CAN has all that)
the silver can is a crystal, it provides the clock frequency for everything.
PIC16F677 is of course the microcontroller. Google it's datasheet for the gory details.

So here is the next question:
Is the Medieval Latin programmed into these PIC chips at the chip factory, and therefore available in their published specifications?
Or, asked the other way around: Does the Vectrix Scooterdiagnostics software speak the Medieval Latin dialect of those chips, or are those chips potentially multilingual when they leave the chip factory, and are later programmed with the Medieval Latin that Vectrix engineers have invented?
Or asked simpler: Who has the dictionary? The chip manufacturer, or Vectrix Corp?

I do this sort of programming on a daily basis and I still get it wrong much more than I get it right. The advantage I have is I can make a copy of the old brain before I get started. If I had a Vectrix I wouldn't go anywhere near that bus. Without buying a package from someone who has done this before you're odds of making anything better are very low. Your odds of turning your Vectrix into a very heavy push-toy are much higher.

I agree. A good (working) backup of the hex files (or a Vectrix dealer nearby who can re-install them) would be essential before messing with this stuff!

Hello Mik, your bike has older temp. sensors - the newer ones show up on the Scooter Diag screen. The ICM, m/c and charger are all hex files the instrument cluster is not. The tilt controller is fo the 3 wheel bike which has different software.

Thanks.
Does that mean that there can be either of three different types of temp sensors in the VX1?

I know that my Vectux has the temp sensors that were the "Newer" ones in early 2008 and I saw the older (oldest?) ones in another Vectrix around that time.

Apparently Vectrix Australia have been unable to obtain "Improved batteries" that have been available elsewhere since mid-2008 (it's hearsay, I cannot vouch for it). That might refer to the newest temp sensors which you say show up on the Scooterdiagnostic GUI.

Vectrix can invent their own language.

However, they might use some standard commands (words) if interfacing to CAN devices (like a CAN Throttle) made by others.

And, they might have adopted some of the "standard" conventions used in the auto industry.

There are two versions of the sensors, the newer ones have a blob of sealant on the chip on the board that attaches to the battery.
I have to be careful what I say due to a "gagging" agreement so I can not comment on battery supplies to Australia!

Vectrix can invent their own language.

However, they might use some standard commands (words) if interfacing to CAN devices (like a CAN Throttle) made by others.

And, they might have adopted some of the "standard" conventions used in the auto industry.

So, where is the line drawn between "proprietary" and "conforming to convention"?

Good morning,

just a few words to point a CAN BUS read/write tool on a french website :

http://www.totofweb.net/robots-projet-65.html

Cheaper than a commercial one and seems to be well designed.

This page has been added to the Vectrix Collaborative Handbook, so please stay on topic!
.

.

@ Arloguay:

Lots of technical info on the compatible "USB CAN Adapter" from Grid Connect:

http://www.gridconnect.com/usbcanin.html

Good luck, I've found it difficult to do much with the info coming from the CAN bus. Perhaps with a concerted and shared reverse-engineering effort, we could learn enough to do something useful. I'd love to see folks with CAN programming experience chip in, it can't be *that* hard. But I have to admit, I'm over my head in this realm.

Arlo

Have you tried out this adapter? Or anyone else?
I ask because there are two versions of the Can-USB Adapter offered on the Gridconnect website: Either with "Isolation: None" or with "Isolation: 500V +$70.-"

Is the more expensive isolated version needed for the Vectrix?

Could the less expensive version be used on a Prius?

Under which circumstances would it be worth it to spend the extra $70.- ?

.

.

One also needs another cable to connect the adapter to the Vectrix:

And this Can 2m cable also comes in two version to make things more difficult: Either with or without "terminators". These terminators seem to be 120Ω resistors in the DB9 connectors. I don't know how many resistors.
And I don't know which cable is needed for the Vectrix.
Here is some advice I got from Gridconnect:

Basically a CAN network segment needs to always be terminated. You say you are plugging into a scooter. If the scooter interface as well as the interface that is going to be plugged in at the other side of the cable is terminated then you dont need termination. Otherwise you need terminiation.