Firmware 5.03

This is great to see the continued progress and improvement of the VESC project! 

Is there some data/info on exactly how the phase voltage filter is improving motor control? What is the expected impact of using them? Do the phase voltage filters need to have a certain RC constant in order for it to properly function with the firmware? Do some types of motors, say low-inductance, benefit more than others? Would hardware with low-side current sensing still benefit from having these phase voltage sensors?

Are there any details anywhere on what A.S.S. is doing from a technical standpoint? I know I can dissect the code and figure it out eventually. Just asking for convenience sake.

Is the switchable phase/current measurement filters used for HFI / "ASS"?

Or only detection? (ie, are the filters needed to be dynamically disabled for HFI / "ASS" operation?)

I ansered my question - current filters are disabled for HFI (but seems like you keep voltage filter on ;)

That vesctool version refuses to install on android 11.

Is the issue on my end?

I tried the latest dev branch (Commit 89c4d712e8ab6ac22c89e0c982d6b4426f8483ea, Mar 13 2020) and its performing pretty poorly on my setup. Running a 16" hub motor from a Solowheel Original EUC with a Cheap FOCer v2 ESC. 

Startup performs similar to sensorless at startup maybe even a little worse, even tho I'm using sensors, and its very rough sounding and noisy all the way up until near max RPM. As a sanity check i tried 2 different ESCs and it was no different, however swapping back to the master branch made it run smooth as butter.

Not sure what all info/logs i can provide to help.

*EDIT* Just tried the same motor with a stormcore 100s ESC and it seems to work fine, so its something to do with the Cheap FOCer v2.

P.S. I really love this new wizard stuff, much cleaner and easier to use. Also the work of having to implement everything twice was very demotivational.

Ok, i double checked everything, the zip file in the first post is giving me BETA 10 for Cheap FOCer2, it has the issue, so i also tried compiling the latest code and got BETA 11 and still have the issue. 

*edit* Got another user to try it and they described the exact same issue.

I just looked through the scripting page, and it looks like it can majorly cut my development time when working in QML, I'm for sure going to try it next time I mess with that stuff, which is on my todo list. As far as 3rd party hardware control, my master plan for can accessories was to write a bluetooth app that talks over uart with the esc, and has it can forward whatever I want to my can bus accessory so i could essentially make any can bus accessory bluetooth enabled so long as the esc has bluetooth. I could use that for my Balance Buddy.

Just tried it on a FlipSky 4.20 MINI, after doing the detection, I can't get the motor to spin, it just jerks for both sides. Running sensorless. I know this hardware has pretty poor phase current measumerent a bit of DC current offset on the readings, maybe this i interfering with the new sensorless startup

I like the scripting page :) thanks benjamin !

short test, works fine

My offsets are

2056.10
2058.77
2038.57

0.0000 V
0.0000 V
0.0000 V

-0.0006 V
0.0000 V
0.0006 V

I think its fair to say my problem is similar to Pedrodemio's my motor mostly just cogs in both directions unless i crank up the current or give it a push.

One problem:

i updated from 5.02 to dev_5_03 and started the test version from vesc-tool:

Error: "Could not deserialize motor configuration. You probably need to update the VESC firmware, as a new iteration of the test version has been made."

Now i can not read or write the motor configuration

Georg

EDIT: ah, there is a new version behind the link above :) working now

I think there are some factors that affect how other hardware handles some of these changes

• low-side current sensing
• slower MOSFET switching rise/fall times
• lack of current/phase filters
• higher voltage operation

A lot of the hardware I've developed matches these things and I've noticed how much they affect smooth control. Ben, are any of these factors known to affect the quality of motor control or ASS?

Phase filters are not working on my hardware, which is based on the VESC 75/300

Motor detection and running is smooth with disabled phase filter.

With phase filter enabled, motor detection just cogs in both direction

Hi Benjamin,

thanks. First, without phase filters the new detection runs much better than in older versions.

the phase filters are the same as in your design, just change the analog switch to one which is available on jlc

