Runcam Split control Flaky

[Redshifft]

Very intermittent UART control on 1.8.1 with Runcam Split V1 on latest fw v2.0 (or any other fw) When it works the control acts like a toggle, I'm am unsure if this is even the correct. Regardless at next boot it often does not even work at all.

[RealmsFPV]

I can confirm this issue also. Tried Split FW 1.1 and 2.0 with same results. Flashed iNav back to 1.7.3 and no issues.

[RealmsFPV]

Also...I have camera power activated when I arm. When disarming the camera it is still recording, it doesn't stop the recording. Is that normal?

[Redshifft]

Good you posted, tbh although I get it working occasionally I have not seen the thing working as it is intended with regard to how it works, seems to toggle the functions? Starting with the descriptions of the actions it is very poor from i'm assuming runcam (power,which should be called start/stop) etc

[Redshifft]

I did not mention, when it was working I did not use the "Auto start" I could not see the point as it could be started and stopped remotely. I think the issue has to be an initialisation problem in latest INAV because if you get it working all is well until the battery is disconnected

[RealmsFPV]

I got it to work once and that was it on 1.8... I had auto start on power up disabled also however when toggling the camera power mode it just wouldn't start. Tried this on both Runcam FW 1.1 and 2.0 with the same outcome. With iNav 1.7.3 it worked everytime except it doesn't stop the recording when i toggle out of the mode.

[Redshifft]

Lol, sounds like when mine worked it worked the same. Basically runcams control logic is so basic it's essentially a toggle and each time it sees whatever (protocol via the UART) it gives it the same as a button press action - which would be why it requires 3 control switches and each action just toggles the state You will love the workaround I have done to enable 1 switch to start and stop the video ;) We just need the Devs to find the problem with it not initialising and if you have a Taranis I will show you how to do it. In1.7.3 did the "mode" light up in the configurator when you actioned the camera control?

[RealmsFPV]

Yeah it's pretty basic.... I can knock up a logical switch to fix that. Just checked and no.... the mode doesn't light up when starting the camera in 1.7.3 at least it works though!

[Redshifft]

