# ixxat USB-to-CAN compact & Sevcon DLD flashing

Would this USB-CAN adapter possibly work? Looks to be Galvanically isolated to 2500V RMS!

I've actually talked to this seller. Nice guy located in the Bay Area. He was even willing to meet and do a little R&D testing to see if his hardware would work for my application. His device supposedly interfaces with Raspberry-Pi. I wonder if there could be a way to set it up with Raspberry-PI and a small LCD display to use on the road for tweaking settings like regen and throttle curves etc. I guess the Raspberry-Pi would have to run a program that could just edit specific lines of code in the DCF file. We would just have to find the lines of code that controlled certain things and figure out a way for the Raspberry-Pi to edit them.

Its very simple.

You hook up a sniffer like that and record the CAN packets as they go into the Sevcon.
There will be some preamble, same every time.
After that there will be a set of data that has an address and values.

Big picture you want to set data to 0x00 at location 2800 Sub0

All that wont be human readable without the conversion table.
Conversion table is the agreement of how data is unpacked on both ends.

Example: 12.34V
Ok... how do we represent that as a Hexadecimal number which is round by definition?

Well... we can have 0x00 to 0xFFFF.
Thats 0 to 65,535... or "64k" as most know it.

If the number can only be positive that simplifies things.
To maximize resolution... you take the greatest value the number can be... say 20V... and divide that by full resolution.

20.00D / 0xFFFFh = 0.00306091215d
Thats full resolution
Divide it by two orders of magnitude to grab the 0's after the decimal point... (this is why PRECISION is important to pay attention to! 20.0 != 20.00 Those are different numbers!)
0.306091215d (Volts)

Now go back and divide our original 12.34V by our magic number 0.00306091215d
We get 3920.40000233d

Convert that to hex and we get 0x0F50
0x0F50 is the number you would see in the CAN communication.
0.00306091215d (Volts) is the conversion factor that YOU WOULD ONLY KNOW ABOUT IF YOU HAD THE KEY... or the time to reverse engineer.

We can multiply, store, and divide exponential numbers in firmware and in software.
We can not efficiently transmit those same numbers... in a way that scales and is not human readable.
You need to carry sign, data after decimal point, units, and sometimes more.

We now simply multiply these two values to get the value of interest.

0x0F50 to decimal = 3920d
3920* 0.00306091215V = 11.998775628V

Original number: 12.34V
Number after transmit: 1199.8775628V (12V after shifting the decimal twice and rounding)

12V is equivalent to 12.34, with a rounding and transmit error of one bit, which we agreed was 0.306091215V
so

12.31V to 11.69V is our range of output.

And.... drum roll please... this is why numbers get a little FUBAR in the sevcon when converting and transmitting.

This is the level I am operating at.
I can show you the atomic makeup of the tools we are using.
Its up to you guys to fiddle around and figure out which tool will implement this.

DVT expects certain function prototypes to be exposed.
Whatever driver exposes those function prototypes will work.
This is why an IXXAT clone works.

In the same nature... anything that speaks the CAN language at the right pace in the right order will also work... but there is "a lot of work to make that work"
Layer upon layer upon layer of complexity.
Hundreds of engineering hours to repeat or refactor.

-methods

Methods, Awsome summary again!

What you do is an enormus contribution to the community for those who want to better understand these famous Sevcon!

Thanks for posting.

Doc

I did oversimplify a bit... but thats the part that most people get hung up on.
The dictionary that translates what is on the CAN bus to what it means at the Controller and GUI sides.

Yea... the data could be sent human readable... and it really would not burn up that much more bandwidth... but... most people want CAN to require a "keystone" and to maximize compression.

I was just picking at the master for details of how these things are implemented in Python.... out of interest in what it would take to build functionality for a lower cost, higher quality CAN box.
Under a week of work for someone with the time and access.

Generally Speaking:

As you know Sevcon conforms to their flavor of CANopen
CANopen libraries are available free online for python.

If you think of it from a systems perspective...

* GUI where we collect user input and display user input
* Translation layer to error check and format incoming data, and format outgoing data, strictly at the low level (filter spaces, trim leading zeros...)

Now we have data.
What do we do with it?

There are only about 5 things you can do.
To simplify:

You can send data, of a particular type, to a particular place, and get confirmation.
You can request data, of a particular type, from a particular place, and error check it.
You can accept incoming packets sent asynchronously
There are different methods for doing these things... NMT, SDO, PDO, SYNC, TIME, EMCY

