Inverter Firmware 5.35.R

[johu]

After a long time there is finally a new release that fixes various issues that had accumulated in the last months

https://github.com/jsphuebner/stm32-sin ... ag/v5.35.R

• Speed dependent regen pedal travel, use maxregentravelhz
• Bugfix i3 hardware
• Support pin swap (only PWM channels) in sine firmware also
• Improved sampling of analog values (use second ADC)
• Added limiter cruise mode
• Fix terminal problems causing lockup or even watchdog reset
• On Prius inverters ignore break signal when ocurlim==-1
• More reliable pressed throttle detection
• Smoother over temperature derating
• Limit potmax to 3500 to prevent using over range pedal connection
• Add uptime counter, can be used as CAN alive counter
• In SINE firmware filter idc for smoother battery current derating

So it's got the nicer throttle curve by @mane2 reducing regen travel below a certain speed.
Supporting pinswap in sine firmware should be a way to prevent having to swap A/B channels mostly on the LDU. Please test
I also introduced a limiter cruise mode that lets you set a maximum rpm over CAN and throttle is cut back when reaching it. Sort of like an early fmax. I have tested this on the desk not in the car, Please test
On Prius2 inverters it is now possible to ignore the fault signal as it causes some spurious shutdowns on some inverters
Temperature derating now starts cutting back 10°C before reaching the limit.
The added uptime counter should allow you to assemble the OI control message (without CRC) with standard CAN mapping (map potnom as TX with offset as pot and pot2 are unmapped at startup)
And finally I've introduced an IIR filter to the idc calculation which should smooth out battery current limiting.

Please test and report

[grgumxlm]

Tested with esp32 and esp8266. Works as expected

Hardware

Software

[nickyivyca]

Upgraded directly from 5.27. What does 'BrakeCheck' state mean? Currently attempting to send brake over CAN, though I would think there should still be a way to use the physical brake input without using the CAN messaging.

Also, how should I implement the CAN crc, given that the example is given for a 32 bit calculation, but our input value here is 64 bit? Here's the example from the wiki, should I just change it to run for 64 bit values and then still use the lowest 8 bits or is there more to it?

Code: Select all

static uint32_t crc32_word(uint32_t Crc, uint32_t Data)
{
  int i;

  Crc = Crc ^ Data;

  for(i=0; i<32; i++)
    if (Crc & 0x80000000)
      Crc = (Crc << 1) ^ 0x04C11DB7; // Polynomial used in STM32
    else
      Crc = (Crc << 1);

  return(Crc);
}

[johu]

BrakeCheck means it wants to see the brake input go high once.
For CRC you fill your 8 bytes/2 words and leave the CRC byte at 0. Then take CRC of the 2 words, mask it with FF and put it in the last byte. Like here https://github.com/jsphuebner/stm32-car ... r.cpp#L471

You still need to implement a 2-bit counter to get rid of the CANCOUNTER message

[nickyivyca]

Was able to get CAN and brakecheck up and running, I was missing the second counter (only had the bits 30-31 enabled at first). Then after adding that it still was not working, but then after fiddling around but overall changing nothing it started working - I imagine it may have been something to do with not starting my software and the inverter up at the same time so that the cancounter was randomly stepping back to 0 in the view of the inverter.

Was also able to get crc working, my non-STM code here (I need inverterCANsend because of requirements of mbed). crc function from here as linked in wiki.:

Code: Select all

union bytes {
    uint8_t bytes[8];
    uint32_t words[2];
    uint64_t bits;
} inverterCAN;

uint8_t* const inverterCANSend = inverterCAN.bytes;

uint8_t canrun = 0;

