BF3.2 on BFF3 FC 100% CPU load with dynamic filter

[stellarhopper]

If I turn off dynamic_filter, the load drops to ~45%. I have most other features turned off. I did have crash_recovery set to on, but even without that, the load fluctuates between 95% and 100%.

# status
System Uptime: 252 seconds
Voltage: 0 * 0.1V (0S battery - NOT PRESENT)
CPU Clock=72MHz, GYRO=MPU6000, ACC=MPU6000
SD card: Manufacturer 0x1b, 976896kB, 12/2010, v1.0, '00000'
Filesystem: Fatal - no FAT MBR partitions
Stack size: 2048, Stack address: 0x10002000
I2C Errors: 0, config size: 2016, max available config: 4096
CPU:76%, cycle time: 387, GYRO rate: 2583, RX rate: 49, System rate: 9
Arming disable flags: 0x80

# tasks
00 - (         SYSTEM)      9       4       1    0.5%    0.5%         4
01 - (       GYRO/PID)   6250     130     109   81.7%   68.6%    201731
02 - (          ACCEL)    905      27      21    2.9%    2.4%      4893
03 - (       ATTITUDE)     98      38      35    0.8%    0.8%       857
04 - (             RX)     49      83      68    0.9%    0.8%       874
05 - (         SERIAL)     98  101419       3  994.4%    0.5%       382
07 - (BATTERY_VOLTAGE)     49      10       4    0.5%    0.5%        44
08 - (BATTERY_CURRENT)     49       3       2    0.5%    0.5%        20
09 - ( BATTERY_ALERTS)      4       5       3    0.5%    0.5%         3
10 - (         BEEPER)     98      11       2    0.6%    0.5%        55
13 - (            OSD)     59     815      98    5.3%    1.0%      1449
15 - (            CMS)     59       8       2    0.5%    0.5%        30
16 - (        VTXCTRL)      4      44      36    0.5%    0.5%        45
17 - (        CAMCTRL)      4       3       1    0.5%    0.5%         1
RX Check Function                   9       5                        56
Total (excluding SERIAL)                        95.7%   77.6%

Full config dump:
https://hastebin.com/yamexowene.pas

Commit ID: e955fa9

[martinbudden]

@stellarhopper , dynamic filter is very processor intensive, so if you want to use it on F3 you'll probably need to reduce your gyro/pid loop. Try 8K/4k or 4K/4K.

[rav-rav]

Gyro loop of 4k is max when using dynamic filtering.
This seems to happen a lot, maybe the gyro loop should be adjusted automatically.

[borisbstyle]

We could indeed add a guard against it Op 21 jul. 2017 12:41 schreef "rav-rav" <notifications@github.com>:

…

Gyro loop of 4k is max when using dynamic filtering. This seems to happen a lot, maybe the gyro loop should be adjusted automatically. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3585 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKQlhIIb_YhRrjQLyFkpCBFTmyjcRkuMks5sQIA7gaJpZM4OfEhn> .

[wolverin3]

I'm using Betaflight F3 FC on BF 3.2 with Dynamic Filtering, 8k/8k, DShot600, several features enabled (telemetry, LED strip and OSD). CPU usage at 55% and it is flying without any issue.

[wolverin3]

I'm using Airmode too, but on switch. CPU usage might be higher, but everything seems to be okay.

[wolverin3]

I noticed this in your snapshot, it might actually caused you the problem?

Filesystem: Fatal - no FAT MBR partitions

[rav-rav]

Hm, maybe you are right.
01 - ( GYRO/PID) 6250 130 109 81.7% 68.6% 201731
Average runtime is 109µs so that would fit into 8kHz.

This does not seem right though:
05 - ( SERIAL) 98 101419 3 994.4% 0.5% 382

Edit: Sorry average load for SERIAL is 0.5%, only max was high.

[lunohod]

@wolverin3 could you please upload your diff dump?

[martinbudden]

@rav-rav , not 8kHz gives 125us per gyro loop. Which means that gyro runtime + max other runtime must be less than 125. So this won't work at 8kHz.

The tasks table indicates this, GYRO/PID being throttled, it is running at 6250, whereas it should be running at approximately 8000.

[wolverin3]

@lunohod , here it is:

diff

Betaflight / BETAFLIGHTF3 3.2.0 Jul 18 2017 / 20:57:50 (cd5e57e)

name Wolverine
resource PPM 1 NONE
resource SERIAL_TX 11 B07
resource ESCSERIAL 1 NONE

