motor does not reach max speed like old Gen2.x binary

[RoboDurden]

continued from #4 (comment)

In the past, I had problems with SimpleFOC due to the limited speed of the encoder readings. The Arduino interrupt handling code has a lot of overhead, made worse by the various processor layers. If the code handling the hall sensors is not fast enough, speed is limited by that. And we are using a 48MHz processor, pretty slow all considered.

I don't have time today, though. Over the weekend, I'll look at ways to speed up the interrupt handler and see if that improves anything.

I might be easier to slow down the hall sensor reading artifically and see if that has an effect on the motor max speed :-)

[Candas1]

I am still not sure if the sensor alignment is good.

One way to check this is described here

Do you see/hear differences in how the motor spins in each direction with both binaries?
A wrong offset could lead to phase advance in one direction, and phase delay in the other direction.

[RoboDurden]

you can hear in the video for yourself but no the sound is the same.
The current however is about 540 mA spinning "left" and about 580mA spinning "right".
So there indeed is some asymmetry

Good night ! i am tired now and i still want to finish the rewatch of https://en.wikipedia.org/wiki/The_Hunt_(2012_film)
Good dvd...

[robcazzaro]

@RoboDurden can you please do a quick test

Add the following to the plaformio.ini file

build_unflags = -Os
build_flags = -Ofast

It compiles the binary with the highest level of optimizations possible, and if my theory is correct (slow interrupt), it should speed up the motor by a small but measurable amount.

Meanwhile I'm looking at the interrupt code

[RoboDurden]

@robcazzaro , I would rather do that tomorrow when I have arrived at my solar warehouse. I have already packed the test setup in a box. And my notebook is occupied with 3d printing..

[RoboDurden]

If the effect is small i will need UART rpm logging and I have yet to setup that again.

[robcazzaro]

@robcazzaro , I would rather do that tomorrow when I have arrived at my solar warehouse. I have already packed the test setup in a box. And my notebook is occupied with 3d printing..

Of course, I didn't mean "right now" 😉 whenever you have time, no hurry

I saw a few Android apps that can measure RPMs if you stick a white tape to the wheel, maybe that is easier than enabling UART. I mean, UART is good to have, but an RPM meter app might be a quick way to see if there are differences

[robcazzaro]

@RoboDurden I understand the interrupt handling code pretty well now, and there are a few hacks that would speed things up. But it requires a few changes to a few files and possibly breaking compatibility with the official GD32 core.

If, whenever you have time, you can confirm that compiling with -Ofast (the platformio.ini changes above) makes a difference, I will send you the modified files. Otherwise there's no point in having you waste time with the changes.

[RoboDurden]

Okay that were my changes:

;build_flags = -D __PIO_DONT_SET_CLOCK_SOURCE__
;	-D __SYSTEM_CLOCK_48M_PLL_IRC8M_DIV2=48000000
build_unflags = -Os
build_flags = -Ofast	

I did not hear a higher speed and android apps do not use camera but inernal IMU and you have to put your phone on the turntable..

But current was sligtly less. before 590mA and 550mA (left/right) and with your requested changes: 550mA and 500mA

So i recorded the audio: www.robosoft.de/forums/rpmsound.mp3
first you hear simpleFOC-old left/right, than your new ini file left/right, and last the gen2.x left/right
And i made a fft analysis from the constant part of all three left(?) sounds:

So yes, your requested ini changes result in a 476 Hz / 456 Hz = 4.3% speed increase,
but the gen2.x still has another 547 / 476 = 15% rpm increase on top of your changes.

This was a long sunday for me. Got 3.5 kW old solar panles for free:

Good night and good luck :-)

[robcazzaro]

That is really good news @RoboDurden. We can confirm it's a IRQ overhead issue. I will send you a couple of file to try before my end of day (overwriting the existing one for now). Thanks for doing this, and clever use of the audio, well done!

Just FYI: the GD32 Arduino core has some weird behavior with the interrupts, I opened an issue in their repository to be sure CommunityGD32Cores/ArduinoCore-GD32#105.

TLDR:
The GD32 interrupt handler (at a hardware level) groups GPIO 0-1, GPIO 2-3 and GPIO4-15 as separate interrupt source. So the EXTI01 handler must check if GPIO0 or 1 fired. Same for EXTI23. The problem is that any interrupt for pins 4 to 15 fires only one interrupt, and the handler must scan all 12 possible sources to see which one fired. So the HALL sensor on PB11 takes a long time, and the one on PC14 even more. The easy hack is to only check for pin=11 or pin=14 in the EXTI4-15 handler (which makes the code much, much faster), but I wanted to fully understand the GD32 logic for multiple ports and pins before messing with it.

Also opened CommunityGD32Cores/ArduinoCore-GD32#106 to see if we can speed up the IRQ handler without having to change the GD32 Arduino files

Bottom line: as long as we know what interrupts we need for GPIO pins change, we can easily speed things up, and I have working code. Just want to finish testing it

[robcazzaro]

Ok, here are 3 files to replace whenever you have time @RoboDurden

C:\Users[yourname].platformio\packages\framework-arduinogd32\cores\arduino\gd32\gpio_interrupt.c
[project_dir].pio\libdeps\GD32F130C8\Simple FOC\src\sensors\HallSensor.h
[project_dir]..pio\libdeps\GD32F130C8\Simple FOC\src\sensors\HallSensor.cpp

