openinverter forum

I’m away from home until later next week I’ll give it a test when I’m back, does this version still have syncadv but just current values averaged over fewer samples?

johu wrote: ↑Thu Aug 11, 2022 8:20 pm So one change a while ago was taking 8 samples of the two phase current instead of 3 and also I upped sample time from 1.5 to 7.5 clocks. Goal was to make vibration go away. It means current values were about 14us old on that version but are 53 us old on the newer versions. Or are they? I mean it is the average of the 8 last samples. How "old" is that?

Besides that syncadv is calculated with a heavily filtered frequency also to help smoothness.

That would make a lot of sense. Whenever something works well in the steady state but not when things are changing then anything slow to respond is a good candidate.

Bit suspicious of the filtered syncadv. Is is possible that the first bit is deceleration when coming off the throttle causes an error in the calculated syncadv, this error then causes increased deceleration which then causes a bigger error which causes even greater deceleration and so an even bigger error and so on until everything is on the limits. This could continue until the deceleration hit the maximum limit at which point the filtered value would start to catch up and things would return to normal? This same effect might tend to reduce acceleration in FW, is there any sign of this?

Ev8 wrote: ↑Thu Aug 11, 2022 10:39 pm I’m away from home until later next week I’ll give it a test when I’m back, does this version still have syncadv but just current values averaged over fewer samples?

Yes, exactly identical only fewer current samples and faster reaction of syncadv.

Pete9008 wrote: ↑Fri Aug 12, 2022 7:01 am Bit suspicious of the filtered syncadv. Is is possible that the first bit is deceleration when coming off the throttle causes an error in the calculated syncadv, this error then causes increased deceleration which then causes a bigger error which causes even greater deceleration and so an even bigger error and so on until everything is on the limits. This could continue until the deceleration hit the maximum limit at which point the filtered value would start to catch up and things would return to normal? This same effect might tend to reduce acceleration in FW, is there any sign of this?

Yes, something along these lines. Control loop black magic.

Can we produce a freezeframe function that you store many samples spit them out of CANBus and we can reconstruct those graphs?

Then we could simply make a model from the current software with parameters and feed it the live data and check what's going on.
And even better repeat these tests on each change of the code...

With other words. We need recordings.

EV_Builder wrote: ↑Fri Aug 12, 2022 5:34 pm With other words. We need recordings.

I'd agree with this, it would make diagnosing problems easier. Not sure it's a simple job to do though. I had a bit of a think about it while designing my board and concluded that it would need extra hardware.

To be most useful it needs to capture all the inputs to, and all the outputs from, the main control loop on every execution. That way you should have all the important data to figure out what the motor was doing and how the loop was responding. Say a dozen 16-bit variables (a guess but hopefully somewhere close?) at 8.8kHz so around 200kBytes/sec or 2Mbps. This is too much for CAN and too much to buffer on the F103 for more than a fraction of a second. Also any logging code should also be minimally invasive into the inverter software to minimise risk of it introducing, or fixing/changing/moving, problems.

It might be possible to stream it out though the WiFi module which would be a nice solution but I don't know the ESP part well enough to comment (my main worry would be latency and buffering on the module). This would rely on having something connected to WiFi at all times if you want to catch rare or intermittent issues.

My feeling is that the best solution could be an SD card used to store the data to whenever the inverter is running. Few issues with this. First SD cards have a nasty habit of going into a wait state for up to 100ms while doing housekeeping tasks (at least they did last time I streamed data to them - it was a few years ago though and they might have improved since) so to guarantee continuous data you need a 100ms buffer (20kByte in the above case). Also a filesystem saving this much data might be a bit too much additional load for the current processor. Finally I don't think there are the spare pins for the card! Something like a STM32F405 AdaFruit Feather connected to a spare UART and doing all the buffering and file system stuff might do the job though?

I doubt so much is needed. We could start simple and see if its enough or not.
If the ESP could export its graph we have a starting point of values.
If we see the software failing in 10mS steps i also see it failing at 8.8kHz.

So I am currently testing the software posted previously, seems to have helped a little with reducing unwanted regen, however regen it’self is generaly less smooth, smoothness in positive torque seems very similar if anything throttle response is crisper, also regen seems to behave differently than before off throttle regen set to 10% seems to retard more than before and produce more amps but on brake is much less aggressive than it was, previously 40%would push 60-100amps back to the battery and would come on fairly aggressively now I need 60% to generate to same current but it’s much more linear and tappers down with revs. It’s not bad just different. I think this software has helped reduce the control loop oscillation from mechanical slack in the couplings, I will continue testing

Thanks for testing. I did expect some smoothness to be lost. The difference in regen might well illustrate that the motor receives a different id/iq split now.

No problem I will keep testing and see if I’m able to tune around anything

Ok so I know there is progress on this problem now thanks to the simulation thread but I thought I’d update after a week driving on this software, basically no improvement in the lift off regen but I mentioned before how my brake pedal regen was much softer then before, we’ll turns out it was actually some sort of on demand uncontrolled regen I had with 5.17 is with this software and I full charge I noticed I suddenly had no regen until 80% battery, before I pretty much always got regen when braking, checked and my udc max was 316v so the previous software was not abiding to this, anyway here’s hoping to a new software to test soon!

I have just tested this firmware and didn't get unwanted regen! syncadv must be lowered to 0.5.
Performance may suffer but we will work on MTPA to fix that

just some minor mods:
- 3 ADC samples, 1.5 clocks S&H time
- syncadv changed to 0.5
- anti-windup fix

Awesome will try and test this week, the previous changes reducing the number of samples was actually an improvement over previous software once I tuned a the pi controllers better.

What’s the reason syncadv must be 0.5?

Ev8 wrote: ↑Mon Sep 05, 2022 5:54 pm What’s the reason syncadv must be 0.5?

It has always been too high: viewtopic.php?p=44685&hilit=syncadv#p44685

Again, decreasing syncadv does lead to performance loss right now, MTPA has to be fixed to cure that.