# Hyper9 CAN Protocol?



## SimonRafferty (Apr 13, 2009)

I've not started trying to reverse engineer it yet - but here's what I've found so far.

The 'Hyperdrive' inverter is in fact a Dana TM4 Tautronic ACX1-I inverter, badged as Netgain.


https://www.dana.com/globalassets/resource-library/crossover-resources/spec-sheets/spec-sheet-tautronic-5-en.pdf



In the PDF it says the inverter uses CANOpen protocol - which is slightly different to a lot of BMS's and other vehicle components.


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


A better explanation here:








CANopen Explained - A Simple Intro [2022]


Need to understand CANopen? Then check our simple intro where we cover the object dictionary (OD), SDO, PDO, COB-ID and more - with clear, visual examples!




www.csselectronics.com





If you look at the files installed for the Tau application, there are two help files, which have a bit more info about the CAN config.








The Node ID can be from 1 to 0x0080 (1 to 127). Since this is added to the TPDO ID, I think the TPDO ID has to be higher than 0x80 and exclude the values shown above, which from the Wiki article have special meanings. Also, it infers that the Node ID should be 1 to make it the 'Master'.

So, for example, a TPDO ID of 400 would be suitable - giving a CAN ID of 0x0401

I had hoped to find a list of the CAN messages that the Tautronic ACX1-I will accept (for control) - but it has eluded me so far. I have an idea though!

In the next couple of days, I'll put a CAN Sniffer on it & see what I can see!


----------



## Jeep Man (Sep 21, 2021)

SimonRafferty said:


> I've not started trying to reverse engineer it yet - but here's what I've found so far.
> 
> The 'Hyperdrive' inverter is in fact a Dana TM4 Tautronic ACX1-I inverter, badged as Netgain.
> 
> ...


THAT'S GREAT!

I just talked to JJ at LegacyEV, they sold me the Hyper9HV-IS and the AEM CD-7, he's going to try to track down the entire list of PIDs (TPODs, CAN IDs, etc.) that he will put into a full TPDO and attempt to export as a .dbc file.

Fingers crossed for us both.

Thanks - Patrick


----------



## RickXD (6 mo ago)

This is an interesting project! Hope to see some updates soon


----------



## Jeep Man (Sep 21, 2021)

RickXD said:


> This is an interesting project! Hope to see some updates soon


I should have a reply from JJ at Legacy EV tomorrow or Friday.

We worked on the motor settings today - commissioning and cutoffs - sooo complicated, soooo fun!

I'll let you know when I have the .dbc file - or anything close.

- Patrick


----------



## RickXD (6 mo ago)

Alright! Good luck


----------



## SimonRafferty (Apr 13, 2009)

Jeep Man said:


> We worked on the motor settings today - commissioning and cutoffs - sooo complicated, soooo fun!


I'd be interested in what you changed / set up?

I have my motor running - but everything was a guess!


----------



## Jeep Man (Sep 21, 2021)

SimonRafferty said:


> I'd be interested in what you changed / set up?
> 
> I have my motor running - but everything was a guess!


Mostly screwing around with cutoffs A B C D settings.

I should have a clone tomorrow with a .dbc hopefully.

I'll fill you in when I get it.

- Patrick


----------



## Jeep Man (Sep 21, 2021)

Working on the layout of the 'Tech Deck' - wires, wires and more wires.

Attempting to wrangle them.


----------



## Jeep Man (Sep 21, 2021)

Ignore that last layout - I've got a new one that I LOVE!








View from grill looking back toward firewall.









Showing Switch / Fuse wall.

This is from a little earlier but shows another view of the Switch / Fuse wall:








The three holes are where the W, U, V (AC motor) wires will go.

Saves a ton or room and makes for more room for other stuff at the front. Plus, more medullar. I think the ease of access is important also.

I also flipped the Pack charger - this way I can vent to the engine bay rather then press down on the top of the battery box.

- Patrick


----------



## SimonRafferty (Apr 13, 2009)

Success!
I'm now reading data from the Hyper9 Controller. I tried various things - with no joy, then stumbled on this:








I set the Node ID=1 and the TPDO ID = 400 - and data started appearing on the bus.

In my case, I've set the fields differently, as I'm only really interested in RPM at the moment. It may be that if you configure the fields as above, the AEM display will just ead them. Set it to look at the CAN ID = 0x0401. (Decimal 1025)

Now I'll see if I can send data to the HyperDrive to set SOC etc. It looks fairly simple (famous last words!):








Since I'm already reading SOC from the Orion, I can package it up appropriately for the Hyperdrive.

If this all works, I'll write up how to use an Arduino to send data between the Orion & Hyper9.


----------



## Jeep Man (Sep 21, 2021)

SimonRafferty said:


> Success!
> I'm now reading data from the Hyper9 Controller. I tried various things - with no joy, then stumbled on this:
> View attachment 132562
> 
> ...


Larger please - I can't read most of that.


----------



## SimonRafferty (Apr 13, 2009)

Jeep Man said:


> Larger please - I can't read most of that.


I'm afraid the editor won't allow me to make it any biger!
Use Ctrl + & Ctrl - on your keyboard to zoom in & out on web pages. Works on most browsers!


----------



## agmatthews (Oct 5, 2018)

SimonRafferty said:


> Now I'll see if I can send data to the HyperDrive to set SOC etc. It looks fairly simple (famous last words!)


How did you go *sending* CAN data to the hyper 9 controller?
I haven’t been able to find any examples or documentation anywhere of people successfully doing this.
I suspect the CAN bus in the hyper 9 / X1 is a one way - output only - bus
It would be great if you could send things like current limits, but …..
A


----------



## SimonRafferty (Apr 13, 2009)