Please note that one is in the platformio GD32 platform directory, the other 2 in the project directory. And please check that the changes are compiled. Incidentally, the VS Code UI sometimes gets confused by all the nested defines, so in the gpio_interrupt.c file, the portion following `#elif defined(GD32F3x0) || defined(GD32F1x0)" is shown as disabled (greyed out), but it's active and gets compiled (GD32F1x0 is defined). It's a VS code UI bug. That one is the file I hope not to have to change thanks to this

Please also keep the -Ofast optimization enabled for now. It will make debugging harder, but a 4% gain is non-trivial. There are further optimizations possible in the Hall sensor code (updateState()), but those require more thinking. The ones I did for now are pretty safe.

If anything is unclear, just ask. I tested everything and it seems to work as expected, but it would not be the first time I screw up 😊

hall_IRQ.zip

[robcazzaro]

BTW: I have been looking at other ways to potentially speed things up, but would require changes here and there. If the interrupt enhancements are not enough, I have a few more things to try. But the GD32 at 48MHz is slower than most other processors recommended for SimpleFOC, so we might have to hand-optimize more. To be fair, the FOC algorithms are more compute-heavy than the type of control implemented by most hoverboards

[Candas1]

Don't be pessimistic, I am sure we will get there.
We are not doing foc yet, but I assume that the boards with current sensing had foc implemented.

We for sure will have to optimize because of the arduino-gd32 and simplefoc overhead.

[RoboDurden]

no, the new three file do not make a difference:

The gen2.x also has a speed difference with left/right, but only 0.7%.
the simpleFOC has 1.5%.

I think the gen2.x has no interrupts for the three hall sensors at all but simply reads the state in the bldc.c 16 kHz CalculateBLDC():

	// Read hall sensors
	hall_a = gpio_input_bit_get(HALL_A_PORT, HALL_A_PIN);
	hall_b = gpio_input_bit_get(HALL_B_PORT, HALL_B_PIN);
	hall_c = gpio_input_bit_get(HALL_C_PORT, HALL_C_PIN);

So i do not really think that the three hardware interrupts from HallSensor class take longer or are less accurate ?

The EFeru FOC is faster than the Gen2.x anyway and with field weakening it can get even faster (20%). So maybe we should procceed with current sensing to get simpleFOC foc working and then have new options to tune speed and power consumption.

[Candas1]

Foc is actually slower than trapezoidal or sinepwm, even with EFeru's firmware.

[robcazzaro]

Bummer. And thanks @RoboDurden for your additional tests.

Clearly, even if the interrupt code was inefficient, it did not consume enough cycles to be a meaningful difference. Was a low hanging fruit, but not the right one.

There might be other opportunities (for example the sensor.updateState() function is over complex and calls bloated functions (like micros() that is needlessly complex, would be easier to re-implement using DWT_CYCCNT and knowing that the core clock is 48MHz). @RoboDurden if you try following the hall sensor code, you will see that a simple 3-line GPIO read in the gen2.x software is more than 50 lines, called each hall interrupt (open and close). SimpleFOC abstraction makes things more complicated (SimpleFOC can for example use SPI encoders for angle control, and the same code works with hall sensors)

As for the speed difference between boards, that is 0.7%. We are running the GD32 using the internal oscillator, which has a 1% accuracy, so that could explain the small difference you are seeing.

The next step unfortunately it's profiling the code. The best way is to use SWD/SWO, but if you have a cheap STLink Chinese clone, the SWO pin is not enabled. It can be enabled with https://lujji.github.io/blog/stlink-clone-trace/ and it's well worth it, but time consuming and you need to be good at soldering on the small STM32 pins. With that enabled, you can ten use the STM32CubeIDE from ST to run the SWV Statistical Profiling (it's under Window, Show View, Other

That would get you a complete profiling profile, but might be too slow over SWO and pretty hard to get running.

Otherwise use macros and DWT_CYCCNT to measure execution cycles by function, which is probably the best way to go for us here. There are even available implementations like https://github.com/Serj-Bashlayev/STM32_Profiler. DWT_CYCCNT is a standard M3 core register, so available on the GD32. That library prints using SWO (once again), but it could also print to a debug output after a fixed time profiling.

Or it would be easy to enable DWT_CYCCNT once at the beginning, create a structure for the various functions we use, store the DWT value upon entering the function, subtract the value at the end from the start, and add the instruction count to the right element of the structure for that function

//the following code needs to run only once when enabling the profiling

// enable DWT
CoreDebug->DEMCR |= 0x01000000;
// Reset cycle counter
DWT->CYCCNT = 0;
// enable cycle counter
DWT->CTRL |= 0x1;

// for each function
uint32_t start = DWT->CYCCNT;

// code to be measured here

structure.this_element += DWT->CYCCNT-start;

Then stop the code after, say, 1000 loops and print the values in the structure. the DWT counter can go up to 4294967295, so at 48MHx, as long as the profiling session ends within 89 seconds of the DWT->CTRL |= 0x1 instruction, we won't have to worry about handling the counter overflow

Alas, I can't profile on the Bluepill dev board. Without a motor and hall sensors, the code won't work as expected. If you think you can run the profiler, I'd be happy to then analyze the code and see where we can gain. If you can't, I'll have to set up my only board and hope for the best

[RoboDurden]

Well all the many lines you wrote here about such a profiler does not make me wanting to do it at all :-/
My dso single channel did show that the simpleFOC and gen2.x waveforms are quite alike.
So.why not find a clever way to see what is different...
I think candas mentioned a different alignment.
I think I have a cheap multi channel logic analyser in my train station but I forgot to take it with me to my solar warehouse.
Logging the three hall inputs and some gate outputs might shed some light in what simpleFOC is doing differently or badly.

If there are some delay parameters we could program an Auto-Tuning that optimizes rpm with a steepest descent over all parameters..

I would prefer some direct approach instead of blindly increase analyzing..

Good night for today's

[robcazzaro]

Profiling is not blindly increasing analyzing 😉. It's looking for inefficient areas of the code that are holding back performance. If we are performance limited now, it's only going to get worse once we add the more complex elements of the SimpleFOC code. Insufficient processor performance is one of the most common causes of problems reported in the SimpleFOC forums.

You can't examine external signals to see where the problem is. Let's assume we find that the PWM waveform is 3% delayed compared to other code. How would we go about changing that, if we don't know what's causing it?

The main take away from my previous comment is that measuring performance is as easy as adding 2 instructions, one at the beginning, one before the exit of each function, plus half a dozen at the end of setup(). If we use macros for the beginning/end of each function, we can enable/disable perf measurement during development. And that will benefit everything we do and help optimize in the future.

That is the clever way to see what's happening, IMHO. But I'd be happy to be proven wrong, if you can find something else that works. And, yes, it might be just a hall sensor alignment, that would be great. I'll hold on doing anything wrt profiling until you fully evaluate that option.

[Candas1]

Just a reminder.
Gen 2.x is running at 72Mhz, the simpleFOC one at 48Mhz.

[RoboDurden]

I simply am the totally wrong guy to analyze bad code instead of writing good code right from the beginning :-/
?? The GD32 runs at 72 MHz, Gen2.x and simpleFOC both run on the same hardware ??

Speaking of bad code, putting a time critical function in to loop() should be an absolute no-go. It only needs a delay(1); to crush the motor output:

void loop()
{
  // main FOC algorithm function
  // the faster you run this function the better
  // Arduino UNO loop  ~1kHz
  // Bluepill loop ~10kHz 
  motor.loopFOC();
  delay(1);

I do not really understand The Gen2.x code comments. bldc.c:

// Calculation-Routine for BLDC => calculates with 16kHz
void CalculateBLDC(void)

Which is called by an interrupt handler in it.c:

// This function handles DMA_Channel0_IRQHandler interrupt
// Is called, when the ADC scan sequence is finished
// -> ADC is triggered from timer0-update-interrupt -> every 31,25us
//----------------------------------------------------------------------------
void DMA_Channel0_IRQHandler(void)
{
	// Calculate motor PWMs
	CalculateBLDC();

1s / 31,25us = 32 kHz, not 16 kHz. But nice idea to trigger the CalculateBLDC() when all adc input are ready to be read.
I guess that handler is initialized in setup.c::ADC_Init() :

	// Configure ADC clock (APB2 clock is DIV1 -> 72MHz, ADC clock is DIV6 -> 12MHz)
	rcu_adc_clock_config(RCU_ADCCK_APB2_DIV6);
	// Interrupt channel 0 enable
	nvic_irq_enable(DMA_Channel0_IRQn, 1, 0);

But i do not understand how RCU_ADCCK_APB2_DIV6 -> 12 Mhz translates to 32 kHz.

As all three phase channels should be absolute in sync, i also do not understand why three different timers are needed. But maybe all 4 (or 5 for the C8 variant) 16-bit timers are in sync as they are based on one internal counter..

What i like about the Gen2.x code is that it is plain simple. One CalculateBLDC() that runs at whatever kHz and everything is in sync.

I guess we are free to overwrite some simpleFOC classes and replace code the object oriented way.
Instead of modififying simpleFOC or GD32-Core files.
I am the wrong guy for analyzing code without first having understood what it is intended to do.

[RoboDurden]

okay, max speed is even higher (545 Hz left and 555 Hz right) then Gen2.x when setting these two init values to 20 instead of 26 (Volt):

  driver.voltage_power_supply = 20;
  driver.voltage_limit = 20;

But the current high rises to 850-900 mA instead of the Gen2.x with less than 500 mA :-/
I have the feeling that the problem is not code optimization but wrong pwm alignment and therfore inefficient motor control.
But with my 1 channel dso i fear i can not dig deeper.

Update:
22 Volt lead to 537 Hz and 544 Hz at about 700 mA.
24 volt give 502 Hz and 502 Hz (left/right) at about 600 mA.

It think these two parameters get used here:

// Set voltage to the pwm pin
void BLDCDriver6PWM::setPwm(float Ua, float Ub, float Uc) {
  // limit the voltage in driver
  Ua = _constrain(Ua, 0, voltage_limit);
  Ub = _constrain(Ub, 0, voltage_limit);
  Uc = _constrain(Uc, 0, voltage_limit);
  // calculate duty cycle
  // limited in [0,1]
  dc_a = _constrain(Ua / voltage_power_supply, 0.0f , 1.0f );
  dc_b = _constrain(Ub / voltage_power_supply, 0.0f , 1.0f );
  dc_c = _constrain(Uc / voltage_power_supply, 0.0f , 1.0f );
  // hardware specific writing
  // hardware specific function - depending on driver and mcu
  _writeDutyCycle6PWM(dc_a, dc_b, dc_c, phase_state, params);
}

[RoboDurden]

short note to @Candas1 , that add_RTT_task.py needs
"\"$PROJECT_PACKAGES_DIR/tool-openocd/bin/openocd\"" +
to handle path names with " " spaces.

Nice to have log output without another cable. But the sensor.getVelocity() output is not smooth at all:

GD32: 26500     0: 0    1: 1    2: 1    angle: 103.81   speed: 41.65
GD32: 26600     0: 1    1: 0    2: 0    angle: 107.79   speed: 38.98
GD32: 26700     0: 0    1: 1    2: 0    angle: 111.70   speed: 41.68
GD32: 26800     0: 0    1: 0    2: 1    angle: 115.61   speed: 35.01
GD32: 26900     0: 1    1: 1    2: 0    angle: 119.59   speed: 40.85
GD32: 27000     0: 0    1: 1    2: 0    angle: 123.43   speed: 41.02
GD32: 27100     0: 1    1: 0    2: 1    angle: 127.41   speed: 36.84
GD32: 27200     0: 0    1: 1    2: 0    angle: 131.39   speed: 41.31
GD32: 27300     0: 0    1: 1    2: 1    angle: 135.23   speed: 41.83```