.....

      inverterCAN.bits = 0;

      inverterCAN.bits = (*DI_BrakeSwitch << 26) | (*DI_ReverseSwitch << 29) | ((uint64_t)(canrun & 0b11) << 30) | ((uint64_t)(canrun & 0b11) << 46);

      uint32_t crc = 0xffffffff;
      crc = crc32_word(crc, inverterCAN.words[0]);
      crc = crc32_word(crc, inverterCAN.words[1]);

      inverterCAN.bytes[7] = crc & 0xFF;

      canBus->write(CANMessage(0x3F, inverterCANSend, 8));
      
      canrun++;

But, not getting any regeneration, either with one-pedal type regen or with brake pedal, even with maxregentravelhz set to a few different values (I tried 0, 1, 50, 200hz), and also tried switching direction such that inverter direction is forward (I normally operate in SwitchReversed so normal inverter direction is reverse). Any possible reasons why? Should maxregentravelhz=0 result in the same behavior as previous versions?

[johu]

On first glance it looks like you're sending regenpreset=0
Yes max... hz=0 results in legacy throttle map

[Boxster EV]

A few days ago I updated from sine 5.20 to 5.35 for my Tesla large drive unit. I did this with hex file via ST Link and some previously planted fly leads as I don’t trust the board’s wifi module.

The new firmware has a very different motor performance output. With the same parameter file, It’s fast., very fast. Dare I say too fast. So much so, I’m worried about breaking my drive shafts or killing the inverter. I’ll adjust my slip settings in the coming days to make less powerful.

Very pleased.

[glink]

Hi, for FOC implementation, only way to tweak field weakening seems to be fwcurmax since ffwstart is deprecated. I would really like to have some way to control the startup as I'm using field weakening to get higher RPM on my boat propeller. Now field weakining kicks in pretty much from start, so going from 0 RPM to MAX RPM within only a couple 100s difference in Pot. If I carefully find the lowest Pot that will spin the motor, it has a lot of oscillation. For the SINE implementation there is parameter fweakstrt with description "Fweak value at potnom < 35%. Can improve low speed stability and reduce oscillation when set higher than fweak. Set equal to fweak to disable." Something like this for FOC would be great. Or is there a way to do it with the current implementation?

[johu]

Have you tried "boat mode"?

I'm currently away but I think it's activated by setting cruisemode to Pot. Then set speedflt=0 or maybe 1 and tweak speedkp until you have stable rotation. Would love to hear back from that

[ElMaco]

Have you tried "boat mode"?

I'm currently away but I think it's activated by setting cruisemode to Pot. Then set speedflt=0 or maybe 1 and tweak speedkp until you have stable rotation. Would love to hear back from that

Super interesting! We will check this as well.

[ElMaco]

Have you tried "boat mode"?

Is the boat mode documented anywhere? The only mention I find is in the release notes for 5.20 on GitHub.

[Ev8]

Does this firmware allow me the share the analog throttle attached to one oi board to another oi board?

Obviously pre Crc I would just map the throttle pots across can, not sure I understand if the added uptime counter makes this possible or not?

[glink]

Have you tried "boat mode"?

I'm currently away but I think it's activated by setting cruisemode to Pot. Then set speedflt=0 or maybe 1 and tweak speedkp until you have stable rotation. Would love to hear back from that

Thanks. Will test, but not at the boat ATM. If I do not apply field weakening, RPM increases linearly with POT up to max RPM (about 850 on 48V), so I'm also thinking about setting fwcurmax over CAN when I want more RPM than 850, but haven't tested if this will take effect immediately or if it requires a reboot.

[johu]

It will take effect immediately so you should increase it slowly

[ElMaco]

Have you tried "boat mode"?
...
Would love to hear back from that

We were at our boat today and tested a bit.
The thing that struck us most was that we couldn't get the motor to spin backwards in "boat mode". Possibly, and perfectly reasonable, this is because "boat mode" is based on the cruise control function.

Please let me know if anyone knows how to get the motor to spin backwards in "boat mode". Because of this we are back to "car mode" and torque control instead of speed control.