my hwconf/hw_gesc.h

/*
	Copyright 2018 Benjamin Vedder	benjamin@vedder.se

	This file is part of the VESC firmware.

	The VESC firmware is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    The VESC firmware is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.
    */

#ifndef HW_GSVESC_H_
#define HW_GSVESC_H_

#define HW_NAME					"GESC"

// HW properties
#define HW_HAS_3_SHUNTS
#define HW_HAS_PHASE_SHUNTS
#define HW_HAS_PHASE_FILTERS
#define INVERTED_SHUNT_POLARITY
#define HW_HAS_NO_CAN
#define HW_HAS_RFM95W

// Macros
#define LED_GREEN_GPIO			GPIOB
#define LED_GREEN_PIN			0
#define LED_RED_GPIO			GPIOB
#define LED_RED_PIN				1

#define LED_GREEN_ON()			palSetPad(LED_GREEN_GPIO, LED_GREEN_PIN)
#define LED_GREEN_OFF()			palClearPad(LED_GREEN_GPIO, LED_GREEN_PIN)
#define LED_RED_ON()			palSetPad(LED_RED_GPIO, LED_RED_PIN)
#define LED_RED_OFF()			palClearPad(LED_RED_GPIO, LED_RED_PIN)

#define PHASE_FILTER_GPIO		GPIOC
#define PHASE_FILTER_PIN		9
#define PHASE_FILTER_ON()		palSetPad(PHASE_FILTER_GPIO, PHASE_FILTER_PIN)
#define PHASE_FILTER_OFF()		palClearPad(PHASE_FILTER_GPIO, PHASE_FILTER_PIN)

#define AUX_GPIO				GPIOC
#define AUX_PIN					12
#define AUX_ON()				palSetPad(AUX_GPIO, AUX_PIN)
#define AUX_OFF()				palClearPad(AUX_GPIO, AUX_PIN)

#define CURRENT_FILTER_ON()		palSetPad(GPIOD, 2)
#define CURRENT_FILTER_OFF()	palClearPad(GPIOD, 2)

/*
 * ADC Vector
 *
 * 0  (1):	IN0		SENS1
 * 1  (2):	IN1		SENS2
 * 2  (3):	IN2		SENS3
 * 3  (1):	IN10	CURR1
 * 4  (2):	IN11	CURR2
 * 5  (3):	IN12	CURR3
 * 6  (1):	IN5		ADC_EXT1
 * 7  (2):	IN6		ADC_EXT2
 * 8  (3):	IN3		TEMP_MOS
 * 9  (1):	IN14	TEMP_MOTOR
 * 10 (2):	IN15
 * 11 (3):	IN13	AN_IN
 * 12 (1):	Vrefint
 * 13 (2):  IN5     ADC_EXT1
 * 14 (3):  IN6     ADC_EXT2
 */

#define HW_ADC_CHANNELS			15
#define HW_ADC_INJ_CHANNELS		3
#define HW_ADC_NBR_CONV			5

// ADC Indexes
#define ADC_IND_SENS1			0
#define ADC_IND_SENS2			1
#define ADC_IND_SENS3			2
#define ADC_IND_CURR1			3
#define ADC_IND_CURR2			4
#define ADC_IND_CURR3			5
#define ADC_IND_VIN_SENS		11
#define ADC_IND_EXT				6
#define ADC_IND_EXT2			7
#define ADC_IND_EXT3			10
#define ADC_IND_TEMP_MOS		8
#define ADC_IND_TEMP_MOTOR		9
#define ADC_IND_VREFINT			12

// ADC macros and settings

// Component parameters (can be overridden)
#ifndef V_REG
#define V_REG					3.3
#endif
#ifndef VIN_R1
#define VIN_R1					56000.0
#endif
#ifndef VIN_R2
#define VIN_R2					2700.0
#endif
#ifndef CURRENT_AMP_GAIN
#define CURRENT_AMP_GAIN		20.0
#endif
#ifndef CURRENT_SHUNT_RES
#define CURRENT_SHUNT_RES		0.001
#endif