Do not think that the rpm at max speed changes by 40.85/35.01 = 17% within 100ms

Maybe we should indeed implement/derive our own HallSensor class :-/

[robcazzaro]

@RoboDurden the sensor is not filtered in SimpleFOC and very "spiky". There is a new smoothedsensor class being developed for that reason.

The folks running the forum recommend using motor.shaftVelocity() instead of sensor.getVelocity(). That is filtered and smoothed

As for your question on the clocks, the GD32 (like STM32) have multiple buses and clocks, each with PLLs and dividers, and it's a puzzle trying to understand how fast each bus runs. for STM32, there is a function in the STM32CubeIDE that helps calculate each and every PLL and divisor and gives you an idea in MHz or kHz. I haven't checked, but if Gen2.x is running at 72MHz, all bets are off with clocks and timing accuracy and I doubt it's. But if you want to truly understand the actual values, you need to look at the clock initialization and note each and every value being configured, then you can know the actual speed of a specific bus or component (in some cases, the speed can be half of the clock, depending on the edge polarity). Just to give you a sense, here's the clock tree for the GD32F130 (page 79, User manual)

[robcazzaro]

@RoboDurden one more comment re:

void loop()
{
  // main FOC algorithm function
  // the faster you run this function the better
  // Arduino UNO loop  ~1kHz
  // Bluepill loop ~10kHz 
  motor.loopFOC();
  delay(1);

Adding a delay(1) is really a lot in what should be a tight loop. A loop() with only a single instruction of delay(1) runs at less than 1kHz, which is way too low for SimpleFOC. So adding a huge delay of 1msec in that loop will never work. For a more relevant test you might want to use delayMicroseconds(1); If that causes problems, that means that the processor is not fast enough with the current code. If even something like delayMicroseconds(10) causes no problems, that means that the code is fast enough and the problem is not code efficiency (but settings and hall alignment)

The goal is to run the loop at at least 10kHz to have a smooth performance. Alas, SimpleFOC is not timer-driven, but runs in a tight loop which is a bad way to write time-critical code.

From the Gen2.x code I can't understand how the GD32 clock is initialized. Usually there is a call to SystemClock_Config() to initialize the GD32 clock, but the Gen2.x code uses a non standard way.

	//SystemClock_Config();
  SystemCoreClockUpdate();

I don't have Keil, so can't quickly test. I could port the code to VSCode, but it will take some time.

@RoboDurden If you have spare time, could you print the value of SystemCoreClock ? That variable is the GD32 clock (48000000 or 72000000). Knowing it will help making comparisons to the gen2.x code

[Candas1]

We are free to move loopfoc and move functions to interrupts if we want to

https://community.simplefoc.com/t/simplefoc-theory-timing/2310/2?u=candas1

[robcazzaro]

Good point @Candas1. Just a note that if we do that, we need to change how the hall sensor code works and disable those interrupts. Basically read the hall sensor upon receiving the timer interrupt like Gen2.x does (which would also make the velocity calculation much simpler and faster compared to the current one using the time between changes to calculate velocity, which as Robodurden noticed is very spiky). And make sure that the ADC code doesn't rely on interrupts either (Gen2.x uses ADC interrupts, but there are ways to start the ADC without interrupts). And look at how USART uses the interrupts in the Arduino code

Otherwise we have to deal with re-entrant interrupts and that causes all sorts of problems.

[Candas1]

Yes we will trigger inserted adc at timer update event.

[Candas1]

Some good advices were shared just now
https://community.simplefoc.com/t/hall-sensor-bldc-motor-does-not-turn/3046/10?u=candas1

[RoboDurden]

In honor of @flo199213 who ported the good old Niklas Fauth hoverboard firmware to the split boards, we should refer to "Gen2" as my "Gen2.x" only added odometer, better serial and different board layouts.

Our main loop of the simpleFOC fimrware normaly takes about 110 us but max 1122 micro seconds, i guess when debug output gets sent:

  long long iMicrosNow = _micros();
  long iMicros = iMicrosNow - iMicrosLast;
  if (iMicrosMax < iMicros) iMicrosMax = iMicros;
  iMicrosLast = iMicrosNow;
  motor.loopFOC();
...
  if (iTimeSend > iNow) return;
  iTimeSend = iNow + TIME_SEND;
  DEBUG( 
    OUT2T("SystemCoreClock",SystemCoreClock ) 
    //for (int i=0; i<HALL_Count; i++)  OUT2T(i,aoHall[i].Get())
    OUT2T("angle",sensor.getAngle()) 
    OUT2T("speed",sensor.getVelocity())
    OUT2T( iMicros , iMicrosMax )
    OUT2T( 1000.0f/iMicros , 1000.0f/(float)iMicrosMax )
    OUTLN()
  )
  iMicrosMax = 0;

SystemCoreClock: 72000000       angle: 284.77   speed: 0.00     116: 307        8.62: 3.26
SystemCoreClock: 72000000       angle: 269.76   speed: -36.21   118: 294        8.47: 3.40
SystemCoreClock: 72000000       angle: 250.98   speed: -40.05   115: 1116       8.70: 0.90
SystemCoreClock: 72000000       angle: 230.66   speed: -44.78   114: 1114       8.77: 0.90
SystemCoreClock: 72000000       angle: 210.49   speed: -40.10   114: 301        8.77: 3.32
SystemCoreClock: 72000000       angle: 190.38   speed: -38.98   113: 1115       8.85: 0.90
SystemCoreClock: 72000000       angle: 170.27   speed: -42.86   113: 1115       8.85: 0.90
SystemCoreClock: 72000000       angle: 150.17   speed: 0.00     113: 301        8.85: 3.32
SystemCoreClock: 72000000       angle: 129.92   speed: -44.98   116: 1114       8.62: 0.90
SystemCoreClock: 72000000       angle: 109.75   speed: -40.80   125: 1122       8.00: 0.89
SystemCoreClock: 72000000       angle: 89.71    speed: -37.17   125: 308        8.00: 3.25
SystemCoreClock: 72000000       angle: 69.60    speed: -37.45   127: 312        7.87: 3.21
SystemCoreClock: 72000000       angle: 49.50    speed: -41.19   126: 313        7.94: 3.19
SystemCoreClock: 72000000       angle: 30.23    speed: -35.66   126: 311        7.94: 3.22
SystemCoreClock: 72000000       angle: 14.59    speed: -27.01   125: 316        8.00: 3.16
SystemCoreClock: 72000000       angle: 3.21     speed: -17.61   123: 308        8.13: 3.25
SystemCoreClock: 72000000       angle: -3.63    speed: -8.89    125: 313        8.00: 3.19
SystemCoreClock: 72000000       angle: -5.59    speed: -0.79    123: 310        8.13: 3.23
SystemCoreClock: 72000000       angle: -4.19    speed: 6.77     126: 1114       7.94: 0.90
SystemCoreClock: 72000000       angle: 1.75     speed: 16.40    117: 302        8.55: 3.31
SystemCoreClock: 72000000       angle: 12.36    speed: 23.44    116: 303        8.62: 3.30
SystemCoreClock: 72000000       angle: 27.09    speed: 33.13    114: 302        8.77: 3.31
SystemCoreClock: 72000000       angle: 45.52    speed: 37.23    113: 302        8.85: 3.31
SystemCoreClock: 72000000       angle: 65.35    speed: 40.35    115: 301        8.70: 3.32
SystemCoreClock: 72000000       angle: 85.24    speed: 41.09    112: 302        8.93: 3.31
SystemCoreClock: 72000000       angle: 105.07   speed: 36.76    113: 300        8.85: 3.33
SystemCoreClock: 72000000       angle: 124.97   speed: 39.38    115: 302        8.70: 3.31
SystemCoreClock: 72000000       angle: 144.65   speed: 39.49    114: 296        8.77: 3.38
SystemCoreClock: 72000000       angle: 164.41   speed: 36.42    113: 302        8.85: 3.31
SystemCoreClock: 72000000       angle: 184.17   speed: 38.72    112: 301        8.93: 3.32
SystemCoreClock: 72000000       angle: 203.99   speed: 41.02    115: 301        8.70: 3.32
SystemCoreClock: 72000000       angle: 223.82   speed: 40.83    114: 1113       8.77: 0.90
SystemCoreClock: 72000000       angle: 243.72   speed: 37.37    115: 304        8.70: 3.29
SystemCoreClock: 72000000       angle: 262.57   speed: 32.56    125: 312        8.00: 3.21
SystemCoreClock: 72000000       angle: 277.93   speed: 26.89    124: 310        8.06: 3.23
SystemCoreClock: 72000000       angle: 289.17   speed: 18.26    125: 311        8.00: 3.22
SystemCoreClock: 72000000       angle: 295.94   speed: 8.62     123: 308        8.13: 3.25
SystemCoreClock: 72000000       angle: 297.89   speed: 0.00     116: 313        8.62: 3.19

So 0.9 kHz some times is not acceptable and normal Arduino users will load the loop() with lots of i2c modules and even wlan or bluetooth anyway.

I think we should move on with low-sde current sensing because that will come with better timing than the hall sensors anyway ?
When porting that low-side current sensor to GD32 we might want to introduce a new timer interrrupt for adc sampling anyway.
Like letting it "called, when the ADC scan sequence is finished" = https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/blob/main/HoverBoardGigaDevice/Src/it.c#L137
When we have such a 16kHz (or 32 kHz) interrupt we can overwrite the HallSensor class and call motor.loopFOC(); from there.
That might simplify the alignment and we better understand what the difference to the good old Gen2 code is.

[Candas1]

Yes we can use the adc interrupt, but we don't need the dma.

Let's implement, we will see what needs to be optimized.

I think segger rtt shouldn't introduce any delay, it's just reading from memory.

[robcazzaro]

Sounds like a good plan. Please assign to me any low level issue and I'll take care of it.

@RoboDurden thanks for verifying that Gen2 actually runs at 72MHz, which is a very high overclocking (50% above rated). While that might be ok for basic core math and some GPIO, more complex functions like PWM and especially ADC will be impacted. We should keep running at the rated 48MHz, even if that has a performance impact

@Candas1 RTT does have a small performance impact when sending data, but much less than any other channel (like UART), since it uses the existing SWD protocol. Having no debug is the best option for speed, but if any output is needed, RTT is by far the best option

[Candas1]

Feel free to contribute to simplefoc if you think your interpolation is better. That still doesn't clarify why gen2.x was more efficient without interpolation.

[RoboDurden]

Well this FOC code is still a black box to me:

void BLDCMotor::setPhaseVoltage(float Uq, float Ud, float angle_el) 
{
...
    case FOCModulationType::SinePWM :
      // Sinusoidal PWM modulation
      // Inverse Park + Clarke transformation

      // angle normalization in between 0 and 2pi
      // only necessary if using _sin and _cos - approximation functions
      angle_el = _normalizeAngle(angle_el);
      _ca = _cos(angle_el);
      _sa = _sin(angle_el);
      // Inverse park transform
      Ualpha =  _ca * Ud - _sa * Uq;  // -sin(angle) * Uq;
      Ubeta =  _sa * Ud + _ca * Uq;    //  cos(angle) * Uq;

      // center = modulation_centered ? (driver->voltage_limit)/2 : Uq;
      center = driver->voltage_limit/2;
      // Clarke transform
      Ua = Ualpha + center;
      Ub = -0.5f * Ualpha  + _SQRT3_2 * Ubeta + center;
      Uc = -0.5f * Ualpha - _SQRT3_2 * Ubeta + center;

      if (!modulation_centered) {
        float Umin = min(Ua, min(Ub, Uc));
        Ua -= Umin;
        Ub -= Umin;
        Uc -= Umin;
      }
      break;
...
  // set the voltages in driver
  driver->setPwm(Ua, Ub, Uc);
}

But i guess it is very sensitive to the motor angle, whereas Gen2 directly and non-tunable "block commutates" the three phases according to the hall sensors - not much to be done wrong.

I still have not undestood why setting driver.voltage_power_supply lower as the true battery voltage makes the motor even spin faster. And now with true voltage already exceeding Gen2, setting

driver.voltage_power_supply = 2.6 * BAT_CELLS; // power supply voltage [V]
will boost the max speed from 42.49 to 55.28 and the current still is only 550 mA.
That is a 30% speed boost !!!
The Audacity fft frequency analisys no longer works because the sound spectrum has changed.
But as i store the angle/time tuples for my linear interpolation, i also smoothed the

float HallSensor::getVelocity()
{
  long last_pulse_diff = pulse_diff;
  if (last_pulse_diff == 0 || ((long)(_micros() - pulse_timestamp) > 2*last_pulse_diff) ) // last velocity isn't accurate if too old
    return 0;

  float vel = direction * (_2PI / (float)cpr) / (last_pulse_diff / 1000000.0f);

  bNoUpdate = true;   // thread safety
  float fPulseDiff = last_pulse_diff;
  int iSum = 1;
  for(int i=1; i<PolynomialInterpolationCount-1; i++)
  {
    int iDiff = aiTimeLastUpdate[i] - aiTimeLastUpdate[i+1];
    if (  (fPulseDiff + iDiff) > 50000) // do not average over more than 50 ms
      break;
    fPulseDiff += iDiff; 
    iSum++;
  }
  if (bNoUpdate)
  {
    fPulseDiff /= iSum;
    vel = direction * (_2PI / (float)cpr) / (last_pulse_diff / 1000000.0f);
  }
    
  // quick fix https://github.com/simplefoc/Arduino-FOC/issues/192
  if(vel < -velocity_max || vel > velocity_max)  //if velocity is out of range then make it zero
    return 0;
  return vel;
}

I think that lowering the driver.voltage_power_supply will still allow that FOC black box to generate max sine curves.
Which afterwards get clamped to square waves in

void BLDCDriver6PWM::setPwm(float Ua, float Ub, float Uc) {
  // limit the voltage in driver
  Ua = _constrain(Ua, 0, voltage_limit);
  Ub = _constrain(Ub, 0, voltage_limit);
  Uc = _constrain(Uc, 0, voltage_limit);
  // calculate duty cycle
  // limited in [0,1]
  dc_a = _constrain(Ua / voltage_power_supply, 0.0f , 1.0f );
  dc_b = _constrain(Ub / voltage_power_supply, 0.0f , 1.0f );
  dc_c = _constrain(Uc / voltage_power_supply, 0.0f , 1.0f );
  // hardware specific writing
  // hardware specific function - depending on driver and mcu
  _writeDutyCycle6PWM(dc_a, dc_b, dc_c, phase_state, params);
}

But that is just my guess.
That max speed now totally outperforms the Gen2 code.

[RoboDurden]

The chatGPT code was a misfire. Did only produce overflow floats.
I found a nice Lagrange Interpolation the old google way.

  long iNow = _micros();
  float fAngleNow = 0;
  for(int i=0; i<PolynomialInterpolationCount; i++)
  {
    float fCoeff = 1;
    for(int j=0; j<PolynomialInterpolationCount; j++)
      if( i!=j )
        fCoeff *=  (float)(iNow - aiTimeLastUpdate[j]) / (float)(aiTimeLastUpdate[i] - aiTimeLastUpdate[j]);
    fAngleNow += fCoeff * aiAngleLastUpdate[i];
  }
  fAngleNow = 0.1 * fAngleNow + 0.9 * (float)(electric_rotations * 6 + electric_sector);    // only take 10% of the predictioin
  fAngleLagrange = (fmod(fAngleNow,cpr) / (float)cpr) * _2PI ;
  if (bNoUpdate)  
    return fAngleLagrange;

https://www.codesansar.com/numerical-methods/lagrange-interpolation-method-using-c-programming.htm

But adding mor then 10% of that 4th polynomial interpolation did block the motor :-(
(i logged the fAngleLagrange and fAngleOrg and could verify that the predicted fAngleLagrange was reasonable)

I also noticed that the execution time of that code affected the motor behavior (additional 30 mA) even without using fAngleLagrange at all. So the getMechanicalAngle() call from BLDCMotor::loopFOC() is very time critical.
And my simple linear interpolation might already be the optimum :-)

[robcazzaro]

I still have not undestood why setting driver.voltage_power_supply lower as the true battery voltage makes the motor even spin faster. And now with true voltage already exceeding Gen2, setting

The way I understand it, SimpleFOC needs to know the power supply voltage value when calculating currents (you can set the motor impedance) and to optimize voltage and current in each phase.

Then you use motor.voltage_limit and driver.voltage_limit to protect the motor especially when starting to protect the motor and board.

Let's say that you have a 10V power supply and set driver.voltage_power_supply to 10 and driver.voltage_limit to 5V. The PWM will never produce more than 50% voltage when the algorithm would output 100%. If you set driver.voltage_limit to 10, now at max phase voltage you will get 10V

It looks as if, by setting the power supply value lower than actual, you are driving the PWM more fully. Do you have motor.voltage_limit and driver.voltage_limit set, by chance? Try printing those values and see if they are the same or lower than the power supply value

Keep in mind that speed is only one aspect. For my uses, for example, I will need the motor to move very slowly (<10 RPM) with constant torque and be able to hold position with the same torque. The value of using SimpleFOC, for me, would be that once a board and motor parameters are optimized, it can be used in many different ways equally easy, without having to change the core code, just change settings in the setup()

[Candas1]

I would check the 3 voltages with this, maybe we see what happens

[Candas1]

I am wondering if at high duty cycle the values are clamped, so the sinusoidal is flat.

[robcazzaro]

I am wondering if at high duty cycle the values are clamped, so the sinusoidal is flat.

The best way to verify that would be to use a logic analyzer connected to the processor PWM pins (it's enough to only use 3 pins, like the 3 high phase pins), and once the motor is spinning at constant speed, capture enough pulses to see the PWM signal. It's easy that way to see a clipped signal, as a long sequence of 1s

[RoboDurden]

Thanks @robcazzaro , having two voltage_limit at the same time in different classes looks like very bad programming behavior to me.
FOCMotor::voltage_limit is never used in that base class FOCMotor class anyway and the dereived BLDCMotor can not work without a driver and also makes multiple uses of driver->voltage_limit.
So i guess it is a bug to use FOCMotor::voltage_limit in some other places of the same code file :-(
If indeed some other derived FOCMotor class would need its own voltage_limit without having a driver, then it should be defined in that other class and not in the base class.

OUT2T( motor.voltage_limit, driver.voltage_limit)
-> 12.00: 25.20

The 25.2 Volt is my 7s 3.6 * BAT_CELLS, the 12.0 is still the DEF_POWER_SUPPLY

Indeed, in BLDCMotor::move(float new_target), the motor::voltage_limit is used for clamping:

  switch (controller) {
    case MotionControlType::torque:
      if(torque_controller == TorqueControlType::voltage){ // if voltage torque control
        if(!_isset(phase_resistance))  voltage.q = target;
        else  voltage.q =  target*phase_resistance + voltage_bemf;
        voltage.q = _constrain(voltage.q, -voltage_limit, voltage_limit);

But BLDCMotor::setPhaseVoltage concludes with driver->setPwm(Ua, Ub, Uc); and there the
Ua = _constrain(Ua, 0, voltage_limit);
has no effect because driver::voltage_limit is way higher than the still default 12.0 used for clamping in BLDCMotor::move().
And the final clamp to [0.0..1.0] i guess will only allow the max of 1.0 if i also reduce the driver::voltage_power_supply to 12.0 V
dc_a = _constrain(Ua / voltage_power_supply, 0.0f , 1.0f );

I think there should not be a FOCMotor::voltage_limit at all :-(
It is never used in that base class FOCMotor, and in the derrived BLDCMotor class driver->setPwm(Ua, Ub, Uc); is hard coded in BLDCMotor::setPhaseVoltage(...). So it would be no problem at all to not use FOCMotor::voltage_limit in BLDCMotor::move() (and other places) but
voltage.q = _constrain(voltage.q, -driver->voltage_limit, driver->voltage_limit);
instead of what is now implemented:
voltage.q = _constrain(voltage.q, -voltage_limit, voltage_limit);

I also do not (want) to undestand why using voltages when in the end we factor and clamp it down to [0..1] anyway.
The voltage_power_supply is only used to scale the duty cacle down to 0..1. There is no analog read of the battery voltage to compare it against voltage_power_supply. in neither the base class BLDCDriver nor any of the derived BLDCDriver_x_PWM classes.
The [0.0..100.0] duty cycle is more intuitive.

But i think it is too late to change that now.
At least the FOCMotor:.voltage_limit should be removed i guess.

Do not really have the happiness to start arguing with the simpleFOC community..
@Candas1 , why don't you accept my pull request: #7 ?
Then @robcazzaro could already begin with adc low level stuff.
I do not really have a use scenario that needs currents sensing. I feel current sensing is NOT needed for FOC but only for torque control..

[Candas1]

Because I don't aim to maintain my own branch of simplefoc except the GD32 drivers.
Anything else will also be beneficial to the simpleFOC community.
You are working on topics the simpleFOC team is already about to release, without even trying it.
This will even make it harder to merge anything new they are bringing.

[RoboDurden]

I don't pose a problem if I can't offer any solutions

• i am totally undecided whether FOCMotor::voltage_limit or BLDCDriver_x_PWM::voltage_limit should be removed.
• I don't know if removing that unneccesary voltage stuff could be removed anyway
• I only have a stupid linear interpolation that boosts max speed by 33% but performs poorly at low speeds.

So no solutions to offer and therefore no happiness to pose questions to other people.

[RoboDurden]

@robcazzaro i still do not really understand why you don't buy some used hoverboards locally. I do not know all the US websites to buy used items but already facebooks lists multiple items: https://www.facebook.com/marketplace/seattle/hoverboards?maxPrice=20&exact=false
And me (and i guess Candas too) would be happy to each $20 donate to you for getting some boards.
If your really plan to do multiple projects with hoverbaords you will need your own stock of used hoverboards anyway.

[RoboDurden]

i am not really making progress with my linear interpolation. Has taken all day to verify that my angle prediction works quite good, but the motor does not like the "better" values.
I also notice that the motor is spinning more poorly left then right.
Sometimes it even gets "out of phase" and is rotating with a bad stutter. Then after a few seconds it kicks back "into the right phase" and rotates "nicely" again.
So the original HallSensor is also not perfect.

With Gen2 however, the phase pwm are simply directly calculated from the 6 (8?) possible hall combination.

  // Determine current position based on hall sensors
  hall = hall_a * 1 + hall_b * 2 + hall_c * 4;
  pos = hall_to_pos[hall];

So nothing can get "out of phase" over time.

With simpleFOC however, the angle increments with every hall step, is then mapped to 360° = [0.0 .. 2pi], some offset is added
sensor->getMechanicalAngle() - zero_electric_angle
but once that angle "gets out of phase", the three pwm phase voltages
get applied wrong "forever".

I think there should be an ongoing closed loop that corrects the zero_electric_angle.
to match the coarse hall_to_pos[hall];
And i guess there should be a zero_electric_angle_left and zero_electric_angle_right

@Candas1 , how did you obtain motor.initFOC(2.09,Direction::CCW); // Start FOC without alignment which skips the BLDCMotor::alignSensor()- which does not work at all for me. Only your 2.09 work
Was that simply try and error ? Then maybe with my "better" linear interpolation, i must find a new value.

[Candas1]

Please check those comments:
#1 (comment)
#5 (comment)
#5 (comment)

[robcazzaro]

@RoboDurden SimpleFOC is a bit hard to understand and has quite a few quirks. On the other hand, it's solid code that works for a variety of projects and hardware. Trying to hack around its inner workings without understanding why certain things were done a certain way it's a recipe for frustration. Many of the issues we are facing are known by the SimpleFOC team and work is happening to address them.

If we think something could be done better, the right approach is to engage with them and suggest changes. Most of the times, their answer will explain why their approach is better and the side effects of doing things differently. Every time I suggested changes, they were incredibly open and responsive.

You say I do not really have a use scenario that needs currents sensing. I feel current sensing is NOT needed for FOC but only for torque control.. Well, torque control at very low speeds is the only scenario that matters to me 😁, and the reason why we even started having these conversations. I'd like to have a solution for torque control using the hoverboard split boards. I already have other boards (like DRV8302 that works perfectly well with SimpleFOC, just wanted to see if it's possible to use a split hoverboard board

So, while I appreciate your desire to quickly get the code to a working state for higher speeds, that is not an approach I think will work long term. As I mentioned before, there is already a solution for a smoothed hall sensor that works at any speed. It might be suboptimal in certain cases compared to your approach, but works in general. IF you think your approach is better, I'm sure that the SimpleFOC people will be interested in hearing about it and discuss it with you.

[RoboDurden]

Thanks @Candas1 for the links, i had searched for them but did not find them in our too long issues.
Tomorrow i will try adding the yet missing parameters to
BLDCMotor(int pp, float R = NOT_SET, float KV = NOT_SET, float L = NOT_SET);

That would give a "better" result in BLDCMotor:move()

        if(!_isset(phase_resistance))  voltage.q = target;
        else  voltage.q =  target*phase_resistance + voltage_bemf;

Then maybe the BLDCMotor::alignSensor() will result in a zero_electric_angle that at least will also work like your 2.09
I guess i can measure R with my multimeter, simple the resistance from blue phase to yellow.
KV should be 14, according to one of my first youtube videos: https://youtu.be/pbip8CVaAbc
How can i obtain L ? My cheap multimeters do not seem to measure inductivity.

according to https://forum.esk8.news/t/hoverboard-foc-motor-settings-vesc/25343/4 :
R = 0.1664 Ohm
L = 0.00036858 H
KV = 16

update2:
no, BLDCMotor motor = BLDCMotor(BLDC_POLE_PAIRS, 0.1664, 16.0, 0.00036858); did not help to produce BLDCMotor::alignCurrentSense() some usable value zero_electric_angle.
And motor behavor is badly. Motor quickly jumps to a high speed :-(

If these additional 4 parameters are the problem then i guess i will have to code my own optimizer :-/

[Candas1]

"If the top speed is higher in one direction than the other, use sine modulation and adjust motor.zero_electric_angle until both directions are equal (it’s set automatically by calibration, but sometimes needs manual adjustment to correct for imperfect sensor placement)"

[RoboDurden]

Spent nearly most of Sunday to find better motor settings but haven't found anything better then the 2.09 that Candas chose.
My linear predictions still gives a 30% speed boost but the motor gets very noisy. Do not understand this.

Speed_left/right  Average_r/l  AverageDelta_l/r   linerar [%]   loopFOC[ns]_loop[ms]   samples_LowPass
-14.51: 14.31   13.17: -13.13   0.19: 0.04      fLinAdd: 2.50   221: 1254       21605
-14.62: 14.48   13.18: -13.40   0.15: 0.23      fLinAdd: 7.50   237: 1224       21645
-14.72: 14.52   13.13: -13.34   0.20: 0.20      fLinAdd: 12.50  223: 1233       21057
-14.89: 14.61   13.21: -13.28   0.29: 0.07      fLinAdd: 17.50  223: 843        21871
-14.92: 14.70   13.36: -13.35   0.21: 0.01      fLinAdd: 22.50  236: 1240       20907
-15.08: 14.85   13.43: -13.43   0.23: 0.00      fLinAdd: 27.50  224: 1228       21659
-15.44: 15.09   13.40: -13.15   0.35: 0.26      fLinAdd: 32.50  239: 1226       21250
-15.79: 15.19   13.27: -12.94   0.60: 0.33      fLinAdd: 37.50  221: 1237       21107
-16.77: 15.87   13.59: -13.02   0.90: 0.57      fLinAdd: 42.50  234: 1266       21160
-17.23: 16.36   13.84: -13.17   0.87: 0.67      fLinAdd: 47.50  223: 1280       20119
-17.83: 17.13   15.12: -15.17   0.70: 0.05      fLinAdd: 52.50  224: 847        20163
-18.21: 17.65   15.86: -15.66   0.57: 0.20      fLinAdd: 57.50  238: 1276       19270
-18.48: 17.94   16.23: -16.22   0.54: 0.01      fLinAdd: 62.50  221: 1277       19498
-18.65: 18.37   16.48: -16.55   0.27: 0.06      fLinAdd: 67.50  237: 1267       19470
-19.06: 18.71   16.63: -16.86   0.35: 0.23      fLinAdd: 72.50  221: 1277       19011
-19.28: 19.02   16.85: -17.16   0.26: 0.32      fLinAdd: 77.50  223: 1263       19703
-19.65: 19.04   16.86: -17.19   0.61: 0.33      fLinAdd: 82.50  237: 1235       18921
-19.92: 19.38   16.92: -17.09   0.55: 0.17      fLinAdd: 87.50  214: 1268       19490
-19.98: 19.85   17.22: -17.11   0.12: 0.11      fLinAdd: 92.50  238: 1265       19200
-20.27: 20.19   17.07: -17.16   0.07: 0.08      fLinAdd: 97.50  222: 1279       19087
-20.23: 20.10   17.28: -17.12   0.13: 0.16      fLinAdd: 97.50  237: 1266       19515

The 20.10/14.31 for max_speed_r is a 40% boost, the 17.28/13.17 for average_speed_r is a 31% boost.
But even so the prediction should be accurate, the motor gets very noisy.
In these tests, i let the motor spin left for about 2 seconds, then right for another 2 seconds. Total time 5 seconds and samples_LowPass times LoopFOC was called.

  if (-fSpeed > driver.voltage_limit)  // will be clamped and therefore be constant
    fSpeedAvgMax = 0.99 * fSpeedAvgMax + 0.01 * fVelocity;

Today i have built myself a Gen1 test setup. Will try to flash our simpleFOC software to it. Then i can compare with the noise and max speed of the EFeru FOC.

Would be nice to have at least overall current adc. Then i could compare the power with speed to judge the efficiency of the different firmwares. If i remember correctly, the EFeru firmware outputs speed in rpm. SimpleFOC velocity seems to be angulare frequency ( 2 pu / f ).
First test run with EFeru FOC was so silent that my Audacity frequency analysis would give no results.

As Candas will not accept my pull request, @robcazzaro if you want to and know how to start a SimpleFOC/src/current_sense/hardware_specific/gd32/gd32_mcu.cpp , you could download my preperation from my fork: https://github.com/RoboDurden/Split_Hoverboard_SimpleFOC

But i guess, Candas will be back from holidays in about a week and if he wants to do it, we can happily wait :-)

[RoboDurden]

had really bad sleep last night and am very tired today.
Have problems to match the EFeru rpm = rtY_Right.n_mot

rpm_l:-368 rpm_r:0 cmdL:1000 cmdR:1000 BatADC:1016 BatV:2695 TempADC:1722 Temp:227   
rpm_l:-368 rpm_r:0 cmdL:1000 cmdR:1000 BatADC:1006 BatV:2695 TempADC:1722 Temp:227   
rpm_l:-347 rpm_r:0 cmdL:1000 cmdR:1000 BatADC:1004 BatV:2695 TempADC:1722 Temp:227   
rpm_l:-353 rpm_r:0 cmdL:1000 cmdR:1000 BatADC:1030 BatV:2695 TempADC:1722 Temp:227   
rpm_l:-359 rpm_r:0 cmdL:1000 cmdR:1000 BatADC:1016 BatV:2695 TempADC:1722 Temp:227   
rpm_l:-365 rpm_r:0 cmdL:1000 cmdR:1000 BatADC:1008 BatV:2695 TempADC:1722 Temp:227   
rpm_l:-359 rpm_r:0 cmdL:978 cmdR:978 BatADC:1026 BatV:2695 TempADC:1722 Temp:227   
rpm_l:-326 rpm_r:0 cmdL:900 cmdR:900 BatADC:1006 BatV:2695 TempADC:1722 Temp:227   
rpm_l:-305 rpm_r:0 cmdL:828 cmdR:828 BatADC:1004 BatV:2695 TempADC:1722 Temp:227

with the simpleFOC angular speed.

float vel = direction * (_2PI / (float)cpr) / (last_pulse_diff / 1000000.0f); // cpr = 90 (hall ticks per revolution)

Speed_left/right  Average_r/l  AverageDelta_l/r   linerar [%]   loopFOC[ns]_loop[ms]   samples_LowPass
-20.40: 19.83   17.20: -17.13   0.57: 0.06      fLinAdd: 92.50  213: 846        18866

The EFeru max rpm was 368. Divided by my 26 Volt confirms the 14.15 KV of my old youtube video.
So 368 / 60 = 6.13 is the frequency f (revs). And therefore, the angular velocity w = 2 pi / T = 2 pi f should be 2 pi 6.13 = 38.5 which clearly is not close to 20.4 max_simpleFOC or 17.2 average_simpleFOC.

But maybe a factor 2 ?

But i do not find that in the simpleFOC code, unless we should use pole_pairs = 30 instead of 15:

//   - pp           - pole pairs
HallSensor::HallSensor(int _hallA, int _hallB, int _hallC, int _pp)
{
...
  // hall has 6 segments per electrical revolution
  cpr = _pp * 6;

But that should have the oppsite effect and half the 20.40 to 10.20 for the simpleFOC velocity :-/

[Candas1]

Maybe there is an issue with time measurement.
I can measure the speed with a tachometer when I am back.

[RoboDurden]

ah my fault. Now at the end of this day my mind gets a bit clearer.
I simply made the latest simpleFOC test with

driver.voltage_limit = 0.3 * driver.voltage_power_supply

Now with 1.0 i get a max speed of 44 and an average max speed of 38.0 at 1250mA/1200mA:

-44.27: 41.88   -36.69: 37.15   2.39: 0.46      0.00: 2090.00   205: 1279       38587
-43.72: 41.46   -38.66: 37.29   2.26: 1.37      0.00: 2090.00   223: 1279       38634
-44.05: 41.56   -36.61: 36.12   2.49: 0.48      0.00: 2090.00   218: 1277       38602

The EFeru_FOC gave an angular velocity of 38.5.

With 90% of my linear interpolation (prediction) i get a max average of 65 at 1000mA/1100 mA:

-74.91: 73.10   -65.86: 63.48   1.80: 2.38      0.00: 2090.00   193: 1277       38013
-73.49: 73.33   -65.36: 64.07   0.15: 1.29      0.00: 2090.00   222: 1271       38022
-74.11: 72.95   -63.44: 64.85   1.16: 1.41      0.00: 2090.00   237: 1280       38372

Now that is a 65/38 = 71 % speed boost with less current. Maybe my current limit was too low at the last tests.
Will have to make a youtube video so you can believe me.

P.s. i tried to white list my Arduino_FOC lib source and push it to my fork, so i can link to my code changes.
But this .gitignore does not work

.pio
.vscode/.browse.c_cpp.db*
.vscode/c_cpp_properties.json
.vscode/launch.json
.vscode/ipch
# Ignore everything
*
# But descend into directories
!*/
# Recursively allow files under subtree
!.pio/libdeps/GD32F130C8/Simple FOC/src/**

Github Desktop then already lists the folder as having changed, but they do not get pushed to github and no files are listed/found as having changed.
ideas welcome

[Candas1]

If it's higher than rated KV you're probably doing field weakening.

[Candas1]

This probably explains why the motor would slow down at higher target values.

[RoboDurden]

Well this does not explain why my simple linear prediction makes a 37% speed boost. Here with only

    fSpeed = (0.5*driver.voltage_power_supply)  * (ABS(	(float)(((millis()-iLoopStart)/10 + 250) % 1000) - 500) - 250)/250;
    float fLinAdd = 0.9;

rpm/V loopFOC[ms]:HallStep[ms]  fAngle0:fAngle    predict[ms]:fAngleLin ...
KV: 17.29       273: 1460       3.28: 3.35      1307:3.33 1065:3.32   69:3.28
KV: 17.38       274: 1431       3.35: 3.42       hall_int  1176:3.40  933:3.39  121:3.36 
KV: 16.45       273: 1768       3.42: 3.49      1573:3.49 1331:3.48 1090:3.47  264:3.43
KV: 17.06       269: 1545       3.49: 3.56      1458:3.55 1220:3.54  980:3.53   79:3.49
KV: 17.08       270: 1452       3.56: 3.63      1322:3.61 1084:3.60  183:3.57

first column = KV [rpm/V]
second column = difference of last two loopFOC calls [ms] and milliseconds between the two last hall steps (the greater the slower the speed)
third column = the previous angle (hall pos) that the linear prediction based on: the true angle that followed after these ms between the two last hall steps (each increment is 4° = 0.07 rad)
fourth column = array of up to 8 paris predict time in ms: predicted angle.

Usually the predict times change by loopFOC[ms] but sometimes my loop() takes up to 1ms.

Here when the motor slowed down:

KV: 9.85        275: 2663       1.12: 1.19      2565:1.18 2323:1.17 2081:1.17 1839:1.16 1598:1.15 1356:1.15  197:1.12
KV: 9.77        276: 2733       1.19: 1.26      2563:1.25 2320:1.24 2077:1.24 1834:1.23 1590:1.22 1349:1.22  177:1.19 
KV: 9.84        275: 2708       1.26: 1.33      2497:1.31 2254:1.31 2011:1.30 1768:1.30 1525:1.29 1282:1.29  107:1.26
KV: 9.90        275: 2587       1.33: 1.40      2444:1.38 2202:1.38 1960:1.37 1719:1.37 1477:1.36 1235:1.36   65:1.33 
KV: 9.76        272: 2812       1.40: 1.47      2719:1.46 2480:1.45 2241:1.45 2003:1.44 1772:1.44 1534:1.43 1301:1.43 

My linear extraplation/prediction works nicely and i don't understand why that should have a field weakening effect.

BLDCMotor:move(target) does nothing but if(!_isset(phase_resistance)) voltage.q = target;
loopFOC() does nothing with our setting TorqueControlType::voltage and directly calls setPhaseVoltage(voltage.q, voltage.d, electrical_angle);
in which i do not see any parameter that might tune the pwm output in some bad way that my linear predicition resolves:

    case FOCModulationType::SinePWM :
      // Sinusoidal PWM modulation
      // Inverse Park + Clarke transformation

      // angle normalization in between 0 and 2pi
      // only necessary if using _sin and _cos - approximation functions
      angle_el = _normalizeAngle(angle_el);
      _ca = _cos(angle_el);
      _sa = _sin(angle_el);
      // Inverse park transform
      Ualpha =  _ca * Ud - _sa * Uq;  // -sin(angle) * Uq;
      Ubeta =  _sa * Ud + _ca * Uq;    //  cos(angle) * Uq;

      // center = modulation_centered ? (driver->voltage_limit)/2 : Uq;
      center = driver->voltage_limit/2;
      // Clarke transform
      Ua = Ualpha + center;
      Ub = -0.5f * Ualpha  + _SQRT3_2 * Ubeta + center;
      Uc = -0.5f * Ualpha - _SQRT3_2 * Ubeta + center;

      if (!modulation_centered) {
        float Umin = min(Ua, min(Ub, Uc));
        Ua -= Umin;
        Ub -= Umin;
        Uc -= Umin;
      }

The electrical_angle add your 2.09 to my mechanical_angle (prediction) but that only is the neccessaary calibration of the hall sensors position.

My linerar prediction works and i can not see how that should be bad.

Here max speed without my linerar prediction:

    fSpeed = (0.5*driver.voltage_power_supply)  * (ABS(	(float)(((millis()-iLoopStart)/10 + 250) % 1000) - 500) - 250)/250;
    float fLinAdd = 0.0;

KV: 12.54       263: 2122       1.61: 1.68      1957:1.61 1724:1.61 1482:1.61 1241:1.61  240:1.61
KV: 12.62       265: 2102       1.68: 1.75      2018:1.68 1784:1.68 1549:1.68 1315:1.68 1081:1.68   99:1.68 
KV: 12.71       264: 2022       1.75: 1.82      1955:1.75 1722:1.75 1488:1.75 1253:1.75  182:1.75

Of course the "predicted angle" stays at the old angle for all loopFOC calls until the next hall step occurs :-(

17.38 / 12.71 = 37% speed boost

Yes i know that we should not get a KV of more than 15 for our bldc motors.
And with full voltage_power_supply (1.5* gets clamped to 1.0) i even get a KV of 21.63 rpm/V

    fSpeed = (1.5*driver.voltage_power_supply)  * (ABS(	(float)(((millis()-iLoopStart)/10 + 250) % 1000) - 500) - 250)/250;
    float fLinAdd = 0.9;
KV: 21.49       263: 1151       1.88: 1.95       977:1.93  174:1.89
KV: 20.68       266: 1415       1.95: 2.02      1278:2.02 1042:2.01  807:2.00   90:1.96 
KV: 21.46       267: 1175       2.02: 2.09      1016:2.07  130:2.03
KV: 21.63       268: 1152       2.09: 2.16      1052:2.15  815:2.14  109:2.10
KV: 20.57       266: 1402       2.16: 2.23      1197:2.23  962:2.21  169:2.17 

Only by correctly predicting the current hall position :-/

I should test the motor under load.. Don't really know how to do this.
Ideas welcome.

P.S. i do not like voltage_power_supply nonsene. There isn't a single Driver class in simpleFOC that drives a motor with an analog voltage. It is always (of course) a pwm ration from 0.0 to 1.0.
So why the complexity of voltage_power_supply , voltage_limit and move(voltage) ??
Our 10s batteries can go from 42.0 Volt down to 25.0V ! But of course we always want the 0.5 for pure sine FOC.
Using absolute voltages does not make any sense to me.

[RoboDurden]

So stm32 test setup is running and i can compare Gen1 vs Gen2 with the same simpleFOC software.
But i have a different motor in that setup :-/ It is not impossible that the Gen2 test setup has 20mm magnets and the Gen1 test setup has 25mm magnets inside. For difference see my old test: https://www.youtube.com/watch?v=cYIpnW6RCSE

And we really need a 16 kHz timer to move loopFOC() out of the main loop(). I can not log more output via UART on the Gen1 without the motor spinning poorly because loopFOC does no longer get called often enough.

Gen1 ----------------------

  driver.voltage_power_supply = 3.6 * BAT_CELLS; // power supply voltage [V]
  driver.voltage_limit = 1 * driver.voltage_power_supply;   // 0.3 = keep well below 1.0 for testing !
    fSpeed = (0.5*driver.voltage_power_supply)  * (ABS(	(float)(((millis()-iLoopStart)/10 + 250) % 1000) - 500) - 250)/250;
    float fLinAdd = 0.0;

KV: rpm/V   latest loopFOC[ms]: max loopFOC[ms]
KV: -9.58  186: 2615
KV: -9.53  183: 2835
KV: -10.34  187: 2531
KV: -11.10  183: 2264
KV: -11.26  187: 2200
KV: -12.00  188: 2040
KV: -11.84  210: 2227
KV: -12.11  176: 2205
KV: -11.38  173: 2260
KV: -11.26  173: 2333
KV: -10.23  204: 2565
KV: -10.16  177: 2574
KV: -9.54  173: 2708 

  driver.voltage_power_supply = 3.6 * BAT_CELLS; // power supply voltage [V]
  driver.voltage_limit = 1 * driver.voltage_power_supply;   // 0.3 = keep well below 1.0 for testing !
    fSpeed = (0.5*driver.voltage_power_supply)  * (ABS(	(float)(((millis()-iLoopStart)/10 + 250) % 1000) - 500) - 250)/250;
    float fLinAdd = 0.7;

KV: -8.48  187: 3060
KV: -8.78  188: 3014
KV: -9.47  182: 2793
KV: -10.09  188: 2435
KV: -10.19  187: 2505
KV: -11.08  183: 2329
KV: -10.96  183: 2347
KV: -11.76  188: 2289
KV: -11.59  178: 2283
KV: -11.95  188: 2258
KV: -11.23  173: 2286
...
KV: 8.23  207: 3047
KV: 8.66  205: 3058
KV: 9.94  233: 2647
KV: 10.33  200: 2583
KV: 11.26  207: 2323
KV: 12.09  235: 2305
KV: 12.51  206: 2237
KV: 13.36  207: 2057
KV: 14.25  207: 1875
KV: 14.71  207: 1871
KV: 15.00  205: 1921
KV: 16.38  206: 1526
KV: 16.37  226: 1610
KV: 16.84  207: 1592
KV: 16.83  206: 1555
KV: 15.65  205: 1673
KV: 15.24  207: 1601
KV: 13.90  207: 1989
KV: 13.48  208: 1817
KV: 12.63  207: 2149
KV: 11.54  206: 2356
KV: 11.20  208: 2264
KV: 10.09  207: 2597
KV: 9.30  207: 2818

Gen2.0 ----------------------

  driver.voltage_power_supply = 3.6 * BAT_CELLS; // power supply voltage [V]
  driver.voltage_limit = 1 * driver.voltage_power_supply;   // 0.3 = keep well below 1.0 for testing !
    fSpeed = (0.5*driver.voltage_power_supply)  * (ABS(	(float)(((millis()-iLoopStart)/10 + 250) % 1000) - 500) - 250)/250;
    float fLinAdd = 0.0;

KV: 11.73  255: 2278
KV: 12.01  258: 2408  
KV: 11.64  255: 2379  
KV: 11.53  290: 2472  
KV: 11.30  291: 2272  
KV: 10.93  258: 2584  
KV: 10.07  258: 2809  
KV: 10.11  257: 2604  
KV: 9.09  255: 3030  
KV: 9.22  257: 2886  
...
KV: -8.75  233: 3041  
KV: -9.21  234: 2940  
KV: -9.79  234: 2882  
KV: -10.59  230: 2337  
KV: -11.17  233: 2440  
KV: -11.24  233: 2331  
KV: -12.47  233: 1996  
KV: -11.92  234: 2166  
KV: -13.56  224: 1820  
KV: -12.09  234: 2169  
KV: -12.08  234: 2390  
KV: -11.34  265: 2343  
KV: -11.34  231: 2454  
KV: -10.39  230: 2593  
KV: -10.30  234: 2623  
KV: -9.51  234: 2801  
KV: -9.50  235: 2639  

  driver.voltage_power_supply = 3.6 * BAT_CELLS; // power supply voltage [V]
  driver.voltage_limit = 1 * driver.voltage_power_supply;   // 0.3 = keep well below 1.0 for testing !
    fSpeed = (0.5*driver.voltage_power_supply)  * (ABS(	(float)(((millis()-iLoopStart)/10 + 250) % 1000) - 500) - 250)/250;
    float fLinAdd = 0.9;

KV: 9.78  258: 2741  
KV: 10.16  258: 2603  
KV: 11.68  259: 2184  
KV: 11.87  290: 2290  
KV: 13.33  259: 2040  
KV: 13.13  255: 2096  
KV: 13.97  255: 1750  
KV: 15.03  256: 1726  
KV: 15.38  258: 1713  
KV: 15.83  258: 1726  
KV: 16.96  289: 1520  
KV: 16.27  247: 1542  
KV: 16.29  259: 1610  
KV: 16.76  287: 1531  
KV: 15.66  259: 1716  
KV: 15.62  260: 1569  
KV: 15.36  258: 1683  
KV: 14.38  258: 1822  
KV: 13.99  256: 1835  
KV: 12.71  258: 1913  
KV: 12.56  258: 2107  
KV: 10.58  241: 2650  
KV: 10.51  259: 2466  
KV: 9.20  292: 2751  
...
KV: -8.29  234: 3082  
KV: -9.04  230: 2744  
KV: -9.66  230: 2602  
KV: -9.68  230: 2771  
KV: -10.71  235: 2499  
KV: -10.63  231: 2471  
KV: -11.71  234: 2254  
KV: -11.65  235: 2201  
KV: -12.75  230: 2062  
KV: -12.40  222: 2115  
KV: -12.73  230: 2118  
KV: -11.68  234: 2283  
KV: -12.14  230: 2134  
KV: -10.83  233: 2460  
KV: -11.02  230: 2258  
KV: -10.08  233: 2620  

The Gen2 GD32 code is about as efficient as the STM32 code :-)
My linear prediction now only seems to work in one direction for both Gen1 and Gen2. Need to investigate why that changed for Gen2.
But i also see a 33% speed boost for the stm32 Gen1 code.
So that strange boost has nothing to do with the GD32_mcu.cpp implementation.

Will have to do more test.
My code is online here https://github.com/RoboDurden/Split_Hoverboard_SimpleFOC/blob/main/src/main.cpp
But the GD32/HallSensor and STM32/HallSensor changes needed are offline.
So the code currently is not ready for a pull request

[Candas1]

I switched back to trapezoidal, sinePWM was a mistake without interpolation, I thought it would just perform like trapezoidal and it was less noisy.
In the next few days I will try the simpleFOC dev branch improvements (interpolation, better interrupt handling, faster sin/cos, new initFOC) together with the gd32 drivers and sinePWM.

[RoboDurden]

Good to hear from you Candas :-)
When can i expect a 10-16 kHz Timer Interrupt to call loopFOC ?
If this will take you more then 2 weeks i might want to start with a dummy currentSensor the Gen2 style. Only to move the loopFOC out of the main loop. Then i may try to add adc sampling like done in the Gen2 code and we can later see what works better. your inserted adc or the gen2 style.

[Candas1]

Feel free to experiment if you want to learn.

[RoboDurden]

hm, no answer to my question.

[Candas1]

I never said I was going to work on an interrupt, so feel free to experiment if you think what we need now is an interrupt.

[RoboDurden]

Okay thank you for that answer :-) I thought it is obvious that we need an additional interrupt for loopFOC.
So i will begin to port the Gen2 adc the next days..

I am currently working on a vertical axis wind turbine with a 10" hoverboard motor:

The idea was to only use two blades as the hoverboard controller can start the turbine..
But now i guess i will add a little savonius wind turbine of 1/4 diameter. The tip-speed-ration is only about 1/4 of the darrieus..
Don't know if it is really worth adding a hoverboard controller with a kind of mppt that varies a target speed..