You can send data both ways - however, I found it a load of trouble!
If there was anything wrong with a single message - either content or timing (frequency of sending) it would generate an error and switch off the motor. 

After a few days effort, I gave up on it.

All the information required is given when you set up a received message in Tau. There isn't a list of what it can receive because everything is user configurable.

Receiving data from it worked fine - but there is nothing, apart from the motor RPM that's useful or unavailable from the BMS. I ended up just switching it off as it just added traffic on the bus.

It's a real shame because without things like current limits, the protection that the BMS could provide is worthless too.

I tried a work-around using an Arduino to receive the Charge & Discharge limits from the BMS and pass them on to the Hyper9 as analog (0-5V) signals. The harness I bought only had a single Analog port wired up (for the throttle). I added the connections for another two - but it seems they are not connected (configured?) inside the hyper9 itself - so that was a bust!


----------



## agmatthews (Oct 5, 2018)

SimonRafferty said:


> You can send data both ways - however, I found it a load of trouble!
> If there was anything wrong with a single message - either content or timing (frequency of sending) it would generate an error and switch off the motor.
> 
> After a few days effort, I gave up on it.
> ...


Thanks Simon,
I suspected it would not be readily doable, or Orion / Ewart would have had the Orion BMS talking to the Hyper 9 X1 controller long ago. 
Bit of a shame really.
I’ll have a tinker and see how frustrated I get too.
if I have any success I’ll report back
A


----------



## agmatthews (Oct 5, 2018)

@SimonRafferty 
just thinking about this - i assume you did your test with the regular consumer version of the TAU software?
I might see if I can source the TAU OEM version and see if that is any better - i do vaguely recall a thread / discussion that said if you wanted to use the additional analog ports you needed to source the OEM version.
A


----------



## SimonRafferty (Apr 13, 2009)

I'm using the OEM version. You can hardly do anything with the Consumer Version!

The main reason (I think) Orion can't talk to the Hyper9 is they've been designed with different protocols in mind.
The Orion uses OBD2 where Hyper9 uses ISO 11898 CAN.

Either of them could adapt their software to talk to the other but I think they are both just hoping the other one will.

I wonder if Orion did try, but ran into the same difficulty as me - that the data receivied by the Hyper9 had to be more perfect than was easily achievable. Any small error and the Hyper9 would throw a fault and shut down, requiring the power to be cycled. This tended to happen most often while I was driving (more electrical noise I guess) - which is potentially quite dangerous.

If you can get the Analog ports to work - I think that's the most robust solution!
(if you need help with an Arduino implementation of that, I could probably point you in the right direction)


----------



## SimonRafferty (Apr 13, 2009)

Jeep Man said:


> Larger please - I can't read most of that.


You know, on most browsers you can press [ctrl] with [+] or [-] to zoom in or out of the content on a page? That way, you can adjust so you can read it.


----------



## asymptonic (Oct 14, 2021)

Interesting. Wondering now if I shouldn't add a second CAN input in my microcontroller project to translate between the Orion and the Hyper9


----------



## SimonRafferty (Apr 13, 2009)

No need - they can both sit on the same bus.
The problem is the Hyper9 expects the data to be too perfect. You specify a packet interval for transmit & receive. If a packet is late, even by a few mS, it generates a fault & shuts down.
That's tricky to do when the microcontroller has to read data when it becomes available. That might make it miss the transmission slot for the Hyper9.
It really needs a processor which can multi-thread / multi-task.
It could also be done where the Tx timer can interrupt a CAN Read, but a read cannot interrupt the timer.

I would set the Hyper9 to transmit any data that you're intersted in. Read the Orion data and use that to set the values of two PWM outputs to drive analog inputs on the Hyper9 to set the max charge & discharge currents.

That's how the Orion should implement it. They have digital IO, which could generate PWM if they wanted.


----------



## asymptonic (Oct 14, 2021)

Makes sense. With two separated CAN buses however, and a fast enough real time microcontroller, you could prevent overlap entirely. I agree it may not be worth it though.


----------



## SimonRafferty (Apr 13, 2009)

Speed isn't the issue. I'm running on a Teensy 4 at 600MHz, but two instrictions per cycle - effectively 1.2GHz so speed isn't the issue.
The problem is the lack of prioritisation of interrupts. It's probably possible by delving deeper than the Arduino IDE though.

When I have a bit more time, I'll have another look as it would be good to find a robust solution.


----------



## asymptonic (Oct 14, 2021)

Seems doable: Interrupt priority for attachInterrupt?


----------



## agmatthews (Oct 5, 2018)

With some help from @SimonRafferty I have a microcontroller reading CAN data from my Hyper9 / X144 controller.
In addition to the messages that I have setup in the TAU software, I can also see three messages from the Hyper 9 controller 
ie before I set anything up the controller was sending these three messages 

`msg_ID size
701 1 byte
181 8 bytes
281 8 bytes

Sample data (with motor stationary)
0x0701 5 
0x0181 99 1 0 20 5B 0 0 39 
0x0281 0 0 0 0 0 0 0 0`

Does anyone know the meaning of these three messages?
There is nothing in the manuals or help files that I can find, I suspect they maybe for a CAN based display 
It may take some reverse engineering to decode them 
I think they are message ID's of 700,180 and 280 with the node ID of 1 added to the MsgID
According to https://en.wikipedia.org/wiki/CANopen#Process_Data_Object_(PDO)_protocol the 0x0701 message will be a heartbeat indicating 'normal' operation

I am using an Adafruit Feather M4 CAN Express board (with an Adafruit 128x64 OLED for diagnostics) - image below
I'll see if can simulate a BMS *sending* SOC and DCL messages tomorrow, it will be interesting to see if I have the same reliability issues as Simon had
I might try with and without a heartbeat msg


----------



## SimonRafferty (Apr 13, 2009)