// Input voltage
#define GET_INPUT_VOLTAGE()		((V_REG / 4095.0) * (float)ADC_Value[ADC_IND_VIN_SENS] * ((VIN_R1 + VIN_R2) / VIN_R2))

// NTC Termistors
#define NTC_RES(adc_val)		((4095.0 * 10000.0) / adc_val - 10000.0)
#define NTC_TEMP(adc_ind)		(1.0 / ((logf(NTC_RES(ADC_Value[adc_ind]) / 10000.0) / 3380.0) + (1.0 / 298.15)) - 273.15)
#define NTC_VALUE_MOTOR         10000.0
#define NTC_RES_MOTOR(adc_val)	(NTC_VALUE_MOTOR / ((4095.0 / (float)adc_val) - 1.0)) // Motor temp sensor on low side
#define NTC_TEMP_MOTOR(beta)	(1.0 / ((logf(NTC_RES_MOTOR(ADC_Value[ADC_IND_TEMP_MOTOR]) / NTC_VALUE_MOTOR) / beta) + (1.0 / 298.15)) - 273.15)

// Voltage on ADC channel
#define ADC_VOLTS(ch)			((float)ADC_Value[ch] / 4096.0 * V_REG)

// Double samples in beginning and end for positive current measurement.
// Useful when the shunt sense traces have noise that causes offset.
#ifndef CURR1_DOUBLE_SAMPLE
#define CURR1_DOUBLE_SAMPLE		0
#endif
#ifndef CURR2_DOUBLE_SAMPLE
#define CURR2_DOUBLE_SAMPLE		0
#endif
#ifndef CURR3_DOUBLE_SAMPLE
#define CURR3_DOUBLE_SAMPLE		0
#endif

// COMM-port ADC GPIOs
#define HW_ADC_EXT_GPIO			GPIOA
#define HW_ADC_EXT_PIN			5
#define HW_ADC_EXT2_GPIO		GPIOA
#define HW_ADC_EXT2_PIN			6

// UART Peripheral
#define HW_UART_DEV				SD3
#define HW_UART_GPIO_AF			GPIO_AF_USART3
#define HW_UART_TX_PORT			GPIOB
#define HW_UART_TX_PIN			10
#define HW_UART_RX_PORT			GPIOB
#define HW_UART_RX_PIN			11

#define HW_UART_P_BAUD			115200
#define HW_UART_P_DEV			SD4
#define HW_UART_P_GPIO_AF		GPIO_AF_UART4
#define HW_UART_P_TX_PORT		GPIOC
#define HW_UART_P_TX_PIN		10
#define HW_UART_P_RX_PORT		GPIOC
#define HW_UART_P_RX_PIN		11

// ICU Peripheral for servo decoding
#define HW_USE_SERVO_TIM4
#define HW_ICU_TIMER			TIM4
#define HW_ICU_TIM_CLK_EN()		RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM4, ENABLE)
#define HW_ICU_DEV				ICUD4
#define HW_ICU_CHANNEL			ICU_CHANNEL_2
#define HW_ICU_GPIO_AF			GPIO_AF_TIM4
#define HW_ICU_GPIO				GPIOB
#define HW_ICU_PIN				7


// I2C Peripheral
#define HW_USE_I2CD1
#define HW_I2C_DEV				I2CD1
#define HW_I2C_GPIO_AF			GPIO_AF_I2C1
#define HW_I2C_SCL_PORT			GPIOB
#define HW_I2C_SCL_PIN			8
#define HW_I2C_SDA_PORT			GPIOB
#define HW_I2C_SDA_PIN			9

