Cant select menu items intermittently BF-4.0 Conf-10.5.0

[JustAskDave]

Describe the bug After playing around with the rates and profiles on the PID page, intermittently I am no longer to select other menu items without disconnecting and reconnecting.

To Reproduce I just connected and only flicked Rate Profiles with switch on my TX to check the settings and it locked up again. If I hover the mouse over the other menu items they highlight, but can not be clicked on. Everything on the current page works and saves fine. I have not been able to reproduce by doing what ever locked it up, but it has locked up about 10 times this morning so far, always when on the PID page. I have been fiddling with the Rates, Expo, Angle/Horizon Limit, Motor Max, and multiple profiles for Angle/Horizon limit and multiple Rate Profiles for all the others (making a Easy/intermediate/advanced control for students).

Expected behavior To move to a different menu item!!

Flight controller configuration

defaults nosave

board_name OMNIBUSF4SD
manufacturer_id 
mcu_id 0032001e3436511439373635
signature 

# name
name BF4 Test

# resources

# timer

# dma

# mixer

# servo

# servo mix

# feature
feature -RX_PARALLEL_PWM
feature RX_SERIAL

# beeper

# beacon
beacon RX_LOST
beacon RX_SET

# map

# serial
serial 0 64 115200 57600 0 115200

# led

# color

# mode_color

# aux
aux 0 0 3 1575 2100 0 0
aux 1 1 0 900 1550 0 0
aux 2 2 0 1625 2100 0 0
aux 3 13 1 1300 2100 0 0

# adjrange
adjrange 0 0 2 900 2100 12 2 0 0

# rxrange

# vtx

# rxfail

# display_name

# master
set acc_calibration = 24,27,54
set serialrx_provider = IBUS
set motor_pwm_protocol = DSHOT600
set vbat_scale = 109
set small_angle = 45
set pid_process_denom = 1
set osd_tim2 = 1281
set osd_vbat_pos = 2509
set osd_tim_1_pos = 2466
set osd_tim_2_pos = 2498
set osd_flymode_pos = 2519
set osd_crosshairs_pos = 2253
set osd_ah_pos = 2126

# profile
profile 0

set level_limit = 25

# profile
profile 1

set level_limit = 40

# profile
profile 2

# restore original profile selection
profile 0

# rateprofile
rateprofile 0

set thr_mid = 40
set thr_expo = 30
set roll_rc_rate = 50
set pitch_rc_rate = 50
set yaw_rc_rate = 50
set roll_expo = 50
set pitch_expo = 50
set yaw_expo = 50
set throttle_limit_type = SCALE
set throttle_limit_percent = 50

# rateprofile
rateprofile 1

set thr_mid = 40
set thr_expo = 30
set roll_rc_rate = 50
set pitch_rc_rate = 50
set yaw_rc_rate = 50
set roll_expo = 50
set pitch_expo = 50
set yaw_expo = 50
set throttle_limit_type = SCALE
set throttle_limit_percent = 75

# rateprofile
rateprofile 2

set thr_mid = 40
set thr_expo = 30
set roll_expo = 30
set pitch_expo = 30
set yaw_expo = 30

# rateprofile
rateprofile 3

# rateprofile
rateprofile 4

# rateprofile
rateprofile 5

# restore original rateprofile selection
rateprofile 0

# save configuration
save
# 

Setup / Versions

• Flight controller - XRotor-Nano-F4 - OmnibusF4SD, running BF4.0 (bulk purchase for Schools Project) and BF Configurator 10.5.0 on Windows 10 laptop (with latest windows updates)
• Other components - XRotor-Nano-20A ESC. BLHeliS-D600, FlySky ia6 receiver using iBUS,
• how are the different components wired up - soldered?

Additional context Add any other context about the problem here.

[JustAskDave]

Just connected another drone, same hardware (identical, but without a receiver and no battery connected) and it was at a very similar programming but had a few of the auxiliary switches set differently.

I connected (in Expert Mode) clicked on the Adjustments tabs to see what was set, change the Aux number but didn't save it, clicked on the PID tab to check that then it locked and would not let me select any other tabs. I pulled the USB and reconnected (effectively power cycle the Flight Controller) and it returned to working, repeated the above and it did not lock it up this time.

So very random and not reproduceable on command. The only thing consistent is it gets stuck on the PID page.

Cheers, Dave

[mikeller]

@JustAskDave: So, to clarify when this is happening:

• it happens in configurator;
• it happens when you are switching rate profiles through the TX while the flight controller is connected to configurator.

Is this correct?

Moving this into the betaflight-configurator project.

[JustAskDave]

Correct, it happens in the configurator It happens at totally random, non repeatable times. ie, once I switched rate profiles on the TX and it locked to the PID tab, another time I simply looked at the PID tab and it locked to it, other times I have made a change on the PID tab and saved it then it locked to the PID Tab. It has happened on two different (but identically setup) quads. Removing the USB connection to the quad (rebooting it) then reconnecting without rebooting the Configurator solves the problem PS - sorry, didn't see the separate list for the configurator!

[mikeller]

@JustAskDave: Ok, the 'totally random, non repeatable times' part will make this hard to reproduce / debug. Are you set up to build configurator yourself, so that you could build a debug version and see if you can get some debug log output?