Interesting, no light should mean it is not actioned apparently - mine did not also Yeah for the function to toggle it needed so see that UART for about 250ms, problem was you could toggle states by setting INAV to switch at say 1000us and 2000us but if the switch was switched fast it sometimes did not action then next time you switched to "on" it would turn off the record :) Ingenious 0.5sec "servo slow" on that switch channel with the activation range set across the middle range say 1.2~1.8ms allowed the perfect repeatable time to toggle the function every time :) worked a bloody treat, only then to discover this problem :(

[RealmsFPV]

Ah yes, I noticed that too. Just tried your fix and works a treat. You could create a logical switch that is triggered by a physical 3 way. You could have both top and bottom of the switch the same value to start/stop and the middle is out of the activate band.

[fiam]

The problem is that until firmware 2.0, there was no way to ask the camera to start/stop recording or take a picture, the only thing the API could do is simulate button presses. That's the reason why currently the controls are so clunky.

I plan to drop support for RC Split firmwares < 2.0 and make the camera handling more robust, but time has been tight lately.

[Redshifft]

`

Baud Rate	Data Bits	Stop Bits	Patiry
115200	8	1	none

`

[Redshifft]

@RealmsFPV :D no one will touch me with a mechanical solution, I just don't do code

@fiam all the fw versions acted the same - suppose it would with the same operating code which it seems Runcam wrote and added to INAV - strange Betaflight has had the same problems just recently

[Redshifft]

Didn't have a long run of success.. https://github.com/iNavFlight/inav/commit/fa603a27ef09680688a7129bd7a742ad1ff7c85e

[Redshifft]

It did not paste that serial code here is a link.. https://support.runcam.com/hc/en-us/articles/115011786628?input_string=runcam+split+inav+control

[azolyoung]

Hey guys, I'm sorry about that, the 1.8.0 can't work with your split, might be it was caused by the PR that used to support new RC SPLIT firmware(including exactly control, like start/stop, take photo...), and it was submit by me:(, @fiam was help me to improve the camera date update and useful suggestions, thanks!

and I'm preparing a PR for this issue, I think this problem was caused by the initializing for the device failed when the duration of rcsplit initializing is longer then FC, so the FC can't communicate with RC SPLIT correctly. this is the first look of the PR, but still need to confirm it has solved this issue:( https://github.com/azolyoung/cleanflight/commit/23e7b0b0e25041318cfdce4182362f99ef61689f

@RealmsFPV , If I gues right, you've test the SPRACINGF3(1.8.1), but still not work:(, is that right? I still suspect the camera out of control is caused by failure of initialization. and If your throttle is unlocked, in the 1.8.1(the SPRACINGF3 firmware we sent to you) it may also cause RC SPLIT to fail to initialize, Is it possible？

@Redshifft could I sent a test firmware to you to confirm 23e7b0b is solved the issues in you case? If ok, please tell me the name of your FC BOARD, I'll post the firmware af here.

[RealmsFPV]

@azolyoung Yes, that was me from the Runcam support channel. I tested 1.8.1 on SPRACING F3 but could not get it to work. Are you saying it wont activate if the motor/s are armed?

[azolyoung]

Hi @RealmsFPV , Yes, for now, there are two places will initialze the RC split:

1. when FC initializing, it'll try to initialize RC split, but it might failed in some cases, e.g RC split still in initializing when FC talk with it
2. when the modes and serial port are setup, and you try to active the MODE, FC will check the RC SPLIT status, if it is not prepared, FC will try to reinitialize RC split, but it will do nothing when motors are armed

so I guess you can't work with the test firmware, it might be the motors are aming

[RealmsFPV]

@azolyoung I see. It's a pity because I only want to start recording and stop when arming and disarming. To have the function on the same mode switch just seams logical to me. Can this be done?

[azolyoung]

@RealmsFPV Oh, I see.. so your arming channel is same with channel of start/stop record?

[RealmsFPV]

@azolyoung Yes, correct. Makes sense to me. I arm and take off land and disarm. Exactly when I want to record!

[azolyoung]

@RealmsFPV Please try again with the following test firmware, it's build for SPRACINGF3.

I've adjust the timeout duration of RC SPLIT initializing, the original is to try three times, each longest time is 100ms, now is still try to initialize three times, but each longest time is 300ms, in normal case, it's should initialize success in second try. inav_1.8.1_SPRACINGF3.hex.zip

[Redshifft]

@azolyoung Thanks for helping out here and sorry I have not been around. My target/board is not on the list I'm afraid. Could you highlight the code changes you made?

[RealmsFPV]

@azolyoung Thank you. Just tested the changes and works perfectly. Will it be possible in the future for start and stop to be two distinct commands?

[Redshifft]

Yes that and a one command take picture would all I would think 99% of users would really want for the remote control @RealmsFPV did you try a logic switch in taranis?

[RealmsFPV]

@azolyoung No because I dont have a spare channel to assign to the logical switch. It would work but shouldnt have to be that way. I'd prefer to have it so when the mode is within a certain range it sends the start command and when outside that range it sends a stop command. I understand the command sent is interpreted as a button push is that right?

[azolyoung]

@Redshifft :), yes, please take a look with the following link, just change three constants: https://github.com/azolyoung/cleanflight/commit/8053bff0a48d7f59a54f78c1eae4bd72bc2c595e And I'll submit a PR to fix this issue after you confirm it can work fine as well. Thanks!

@RealmsFPV, @Redshifft understanding, it's make sense, in the next version of RC split, we've provide distinct commands to start/stop recording, and also take photo. but for now.. I've no idea why it still has a serious bug, my colleague told me it's caused by the OSD feature even we've disable it. but for now, we don't want to remove the OSD feature totally, my colleagues also has other jobs working, After our Spring holiday, I'll push on it to make it release ASAP.

[RealmsFPV]

@azolyoung Thanks that will be great to have those features. Thanks for getting 1.8.1 working for me as is.

[azolyoung]

@RealmsFPV Great! Thanks for your testing!

[fiam]

@azolyoung I’m thinking of writing a new fully async driver from scratch for the RC Split. Please, message me on slack if you have time. Thanks!

[Redshifft]

@azolyoung Thank you for the quickly giving us the work around, I will try to get a build with the modified initialization added and let you know how it works

[Redshifft]

@RealmsFPV what fw version do you have on your split ?

[Redshifft]

@azolyoung I have just spent 5 hours trying everything with latest INAV 1.9 (with fix) Sorry I am going to say your fix does not work for this F4 Board, it is actually worse than without the fix and almost impossible to get an initialization.The only way I can get it to work is to force a FC reboot after everything is powered up using INAV's Configurator to me this indicates the Runcam is too slow to get to a listening state from cold start. maybe you need a 2~3 sec initialization delay - something along these lines would work for for sure as hot initialization is 100% repeatable in my testing.

[fiam]

@Redshifft The fixes haven't been committed to the development branch yet. Not sure from your comment if you're stating that you applied #2767 on top or you were expecting the development branch to have the fix. Can you clarify if you applied #2767?

[fiam]

@Redshifft just in case you see this later, if the problem persists with #2767, please edit src/main/io/rcdevice.c and around line 193, make the code inside the if look like:

     if (commandID == RCDEVICE_PROTOCOL_COMMAND_GET_DEVICE_INFO) {
          max_retries = 10;
          timeoutMs = 500;
      }

Assuming you're using FW 1.1 or later, that should give the camera up to 5 seconds to initialise itself (FW 1.0 is initialised using a different code path). Let us know if that works for you and we'll see if we can find a quick solution for 1.9.

[Redshifft]

@fiam sorry I have not followed this for a few hours. Yes it was the #2767 patch applied to the build.

I would say almost certainly your code change will work as it falls in line with my thoughts on what kind of time the Split needs to do it's beeps and initialisation before its receptive to serial control packets. As I mentioned earlier I am on fw v2.0

I will see if I can get your mods added, unfortunately there is only one person in the whole world with the necessary skills to build the fw for my board (for reasons I wont go into here) :D Thanks, I'll keep you posted

[spoler]

As @Redshifft said, behavior on 1.9.0 with Runcam Split V1 on latest fw v2.0 is following:

The only way I can get it to work is to force a FC reboot after everything is powered up using INAV's Configurator to me this indicates the Runcam is too slow to get to a listening state from cold start.

So it seems increasing max_retries/timeoutMs should fix the problem.

[stale[bot]]

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help. This issue / pull request will be closed if no further activity occurs within two weeks.

[ihsanonsoy]

Hi, I have similar problems with runcam Split mini and Inav communication. Should I wait for a fix? Thank you for your efforts and work.

[advancetom]

same issue working after reboot then nothing :( Inav 1.9.1 Omnibus F4 Pro v3 Hope a fix coming soon

[mu2004]

Same problem on Matek F405-CTR 1.9.1.

[advancetom]

the problem is not fixed i tried with inav 2.0 RC3 doesnt work pls increase timeoutMs =1000 to 5000

[putimir]

Same here on RC4, RCSv2 fw. 2.0 - @azolyoung: is there something we can do to change code and build it ourself? Thanks!

[Redshifft]

The simple fix is to use the PWM control (sold with a usb adapter) Cut the cable and use the white o/p from control module into that split RX pin, map a PWM on the FC or your RX and you will have a reliable control. You won't fix it any other way until the control logic is re written. I spent a lot of time on this issue :)

[advancetom]

Make a reboot over OSD then it Works

[putimir]

Yes I did that, I also built it myself with increased timeouts and retries, but to no avail. I also tried on 2 different boards (Matek F405-wing and F405-STD, with 2 (brand new) Runcams, Split v2 and Split mini.

I just got "semi generic" answer from Runcam:

Sorry about this situation.

We have noticed this bug with iNav Flight controller and will get it solved and update the new firmware.

But our technician is now busy with some other urgent project. You may have to wait for sometime. We will let you know once it is ready. Regards, Stella T. RunCam Customer Service

[er9xuser]

Unfortunately still doesn't work. iNav 2.0, Matek F405-STD and the latest FW V2.1.7 from 30.08.2018 for RunCam Split v2.

[putimir]

Yea, I was in contact with Runcam few days ago, trying to put a little pressure on them and maybe get a courteous PWM module in the meantime :)

The answer was:

Do you refer to this module? It is not for sale separately. If you need it, you can buy this remote cable from us.

and

We will update you the firmware when we get it ready.

Excellent 👎

I suggested that they remove iNav as the compatible controller from their description.

[putimir]

Hey @Redshifft, I got the board today, can you provide more detail on the procedure:

1. I suppose I need to power the board with 5v, right?
2. I cut & connect the white signal wire on one side (the one with usb plug) to the RX pin of the split - what do I use on the other / FC side? (using Matek F405-WING, iNav ofcourse) How do I map PWM on iNav?
3. Is there any documentation on which PWM values translate to which Split commends?

Thanks a lot!

[azolyoung]

Hi,

Sorry for the late reply:(, I have make some test firmware to fix this issue, and the source code was submitted to my inav fork:https://github.com/azolyoung/inav/tree/fix_rcdevice_not_work, please test it, thanks!

https://s3.amazonaws.com/rctmpfiles/inav_test_fws/inav_2.1.0_OMNIBUSF4V3.hex https://s3.amazonaws.com/rctmpfiles/inav_test_fws/inav_2.1.0_MATEKF405SE.hex https://s3.amazonaws.com/rctmpfiles/inav_test_fws/inav_2.1.0_MATEKF405.hex

[putimir]

Great! I will do that asap!

One more thing:

I know it's far fetched, but will there be a possibility to remote turn on/off the device? The main problem I'm having with my builds, is, added interference for GPS module to make a satellite lock (I can reproduce how GPS modules lock without the RCSplit turned on and loose lock after power on; plus I can reproduce how GPS modules cannot get a lock while RCsplit turned on, and after 5-10 secs after RCsplit is turned off, I can get lock....So the solution for all my builds, where I have the Split accesible, is to have the Auto power-on disabled, wait for the lock and then power on the Split. The problem is with builds, that have the Split burried in the fuselage, without access to the buttons....:(