// Hall/encoder pins
#define HW_HALL_ENC_GPIO1		GPIOC
#define HW_HALL_ENC_PIN1		6
#define HW_HALL_ENC_GPIO2		GPIOC
#define HW_HALL_ENC_PIN2		7
#define HW_HALL_ENC_GPIO3		GPIOC
#define HW_HALL_ENC_PIN3		8
#define HW_ENC_TIM				TIM3
#define HW_ENC_TIM_AF			GPIO_AF_TIM3
#define HW_ENC_TIM_CLK_EN()		RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM3, ENABLE)
#define HW_ENC_EXTI_PORTSRC		EXTI_PortSourceGPIOC
#define HW_ENC_EXTI_PINSRC		EXTI_PinSource8
#define HW_ENC_EXTI_CH			EXTI9_5_IRQn
#define HW_ENC_EXTI_LINE		EXTI_Line8
#define HW_ENC_EXTI_ISR_VEC		EXTI9_5_IRQHandler
#define HW_ENC_TIM_ISR_CH		TIM3_IRQn
#define HW_ENC_TIM_ISR_VEC		TIM3_IRQHandler

//GSVESC additional buttons
#define HW_HALL_TRIGGER_GPIO            GPIOC
#define HW_HALL_TRIGGER_PIN             13
#define HW_HALL_ROTARY_A_GPIO           GPIOC
#define HW_HALL_ROTARY_A_PIN            14
#define HW_HALL_ROTARY_B_GPIO           GPIOC
#define HW_HALL_ROTARY_B_PIN            15
#define HW_HALL_ROTARY_A_EXTI_PORTSRC   EXTI_PortSourceGPIOC
#define HW_HALL_ROTARY_A_EXTI_PINSRC    EXTI_PinSource14
#define HW_HALL_ROTARY_A_EXTI_CH        EXTI15_10_IRQn
#define HW_HALL_ROTARY_A_EXTI_LINE      EXTI_Line14
#define HW_HALL_ROTARY_A_EXTI_ISR_VEC   EXTI15_10_IRQHandler

// SPI pins
#define HW_SPI_DEV				SPID1
#define HW_SPI_GPIO_AF			GPIO_AF_SPI1
#define HW_SPI_PORT_NSS			GPIOA
#define HW_SPI_PIN_NSS			4
#define HW_SPI_PORT_SCK			GPIOA
#define HW_SPI_PIN_SCK			5
#define HW_SPI_PORT_MOSI		GPIOA
#define HW_SPI_PIN_MOSI			7
#define HW_SPI_PORT_MISO		GPIOA
#define HW_SPI_PIN_MISO			6

#ifdef HW_HAS_RFM95W
#define HW_RFM95W_SPI_DEV				SPID1
#define HW_RFM95W_SPI_GPIO_AF			GPIO_AF_SPI1
#define HW_RFM95W_SPI_PORT_NSS			GPIOA
#define HW_RFM95W_SPI_PIN_NSS			4
#define HW_RFM95W_SPI_PORT_SCK			GPIOA
#define HW_RFM95W_SPI_PIN_SCK			5
#define HW_RFM95W_SPI_PORT_MOSI		    GPIOA
#define HW_RFM95W_SPI_PIN_MOSI			7
#define HW_RFM95W_SPI_PORT_MISO		    GPIOA
#define HW_RFM95W_SPI_PIN_MISO			6
#define HW_RFM95W_SPI_PORT_DIO0         GPIOC
#define HW_RFM95W_SPI_PIN_DIO0          5
#define HW_RFM95W_SPI_PORT_RESET        GPIOB
#define HW_RFM95W_SPI_PIN_RESET         2
#endif

// Measurement macros
#define ADC_V_L1				ADC_Value[ADC_IND_SENS1]
#define ADC_V_L2				ADC_Value[ADC_IND_SENS2]
#define ADC_V_L3				ADC_Value[ADC_IND_SENS3]
#define ADC_V_ZERO				(ADC_Value[ADC_IND_VIN_SENS] / 2)

// Macros
#define READ_HALL1()			palReadPad(HW_HALL_ENC_GPIO1, HW_HALL_ENC_PIN1)
#define READ_HALL2()			palReadPad(HW_HALL_ENC_GPIO2, HW_HALL_ENC_PIN2)
#define READ_HALL3()			palReadPad(HW_HALL_ENC_GPIO3, HW_HALL_ENC_PIN3)


