Hi there!

I have a Iflight Succex E f405 v2.1 that I want to use together with a Runcam Phoenix 2, and would like to access the camera control through bf camera control simulation using my controller. However, there are some odd things happening:

This fc in this version does already have a CC pad, so I would expect not to need any remapping for this to work, but when checking resources, camera_control is not assigned to any pad. So, I guessed it could be because all versions of this fc use the same target in bf, and therefore cannot have camera_control defined, because previous versions of the same fc would not have a CC pad. 

I checked for continuity between all the exposed MCU pins and the CC pad, and found it to be the sixth one starting from the bottom, in the left side of the MCU (looking at the written letters' orientation). According to the pinout in ST's documentation, that's PC3 if I'm not mistaken, so, after checking that C03 was not being used for anything according to bf, I mapped that to camera_control 1. 

Internal resistance and ref voltage for the camera are set to proven values taken from the "Betaflight Camera Control Compatibility Reports" thread in RCGROUPS forum for the same camera. Nothing works.

I checked, and C03 also does not have any timer or dma assigned, which I think would be necessary for camera_control to work, and when I try to assign a timer I get an error (I have tried with anything from AF1 to AF8):
###ERROR: timer: INVALID ALTERNATE FUNCTION FOR C03: 'AF1'###

Any suggestions?? I'm completely lost... Using LED strip pad for camera control is not an option, I am using that pad for actual LEDs.

Thanks!!!

Is your camera the JB version?
If it does you will use the uart Tx and rx pins on camera and they go to an unused uart .

(05-Jan-2023, 08:01 PM)Rob3ddd Wrote: Is your camera the JB version?
If it does you will use the uart Tx and rx pins on camera and they go to an unused uart .

No, it's not. It's the normal one, with analog camera control. The one that's supposed to work with the joystick.

The PC3 pin on an F4 MCU doesn't have any associated timers which is why you can't assign a timer to that resource.

If you traced the CC pad back to the 6th pin from the left on the MCU with the writing on the chip the correct way up then that is the PH1 pin, but that pin is no use on flight controllers and isn't used so I suggest you go back and re-check which pin the CC pad actually goes to because you must have made a mistake.

The smaller of the 2 "dots" on the MCU is the corner where pin 1 is located...




This is the pinout for an STMF405 MCU...

(06-Jan-2023, 06:06 PM)SnowLeopardFPV Wrote: The PC3 pin on an F4 MCU doesn't have any associated timers which is why you can't assign a timer to that resource.

If you traced the CC pad back to the 6th pin from the left on the MCU with the writing on the chip the correct way up then that is the PH1 pin, but that pin is no use on flight controllers and isn't used so I suggest you go back and re-check which pin the CC pad actually goes to because you must have made a mistake.

The smaller of the 2 "dots" on the MCU is the corner where pin 1 is located...




This is the pinout for an STMF405 MCU...

Damn!! I didn't know I had to look for that dot to know where pin 1 was! Then it's not PC3!! Also I might have explained myself incorrectly. It was the 6th pin starting to count from the bottom left, but UPWARDS. So actually in the left side of the square, not in the bottom side. So it would then be PB7. I'll try it and let you know.

Thanks!!!

(06-Jan-2023, 08:13 PM)krprd Wrote: Damn!! I didn't know I had to look for that dot to know where pin 1 was! Then it's not PC3!! Also I might have explained myself incorrectly. It was the 6th pin starting to count from the bottom left, but UPWARDS. So actually in the left side of the square, not in the bottom side. So it would then be PB7. I'll try it and let you know.

Thanks!!!

It let me set B07 as CAMERA_CONTROL pin, it let me assign AF2 timer to that pin, and I assigned dma 0 to it too (this last step I don't really know if it's necessary). I have reached further, but seems like it still won't work... My camera_control settings are the following:

Quote:# get camera_control
camera_control_mode = HARDWARE_PWM
Allowed values: HARDWARE_PWM, SOFTWARE_PWM, DAC

camera_control_ref_voltage = 320
Allowed range: 200 - 400
Default value: 330

camera_control_key_delay = 180
Allowed range: 100 - 500

camera_control_internal_resistance = 195
Allowed range: 10 - 1000
Default value: 470

camera_control_button_resistance = 450,270,150,68,0
Array length: 5

camera_control_inverted = OFF
Allowed values: OFF, ON

Any other suggestions? 

Thank you

For future reference the identification writing on an IC can be printed in any orientation and will depend on the manufacturing process, so you can't use the orientation of that writing to determine where the pin numbering starts. There is always a dot on one of the corners of an IC chip to indicate where pin 1 is. If there is both a large and small dot like on the STM32 MCU's then you generally use the smaller dot for the pin 1 location.

Can you please run the "dump" and "resource show all" commands in the CLI and post the results back here so we can take a look at all your current settings.

(06-Jan-2023, 09:58 PM)SnowLeopardFPV Wrote: For future reference the identification writing on an IC can be printed in any orientation and will depend on the manufacturing process, so you can't use the orientation of that writing to determine where the pin numbering starts. There is always a dot on one of the corners of an IC chip to indicate where pin 1 is. If there is both a large and small dot like on the STM32 MCU's then you generally use the smaller dot for the pin 1 location.

Can you please run the "dump" and "resource show all" commands in the CLI and post the results back here so we can take a look at all your current settings.

Thank you for the clarification on the pin numbers! Don't think I'll ever obviate that again.

"dump" and "resource show all" outputs are in the files attached. (
  dump.txt (Size: 29.76 KB / Downloads: 36) , 
  resource_show_all.txt (Size: 2.01 KB / Downloads: 35) )

Thanks!!

I can see nothing wrong with your settings. Try reverting to default values for all of the camera control settings. You have the default values set except for the two following settings, so try setting those back to the default values shown below...

(07-Jan-2023, 06:34 PM)SnowLeopardFPV Wrote: I can see nothing wrong with your settings. Try reverting to default values for all of the camera control settings. You have the default values set except for the two following settings, so try setting those back to the default values shown below...

Code:

set camera_control_ref_voltage = 330
set camera_control_internal_resistance = 470
save

Tried. Still doesn't work

Maybe there's a fault with the OSD function on the camera itself rather than an issue at the FC end, or maybe you just need to use trial and error to figure out what camera_control parameters will work for your particular setup. Analog camera control was always a bit flaky and could take a lot of head scratching to get working on some setups. Newer versions of Betaflight could also have introduced some bugs which prevent ti from working reliably.

I would try the camera on another FC which has the Camera Control resources already pre-configured correctly in the Betaflight target settings so you can then either confirm or eliminate the camera itself as being a cause of the issue. You can also try and get hold of one of the RunCam OSD Keyboards with 5 buttons on (see HERE) and connect that directly to the camera (thus bypassing the FC functionality) to see if that works at all. If it does, you will then know that the issue is with the FC / Betaflight settings.

(09-Jan-2023, 03:58 PM)SnowLeopardFPV Wrote: Maybe there's a fault with the OSD function on the camera itself rather than an issue at the FC end, or maybe you just need to use trial and error to figure out what camera_control parameters will work for your particular setup. Analog camera control was always a bit flaky and could take a lot of head scratching to get working on some setups. Newer versions of Betaflight could also have introduced some bugs which prevent ti from working reliably.

I would try the camera on another FC which has the Camera Control resources already pre-configured correctly in the Betaflight target settings so you can then either confirm or eliminate the camera itself as being a cause of the issue. You can also try and get hold of one of the RunCam OSD Keyboards with 5 buttons on (see HERE) and connect that directly to the camera (thus bypassing the FC functionality) to see if that works at all. If it does, you will then know that the issue is with the FC / Betaflight settings.

I have tried with an OSD keyboard that I had laying around from a foxeer camera and it works perfectly with the runcam phoenix 2. So I would guess that it would need the same values in camera_control as that Foxeer camera. But that camera used to work flawlessly with the default bf values in my previous FC, that also had a CC pad. No configuration needed, just plug&play. However, I didn't have the chance to try the new camera in that FC yet, neither did I try the old camera in the new FC. I'll give it a try, hopefully this week.

Thank you!

You might just be out of luck getting Camera Control to work with the iFlight SucceX-E F405 V2.1 FC if the root cause is down to poor hardware design of the FC itself (which wouldn't really be a surprise with iFlight electronics). It might also explain why the unified Betaflight target for that FC doesn't have the Camera Control resources mapped. Maybe whoever maintains that unified target already knows that Camera Control doesn't work properly on that particular FC even though it has a dedicated CC pad on the FC.

(11-Jan-2023, 10:55 AM)SnowLeopardFPV Wrote: You might just be out of luck getting Camera Control to work with the iFlight SucceX-E F405 V2.1 FC if the root cause is down to poor hardware design of the FC itself (which wouldn't really be a surprise with iFlight electronics). It might also explain why the unified Betaflight target for that FC doesn't have the Camera Control resources mapped. Maybe whoever maintains that unified target already knows that Camera Control doesn't work properly on that particular FC even though it has a dedicated CC pad on the FC.

Sorry for taking so long, but I have updates that may prove you right. I had the chance to try the older camera in this new FC with the exact same values that would make it work fine in the older FC, and it didn´t work, so yes, I would guess it's FC's fault. Unnfortunately I could not try it the other way around, but I don't see how that would fix my proble even if the new camera would work with the older FC. 

Thank you for all the help though! I learned something in the process at least...