Could it be that in map 3 the ramping is not used, so you could be getting quite big jumps in torque requests?

Ok I will try to explain: The idea is based on how a basic ignition map works in an ice, - return an advance value based on input of speed and load. The maps act like a spread sheet for us to look up and return a value based on 2 inputs; for the x axis (columns) this is the throttle position as read...

Yes it should be a lower number, I'm not sure where you are doing the flip for reverse now, in OEM orientation -20 should map to -200nm at 100% pedal. Throttle position is just to add a little extra dead zone to the pedal to catch accidental blips, you could set this to 1. Personally i would keep to...

Yes that's the torque and speed limit in reverse.

Change the -6 for more torque

No not public, agree that unofficial code can cause a lot of headaches!

I always change the version number as well so it's easier to spot if these things get in to the wild.

I can send you a version with a hardcoded value for testing purposes.

What zombie fw are you currently using?

Ok so I think we can say your application does not need any ramping to control wheelspin. I would suggested removing it and simplifying the code, your fork is quite far from mine now so It's hard to debug any issues you are having I would be interested to see if you can actually command (and get) mo...

I have the same temp over read on mine also whilst bench testing. Temp shoots up once the motor is turning. I came across some other instances as well notably: https://openinverter.org/forum/viewtopic.php?p=50409#p50409 I've tried moving the bytes where this temp is taken from in the code but no suc...

Did you also change or comment out the over torque check in the code?

I ask as a value of 15 in the map would be 150% of 200nm so 300nm
Would be interesting to see how much the inverter thinks it's putting out.

That's odd.. the built in flash is all I've ever used.

Could be a library mis match or something, if I get a chance I'll try building your code here to see if I can replicate.

Hi Arber, Good to hear you are driving. For the low power in the different modes you should play with the maps to get the response you want. I would suggest using all 1's in map 3 this will give a straight mapping of pedal position to torque, ie 50% pedal 100nm torque. To note there is also no torqu...

Hi Mark,

I would be most grateful to acquire your latest PCBs if you have any available

drop me a PM with your details, I have VCU boards but no BMS ones..

Hi Arber, I will take a look at your code and report back if i spot anything. As for the regen, the basic idea is a regen value is acquired from the map using throttle position and speed. There are some delays and everything gets incremented to ensure smooth driving. I found all the above necessary ...

MinTorque is not used in the code. Not sure on why the fan is not turning on, does it work using the test options. Well the you could be getting de-ratted as there is no specific values for max discharge. There should not be a condition where the motor 'sticks' i suspect something do with the mounti...

Small but very important detail, this is all coded for normal oem orientation. Rather than reversing all the code it might be worth just inverting the incoming RPM messages void canRX_289(const CAN_message_t &msg) { motorTorque = ((((msg.buf[0] * 256) + msg.buf[1]) - 10000) / 10); // Motor Torqu...

I actually don't know, I've not really tried to exceed the published torque.

It's more than I need in my application.

I limit speed in reverse by setting torque request to 0 when in reverse this works well for me but not exactly smooth. if (motorRPM < -2000) { torqueRequest = 0; } } In all cases if torque goes outside of the accepted norms ( -+200nm) then we set torque request to zero There is also a crude step dow...

BMS_packvoltage is voltage as read from the BMS. No the VCU will not go in error state if pre-charge conditions are not met, in fact there is currently no max pre-charge time so it will just sit there waiting for the conditions to be met. The only exception here is if pre charge happens too quickly ...

Good to hear your are making progress. regarding the pre-charge timers, the first one is a normal minimum time for pre-charge to occur and the second is to measure how long the pre - charge took, if it happens too quickly it could indicate a problem, or that you just turned the car on and off again ...

Does it work using the output tests from the menu?

I've certainly damaged a few teensy whilst prototyping, but not once in the board. In all cases though the board has been completely unresponsive rather than just damaging an output.

My inverter is also P/N 9410A163.
I'll take a look at your log and see if I can make sense of it.

Hi Arber, First off the reverse code is in the reverse swich case: digitalWrite(OUT12, HIGH); // Turn on the reversing lights if (throttlePosition > 5) { torqueRequest = throttlePosition * -6; // lets make the pedal less responsive inverterFunction = 0x03; if (motorRPM < -2000) { torqueRequest = 0; ...

Hi Sorry for the lack of interaction, I'm traveling with work and have limited time at the moment. To answer a few questions - This is all coded for the motor mounted in the OEM position, so positive values will spin forward negative will spin backwards. My application uses motor and diff connected ...

Hi good work on the speedo :) I hope I have understood you correctly and i will try to explain; Ok so the way I thought this should work is the charger is controlled by the BMS and the VCU simply listens to a can message from the BMS telling it to go in to charging state (6). Now I think we covered ...

D39 and D38 are right next door so could jump across to those.

Before doing that can you test the teensy on a bread board or similar?
The diodes are there for input protection as we all know how easy it is to kill one of these boards.