Also realized that since 5.35 you must have the in_break signal high to get the in_start signal to take. I understand the benefits of this in a car, but at first it seemed as a problem in our boat application as we don't have breaks. Fortunately the OI was satisfied with in_break and in_start going high at the exact same time. My workaround was to wire in_start and in_brake togther. This seems to work fine since I have a push-button for in_start.

Other than the things mentioned above I am very happy with 5.35. Don't know exactly why, but it seems more "exact" in the throttle control.

Just some short notes from my first encounter with 5.35 and "boat mode".
Thanks for great work to everyone involved!

[Zieg]

Also realized that since 5.35 you must have the in_break signal high to get the in_start signal to take.

I think that's only if you have cruise control enabled. I don't have it enabled and don't have to hit the brake. Guess it's kind of unavoidable here?

[johu]

Try combining it with potmode Bidir

[ElMaco]

I think that's only if you have cruise control enabled. I don't have it enabled and don't have to hit the brake. Guess it's kind of unavoidable here?

Great input! Will check if I have CC enabled.
Thanks!

[ElMaco]

Try combining it with potmode Bidir

Thanks for the tip!
Unfortunately we have already a Curtis ET-134 FNR Throttle kit installed. It gives F signal and throttle if pushed forward, and R signal together with throttle if pushed backwards.
It’s very convenient as it has a mechanical “click” at neutral so you know that you are in a “non spinning state”.
If it can’t be solved in any other way, I’ll consider to rip the ET-134 out and replace it with a pure throttle stick and try Bidir.

[jsimonkeller]

I’ll adjust my slip settings in the coming days to make less powerful.

Boxster, I wonder if you have made those adjustments to your parameters yet? If so, would you mind posting them?

Your parameters have always worked very well on my 911SC with the Tesla large drive unit and I would love to try them out with the new firmware and then tweak from there.

[Boxster EV]

My file is here.

params.json

(1.68 KiB) Downloaded 593 times

[Zieg]

Okay, two quick questions:

1. I'm getting unwanted acceleration again, at higher speed (far into field weakening). But this time it's only happening after hard acceleration. If I gradually accelerate it doesn't happen. If I go WOT and then release the pedal, it will happen. Could this be a syncofs issue? I backed it off by 500 with the same result. I was pretty confident I had it adjusted close to perfect though, since I was able to run the manualid current right up to the point of desat without wheel movement. I haven't experienced this before updating to 5.35.

2. I know regen values are expressed as a percentage, but what's that a percentage of? I seem to be maxing out at about 3kW, regardless of whether I set the regen to -30% or -80%. What are others getting with their leaf motors?

[johu]

Sounds not good. Which speed are you running? I've limited to 7500 rpm.
syncofs isn't something you back off only something you get spot on or not.
Now, since you seem to dare spinning it faster than I do could you try increasing syncadv from 10 (the default) to 11? My finding was the lower syncadv the higher the danger of unwanted acceleration.

[Zieg]

Oh, interesting. I just did a quick calculation and it looks like it was happening around 8000 rpm (110 kph). I did notice that when my syncofs was too high (like several thousand too high) it would try to accelerate on its own, so I thought maybe the starting value too high plus the addition of syncadv was causing the acceleration.

Good idea adjusting syncadv, I will give that a shot!

[nickyivyca]

On first glance it looks like you're sending regenpreset=0
Yes max... hz=0 results in legacy throttle map

Can confirm this indeed fixed it.

I will say, with my 914, I still have the clutch so I get to 'test' the runaway protection sometimes when I shift at high enough RPMs. I was previously on 5.27 and now it seems less prone to runaway with 5.35 - with 5.27 if I pushed the clutch in at high RPMs and then shifted and put the clutch back in, sometimes it would still be running away even after putting the clutch back in (and doing a bit of a 'clutch burnout'). With 5.35 I can still experience a bit of a surge sometimes when shifting in similar conditions, but I haven't seen the 'clutch burnout' behavior anymore. I think I am currently running syncadv of 9, I will try moving this around a bit and see what it does.