Well done!
I would guess at the 181 message being an advertisment to other nodes, saying 'I'm here' & maybe 'this is what I can do'.

Unless that's useful to you, I'd ignore them! 

The heartbeat might be the key to the reliability. I wonder if, because I wasn't sending a heartbeat and if the messages I was sending weren't frequent enough, it was actually thinking I'd gone to sleep. 
Measure the frequency of heartbeat messages the Hyper9 is sending out - then mirror that.


----------



## agmatthews (Oct 5, 2018)

It looks like a CAN heartbeat from the micro controller to the Motor controller is NOT required (well ... not so far)
So long as I send more messages to the Hyper9 controller than it expects it seems to be happy
So I have my message rate set to 500ms in the TAU software and I'm sending data at 200ms - and its happy









If I stop the micro controller, or slow down the message rate too far then it generates a STOP level error


----------



## agmatthews (Oct 5, 2018)

PARTIAL SUCCESS !!
It took a while to work out how to send CAN data to the Hyper9 controller - and I'm only halfway there
But, I now have Orion BMS State of Charge successfully transmitting to the Hyper9 - via a intermediary microcontroller

Here is the micro controller showing CAN data from _*both*_ the Orion BMS and the Hyper9
.. and in this example I have the motor spinning - hence the Amps
The H9 SOC is the data returned from the motor controller - ie data it received from the micro controller as a BMS message and returned on the can bus as a Hyper 9 message










And here is the TAU software showing the set up to source the battery SoC from the "BMS"
In this case the "BMS" is my micro controller that is fetching the BMS data in Orion CAN bus format and sending it backout on the same CAN bus in Hyper 9 format


















The most difficult thing to work out was how to map the data into the CAN message.
You'd think from the image above that the State of Charge number would need to be the first byte (0) in the message - or maybe the last byte
But no... It needs to be sent in the 4th byte
something like this

```
CAN.beginPacket(0x500);
      CAN.write(0x00);
      CAN.write(0x00);
      CAN.write(0x00);
      CAN.write(0x00);
      CAN.write(BMSbatterySoc);
      CAN.write(0x00);
      CAN.write(0x00);
      CAN.write(0x00);
      CAN.endPacket();
```


----------



## agmatthews (Oct 5, 2018)

But that is it so far
I can't get the TAU software to accept any other setup for the BMS data
If I try to set up BMS Status (which automatically turns on the 'limit' settings) and / or BMS Current then the Controller generates a fault on Boot









The Error given is error 52 WRONG PARAMETER - which is the error you get after you enter the wrong configuration / settings into the TAU software









but these settings are the same as the TAU help file.... so I'm perplexed









As this is happening at boot up its not a CAN data format issue - its not even getting to read the first message 

The error implies its an "offset" problem with the "BMS Statu"s message
So I'll try every combination of offset for the BMS Status message - after a cup of tea I think

Any ideas on what is going wrong here would be most welcome


----------



## agmatthews (Oct 5, 2018)

Well the cup of tea worked

This configuration (image below) of byte offsets for inbound "BMS" CAN messages in the TAU software worked - it finally managed to not error on boot up
Its almost like the first 4 bytes are unusable. 










I can now send CAN messages with Wall Charge, BMS Stop, BMS Fault bits set and they have the desired effect on the controller
eg if I set Bit 4 of Byte 5 to 1 (ie set the wall charging flag) then this happens and the main contactor opens









Similar for STOP and FAULT flags


















So far I'm not seeing any effect of me setting the 'LIMIT' flag and a limit value - not exactly sure where to look for this
Something for tomorrow...


----------



## SimonRafferty (Apr 13, 2009)

🥳

I find Tea is often the solution to enigmas.
Earl Grey for particularly perplexing ones!


----------



## MoonUnit (Jun 29, 2019)

Right - there are a whole bunch of things that I note from the above posts (good work, by the way!).

I think I first spoke to Netgain and Ewert about sending current limits to the ACX1 about 3 years ago and was told it was in development. Both sides have tried and I believe the problem is the controller side suffering 'cutouts' but I don't know more than that.

The Orion can send messages via CAN quite happily. The OBD2 is just a messaging protocol for devices to request and receive a piece of data from the Orion. So you can send stuff continously to the ACX1 without needing the ACX1 to request it of the Orion via OBD2.

I have had mixed success sending the SOC from the Orion to the ACX1, and in the end abandoned it because it messes with the ACX1's battery protection map, and indeed the 'wrong parameter' error could have been caused by the battery protection map interacting badly with what the AXC1 thought the SOC was from the Orion.

The ACX1 somewhere does have the ability to receive the Discharge Current Limit from the Orion via CAN, but it's the Charge Current Limit that is important for me. For example, you need to limit regen, ie charging, when it's cold and you can't do that with the battery protection map if, say, the battery is not close to peak charge. I think it's a major flaw.

I have been able to get the Orion to output the DCL and CCL limits via its analog outs, and make a galvanic isolator to pass the voltage levels to the ACX1 via its analog inputs (See Torque/speed limits page). I had to add wiring to the loom for it and configure pins in the software. Remember NOT to connect the Orion to the ACX1 directly as they should be isolated from each other. HOWEVER the 'Torque limits' page I refer to has a map, in which you set your input analog voltage to map to a torque limit *percentage*. This I don't understand - I don't know what 100% equates to in terms of torque anyway (where is this set?), and I don't know how to relate that value of torque percentage to a specific current limit set by the Orion. Really, the ACX1 should be able to take a figure in amps from the Orion and limit the regen to that.


----------



## SimonRafferty (Apr 13, 2009)

@MoonUnit You did well to speak to Netgain & Ewert - neither replied to me!

