openinverter forum

I forgot to ask, when you say more boost, what sort of magnitude did you change it by?

The only quirk that I don't like is not having hill hold like on a Tesla. You just can't seem to get off the brake and onto the go pedal quick enough before rolling back. Even if it's 6 inches it sucks, it's like having a clutch car without an emergency hand brake to hold it while you let the clutch out to hold the car. Other than doing some can bus magic like Jon or getting the idle thing going the only thing I can think off is having a momentary push button to shut off the brake signal to the motor so you can do a little brake torque action in those situations. I would hate to live in San Francisco with this issue. Actually, I would hate to live in San Francisco anyway so it would not be an issue.

jon volk wrote: ↑Mon Sep 21, 2020 9:17 pm I forgot to ask, when you say more boost, what sort of magnitude did you change it by?

I changed boost in steps of 500 untill i was over 7000 and i got to desat again. Wen i fet i got to something i took a step back by 300. It seems too much boost would saturate motor and trip desat.

Roadstercycle wrote: ↑Mon Sep 21, 2020 11:07 pm The only quirk that I don't like is not having hill hold like on a Tesla. You just can't seem to get off the brake and onto the go pedal quick enough before rolling back. Even if it's 6 inches it sucks, it's like having a clutch car without an emergency hand brake to hold it while you let the clutch out to hold the car. Other than doing some can bus magic like Jon or getting the idle thing going the only thing I can think off is having a momentary push button to shut off the brake signal to the motor so you can do a little brake torque action in those situations. I would hate to live in San Francisco with this issue. Actually, I would hate to live in San Francisco anyway so it would not be an issue.

Cant you setup automation section to act as hill hold? I think you have that option in menu. You just need to change time constant and slip constant.
I think that option is called "no brake". So when you lift your foot off the brake some slip and some amps should hold you into a hill.

arber333 wrote: ↑Tue Sep 22, 2020 4:59 am

Roadstercycle wrote: ↑Mon Sep 21, 2020 11:07 pm The only quirk that I don't like is not having hill hold like on a Tesla. You just can't seem to get off the brake and onto the go pedal quick enough before rolling back. Even if it's 6 inches it sucks, it's like having a clutch car without an emergency hand brake to hold it while you let the clutch out to hold the car. Other than doing some can bus magic like Jon or getting the idle thing going the only thing I can think off is having a momentary push button to shut off the brake signal to the motor so you can do a little brake torque action in those situations. I would hate to live in San Francisco with this issue. Actually, I would hate to live in San Francisco anyway so it would not be an issue.

Cant you setup automation section to act as hill hold? I think you have that option in menu. You just need to change time constant and slip constant.
I think that option is called "no brake". So when you lift your foot off the brake some slip and some amps should hold you into a hill.

I think most are running no brake idle. The problem is the latency between reducing brake pressure and the brake light switch deactivating and inverter kicking on is enough time to roll back. This is one of the reasons I went to always on idle and mapping idle throttle to pot2. As soon as you start reducing brake pressure, idle ramps in throttle to help mitigate any roll back.

I did a quick and dirty initial try of deadtime at 120. I have some work to do for further refinement, but I threw a bunch more fslipmax into it to see if it was trip a desat fault. One that one data point it did not, so I think that may be a solution for some of the desat faults we're seeing as you suggested. This may also mean more power can be found since I was hitting desat faults earlier.

Data point of one was just that. Various desat fault scenarios could be replicated at the larger deadtime. I reset back to 63 and am running a slightly higher fslipmin of 1.1

There is still a disparity between flat/moderate slope performance and that on a steep grade. I just ordered a 0-45 degree, 0-5v inclinometer to play with.

EDIT: Acceptable fslipmin definitely appears to be voltage dependent. I have no problem with higher values below 370v, but 397v at the same parameter I introduces surging. I’ll try adding a voltage compensation to see how that works out.

Boxster EV wrote: ↑Mon Sep 14, 2020 9:18 am The below really is very much about fine tuning - overall the car is performing great:


1) Low speed oscillation of the motor when on/off brake - the issue is linked to running automation idlemode in 'no brake' (and idlespeed in a positive number) . This usually occurs when parking the car carefully into a space where low speed control is important. The best way I could describe the symptoms is that It almost feels as if the motor doesn’t know which way to rotate - it just oscillates until the brake is fully released allowing the motor to turn without resistance. I've learnt to live it.

2) I'm getting vibration when pulling away from a standing start at a moderate speed - especially evident when facing uphill. I've been experimenting with lots of settings over the past 6 months and I've not come across anything that makes a difference to improving this 'quirk'. Once the car is moving the motor is very smooth under any conditions and at any speed.

3)Throttle power delivery. It's reactive throughout the throttle range but could be smoother. I've played around ampmin and slipstart with varying success but it's not perfect.

Just to report back. With Jon's help I've now installed the Teensy, CAN shield and brake pressure sensor into my set-up. What's interesting is that despite us both running close to identical configs (LDU model, generation logic board, params, brake sensor etc) the basic sketch from Jon's car was not copy and past into mine. Upon upload, the car had several issues that could be related to the code, or that our hardware generation is somehow different and interpreted the inputs indifferently. Anyway, the code was stripped out to just map fweak and slipmin dynamically over CAN relevant to POT input. The good news is that this has made a noticeable improvement to the control of my car at low speeds, especially when coming off and back on the throttle.

It's early days in testing but initial signs look very positive. I intend to add back in other areas of code relevant to voltage change sensitivities during different SOC and pot2 input. I'll report back.

Boxster EV wrote: ↑Thu Oct 01, 2020 11:43 am Just to report back. With Jon's help I've now installed the Teensy, CAN shield and brake pressure sensor into my set-up. What's interesting is that despite us both running close to identical configs (LDU model, generation logic board, params, brake sensor etc) the basic sketch from Jon's car was not copy and past into mine. Upon upload, the car had several issues that could be related to the code, or that our hardware generation is somehow different and interpreted the inputs indifferently. Anyway, the code was stripped out to just map fweak and slipmin dynamically over CAN relevant to POT input. The good news is that this has made a noticeable improvement to the control of my car at low speeds, especially when coming off and back on the throttle.

It's early days in testing but initial signs look very positive. I intend to add back in other areas of code relevant to voltage change sensitivities during different SOC and pot2 input. I'll report back.

How would you characterize the application of sensors, inputs and code? Do you use some oscillation dampening like PID in your teensy code?
Because then you could also add that code into the existing sine code.

arber333 wrote: ↑Thu Oct 01, 2020 11:57 am
How would you characterize the application of sensors, inputs and code? Do you use some oscillation dampening like PID in your teensy code?
Because then you could also add that code into the existing sine code.

The dumpster fire called code is here. https://github.com/jonvolk/LDU_CAN

Its really way more remedial than any PID loops.

With some comments about startup performance under very small slip values, I started looking at things from another angle. I decided to move fweak around as a test. Lower values were uncontrollable, but throwing it up to 400hz was a dramatic improvement in low speed scenarios and allowed for a 1.8-2.2 fslipmin value. It also allowed for strong/smooth startup on hills. Boost is also increased to around 1700. This of course came a large penalty for overall power. The primary improvement has been around mapping fweak to pot in combination with my previous fslipmax limitation at low speed/low-mid throttle. I spent about a week with this setup and never once had to think about HOW i was driving the car and didnt have any urge to break out the laptop.

Tuning has taken a small detour due to a matter that Ill post about shortly.

I also need to do another refactor of the code to simplify things and remove some unused variables that bled over from my VCU.

jon volk wrote: ↑Thu Oct 01, 2020 3:39 pm

arber333 wrote: ↑Thu Oct 01, 2020 11:57 am
How would you characterize the application of sensors, inputs and code? Do you use some oscillation dampening like PID in your teensy code?
Because then you could also add that code into the existing sine code.