// Override dead time. See the stm32f4 reference manual for calculating this value.
#define HW_DEAD_TIME_NSEC       660.0

// Default setting overrides
#ifndef MCCONF_L_MIN_VOLTAGE
#define MCCONF_L_MIN_VOLTAGE			12.0		// Minimum input voltage
#endif
#ifndef MCCONF_L_MAX_VOLTAGE
#define MCCONF_L_MAX_VOLTAGE			50.0	// Maximum input voltage
#endif
#ifndef MCCONF_DEFAULT_MOTOR_TYPE
#define MCCONF_DEFAULT_MOTOR_TYPE		MOTOR_TYPE_FOC
#endif
#ifndef MCCONF_FOC_F_SW
#define MCCONF_FOC_F_SW					30000.0
#endif
#ifndef MCCONF_L_MAX_ABS_CURRENT
#define MCCONF_L_MAX_ABS_CURRENT		120.0	// The maximum absolute current above which a fault is generated
#endif
#ifndef MCCONF_FOC_SAMPLE_V0_V7
#define MCCONF_FOC_SAMPLE_V0_V7			false	// Run control loop in both v0 and v7 (requires phase shunts)
#endif
#ifndef MCCONF_L_IN_CURRENT_MAX
#define MCCONF_L_IN_CURRENT_MAX			60.0	// Input current limit in Amperes (Upper)
#endif
#ifndef MCCONF_L_IN_CURRENT_MIN
#define MCCONF_L_IN_CURRENT_MIN			-60.0	// Input current limit in Amperes (Lower)
#endif

// Setting limits
#define HW_LIM_CURRENT			-120.0, 120.0
#define HW_LIM_CURRENT_IN		-120.0, 120.0
#define HW_LIM_CURRENT_ABS		0.0, 160.0
#define HW_LIM_VIN				12.0, 50.0
#define HW_LIM_ERPM				-200e3, 200e3
#define HW_LIM_DUTY_MIN			0.0, 0.1
#define HW_LIM_DUTY_MAX			0.0, 0.99
#define HW_LIM_TEMP_FET			-40.0, 110.0

// HW-specific functions
int gsvesc_get_angle(void);

#endif /* HW_GSVESC_H_ */

Maybe it is a problem with bad board design. I moved the switch near to the adc inputs, to have the capacitor as near as possible to the adc input. because i have a round design, the filter input voltage path is very long

Thanks

Georg

yes, just checked again: schematic has GPIOC connected and inside my hw_gesc.c i use the default code

// Phase filters
	palSetPadMode(PHASE_FILTER_GPIO, PHASE_FILTER_PIN,
			PAL_MODE_OUTPUT_PUSHPULL |
			PAL_STM32_OSPEED_HIGHEST);
	PHASE_FILTER_OFF();

is the "PHASE_FILTER_OFF()" still correct ?

All working good on my A200S V3, which has 2x low side shunts and current + phase filters.

One thing I did a bit differently to your designs is my extra filter cap is connected to an open drain IO on the stm32. So I don't need the analogue switches. The pin is either floating or ground.

https://www.youtube.com/watch?v=nmuyHtmVgWI

FOC wizard sets my battery cutoff start/end at 6v, despite selecting 10s on all of the 5.03 test versions.

Tried the latest but it's still not working for me on the Cheap FOCer V2.

Hey Benamin,

here are two pictures of sampled data, triggerd with motor start.

the motor is configured with parameters from the wizzard without phase filters. sometimes the motor starts spinning after 2 or 3 seconds

the same test (try 10% duty cycle) works fine with the same firmware, but disabled phase filtes in the FOC filters tab.

this is with disabled phase filters:

Offsets:

with enabled phase filters the pictures looks like in the post above and the motor does this:

Still not running here, but its more or less a problem on my individual hardware :)

Detection ist not running. Either with HW_HAS_PHASE_SHUNT or without. in addtion the saved config is now not working when phase filters are disabeld...