https://en.wikipedia.org/wiki/CANopen

You can hammer out a DLD or DCF flash - and this can be build out of the above or hard packed together for efficiency.

I have not done it for this particular application.
I have been exposed to it and the development of it back in the day.

If I were a benevolent rich guy I would just build a spoof-driver to trick Sevcon DVT into thinking it was talking directly to the IXXAT... then massage that data into looking like what a cheaper CAN device expects at its driver level. Then we could use DVT with cheaper boxes... as well as existing Python scripts hard coded to the IXXAT.

-methods

Someone else could build a Python CAN DEVICE library to replace the existing library.
Perhaps a thousand lines of code (a bird said in my ear)
This would then make existing Python scripts work that currently work with IXXAT.

Doing it the way I described involves all sorts of windows wizard stuff.
At a minimum the ability to put together proper DLL files.

Layer by layer:

Sevcon DVT is calling functions provided by the IXXAT libraries. You can find out these library names and the functions within are documented with function prototypes (probably 100 when you need 10).
You would have to produce a DLL (or something like that) for DVT to call on. Name it the same and over-write existing files like all the software hacks do.
Inside... you would need to do the same thing DVT is doing... call the functions in the supplied driver for whatever CAN box you want to support.

At this point in time, from my naive perspective, it would need to be supported device by device... until such time as complexity is masked from us at the driver level... or until Sevcon opens up the way they output data.

Look for things that talk about being CANopen compliant. Thats a good first step that may lead you to a solution that could work.

Or then... of course... there is the bruit force attack.
You could always just record every possible permutation of communication and regurgitate

Been there, done that. Works in a pinch for a limited set of controls. Like... ARM. DISARM.

-methods

Starting at the hardware interface and working back:

Python IXXAT

Python CANopen

Ok, we want IXXAT to go away.

On that page are supported modules:

CAN Interface Modules
Socketcan
Kvaser’s CANLIB
CAN over Serial
IXXAT Virtual CAN Interface
PCAN Basic API
USB2CAN Interface
NI-CAN
neoVI Interface
Remote
Virtual

First step... see if something cheap is on the market that is on that list.
I have used a few. IXXAT, PCAN, NI-CAN

Of course if someone wanted to dangle steak in front of me... I would refactor all of it out of Python and into National Instruments LabView... but thats just because I am an NI whore.

I wrote one of the original CAN interfaces in LabView for communicating on the Tesla bus to a component listed in my LinkedIn. Got in some trouble over it too as... I WAS NOT TOLD I WAS WORKING BLIND... but rather was told I was working on project ABC and that everything I had was "dummy data". WTF... but that was coming up on a decade ago... so... so be it.

My advice - dont work blind.
If an employer cant tell you what you are working on... dont work on it.
You never know... it might actually be a evil weapon of mass destruction.

Yes I actually knowingly worked weapons engineering for a very long time.
I never fielded a weapon.
I did learn a whole hell of a lot of what is needed to make things work that are going into harsh environments.

Most of my work was Systems Engineering and Test-n-measurement.
Emulators, simulators, dataloggers.

Making things click and clack and go bang.
Lot of good it did me now... cant even find a job picking up dog shit at the park

Sigh... if bills were paid it sure would be nice to refresh on network layers. Its really a huge body of obnoxious information. Super non-useful in the day to day of things... but becoming much more relevant as we settle on standards. Early on... its heart breaking... as you master things that get dropped. As time goes on, and large companies or groups combine forces, it becomes much easier to make the investment.

Arduino is a great example.
Know how many uController codesets I mastered before Arduino?
Grrr... waste of time.

High level is the way to go. Thats why I love LabView.

MIT App Inventor rocks the Android world for the time being from my perspective.
Write you a Bluetooth compatible Android app in like 15 minutes. 8)

Not that I couldn't do it with one of the 25 other supporting IDE's... its just a matter of KEEP IT SIMPLE STUPID.

And then there is Python... which I am still resistant to... even tho it is starting to pan out.
I still just dont trust the compiler to manage that much sloppy shit.
I mean... once you have seen the sausage being made... (I have made compilers) you really lose trust in the compiler and understand better why things are so strict in something like C++.

-methods

Great thread. I have been tinkering with my Sevcon size 4 and Motenergy 907 motor. I have a few DCF and DLD files I can upload supplied from various parties if interested.