The dumpster fire called code is here. https://github.com/jonvolk/LDU_CAN

Its really way more remedial than any PID loops.

With some comments about startup performance under very small slip values, I started looking at things from another angle. I decided to move fweak around as a test. Lower values were uncontrollable, but throwing it up to 400hz was a dramatic improvement in low speed scenarios and allowed for a 1.8-2.2 fslipmin value. It also allowed for strong/smooth startup on hills. Boost is also increased to around 1700. This of course came a large penalty for overall power. The primary improvement has been around mapping fweak to pot in combination with my previous fslipmax limitation at low speed/low-mid throttle. I spent about a week with this setup and never once had to think about HOW i was driving the car and didnt have any urge to break out the laptop.

Tuning has taken a small detour due to a matter that Ill post about shortly.

I also need to do another refactor of the code to simplify things and remove some unused variables that bled over from my VCU.

Maybe ZeroEV or EVWest have a stock gearset laying around for you from swapping in those 4.5:1 aftermarket ratios.

They do and I’m considering that as well as some other options. They want a fair bit for it, but it’s completely reasonable considering the value to them in rebuilding units for sale as systems.

On my SDU setup, I worked on the slip parameters tuning recently, to avoid very fast inverter temperature rise, and doing this I somehow managed to eliminate vibrating and weird oscillations (is that what you call quirks ?) at very low throttle and low speed.

I suspect the slipstart value to be involved : it's now around 18.
I assume the fslip value is going from min to max above this throttle position, so driving with a throttle oscillating around this slipstart value might generate motor vibrations, but that shall be confirmed with the software algorithm to understand which value is used under the slipstart value.

I think I had issues with lower values (10-14), but as I was working on acceleration and torque performance, the very low speed issues were not my first concerns, so I tried various combinations of fslipmin, slipstart, iacmax until all conditions were optimized.
Then I noticed weird behavior on low speed, which disapeared when I rose the slipstart value. I also got some regen back doing this.

All this to say this parameter might to be part of the game for several functions/behavor/issues.
I need to read the software again and check how it's really being used.

ManuFromParis wrote: ↑Tue Oct 06, 2020 12:40 am On my SDU setup, I worked on the slip parameters tuning recently, to avoid very fast inverter temperature rise, and doing this I somehow managed to eliminate vibrating and weird oscillations (is that what you call quirks ?) at very low throttle and low speed.

I suspect the slipstart value to be involved : it's now around 18.
I assume the fslip value is going from min to max above this throttle position, so driving with a throttle oscillating around this slipstart value might generate motor vibrations, but that shall be confirmed with the software algorithm to understand which value is used under the slipstart value.

I think I had issues with lower values (10-14), but as I was working on acceleration and torque performance, the very low speed issues were not my first concerns, so I tried various combinations of fslipmin, slipstart, iacmax until all conditions were optimized.
Then I noticed weird behavior on low speed, which disapeared when I rose the slipstart value. I also got some regen back doing this.

All this to say this parameter might to be part of the game for several functions/behavor/issues.
I need to read the software again and check how it's really being used.

Can you post your parameter file?

Boxster EV wrote: ↑Thu Oct 01, 2020 11:43 am

Boxster EV wrote: ↑Mon Sep 14, 2020 9:18 am The below really is very much about fine tuning - overall the car is performing great:


1) Low speed oscillation of the motor when on/off brake - the issue is linked to running automation idlemode in 'no brake' (and idlespeed in a positive number) . This usually occurs when parking the car carefully into a space where low speed control is important. The best way I could describe the symptoms is that It almost feels as if the motor doesn’t know which way to rotate - it just oscillates until the brake is fully released allowing the motor to turn without resistance. I've learnt to live it.

2) I'm getting vibration when pulling away from a standing start at a moderate speed - especially evident when facing uphill. I've been experimenting with lots of settings over the past 6 months and I've not come across anything that makes a difference to improving this 'quirk'. Once the car is moving the motor is very smooth under any conditions and at any speed.