I'm noticing on the latest builds that the balance app is struggling with the sleep function going longer than requested (1khz Balance, 1khz IMU). I think this problem has been creeping up for a while, as awesome features are constantly being added. But it seems like we might be hitting the limits of the CPU, tho tbh I'm not entirely sure how to measure CPU load or what the best way to go about reducing it is.

guys, I want to build an external alarm based on IMU+ESP32 (more complex than that but to keep it short we leave it for now)

- Idea is to add "Alarm mode" on VESC, which would execute those steps up on ADC3 line going from 0v to 1.5v with VESC powerd on:
1. put VESC to some sort of lowest power consumption mode
2. Disable throttle input ADC1/PPM/CAN
3. monitor ADC3 for change 
= VESC ready to act if alarm is triggered

- than if ADC3 goes to high (3.3v - alarm triggered):
1. wake up controller
2. Engage breaking to full power (ideally would be if there would be seperate paramter Alarm Breaking Force, so that it can be set higher than typical riding breaking / regen force)
3. go out of Alarm mode once voltage goes down to 0v on ADC3

That would be amazing option in my opinion specially for bicycles and e-scooter at very least!
________________________
if you are interrested in Alarm side it would function someething like that:
1. Arm 1.5v / Disarm 0v output (by phone APP or RFID tag readerr or what ever you want)
2. MPU650 triggered alarm would set output to 3.3v to VESC ADC3, send 3.3v to the FET to open up main battery power to the Siren, Send notification via Blync app over 3G shield (gps shield would also send GPS data over Blync app wher one could track)
3. reset gyro/accelerometer home position every second and go back from triggered to Armed after 30sec without motion detection (output down to 1.5v, siren outout off)

____________

In theory basic alarm function could be implemented completely insidee VESC
- since it has Gyro/Accel on board
- has BT connection (so lock / unlock could be added to the phone App)
- Only not sure what connection could be used to trigger Siren activation (could ADC to be mapped as output - to send trigger for the fet to open up the gate for battery voltage to the siren?) 

This is my results from the threads command. Which are pretty encouraging. Idle thread is at 61.2% so there should be plenty time for the balance app to run. I will try to implement sleeps they way you recommended and report back. However the time of the BMI160 thread really stands out at 30%, it actually starts off low 1% and then steadily increases over time, Ive seen it up to abut 40%. I tested the lsm6ds3 and it does the same thing. I don't understand whats going on there.
 

addr stack prio refs state name motor time
-------------------------------------------------------------------
20001bd8 20000f54 64 1 SLEEPING main 1 189 (0.0 %)
20001c28 20001d34 1 1 READY idle 1 801432 (61.2 %)
2000d580 2000da6c 64 1 SLEEPING mcif timer 1 16265 (1.2 %)
2000d1e0 2000d494 63 1 WTOREVT SampleSender 1 0 (0.0 %)
2000cb58 2000cdfc 124 1 WTOREVT Fault Stop 1 0 (0.0 %)
2000e3a8 2000e84c 64 1 SLEEPING foc timer 1 1939 (0.1 %)
2000db28 2000dfd4 64 1 SLEEPING foc hfi 1 719 (0.1 %)
20008a40 2000901c 64 1 CURRENT comm_block 1 360 (0.0 %)
20001f80 200020ec 126 1 SUSPENDED usb_lld_pump 1 3400 (0.3 %)
200050f0 200052bc 64 1 QUEUED USB read 1 2096 (0.2 %)
20003f58 20005074 64 1 WTOREVT USB process 1 17810 (1.4 %)
20018a90 2001930c 64 1 SLEEPING UAVCAN 1 7 (0.0 %)
2000aeb0 2000b15c 65 1 WTOREVT CAN read 1 0 (0.0 %)
2000b248 2000b4dc 64 1 QUEUED CAN status 1 253 (0.0 %)
20009d18 2000adc4 64 1 WTOREVT CAN process 1 0 (0.0 %)
20014408 200154dc 64 1 READY uartcomm proc 1 2546 (0.2 %)
20002cf0 200031d4 64 1 SLEEPING Main periodic 1 239 (0.0 %)
20002a58 20002c54 2 1 READY Flash check 1 2346 (0.2 %)
20009960 20009c3c 64 1 SLEEPING Timeout 1 196 (0.0 %)
20019918 2001a0f4 64 1 READY BMI Sampling 1 412671 (31.5 %)
20016648 20016f14 64 1 SLEEPING APP_BALANCE 1 17571 (1.3 %)