"I believe the problem is the controller side suffering 'cutouts'"
That's exactly the problem I had. Everything seemed to be working fine, go for a drive and somethimes the controller would just shut down inexplicably. If it showed an error, it was generally related to CAN Timing.

I tried the Analog route too, adding the wires to the connector & configuring in Tau, but the Analog inputs refused to read a voltage - just read the same value. My conclusion was they were not wired up inside the box!

I hope @agmatthews solution works reliably - it could be I wasn't sending the packets frequently enough or there was too much traffic on the bus and occasionallly it would miss one in the required time frame - then throw a wobbly!

I have a knob on the dash which controls regen (again a % of the max regen current you've set). My plan is to feed the +ve of the variable resistor with an analog output from the Arduino (yes, it's isolated ) then set that from the charge current limit from the Orion. The knob will adjust from zero to the max the Orion thinks is good.

For two relatively expensive devices, there seems to be very little support - it being left to us to guess & hack solutions for something that ought to just work.


----------



## MoonUnit (Jun 29, 2019)

When you say:


SimonRafferty said:


> The knob will adjust from zero to the max the Orion thinks is good.


I'm not sure I understand. If you set the charge current limit to (say) 200A in the Orion, then your knob will go from 0% for 0A, to 100% for 200A. 

Your Arduino will then output 0V to 5V to the ACX1 (isolated!).

In the X1, I assume you are setting the regen torque map to go from 0% to 100% as input voltage varies from 0V to 5V.

That would mean that at 5V, you want 100% regen to be equal to (or less than) 200A, otherwise the Orion will throw a fault.

Where do you set 100% = 200A in the X1? This was the issue I faced.


----------



## SimonRafferty (Apr 13, 2009)

MoonUnit said:


> Where do you set 100% = 200A in the X1? This was the issue I faced.



In Tau, you can only set the nominal maximum current:








390A in my case. It's a guess, but I think that's for drive or regen.

The way I've limited it is:








The highest value the pot can reach is 5V which equates to 35%
35% of 390A = 136A (in my case).

My batteries can take more than that - but at 35% you are pretty much head-butting the steering wheel!

The current measured in the logs would seem to back that up. The 390A is only nominal / average - so you get odd spikes up to about 30% higher than that. However the duration is short enough that It's not blown the 400A fuse (yet!)


----------



## agmatthews (Oct 5, 2018)

Simon, 
Does that mean that you have an ‘on/off’ switch on the brakes (like the brake light switch) and the output of this passes through a potentiometer on that dash that you use to adjust the amount of ‘regen’ you get from applying the brakes?
That would be neat way of being able to dial in the brake pedal regen seperate to the overrun / engine braking regen you get on the ‘profiles’ 
Andrew


----------



## SimonRafferty (Apr 13, 2009)

agmatthews said:


> Does that mean that you have an ‘on/off’ switch on the brakes


No - I just use it like engine braking so when you lift off the throttle, you get an amount of regen controlled by the knob on the dash.
Because it's an off-road vehicle, this is particularly useful for hill decents when traction is limited.









I did write a description of how to set that up somewhere on here - but can't seem to find it now! It took a bit of figuring out.

However, a relay connected to the brake lights, connected though a pot is a real simple way of achieving the same for pedal braking!


----------



## MoonUnit (Jun 29, 2019)

@SimonRafferty - nice solution for varying the regen amount 'on the fly'. I just used a switch for the three available profiles but as you say, anything more than about 35% is pretty stiff and I only really used two modes - off or on. The problem I want to solve is how to get the BMS to control the regen amount from the ACX1 as temperature varies, without spinning out the Orion.



SimonRafferty said:


> 390A in my case. It's a guess, but I think that's for drive or regen.


It's 390A RMS, according to the screenshot, which I think means that the DC current draw from the pack should approximate this value, whilst within the controller the peak would be 551A, in theory. I don't know what the actual DC draw on the pack would look like. Clearly the odd spikes you get aren't long-lived enough to blow your fuse, but if you'd set the current limit at 390A in the Orion I don't know whether it would see these spikes as breaches and complain loudly. In other words, does setting an RMS value in Tau match the DC value seen at byBMS?

There is also the 'motor current limit map' which I thought might be able to link max 'drive' and 'brake' (ie regen) %age (on y axis) to an actual current value. I've lifted a screenshot from the help files below, and have asked this question somewhere else on the forum too. I've also fiddled with the values but not been able to make much sense of the results. But it implies that in the example below, at P0 for the red line, 75% 'current limit' = 450A RMS. That would imply that 100% = 600A RMS, but this is only a screenshot so I don't know if that = the 'Nominal Maximum Current' which you have set above to 390A RMS.










If I could reliably know that 100% 'brake limit' was X Amps RMS, I could happily work back from there (assumptions around RMS vs instantaneous measured values at the Orion aside!).


----------



## SimonRafferty (Apr 13, 2009)

The spikes in current were enough to trigger an error of the Orion. Instead I've set the current limits on the orion high enough that they won't trigger and use the limits on the Hyper9 instead.









I'd forgotten about this screen! This has presidence over the percentage set in the throttle / brake maps. In my case the throttle is close to 100% above and the brake to 75%.

So, my 35% is actually 35% of 75% of 390A = 102A

It's easy to varify just by setting & looking at the logs.


----------



## agmatthews (Oct 5, 2018)

I’m really confused about what the ACX1 reports / uses as it’s ’current’ measurement.

In my setup, where I’m limited to about 30 Amps for testing and integration purposes, I can see in the TAU software, and get on the CAN bus, a “DC current” reading. But this reading is almost double what the Orion BMS reports. A clamp on ammeter reports the same DC current as the Orion. You can see some of the numbers in the photo of the micro controller screen back in post #28. 

So why is the Hyper 9 controller reporting almost twice the DC Amps it should?
How does It measure DC amps?