3)Throttle power delivery. It's reactive throughout the throttle range but could be smoother. I've played around ampmin and slipstart with varying success but it's not perfect.

Just to report back. With Jon's help I've now installed the Teensy, CAN shield and brake pressure sensor into my set-up. What's interesting is that despite us both running close to identical configs (LDU model, generation logic board, params, brake sensor etc) the basic sketch from Jon's car was not copy and past into mine. Upon upload, the car had several issues that could be related to the code, or that our hardware generation is somehow different and interpreted the inputs indifferently. Anyway, the code was stripped out to just map fweak and slipmin dynamically over CAN relevant to POT input. The good news is that this has made a noticeable improvement to the control of my car at low speeds, especially when coming off and back on the throttle.

It's early days in testing but initial signs look very positive. I intend to add back in other areas of code relevant to voltage change sensitivities during different SOC and pot2 input. I'll report back.

Just to provide further feedback from the past week. Thanks to Jon, Throtramp variable has now been added in over CAN. My Teensy is dynamically managing Fweak, Slip and throtramp.

I’m struggling to find ANY quirks in terms of general drivability once the inverter is ‘on’. Power delivery is extremely controlled at low speed and smooth throughout the entire rev range.

We’ve seen an ambient temperature drop of nearly 10 degrees over the past week, and I’ve not noticed any difference in the car’s behaviour, full or empty SOC.

The next step is going back to try and (re)introduce mapping idle throttle to pot 2.

If anyone wants to play with this stuff on your own without breadboards, I’ve got a couple of these available.

viewtopic.php?f=12&t=1129

Sign me up!

Jack Bauer wrote: ↑Sat Oct 24, 2020 3:02 pmSign me up!

I’ll shoot ya an email next week. If you send me your json and any can settings messages you already have configured I can get some semblance of a working .ino for ya.

That's great thanks.

Boxster EV wrote: ↑Mon Oct 12, 2020 1:09 pm Can you post your parameter file?

It was posted there :
viewtopic.php?f=10&t=195#p17143

ManuFromParis wrote: ↑Sun Oct 25, 2020 8:44 pm

Boxster EV wrote: ↑Mon Oct 12, 2020 1:09 pm Can you post your parameter file?

It was posted there :
viewtopic.php?f=10&t=195#p17143

I can’t comment on the over temperature issues you faced. On my set-up I run the coolant through a large radiator and never faced an issue once the air was all gone.

However, all of the issues I encountered on my LDU were with low down torque (vibration, overcurrent, bucking) - All minor but irritating. The smoothest static settings I achieved meant that slipmin was at 1.1, fweak at 250 and boost at about 1650. It was a constant balancing act with several factors (too little slipmin caused vibration but too much caused bucking, too much boost caused overcurrent but too little effected power etc).

If you can’t satisfy your needs with static parameters, I’d suggest try manipulating them on the fly over CAN with Jon’s set-up.

The confidence of being able to floor it at the lights with no overcurrent fault is sensational. Conversely, driving at low speed with total smoothness and control is a dream.

johu wrote: ↑Mon Sep 14, 2020 4:43 pm This is pretty awesome. I don't understand much of it to be honest but I wonder if it could be integrated into the firmware for people who don't have a VCU?

So I thought I'd revisit this. As what initiated this thread, Ive still been running some CAN based parameter mapping on my LDU board. This has resulted in very smooth operation without any real issues to speak of in function. Im still running a Teensy based VCU in the car and as the list of connected CAN devices has grown, along with adding more functions to the overall code, the Arduino abstraction (along with my poor optimization) is adding noticeable lag in moving messages where they need to go. Since fweak is one of the parameters that is changed with throttle input, a lag here can in rare occasions result in an overcurrent trip with a fast whack of the throttle since creates a higher change "step" than desired.

My first fix was to start porting the code over to one of Damiens F105 boards as I'm trying to focus on ST based hardware now. In doing so, I decided it would be more efficient and faster (possibly safer) to hard code the changes per Johannes interest above.

