SpeedyBeeF4v3: firmware for SUB. no connection from GCS using 4.5.6, custom firmvare, latest. the version indicated by the date is working

[ilia-enginer]

speedeebeef4v3 board.
sub platform.
firmware version - stable, latest, custom firmvare.
problem: no connection with the mission planer.
there is no such problem in the "indicated by the date" versions.
there is no such problem with the quadcopter firmware

[IamPete1]

How are you connecting? Which serial port? Over telemetry?

[ilia-enginer]

How are you connecting? Which serial port? Over telemetry?

I connect the board's USB output to my personal computer. I use the "Mission Planner

" program

[peterbarker]

@ilia-enginer do you think you could bisect to find whichever commit stopped things working?

[ilia-enginer]

@ilia-enginer do you think you could bisect to find whichever commit stopped things working?

I don't know. Now I compile the firmware myself in vscode. and the problem doesn't occur anymore.

[peterbarker]

@ilia-enginer do you think you could bisect to find whichever commit stopped things working?

I don't know. Now I compile the firmware myself in vscode. and the problem doesn't occur anymore.

Well darn. Could you spend a few minutes and re-verify that a "latest" build still doesn't give you telemetry, please?

It's not sounding promising when it's the same git hash and a downloaded build isn't working but a local one does...

[ilia-enginer]

@ilia-enginer do you think you could bisect to find whichever commit stopped things working?

I don't know. Now I compile the firmware myself in vscode. and the problem doesn't occur anymore.

Well darn. Could you spend a few minutes and re-verify that a "latest" build still doesn't give you telemetry, please?

It's not sounding promising when it's the same git hash and a downloaded build isn't working but a local one does...

still not working

[HendrikBock]

I could be wrong, but from my understanding the problem is related to the fact that there are three default parameters in the "sub/Parameters.h" file which are not found. I don't understand this default parameter mechanism, but I guess we are getting a nullptr from AP_Param::find, thus resulting in an error. The three critical parameters are:

• MNT1_TYPE
• MNT1_DEFLT_MODE
• MNT1_RC_RATE

You can see the resulting error when you connect to the serial port of the flight controller with a terminal program. You will see the error message: "Config error: param deflt fail: MNT1_TYPE".
This error will be repeated over and over again.

When you remove those three default parameters from the Parameters.h-file, the system will come up properly.
About the question on when this problem was introduced: I went back to sub-4.5.0 - because that was the first version which supports my FC - and saw that this version already had the problem. I did not check whether earlier versions are also affected.