feature LED_STRIP
feature DYNAMIC_FILTER
serial 0 32 115200 57600 0 115200
led 0 4,1::CW:10
led 1 5,1::CW:10
led 2 6,1::C:10
led 3 7,1::C:10
led 4 8,1::C:10
led 5 9,1::C:10
led 6 10,1::CW:10
led 7 11,1::CW:10
aux 0 0 0 1700 2100
aux 1 4 0 1700 2100
aux 2 13 1 1700 2100
aux 3 28 0 1700 2100
set gyro_notch1_hz = 0
set acc_hardware = NONE
set min_check = 1010
set rssi_channel = 7
set fpv_mix_degrees = 30
set blackbox_device = NONE
set min_throttle = 1045
set motor_pwm_protocol = DSHOT600
set bat_capacity = 1500
set pid_process_denom = 1
set osd_rssi_alarm = 45
set osd_cap_alarm = 1200
set osd_tim1 = 1280
set osd_tim2 = 769
set osd_vbat_pos = 2504
set osd_rssi_pos = 2106
set osd_tim_1_pos = 54
set osd_tim_2_pos = 2519
set osd_flymode_pos = 2445
set osd_throttle_pos = 225
set osd_vtx_channel_pos = 48
set osd_crosshairs = 200
set osd_horizon_pos = 200
set osd_current_pos = 2497
set osd_mah_drawn_pos = 417
set osd_craft_name_pos = 2081
set osd_gps_speed_pos = 218
set osd_gps_lon_pos = 82
set osd_gps_lat_pos = 65
set osd_gps_sats_pos = 51
set osd_home_dir_pos = 302
set osd_home_dist_pos = 303
set osd_compass_bar_pos = 266
set osd_altitude_pos = 247
set osd_pid_roll_pos = 423
set osd_pid_pitch_pos = 455
set osd_pid_yaw_pos = 487
set osd_debug_pos = 1
set osd_power_pos = 321
set osd_pidrate_profile_pos = 345
set osd_avg_cell_voltage_pos = 2511
set osd_pit_ang_pos = 257
set osd_rol_ang_pos = 289
set osd_battery_usage_pos = 424
set osd_disarmed_pos = 2251
set osd_nheading_pos = 311
set osd_nvario_pos = 279
set osd_esc_tmp_pos = 82
set osd_esc_rpm_pos = 83
set osd_stat_max_spd = OFF
set osd_stat_bbox = OFF
set osd_stat_endbatt = ON
set osd_stat_bb_no = OFF
set vcd_video_system = 1
profile 0

set dterm_lowpass_type = PT1
set i_pitch = 45
set d_pitch = 20
set i_roll = 35
set d_roll = 15
rateprofile 0

set rc_rate = 150
set rc_expo = 30

tasks

00 - ( SYSTEM) 9 7 2 0.5% 0.5% 2
01 - ( GYRO/PID) 8000 120 95 96.5% 76.5% 79898
04 - ( RX) 49 104 89 1.0% 0.9% 534
05 - ( SERIAL) 99 14602 3 145.0% 0.5% 63
07 - (BATTERY_VOLTAGE) 49 11 3 0.5% 0.5% 19
08 - (BATTERY_CURRENT) 49 4 2 0.5% 0.5% 9
09 - ( BATTERY_ALERTS) 4 10 3 0.5% 0.5% 2
10 - ( BEEPER) 99 11 2 0.6% 0.5% 26
11 - ( TELEMETRY) 244 45 6 1.5% 0.6% 323
12 - ( LEDSTRIP) 99 288 163 3.3% 2.1% 1996
13 - ( OSD) 59 786 103 5.1% 1.1% 681
15 - ( CMS) 59 9 2 0.5% 0.5% 14
16 - ( VTXCTRL) 4 7 2 0.5% 0.5% 0
17 - ( CAMCTRL) 4 7 2 0.5% 0.5% 1
RX Check Function 11 4 26
Total (excluding SERIAL) 111.5% 85.2%

version

Betaflight / BETAFLIGHTF3 3.2.0 Jul 18 2017 / 20:57:50 (cd5e57e)

[Saxin]

@borisbstyle et al.

Is it really necessary to adjust notch filters at full rate ?
Per my understanding this can be given as parameter with respect to loop speed (same as BB log rate) this will allow older targets to enjoy this fantastic feature without breaking a sweat.

Min limit can be enforced to eliminate bandwidth reduction.

[borisbstyle]

@Saxin What do you mean with "adjust notch filters at full rate"?

[Saxin]

@borisbstyle

I didn't looked at the code... yet from this issue I got impression that you are performing FFT and adjusting dynamic notch at each PID loop cycle - this is what I mean when saying "adjust notch filters at full rate"

[wind0r]

@Saxin FTT is done with each Gyro Cycle

[Saxin]

Ok, so my proposal holds even more now - is this needed ? what are you doing with all that bandwidth ?
The notches are usually located sub 500 Hz ....

[wind0r]

Feel free to Implement FTT unsynced from Gyro Loop!

[rav-rav]

FFT is not calculated in each loop cycle as a whole. The calculation is already split into 4 steps in order to reduce CPU time per cycle.
This means it takes 12 gyro loop cycles to calculate FFT for all 3 axis. That's why each axis is updated at 333Hz when running 4kHz.

One such step takes up to 25µs. If you run at 8kHz all operations (gyro, pid, rx, osd,...) need to finish in 125µs.

If you don't use each cycle to calculate a step but for example every second step, you'd still hit the time restriction every second cycle.

FFT is also already calculated on downsampled gyro data at 1kHz to reduce complexity.

[martinbudden]

@Saxin , as @rav-rav says, FFT calculation is already split into steps and each step must complete within one gyro loop. Splitting it into more steps would make the calculation less efficient and so detriment the performance on F4 and F7 processors. If you want to use dynamic notch on F3, then you need to reduce your gyro update rate to 4kHz or less.

I'm closing this issue, since it is a limitation of the performance of the F3 processor and not a problem with the implementation.

[Saxin]

Okay thanks for the clarification.