Control RunCam Split 4 video recording from a radio transmitter

I will look this evening to see what version firmware I am running, I believe it was the latest stable version, but will check this evening.

Also , I forgot ask you a question. I was using my laptop for ardupilot mission planner ( windows version)to change all my parameters, but after about a week of using it to set up my wing it started to have issues. every time I open mission planner it will freeze up, so ended up downloading mission planner (Linux version) on my tablet which does not freeze up, but did notice that some of the parameter settings that was on the windows version does not seem to show on the app based version. Have you come across windows based version of mission planner freezing up constantly and if so did they have fix for that. I have seen a lot of talk about other people having this issue, but no one has really addressed the issue. Cause I am wondering if the app version has limitations as far not being able to some parameters that would show up on the windows version, I will definitely look tonight ,when I get home and check the version of the firmware that is installed on my matek h743 wing fc.

Use the beta - I’ve not had any issues with that

Ok, I am running mission planner 1.3.74 version and ardupilot v.4.0.9 firmware on matek h743 wing fc. What version firmware do suggest for fc to solve the runcam hybrid issue and do I need a different version of mission planner for different fc firmware? Oh, and thank you by the way for all of your help, very appreciated.

You need to use ArduPilot 4.1 - since there is currently no beta for Plane you may have to wait. Copter 4.1 beta is out.

Well, here we go again. I moved a Split4k from an F405-CTR (where start/stop worked perfectly) to an F405-WING. On that FC I used the same UART I’m using in another wing to control a Hybrid (UART 6), which also works perfectly there. F405-CTR was AC, now it’s AP (obviously).

The settings are the proven ones, yet start/stop won’t work:

RCn_OPTION = 78 for start/stop
SERIAL6_PROTOCOL = 26

CAM_RC_BT_DELAY,7000
CAM_RC_BTN_DELAY,300
CAM_RC_CONTROL,0
CAM_RC_FEATURES,247
CAM_RC_MDE_DELAY,800
CAM_RC_TYPE,3

One thing I noticed is that the features populated by querying the cam include all boxes ticked - except “Stop recording”. So I ticked that one manually but even after many attempts the cam won’t react to the switch I set. So what is it this time? :wink:

And something I noticed while working on this and really got me excited: There is now SERIALn_PROTOCOL = 27 - Smart Audio?! I found this page but it looks a little broken on my browsers: https://ardupilot.org/copter/docs//common-vtx.html

I was really waiting for this. So far I’ve been controlling SA VTXs directly from the Crossfire RX but of course it’s much nicer to have it integrated into AP. Also some VTXs (Rush, for instance) don’t understand the SA signal coming from the TBS RX so I had to press physical buttons on the VTX with those. Can’t wait to try it out!

So the only difference is the flight controller and it works on one and not on the other? Or are you saying the difference is AP vs AC?

You need to take the extra / out of your URL then it will work

If you can make it break on the CTR I can probably figure out what the problem is - I have a CTR I can test with

Was curious since 4.1 beta came out, do you think it will solve the issue with being able to turn hd recording on and off on the run cam hybrid v2. I know you told me to wait for 4.1 to come out or should I wait for a stable version.

The fix is in the latest beta - so you should try it

Yes, the FC is the only thing that changed. Start/stop worked on the CTR but not now on the WING. AP vs. AC might just be a coincidence, just wanted to mention it.

This is only for a DART 250G, so there won’t be long flight preparation and therefore not much useless 4k video before launch, so it’s not extremely important to have that start/stop switch working. But just when I thought I can make this work on any craft now… The other 2 cams are Hybrids though, so it’s not exactly the same. Should I maybe run Mavproxy again with a special version?

OT question that just cost me an hour: I can’t seem to find NTF_DISPLAY anymore in latest plane dev versions? So far I had them on all AP crafts to indicate armed state, just in case it goes down and people help searching, so they’re warned in case disarm didn’t work.

Thanks for the correct link, for some strange reason the extra / was included in a link I found via startpage.com (results by Google).

1 Like

NTF_DISPLAY is only on 2Mb boards now

I had checked https://ardupilot.org/plane/docs/common-limited-firmware.html#common-limited-firmware and hoped this wouldn’t be the case. Display is not included there. Does that mean it will stop working on all my existing crafts (all running 1 MB FCs) once I update them, and is it possible to tell on which date this change occured? Looks like a big update freeze is coming up for me now, as I can’t afford to buy 5 new F7 FCs and don’t have the time to rebuild all those models either. To me the OLED display is an important safety feature I’m used to and that I really don’t want to give up.

I think 2 weeks ago when I last updated another F405-WING, the display was still working afterwards (and by the way, external I2C baro, which has been on the list for a while, is still working for me on 1MB). On a side note, I wonder why NTF_LED parameters are still available, as I was under the impression they required LUA, which never was working on 1MB?

NTF_LED works it does not require LUA. The problem is that the display code takes up quite a bit of flash and we didn’t think it was used that much. This will all be solved with the custom build server.

1 Like

Ok, I want make sure that I do this correctly, first I save my parameters to a file on desk top, then install new beta firmware and then reload the saved parameters. Also not a big deal , but I will do another auto tune after every firmware update? How often should I do a auto tune, because after doing a auto tune , I would like to put a different flight mode in place of auto tune and if I have to do another auto tune just add it on the flight mode tab perform auto tune and replace it with different flight mode?

It’s worth saving your parameters but the upgrade from 4.0 to 4.1 should preserve your parameters and not require you to retune.

Ok, lost one, gained one. I had always been under the impression that there are no LEDs without LUA on AP. So I always used ones that flash on their own. Using NTF_LED will be a good replacement for the display, at least to warn about armed state.

I had read about the custom build server a while ago and found the idea fantastic of course. However, it sounded like it could still be some months off.

In any case I will still put a display on the DART as planned and either keep using the dev version from the beginning of June which still had NTF_DISPLAY, or wait for the custom build in case I decide to upgrade. Thanks!

Sounds like you used iNav before, which sometimes forbids you to import old parameters, even on minor version changes. Luckily it’s different here. :wink:

Is this on plane or copter that you want it? It’s possible that as we get close to the release that if there is still enough flash we could put it back - the challenge is that seems like a pretty little used feature compared to other things that are already disabled on 1Mb boards.

Well, maybe I am the only NTF_DISP fan - it’s true that when watching peoples’ build videos usually a display is not part of the process. But I find it very practical, even on the bench and while building. For example in rare cases, the OSD doesn’t show up and the display is a quick way to see if booting has completed anyway, even without connecting a GCS. Or if someone is about to throw a plane for me while I’m already seated with goggles on, he can check for prearm failures himself (for example, holding plane more level). I simply like redundancy I guess. :wink:

As for warning about armed state after a crash, a display is very useful IMO, although NTF_LED might be even better. I will try it today I hope.

It’s hard to say if I’d like it to remain in on copter or plane - actually on both, as I hope by the end of the season I’ll have 4x AP and 3x AC. But if I have to pick one I’d say plane because it’s always easier to find a good place to mount a display there.

As for disabled things, I think the list at https://ardupilot.org/plane/docs/common-limited-firmware.html#common-limited-firmware must be a little outdated, as I2C baro is still working for me on F405-WING and Kakute F7 AIO and really hope it can stay (I like to put a temp sensor out on an arm/wing). Even CRSF telemetry is in that list if I interpret it correctly, and in-flight FFT which I used last autumn on F405-CTR.