RunCam serial driver - alpha testers wanted

Progress!
Can you tell me what “features” message you get and what the firmware version of your camera is?
This is a split 2S?

andy

The camera is a Caddx Turtle v2 and it is running the latest firmware. It is supposed to support the runcam serial protocol. I can hook up a Split 2S and a Micro Split 3 today. I will note the features message but I believe it is the same as yours.

Ohhhh, it’s not even a RunCam :slightly_smiling_face: I think all bets are off at this point. Best to get a genuine RunCam working first and then have a look at the Caddx. The two-button protocol is not fully documented so if they have done a clean-room implementation of the runcam protocol I can believe it won’t work.

Looks like the remote is a 4-button remote - not even sure what that would translate to. I think to get it working we would have to do some serious logging and debug. Not saying it can’t be done - just the wrong place to start!

Sure. I will test a micro 3 split and runcam split 2S. According to betaflight wiki caddx turtle v2 works but I have not been able to confirm it. I was just thinking video start stop would work.

So it’s possible that the protocol it supports is the 5-key one that I can’t test in which case there might well be bugs. But if that’s the case it should report a different feature set. Agree video start/stop should work - but if its in the wrong mode then could be a problem. Might be worth trying disabling one of the RC switches.

Are you using the caddx firmware that is downloadable from the betaflight wiki? I agree it should work, so maybe just some bugs to figure out.

I think what I will do is introduce a “features override” bit so that you can force the features to particular values. It used to do this if features was non-zero, but its too easy to save the wrong features that way. I think with features override then we will be able to control exactly what is on or off even if the camera is reporting the wrong features.

I actually used the one from October 2019 on the Caddx download page – one assumes they did not kill the Runcam protocol feature they added in March 2019! I am going to test the Runcams next anyway.

Can speak to the RC joystick control. I do not understand how that works. Or did I misread it?

Ok I have pushed a change that reports the OSD control type supported. You can also use bit 15 in features to override the features

The joystick control is slightly different to BF, people on the dev call did not like that menu enter was very close to the gesture for arm so I have made the default be roll hard right enters the menu instead of yaw hard right. Is that what you mean?

Ok. So the idea is that menu access is only when you are disarmed, right? Using the RC sticks. That makes more sense.

Yes and entering the menu will prevent arming. So you should find if you can enter the menu that you get the de-da-da sound indicating that pre-arm checks have failed.

could put pictures of how to set these protocols
I don’t understand anything about programming anymore I would like to help with the tests
could compile one with debugging enabled?

I’ve put some basic notes here, if you click on the link github will render it pretty well:

I’ll do you a debug version

Debug versions are here: https://www.dropbox.com/sh/ldrh31behoe3ma6/AABRMW1fT7LHVBdF4MxDAijqa?dl=0

Update. I have connected my Omnibus F4 Pro to a Runcam Micro V3 that has been tested to work with serial control with video start/stop. It is flashed with your fork. FC is behaving normally. I should also note the serial port used by the Runcam has been tested and can establish a GCS connection to Mission Planner.

When I boot the FC I get a Mavlink message saying Runcam Initialized Features 0x000. This does not change if the serial port (serial2) set to 26 at 115 Baud (is that the correct baud?) is connected to the Runcam UART or not. So my guess is it is not really connecting to the Runcam.

I am only testing RC10 set to function 78 in this instance. Low to High does nothing to the Runcam Micro V3.

So my question is what does the Features part of the message signify. What should a successful connection look like? This was I thought the surest test as it replicates your runcam setup.

If I compile with debug set to 1, where do the debug settings output?

Features is what is returned by the camera when you send the features message. If it’s zero it means the request timed out, either because the camera is not powered or there is some other problem.

With debug on the easiest way to see it is to use mavproxy, so for instance:

mavproxy.py --console --master /dev/ttyS16

on my setup. Then you will get debug messages in the console.

Baud of 115 is correct?

Yes, but it shouldn’t matter - I explicitly set the baud before opening the serial port

Ok then. Most peculiar.