Hello,

I gave the new field weakening a go just now. Hardware used was a200s v2 and a 6374. Only tested on the bench at low speed and power with current mode. It worked well and the gradual ramp down of d axis current kept the winding voltages in check during braking or sudden release of throttle as expected. Nice work!

I just tried beta21 on a Cheap FOCer2 based Funwheel with Fungineers hub and 12s2p battery. When reusing my existing settings (still worked fine in beta17) I now get a clunk noise when balancing at low speeds. I didn't dare go on an actual ride. Is it unreasonable to expect that old configurations should continue to work? Is there any particular setting I should go adjust or do I need to go through the full calibration process again?

I just built the latest dev branch also on a cfoc2 and ran a fresh calibration and noticed current spikes, here is a graph. The black is motor current, and the red is what the balance app is setting the current to. You can see around the 0 point there are large black spikes while the red is flat. (Some of the black spikes also have red spikes, i think these are reactionary to jitters/cogs getting the IMU out of whack?)
 

Previous betas didn't have spikes like this. Here is a graph from beta 19, its harder to get any spikes, but if i do get some spikes they're much smaller.

*I should point out, it took effort to capture the small spike on beta 19, where as the curren't code i just grabbed a random sample, not even the worst of it.

**Edit: My same setup randomly worked fine on a more recent test, so i guess there is some intermittency to this issue.

I was able to confirm that beta20 also works fine for me. The problem appears to get introduce either by "Merge pull request #282 from powerdesigns/ipm_bemf_decoupling " or by "Merge pull request #283 from powerdesigns/speed_pid_loop_antiwindup " or by both - I can't quite pinpoint it (I tried commit by commit, I installed about 15 versions of the firmware today).

In addition to the clunky noise when balancing near zero speed, I also get such noise after I get off the board and the board is not moving, after about 30 seconds (I have brake current = 7A configured)

> Can you try to making sure that the output of the PID-controller always is greater than cc_min_current?

Any suggestion as to how I can best accomplish that?

I can confirm that the balance app calls "set_current" with values < cc_min_current all the time when riding, regardless of speed - whenever the board is "balanced" the output current can go down to 0 I guess...

I just tried forcing the set_current value to always be >= cc_min_current (I have a beeper alerting me whenever that happens, which is very frequently on a balance vehicle) but that made no difference unfortunately...

Let me see if I understand. According to your commit the delay defaults to 1s, right? How many seconds should I set it to? The balance app sets the current 1000 times a second, do you really want me to call this function each time?

Or did you mean to say "before setting the brake current?" so when starting to idle?

Today I was playing around with settings and clicked write config while the motor was running a few times by accident. It caused the motor to almost instantly stop from 40% duty, after doing this a few times it blew one of the low side mosfets. I thought it was supposed to turn off the modulation when motor settings are changed so this doesn't happen? 

Here some more observations. I did add the call as you suggested, but didn't really notice an improvement. Still quite clunky when rocking back and forth and minimum speed. I also discovered that the weird noises when resting only occur during a firmware upload (which is slow via bluetooth). When I had the board on the ground it started making small movements on its own during the firmware upload process. What's odd though, is that when using a fresh motor configuration by running the newest wizard, I don't get the noises and self movement during firmware updates anymore, but I still get the occasional loud "clunk" when going back and forth at low speed... Sorry if I'm not making things clearer...

I could attach  a diff between my 5.2 motor config and the new (better) motor config I got out of the wizard in 5.3 beta 21 if you'd like.