Below is an incorrectly branched version of 4.97 firmware. I probably should have done it the "correct" way, but this was a clone that was simply re-initialized locally. Before attempting to run this on an actual motor, Id like to request Johannes give it a quick once over and let me know if there's any glaring issues that may cause undesired behavior.

The changes themselves are pretty simple and limited to 3 files. mymath.h, stm32_sine.cpp and pwmgeneration_sine.cpp. In mymath, I added the macro for a MAP function which is taken from the Arduino. Understanding that should hopefully add some logic to the rest. I have affectionately flagged any changes with comment "TRASH" to easily locate. Also note that anything pulling a "pot" value is obviously based off my throttle calibration currently.

https://github.com/jonvolk/stm32-sine_LDU

Take a peak and let me now if theres a high probability in switching in a backup inverter

Just taking a peek. Some comments
- in line 416 you compare a fixed point value with an integer. I think you want to write "Param::GetInt()" instead
- line 549, 544: unfortunately floating point is not supported. So FP_FROMFLT(0.45) converts to fixed point. Also GetInt() again
- Also could you rewrite with potnom so it is more universal?
- pwmgeneration-sine, 103: is that just a copy? You mapped value should already appear in fweakcalc
- MAP macro probably needs rewrite with FP_MUL and FP_DIV macros because it is processing fixed point values

Not the biggest fan of the fixed point macros myself. It is super fast but ugly to use. Attempted to write a fixed point cpp class but that always turned out more complicated than anticipated.

johu wrote: ↑Sat Apr 10, 2021 5:13 pm Just taking a peek. Some comments
- in line 416 you compare a fixed point value with an integer. I think you want to write "Param::GetInt()" instead
- line 549, 544: unfortunately floating point is not supported. So FP_FROMFLT(0.45) converts to fixed point. Also GetInt() again
- Also could you rewrite with potnom so it is more universal?
- pwmgeneration-sine, 103: is that just a copy? You mapped value should already appear in fweakcalc
- MAP macro probably needs rewrite with FP_MUL and FP_DIV macros because it is processing fixed point values

Not the biggest fan of the fixed point macros myself. It is super fast but ugly to use. Attempted to write a fixed point cpp class but that always turned out more complicated than anticipated.

Ill take a dive at comparison issues later today.

On the pwm-generation file, yes, its generally a copy but using fweakcalc instead since thats what was called for in the original code. I guess I was concerned that there was a conditional statement somewhere that might not scale the fweak and change it without any ramping. So, if I change the pwmgeneration file back to it's original state, it should be fine with all changes to fweak being done in the stm32-sine file? In hindsight despite both having an s32fp fweak variable, they are confined to the local scope so what you're saying makes sense.

Would it be cleaner to just call the MAP as a function like originally intended with the Arduino code or is it still better trading elegance for speed here? I only converted it to a macro to fit the current custom math structure.

On the values using pot, I believe potnom is already a throttle ramped value so perhaps it would be better to utilize pot min/max values to get to the same approximate raw throttle percentage input.

Appreciate the feedback.

*EDIT Im not even sure why I tried to use a float in the macro since that .45 value is just a 1 in my current VCU code. Thats probably what I get for re-typing it rather than pasting. The original version requires int values as well.

Did a quick update that I think is directionaly correct on the feedback.

Replaced Param::Get with Param::GetInt to ensure we're calculating/comparing integer values.

Put PWMgeneration file back the way I found it.

The only float that I need is the low throttle input value. I used FP_FROMFLT(.45), which I'm not 100% confident I used correctly.

Replaced "pot" with new variable potPrcnt which inputs pot min/max to come up with a 0-100 value based on current pot value. This calculation probably already existed elsewhere, but Im trying to keep changes localized as possible.



Again, thanks for the feedback.

Figured out the compare between commits to make it easier to see.

https://github.com/jonvolk/stm32-sine_L ... ...2eb9143