In @4Foxtrot ’s instagram photos of his fried ACX1 controller you can see what looks like a CT clamp on the AC side of the internals of the controller, but no clue as to how it would / could measure the DC current. 

Tomorrow, I’ll try to send the Orion BMS current current to the ACX1 by CAN and see if that cleans up the discrepancy.
Maybe it’s all “rough estimates“ and this is why you only get to specify limits etc in % speed or % torque rather than Amps

A


----------



## MoonUnit (Jun 29, 2019)

SimonRafferty said:


> I'd forgotten about this screen! This has presidence over the percentage set in the throttle / brake maps. In my case the throttle is close to 100% above and the brake to 75%.
> So, my 35% is actually 35% of 75% of 390A = 102A


OK - so you have set a maximum current for both drive AND regen in the 'Motor' tab 'nominal current' of 390A RMS.

Using the 'Motor Current Limit Map' above, for 'drive' you have mostly got each point set at 100%, so that gives you 390A maximum current, correct? Plus some odd spikes around 30% higher?

But the regen as determined by your dash knob is maxxed at 35% of the Brake Current Limit as set in the map. For you it's c. 75% x 35% of 390A = 102A as you say, again plus some odd spikes?

When I changed my Motor Current Limit map for 'drive' I just got a drastic drop in available power. I don't recall what I had the nominal current value set to (I don't think I changed it). Logging is a bit awkward for me as the motor controller's in the boot, but it sounds like you;'ve been able to make these changes and verify their effect. Good work!


----------



## SimonRafferty (Apr 13, 2009)

It will use a hall-effect DC Current Sensor. They are not particularly good at low currents compared to their rating. I would guess this one is rated at 1000A or more - so 30A is right at the bottom of it's range. 

The reason is, say it's a 5V device - so delivering close to 5V at 1000A. 30A is only 0.15V. It's inside an electrically & magnetically noisy device - so the noise makes a proportionally bigger difference to the reading than close to 1000A.


----------



## SimonRafferty (Apr 13, 2009)

MoonUnit said:


> Using the 'Motor Current Limit Map' above, for 'drive' you have mostly got each point set at 100%, so that gives you 390A maximum current, correct? Plus some odd spikes around 30% higher?
> 
> But the regen as determined by your dash knob is maxxed at 35% of the Brake Current Limit as set in the map. For you it's c. 75% x 35% of 390A = 102A as you say, again plus some odd spikes?