I somehow convinced Sevcon to send me a license for my newer version DVT. This was good however I was a little short sighted and installed it on my desktop instead of a laptop. So limiting my field changes and testing quite significantly... cant really fit my PC and an AC supply on my test vehicle. I have tried to find a working version of the older DVT software? - where no license key is required - so that I can be capture some live data with a laptop out in the field.

I also thought I bricked the controller after it stalled loading a DLD file - managed to figure out how to exit the bootloader - glad to know I'm not the only one. If only this thread was around back then.. would have saved me some stress!

We have been having a lot of trouble supporting customers in the field who *think* they have a working version of DVT when in fact that have a non-useful version of "DVT Customer"

I have heard... on the grapevine... that certain old versions of DVT are kicking around that dont phone home.

I have never been a supporter of limiting distribution of tools. That said - I am not in a position to distribute any software.

I will try my best to get legitimate access for every qualified individual who needs it.

-methods

Doctorbass said:
4- My actual main problem with sevcon programming is: motor overcurrent that make cutout at 1/3 of the drag strip!!.. and i hate that as i feel pretty shy when it happen and it does not make any good publicity for EV!!

Apparently we need to set the torque map to full torque at every rpm and then to go for a test and record the run and then place the torque just a bit above the obtained torque on the graph... I need to make more experiement regarding that!..

Doc

Doc, have you guys had any updates on this condition of cuting out 1/3 down the strip? We had a similar issue with a sevcon, but our would sometimes cut 2/3 of the way down.

I have limited experience... but what I did was:

* Max out the current limits!!! Set them to 420 or whatever.

* Set torque limits on the curve

When I tried to set a phase current limit in Sevcon it just faulted out on me.

Anyway - it seems that Sevcon wants to bounce off of calculated limits before hard limits

-methods

Jay64 said:
Doc, have you guys had any updates on this condition of cuting out 1/3 down the strip? We had a similar issue with a sevcon, but our would sometimes cut 2/3 of the way down.

Can you give specifics?

DCF File in use
Specific Controller size 6, 4, etc
Conditions under which there were no problems, then problems... like... maybe motor cold its fine, motor hot it trips...

Looking for multiple variables going into the Sevcon Ether resulting in some sort of poorly reported final error.
Sevcon is known for doing a poor job of verbose error reporting.
Yes it is verbose... but often misleading... I understand as its a short-cut during development to just vector out on an easy error.

Those I know who have very refined systems got there by spending a lot time on the dyno as well as putting a lot of people on identical bikes running different styles and addressing the loose ends thread by thread by thread. Tedious for sure... but converging on something very nice.

Sevcon maybe not the best choice for a small operation
What other controllers meet requirements???
Even if a bit larger and a bit more weight?

thanks,
-methods

If you dont have DVT this is much more difficult
The customer verison of DVT (or at least some of them) dont allow this change.

First you have to determine what your offset should be.
You could do this mechanically, with a scope, with DVT, with LabView, with a ClearView, with CAN in hex, with Python...

I can modify it
Send it back... and you can use the customer version to flash the DCF

If you have not yet tuned the encoder value... your first step is to find a way to "test" values.
To do this you only need to know where that value is stored in the DCF where YOU CAN MANUALLY SET IT if you know how to back-calculate the hex value.

Since someone pissed me off in another thread... I will outline that here as a calming exercise (back in 5 minutes...)

-methods

Search for Encoder.
Seek until you find something like this:

[4630sub10]
ParameterName=Encoder offset
ParameterValue=0xfecd
ObjectType=7
DataType=3
AccessType=rw
LowLimit=-32767
HighLimit=32768
PDOMapping=0
DefaultValue=0
;SEVCONFIELD OBJECT_VERSION=1
;SEVCONFIELD ACCESS_LEVEL=4
;SEVCONFIELD SCALING=0.0625
;SEVCONFIELD UNITS=Degrees

Note: There are two encoder offsets. The fist h6mited range. The second is the one we will modify here.
Note: This is the DCF I use. I pulled it off a Zero bike. You can pull any DCF off any Sevcon at any time