[JustAskDave]

I am not, but it may be something I could look at! Electronics is my forte, not so much the programming side of things. But if its just to record a debug log I may be able to do that. What would I need to get started?

I have also noticed a distinct lack of anyone else reporting similar problems or jumping into this one saying yeah, same here. This makes me think it may be more related to something specific about my situation. I might try a full uninstall/reinstall first and see if I the problem reproduces. I have tried two different (though identical) quads so that almost rules that out.

[mikeller]

Instructions for building configurator locally are here:

https://github.com/betaflight/betaflight-configurator#native-app-build-via-nwjs

Once everything is installed, gulp debug will start the debug version, right click into the app, then 'Inspect' will open the debug window, in the bottom of which you will find the debug console.

[bizmar]

I have had this happen frequently on macOS 10.14 and 10.13. On all versions of the Configurator to date. I probably use it more than the typical user, and run into it more frequently. Now that I know how to get to the console I'll bring back some data. :)

[McGiverGim]

I've suffered this too from time to time, but usually with a release version and not a debug version. I'm trying to reproduce it now with a debug version to see if I can get some error message or something... but until now without luck.

[McGiverGim]

I have reproduced it once... there is no error in the console, but I have observed that the function that writes the last tab to the chrome storage has registered itself for a click more than once...

Maybe the problem is here. I will try to keep investigating.

[McGiverGim]

The PR has been merged into master. Please test master to see if you can reproduce the problem or it is fixed. Thanks!

[hydra]

Hi, I have the same issue with the menu items on the left not being selectable after using the TX to change the rate profile.

2019-11-11 @ 17:33:15 -- Running - OS: Windows, Chrome: 72.0.3626.121, Configurator: 10.6.0

Firmware BF 4.1 official release, SPRacingH7EXTREME.

If you disconnect, then reconnect everything is fine until you go to the 'PID Tuning' page and change your rate profile from your TX.

It did it three times in a row then didn't do it, however I worked out steps to repeat.

1) Connect. 2) Change rate profile on TX. 3) Click 'PID tuning' button. 4) Observe that you cannot now get out of the 'PID Tuning' page.

If you change the rate profile /without/ having changed it while looking at any other page it's OK.

[etracer65]

Coincidentally I was doing some testing on fixes to the adjustments today so I was doing lots of rate profile switching on the PID Tuning tab to test my firmware fixes and while testing I was able to generate this error occasionally:

Uncaught TypeError: Failed to execute 'shaderSource' on 'WebGLRenderingContext': parameter 1 is not of type 'WebGLShader'.
    at Object.WebGLShader (three.min.js:613)
    at new <anonymous> (three.min.js:601)
    at THREE.WebGLPrograms.acquireProgram (three.min.js:611)
    at w (three.min.js:500)
    at THREE.WebGLRenderer.renderBufferDirect (three.min.js:547)
    at t (three.min.js:497)
    at THREE.WebGLRenderer.render (three.min.js:555)
    at Model.render (model.js:135)
    at Model.<anonymous> (model.js:85)
    at model.js:98
    at three.min.js:291
    at XMLHttpRequest.<anonymous> (three.min.js:286)

Usually when switching rate profiles quickly. I think there might be a case where another refresh of the page happens before the 3D model finishes initialization or something like that.

Not sure this is the only problem or cause of the non-responsive page, but definitely could cause this error with rate profile switching.

This was testing with master on MacOS.

[McGiverGim]

@hydra

It did it three times in a row then didn't do it, however I worked out steps to repeat.

1. Connect.
2. Change rate profile on TX.
3. Click 'PID tuning' button.
4. Observe that you cannot now get out of the 'PID Tuning' page.

I can't reproduce it. I'm using the MSP receiver because I don't have here a real quad. Are you able to reproduce it using the MSP receiver?

[mikeller]

@McGiverGim: If this is caused by the error that @etracer65 describes then it is some interaction with the WebGL that is used to drive the 3D models. These problems are normally hard to reproduce, as you need the WebGL driver to be in a degraded state for it to occur.

[hydra]

• my webgl was not in degraded state.
• i had an X8R receiver connected.

[mikeller]

@hydra:

my webgl was not in degraded state.

How did you verify this?

[hydra]

I may be mis-interpreting what 'webgl in degraded state' means. When the webgl stuff is rendering correctly it renders nice 3d models, when it's not it doesn't and you get a box instead of the model right? Or do you mean something else by 'webgl in degraded state', if so what?

[hydra]

oh, also not investigated reproducing using MSP RX, don't have time currently, I wouldn't let that stop anyone looking into fixing the bug though.

[mikeller]

@hydra:

I may be mis-interpreting what 'webgl in degraded state' means. When the webgl stuff is rendering correctly it renders nice 3d models, when it's not it doesn't and you get a box instead of the model right?

If you get the box instead of the modes webGL is not working at all or intentionally disabled. In degraded state the 3D model is displayed, but the CPU is pegged at 100%. This often results in other parts of the application being slow / not working correctly.

[haslinghuis]

Closing as inactive as superseded with new firmware and configurator. We always can reopen if the issue raises again.