I'm using the Nominal Motor Current as the absolute limit value - then reducing it with various percentage scaling factors elsewhere. That's the only place (I've found) where you can set an actual value in Amps. Everywhere else is precentages - and that makes sense as they are all applied sequentially.


----------



## MoonUnit (Jun 29, 2019)

agmatthews said:


> In my setup, where I’m limited to about 30 Amps for testing and integration purposes, I can see in the TAU software, and get on the CAN bus, a “DC current” reading. But this reading is almost double what the Orion BMS reports. A clamp on ammeter reports the same DC current as the Orion. You can see some of the numbers in the photo of the micro controller screen back in post #28.


There seem to be a few different current messages that the ACX1 can send, are they all giving you the same value? Are you decoding the CAN message correctly if the value is supposed to be signed? You may need some two's compliment decoding ... and make sure the byte order's the same as the Orion. Apologies if you know all this already.



agmatthews said:


> Tomorrow, I’ll try to send the Orion BMS current current to the ACX1 by CAN and see if that cleans up the discrepancy.


I'm not sure what you will acheive by this, as the ACX1 doesn't care what the Orion thinks current is, nor is there anything it could do with it as far as I know.


----------



## agmatthews (Oct 5, 2018)

MoonUnit said:


> I'm not sure what you will acheive by this, as the ACX1 doesn't care what the Orion thinks current is, nor is there anything it could do with it as far as I know.


What got me thinking is in the BMS to ACX1 CAN message set up is there is a place to send current data from the BMS to the Hyper 9 controller. 









So I ask myself “why would that be there?” “What would the ACX1 do with it?”

The SOC data earlier in the same message replaces the ACX1 calculated SOC when you send it, and the ACX1 uses this in its limt calculations.
So if they were being consistent then would they replace the motor controller measured / calculated current with the BMS one….. but…… this would require consistency.


----------



## agmatthews (Oct 5, 2018)

SimonRafferty said:


> It will use a hall-effect DC Current Sensor. They are not particularly good at low currents compared to their rating. I would guess this one is rated at 1000A or more - so 30A is right at the bottom of it's range.
> 
> The reason is, say it's a 5V device - so delivering close to 5V at 1000A. 30A is only 0.15V. It's inside an electrically & magnetically noisy device - so the noise makes a proportionally bigger difference to the reading than close to 1000A.


Ah yes, of course that makes sense.
while I have the motor in the vehicle, the vehicle is just a chassis and a couple of axels at the moment.
will be a while before I can draw 400 Amps

A


----------



## agmatthews (Oct 5, 2018)

agmatthews said:


> So I ask myself “why would that be there?” “What would the ACX1 do with it?”
> 
> The SOC data earlier in the same message replaces the ACX1 calculated SOC when you send it, and the ACX1 uses this in its limt calculations.
> So if they were being consistent then would they replace the motor controller measured / calculated current with the BMS one….. but…… this would require consistency.


Hmmm, it looks like they are consistent.

After some reorganising the CAN data sent to the ACX1, I now have this set up for BMS CAN data
(reorganised so that the controller allows transmission of all the possible data elements and does not error on boot)








So now I can send a 'Current' Value in Amps as a two byte value from the "BMS" (ie my micro controller) to the ACX1 controller.
(Noting the current is sent multiplied by 10 and this is consistent with data read back from the CAN bus)

```
CAN.beginPacket(0x500);
      CAN.write(0x00);
      CAN.write(0x00);
      CAN.write(0x00);
      CAN.write(BMSCurrentLimit);
      CAN.write(BMSbatterySoc);
      CAN.write(BMSStatus);
      CAN.write((byte)BMSCurrentValue);     
      CAN.write((byte)(BMSCurrentValue >> 8));
      CAN.endPacket();
```
And *voila* the Hyper 9 controller reports this value back as the _DC Bus current_ on the CAN network and on the TAU screen







​
*So, now what?
Does the controller use this value in its current limit checking in any way?*

In the TAU software there are number of items you can set as 'CAN' but it would appear that a lot of these seem to relate to other TAU nodes
ie slave controllers for items like pumps or multi wheel drive motor controllers etc






So these are a bit of a rabbit hole

However in the help file there are these highlighted parts








I note these refer to Controller *Output* Current so I assume they are not directly related to the BMS DC Bus current - as this is an input current, but they may be.....

For testing if I set the Limit Status bit to a 1 and the Limit value to a testing value of 33% nothing obvious happens, even setting it to 0% seems to have no effect on the controller
If I set the status bit to one of the STOP, FAULT or CHARGING status's the controller reacts immediately - with the appropriate error so the Status byte is being read properly
It may be there is no indication anywhere that the controller is being BMS limited


*any ideas?*


----------



## MoonUnit (Jun 29, 2019)

agmatthews said:


> any ideas?


Very interesting, that's good work you are doing there. I'd forgotten about this.

I believe that the 'limit' that relates to Controller Output Current is a discharge / drive current limit, ie the controller will take a value from the BMS and not draw more that this from the pack. In Orion language,this would be the Discharge Current Limit, not the actual current being drawn (else you limit yourself to what you are drawing).

I tried to do this with a guy from EV Shop in Romania back in 2020, and he swore the ACX1 could limit discharge in this way. However, we couldn't make it work (he was trying to help me set parameters remotely and we were in lockdown at the time). Looking back at the screenshots I have, we tried to use bytes 0 and 1 for the current, whereas you have used 4 and 5. It may be we didn't have the Orion CAN message set up properly either, as I never got SOC to work either. In the end, I wasn't convinced he was right about it, and I was only really interested in the Charge Current Limit.

Can you test to see if the ACX1 will limit discharge in this way?


----------



## agmatthews (Oct 5, 2018)

MoonUnit said:


> Can you test to see if the ACX1 will limit discharge in this way?


I’m limited in the number of Amps I can test with as I’m bench testing with some of the gear (motor) in the vehicle and some in a rack on the ground (batteries & BMS). So no high current driving for me, just spinning the wheels with the vehicle up on the hoist. I’ll try setting a discharge limit to a low % and see what happens when I pull, say, 25A. 
might be a day or two.


----------



## agmatthews (Oct 5, 2018)

Oh, and I should point out I’m running the 144V Higher Voltage version of the hyper 9 and ACX1.
not that that should make a difference


----------



## electronlandy (2 mo ago)

Hi, very glad I've found this thread as I too have just started experimenting with the X144 can bus.

I've setup the simple message shown below.











On the smartview live monitoring screen I see inverter_1 temp as 14.4 degrees (It's cold in the garage)

When viewing the broadcast message on the canbus I see the byte_0 as 0x36 (55 as decimal)

What's confusing me is that no matter how I play around cutting / slicing / bit shifting 0x36 I cannot get close 14.4 or there abouts.

Any ideas on how to decipher the data ?

Thanks


----------



## agmatthews (Oct 5, 2018)

electronlandy said:


> Any ideas on how to decipher the data ?


Check the documentation (press the help button in the TAU software while you have the CAN page open)
There is a line describing the conversion for each element - in this case you need to subtract 40









here is my decode code....


```
// Convert Hyper9 CAN values to normal values
  motorTemp = motorT - 40;            // Motor 1 - Temperature Byte °C Motor 1 Temperature (offset of 40°C) [0; +255] ↔ [+40; +295]°C
  inverterTemp = inverT - 40;         // Inverter 1 - Temperature Byte °C Inverter 1 temperature, with an offset of 40°C [0; +255] ↔ [+40; +295]°C
  DCBusVolts = (DCVolts / 10);    // Key Switch Voltage Word cV Controller Supply Voltage [-32768; +32767] ↔ [-327.68; +327.67]V
  DCBusCurrent = (DCAmps / 10);         // My Node DC Bus Current Word dA Node DC Bus Current, estimated or sniffed from BMS (depending on configuration) [-32768; +32767] ↔ [-3276.8; +3276.7]A
  MotorRPM = MotorSpeed;
  Throttle = map(MotorThrtl,0,255,0,100);
```


----------



## electronlandy (2 mo ago)

Oh wow - how embarrassing, I hadn't scrolled down far enough on the help screen to notice that before. Thanks
I'm reading the data into the vehicle control module which then converts that to a PWM signal to drive the original analog dash temp gauge.
I've got everything charging and the motor spinning. In a few days time it'll be ready to take its first drive out of the garage


----------



## agmatthews (Oct 5, 2018)

electronlandy said:


> I've got everything charging and the motor spinning. In a few days time it'll be ready to take its first drive out of the garage


nice!
Just curious, what batteries and BMS are you using?


----------



## electronlandy (2 mo ago)

agmatthews said:


> nice!
> Just curious, what batteries and BMS are you using?


I'm using 14x LG4P3S modules giving me 154V nominal (approx 176 peak) and an Orion 2 BMS.
The modules are split between two packs. The large pack (sitting under the HV control box) contains 10 modules together with the BMS and thermistor expansion module. The 2nd small pack sits in the void beneath the front seat box. This contains 4 modules. Each pack has its own fuse and contactor.


----------



## electronlandy (2 mo ago)

agmatthews said:


> I’m limited in the number of Amps I can test with as I’m bench testing with some of the gear (motor) in the vehicle and some in a rack on the ground (batteries & BMS). So no high current driving for me, just spinning the wheels with the vehicle up on the hoist. I’ll try setting a discharge limit to a low % and see what happens when I pull, say, 25A.
> might be a day or two.


 How did you get on with this test?
Will be fantastic to have a solution for this.


----------



## agmatthews (Oct 5, 2018)

electronlandy said:


> How did you get on with this test?
> Will be fantastic to have a solution for this.


I'm a bit limited on 'dynamic' testing as the car is currently just a chassis up on a hoist and the batteries are in their storage rack parked alongside
This limits the current I can pull to 30A and at that limit I'm not seeing any discharge limiting no matter what I set
I've just got some 80A fuses and holders in the mail so I'll upgrade and try again with a few more angry pixies









In the meantime I've been contemplating using the Orion BMS analog out outputs and the Hyper9 analog inputs to achieve the same result 
(with more wires and less configurability)
Something more for testing - worth the effort to see if the results are different
ie does the Hyper9 TAU software only show limiting when it actually limiting or when it is told to limit


----------



## electronlandy (2 mo ago)

I had a brief chat yesterday with Chris Hazel from zero-ev (largest EV conversion component distributor here in the UK and a Netgain distributor) regarding the can control and he confirmed what we already suspect. Whilst limits can be received by the controller, they will have no effect. 
I believe our only way forward now is to utilise the analog outputs on the Orion, lots of data logging, and attempt to plot a limit graph within the controller that results in a ever so slightly more conservative limit than he BMS DCL / CCL.
I too am using the HV variation of the controller which does simplify the mater slightly in that isolation is not required as it is with the 100v controller,


----------



## Tomdb (Jan 28, 2013)

The lack of limiting has been an issue that has been known about for a while. It kept being promised by Netgain and then the controller and motor supplier SME got taken over by Dana. Nothing has changed since then I believe Netgain is also not a really big customer for someone like Dana.

I feel the Netgain/Hyper 9 setup is quite lacking and even dangerous to be used in EV conversions, it clearly does not meet EU R100 requirements.


----------



## agmatthews (Oct 5, 2018)

An alternative is to read the BMS data via CAN with a micro controller and generate the desired DCL and CCL response curves in that and have the micro controller output voltage to send to the motor controller
I'm sort of already doing this to get the old Land Rover Fuel and Temp gauges to read correctly - using Adafruit CAN express and motor wing for a nice voltage signal independent of the micro controller power supply

This would need the TAU software set up with a linear response curve.
There is one example of this in the "speed" section of the help files - image below 
I'd hope that you could do the same when in torque mode

I'm away from the shed for a few days so cant check if this is feasible for a while


----------



## electronlandy (2 mo ago)

"An alternative is to read the BMS data via CAN with a micro controller and generate the desired DCL and CCL response curves"

Why go to this additional complexity instead of using the analog outputs of the orion BMS as you already stated in post #58 ?


----------



## agmatthews (Oct 5, 2018)

electronlandy said:


> "Why go to this additional complexity instead of using the analog outputs of the orion BMS as you already stated in post #58 ?


If you wanted to implement a smoother curve style of derating rather than the blunt edged solution offered by the combination of Orion BMS and Netgain/Dana Hyper 9, or something like that.

I’m probably over complicating things, but it’s worth the thought experiment, and some testing on the way to the rubbish bin, with all the other grand ideas…
😁


----------



## electronlandy (2 mo ago)

"I'm sort of already doing this to get the old Land Rover Fuel and Temp gauges to read correctly"

I've done a similar thing with my VCS except I take the motor controller temp and BMS SoC and convert them to a PWM signal to drive the two gauges.


----------



## electronlandy (2 mo ago)

With regards to this bit of the BMS doc










I don't want to use these physical relay outputs so my plan of attack is as follows. 

I already have a custom CAN message setup on the Orion to transmit the DTS status & DC bus current to my VCS. I'll add to this a custom flag byte for the Discharge Enable relay status and the Charge Enable relay status. 

The VCS will then use this data to formulate a status message to send to the motor controller (we know at least it does act on that)










Basically, I'll set the STOP bit whenever the BMS feels that the current limits are not being adhered to.

ie 
if Discharge Enable relay status is off but DC bus current > (some small +ve value)
or 
if Charge Enable relay status is off but DC bus current > (some small -ve value)

In the tau config, the stop status will be set to default to 1 (ie STOP)

This I believe will meet the requirements of the OMS doc and the single point of failure issues. 
ie 
The BMS analog signal lock up, the relay status can still communicated when the BMS detects the CCL / DCL breach
The VSC locks up, no status message sent to the controller, controller defaults stop status to 1.


----------



## electronlandy (2 mo ago)

Has a quick test this eve. I configured analog inputs 22 and 34 as the drive and regen limit inputs. Supplying each in turn with the 5v ref input, I could see both on the live monitor. That was a good start, they do work. Next, for both limits I configured a simple linear graph from zero% at 180mV to 5050mV for 100%. Testing the inputs again against the 5V ref, both limits worked as expected. I then connected both inputs to the respective Orion analog outputs and played about setting manual current limits to ensure it worked end-to-end. All good, so this at least proves the approach is viable at this point.


----------



## electronlandy (2 mo ago)

Do we know the definitive definition of this field here ?










In this thread, its been given a few different definitions. The help file has defined it as something completely different to these in that its only relevant during encoder commission!












If you change the value here and save it, you're prompted with this dialog box:











Any idea what 'PID' parameters are before I start playing with this value to see if it really _IS_ nominal motor current or nominal DC current etc ?
Anybody tuned it down to 20 and pressed the throttle ?


----------



## agmatthews (Oct 5, 2018)

electronlandy said:


> Do we know the definitive definition of this field here ?


One clue is that it’s listed as “Arms” so that _should_ be Amps Root Mean Squared which makes it more likely to be an AC current measurement than a DC one. For this reason and because of the reference to motor commissioning in the help file I’ve stayed away from that setting. 
That dialog asking about PID values also points to it being about the commissioning phase where the controller needs to tune its proportional–integral–derivative control loop mechanism to make sure the motor accelerates or decelerates to the desired speed or torque without over run or under run.
A dialog that gives you an unexpected yes / no choice with out a cancel button to go back scares me a little…


----------



## electronlandy (2 mo ago)

It is bizarre then. Not a single field anywhere that defines a concrete upper limit. What are the percentages a proportion of?


----------



## agmatthews (Oct 5, 2018)

electronlandy said:


> What are the percentages a proportion of


re reading the help file - especially the bit about speed mode vs torque mode - I think the percentages are about limiting motor speed or torque rather than power or current. And in a road going EV it’s all about torque.

So we have the BMS wanting to limit DC current, and - because we also have DC Voltage available - we can calculate this as Amps DC or kW, but we can’t directly limit the motor to either of these because it is set up for controlling motor torque. 

Need to do some research on the relationship between motor torque and power consumption. There may be a nice 1:1 formula that helps us out.

Alternatively we could go back to my favourite rabbit hole and have a device between the BMS and Motor controller that reads the BMS requested discharge or charge current limits in amps and sets the torque limits on the motor as a percentage and then reading the live BMS DC current adjusts the torque limit percentage up or down until the actual current is within the desired range. 

Think of this as analogous to a regular automotive cruise control type of function where we have a desired speed and measured speed available but the only output setting we have a percentage throttle amount. Plenty of examples of this type of control loop are available, mostly as PID controllers in software.


----------



## agmatthews (Oct 5, 2018)

*Regen limiting by analog voltage*

I've had some success with limiting 'torque' by analog voltage input
I have Regen limits working in a fashion, Driving limits still need more exploration

*Extra wires needed*
You need to add extra wires to the standard loom supplied by Netgain to utilise additional analog inputs
In my case I had to add: 
Pin 22 Analog Input 3​Pin 34 Analog Input 5​Netgain did helpfully supply three extra pins for the big Ampseal plug in the Hyper9 controller kit

*Limits accumulate *
The limits in the TAU software appear to be cumulative - this makes sense - if you have more than one limit set up then the system takes the greater limit and applies this
In this case I have a low regen profile set with a max 30% regen braking 
So while the analog input is 'low' the active limit will be set "By operating profile"







and when / if the analog limit increases (by me raising the voltage in this example) then the Active limit switches to "By analog Input" and the % drops even further







​*Setup limits*
To set limits I used the Torque Limits / By Analog Input page 
Its important to understand that the % values on this page are the limits to Torque not the % of the limit, so a value of 80% will allow the motor to regenerate at 80% of its maximum torque
If you want less current you need a smaller % value






​I set the Symmetry Offset to 0mV as this allows a simple ramp rather than a top hat style of limit as you see in the help file
(This top hat style limit profile might be useful for a steering based limit etc)

I also set the first point and second point values at 1V and 4V rather than zero and 5 V as the analog input has some noise on it and you may get unwanted behavior around the zero and 5V levels
I chose 5V as I plan to be driving this from a 5V micro controller 

The blue lines on this page show the current value for each analog input
in this example the 2V signal limits the regen torque to 72% of its maximum







​
For testing I removed the limits on the profile and injected between 0 and 5 V via an external power supply
Logging the data and plotting it in Excel shows the Regen limit reduces as I raise the voltage on the input pin






​So what this gives is a repeatable method for setting a limit to the amount of motor torque that can be used in regeneration
What this does not give us is the ability to simply set a numeric limit to charge current in Amps


----------



## agmatthews (Oct 5, 2018)

*Drive Limits*

Viewing drive limits and understanding their behaviour is not as obvious in the TAU software - mainly because the Active limit stays at 0% when the motor is not turning







​I assume this because the overall Torque limit is 0% when the throttle position is 0%

So opening up the throttle (quite limited throttle in my test setup with the car on the hoist) and logging the data gives the following
This shows the torque limit rises and falls with the throttle and motor speed 








​so If I set the limits to a quite low % to get below that brown line on the graph






​and press the throttle gently (again... because I'm testing on a bench/hoist with no load) while setting the analog voltage high 

Then I see the Torque Limited to 2% by the analog voltage






​Success!


----------



## agmatthews (Oct 5, 2018)

So now we need to map Motor Torque to Battery DC Amps so we can limit Discharge current and Charge current as requested by the BMS by setting Driving torque and Regen torque

This graph from Netgain indicates up to approx 4000rpm the torque and current curves are flat
But what throttle values or load is this measured at? Is it with the motor loaded up on a dyno or a free running?
It certainly does not represent the expected motor current at 1000 RPM in a vehicle rolling along a flat road










I can understand that discharge current is more closely related to motor torque than motor speed or vehicle speed - at least at lower RPMs

Can we have a fixed map of Motor Torque to Battery DC Amps?
Would it be the same in Drive and Regen - or do we need two maps?
or
Do we obtain the DC Amps (via CAN) and keep increasing the Torque limit analog voltage until the measured DC Amps meet the Discharge Current Limit requested by the BMS (again obtained via CAN)?


----------



## MoonUnit (Jun 29, 2019)

I don't know if you've seen this post:

Hyper9 - How to set up variable 'lift off&#039... 

but @SimonRafferty may have found a solution to the % torque to amps problem.


----------