Note the limits, thats your range.... respect the range as that gives you polarity (negative or positive
Note the Scaling... 0.0625
Note the value... 0xfecd

65229 is the decimal value of 0xfecd
4076.8125 is what you get after multiplication with the scalier...

Ok... what is 32768 in hex? 8000

thats a round number right?
Whats 8000 x 2? 16K...

Whats 0xFFF in decimal? 4000
Not big enough to do 16K right?

So thats why they use 0x0000 to 0xFFFF
Thats how many hex digits you need to scale +/- 8K

if 0x0000 relates to -32767
if 0x???? relates to 32768

Now you are getting closer.
You know you are looking for a non-insane value yes?
Like... -30, 28, 0, 18... something like that

Now go try to make an Excel conversion to give you proper hex output for given encoder value.
If you cant try two in DVT (to make this trivial exercise...) you need to do some mental exercise

Dont read next post till you get it.

-methods

Here I am trying to show you how to reverse engineer CAN packets...

Not just give answer to this specific question
Go work on it... come back later.

-methods

[4630sub4]
ParameterName=Encoder Offset
ParameterValue=0x0000
ObjectType=7
DataType=6
AccessType=rw
LowLimit=0
HighLimit=46080
PDOMapping=0
DefaultValue=0
;SEVCONFIELD OBJECT_VERSION=1
;SEVCONFIELD ACCESS_LEVEL=4
;SEVCONFIELD SCALING=0.00390625
;SEVCONFIELD UNITS=Degrees

In this case the answer is: -19.1875

You really need 2 answers to solve...

If you go at it bruit force you get:

Maximum number: = 0xFFFF = 65535
Recorded number: = 0xFECD = 65229
Maximum Range: = 180 degrees (to -180 degrees)
Scaler = 0.0625

Rude math equates to: (Max - recorded) * Scaler

65535 - 65229 = 306
306 * 0.0625 = 19.125

19.125 is damn close to -19.1875... where we know there will be rounding errors and we have gone at it bruit force without thinking about sign and scale

Thats why you always need two formulas to solve for a two variable problem... but thats just algebra... and we never use that in real life right?

Ok... Lets go open another DCF and figure out what a positive number looks like...

Then lets approximate on what 0 should look like...
Always careful not to be fooled by working from both ends toward the middle
(General Solution solving here...)

Of course... You could just get a clearview ... and enter the values...

-methods

So here is a DCF that was sent to me by a member... (good guy by the way... very patient)

[4630sub10]
ParameterName=Encoder offset
ParameterValue=0x0000
ObjectType=7
DataType=3
AccessType=rw
LowLimit=-32767
HighLimit=32768
PDOMapping=0
DefaultValue=0
;SEVCONFIELD OBJECT_VERSION=1
;SEVCONFIELD ACCESS_LEVEL=4
;SEVCONFIELD SCALING=0.0625
;SEVCONFIELD UNITS=Degrees

The solution to that one is 0 degrees in DVT

Note: DVT has a feature to edit DCF's offline. At least you can view settings... not figured out how to save them yet... but nice to be able to do it

-methods

Here is a UVW encoder tuned to positive 5 degrees

[4630sub10]
ParameterName=Encoder offset
ParameterValue=0x0050
ObjectType=7
DataType=3
AccessType=rw
LowLimit=-32767
HighLimit=32768
PDOMapping=0
DefaultValue=0
;SEVCONFIELD OBJECT_VERSION=1
;SEVCONFIELD ACCESS_LEVEL=4
;SEVCONFIELD SCALING=0.0625
;SEVCONFIELD UNITS=Degrees

Now I have provided a positive offset, a negative offset, and a zero reference.
If you cant solve it at this point... leave it to me (@ \$100/hr) :wink:

If you can, please make a spreadsheet using LibraOffice and place it here.
With that sheet people can make a run
Calculate a new offset (I do steps of 5 degrees... 10 is too much and 1 is too little... thats a hint for you... while finding offset the bruit force way)
Make change
Repeat

Thats for... desperation on the side of the track... and to get something spinning for a demo or bench top.

Uncle methods loves you... and wants you to learn Shtuff.

-methods

Hrmmm....

Pumping 0x0050 into my LibraOffice spreadsheet I get...

0x0050 equates to 80 decimal
80 decimal times the multiplier is 5
5 is the correct solution

(you know I am solving this in real time right? No fugging idea how to do it... lol...)

But we have 3 equations now
And we have 3 solutions

That means we needed 3 bikes (or 3 DCF's tuned to three values... one to positive, one to negative, one to 0)
Thats called the bruit force method
Those who are more advanced... use the "smart method"... which involves keystones, insider info, previous experience, or whatever.

Same principle applies to any CANopen or any kind of protocol that works on a packed data principle.. where you have 4 hex digits to represent an analog value that is +/-
And where you want to pack and depack quickly
Where you need check sums and general solutions

Ever try to pack and unpack gnarly CAN without using a method like this?
It happens
It sucks

-methods

Ok... spent an hour trying to solve a different riddle...
back on this

So we are working with the matrix:

5
0
-19.1875

Corresponding to

0x0050
0x0000
0xFECD

Scaled by

0.0625

Centered on 16 bits of binary data

5 lands on the far left
0 lands on the maximum far left
-19 lands on the far right

Sounds like they are working toward the middle from the ends...
So you get:

0 12345..... multiplied straight forward...

Lets try for 180 degrees and -180 degrees yes?
Since we know there are 360 degrees possible, PLUS resolution...

And we can find the deadband in the middle.
Assuming symmetry we can identify the beginning of the negative numbers? yes?

-methods

So the first tool you create is this
(requires man in the middle for values under 32K)

In my field of work you never polish past that point. You solve the part which a robot can solve with a robot... then you let the human do the hard part.
As a show of skill... we will now add the if statement to automatically take the input, test above or below 32k, then just give the right answer

NOTE: It teaches folks the most to do it the MITM way... as the fancy way leaves one scratching ones head.

Formulas used: ... just type: =H or =D
You will get tips for HEX2DEC and DEC2HEX

-methods

To use an IF statement in a spreadsheet you do this:

=IF(E4>32767,65535-E4,E4)

=IF(TEST,TRUE,FALSE)
Where the cell with the IF statement is replaced by the value in the TRUE field or FALSE field
For values less than 0xFFFF/2 we want to just use the number entered... like 0x0050
For values greater than 0xFFFF/2 we want to subtract that number from 0xFFFF and multiply by -1

Convert all your numbers to dec before using calcs or make sure you enter as hex numbers!

So here is the result

-methods

And since someone made fun of me earlier...
Here is the spoon feed solution.

I SUGGEST you go through the work of doing it yourself so you can actually learn something. :lol:

In the way of Stanford, MIT, and Tesla...

If I figure it out... you have figured it out

There is no honor in competing for the resources of knowledge... even if it makes us rich.
I am poor. Very poor... as in... all I have is my self respect... and thats enough.

For the haters out there... you will understand one day that the tools you use... the things that make your life easy... did not solidify from vapor.
They were hard won through intense work... and this is why I want you to go to school.

-methods

#### Attachments

• Sevcon16bitOffsetCalculatorV2.ods
9.3 KB · Views: 150
So anyway...

That basic approach will allow you to walk up to any Zero bike, any Sevcon Golf Cart, or anything running a Gen4
Rip the DCF
Modify the hex settings
Burn the DCF

and WIN.

If you dont even have DVT customer...
Then you need to know the bit stream (bit bang approach) necessary to pull all the address values
The reverse to write them

It is very straight forward and documented... if you are into reading like 46,000 pages of super high level CANopen documentation.

-methods

Suggested next steps:

Procure a ClearView
Sniff what it is doing
Emulate it

Ok... what does that mean?

Well.....
Lets say you are running steady state
Lets say you want to go into PreOp, change the encoder setting, pop back into Op

You would sniff that
Record it
Play it back

Only... when you play it back you change the values of interest
To do this you may or may not have to calculate new checksums
To do this you have to know how they are calculated
Even with that info... you have to do the calculation

Its all very simple...
But layer upon layer upon layer of dependency

No guy is going to come out of the dark and just "hack shit". Lol.. unless it is totally unprotected, which it is not, because you could not detect packet errors.
You have to understand what is going on at every level to make changes at the hardware level (usually)

In most cases... something like a DCF would not be in ASCII... that makes it REALLY EASY to work with.
Had it been in a binary format... pffft... hosed... unless you have the key to make sense out of it.

Nearly all of these "hacks" you see in the media are insider.
You simply can not do it without insider knowledge
Its called key-stoning

I can calculate a one in 32 Trillion possibility with a key.
Simple, easy.

Without it?
Impossible.

An engineer is a key to making things work.
There are MANY kinds of engineers... who specialize in many things...

There are also a lot of implementers out there. Dont mix them up.

Implementer != properly schooled engineer
(!= means "not equal" in C)

irritated again... damn haters are hating.

-methods