Inav: 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....:(

[azolyoung]

Thanks for your help!

Yeah, I have forward your idea to my colleague. we have receive some user feedback, they also met this problem, runcam split will interfere the GPS device.
And we make a EMC box or Aluminum box, put runcam split into the box(The runcam split has been insulated), then runcam split and gps can work fine together.

[putimir]

Tried today, but no luck (MATEKF405SE + RCSplit V1, V2.0.0,16th,Jan 2018)...

Is the fix universal or it is hw/fw specific?

I received info from Runcam, that the solution is in Runcam firmware not iNav...?

[azolyoung]

@putimir

I want to confirm:, your tx\rx of rcsplit has been connected with the spare uart of the flight controller?Will your rcsplit blue light continue to flash after power-on?
When the blue light continues to flash, does your rcsplit have inserted a sdcard, and this sdcard has free space?

[putimir]

your tx\rx of rcsplit has been connected with the spare uart of the flight controller? - yes absolutely

I have set my split to auto record, so after power on, + 2 sec (cca), it starts to record, so the blue led blinks in cca 1 sec intervals...

If I then try to operate the remote (via TX switch / iNav modes), nothing happens. I also tried to reboot FC after power on, but no luck either....

[Redshifft]

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

I suppose I need to power the board with 5v, right?
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?
Is there any documentation on which PWM values translate to which Split commends?

Thanks a lot!

Sorry mate, I did not see your question, Inav has a new mixer now, sure someone can help you get just a high, medium and low pwm out of servo output. map to a 3 way switch and play with it, a fast toggle switches modes and on end starts and stops record or picture.
Take a look at painless360 on YT think he had a vid on Runcam control :)

[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.

[Nihilistic]

I'm having the same problem with my Runcam Split 2S wired to a Matek F405-CTR. I know the wiring and switches are set up correctly, because if I reboot the FC either via the iNAV configurator or OSD stick menu, all three of the transmitter switches will operate the Split 2S as they're supposed to. But, none of them work after the initial power up without a reboot of the FC with the Split 2S already powered up. I'm running iNAV 2.0.1

[Haukanes]

I added a small delay before the init() function in main, which fixed the issue for me.

[teckel12]

@Haukanes Do you have the changes you can share so we can merge into 2.1? You can just attach or post them here and I can do the pull request if you want.

[Haukanes]

You can see it in my inav fork. It was not meant for a final version, just to check if slowing bootup would help.

[datamann]

https://github.com/Haukanes/inav/commit/321248028f8c18d49ab8d8ee2d18fcda55fa8cc4#diff-c27ac60319310f0e3b936bca81499818

[azolyoung]

Sorry to reply so late. Last week until now, it took some time to debug the issue that runcam split can't be controlled via iNav. This time, I finally reproduce the uncontrollable phenomenon. Because the Split data cannot be received correctly during the initialization process, the initialization fails. At present, I can't find the specific reason. Since I have spent a lot of time looking for the cause, but still can't locate the problem. So for the time being I made a compromise, using two cli commands to make the camera's features recognizable correctly.
The main changes to the test firmware linked below are:
1.Change the Split communication protocol to asynchronous, avoid blocking camera initialization, causing motor restart or other strange problems.
2.Added rcdevice_protocol_version and rcdevice_feature to manually identify the camera's characteristics and protocol version number.

If you still can't enable camera control using the following firmware, please paste the following three commands into the cli interface and try again:
set rcdevice_protocol_version = 1
set rcdevice_feature = 7
save

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

[Bobi456789]

Hi , I would be extremely grateful if you could help me. I have the same problem with runcam split 2s firmware V 3.1.0 but with kakute f4 v2 , inav 2.0.1
thank you so much

[azolyoung]

@Bobi456789

Yeah, thanks for you help! following firmware is for KAKUTEF4 and F7.

https://s3.amazonaws.com/rctmpfiles/inav_test_fws/inav_2.1.0_KAKUTEF7.hex
https://s3.amazonaws.com/rctmpfiles/inav_test_fws/inav_2.1.0_KAKUTEF4.hex

[Bobi456789]

Hello, I tried your firmware but did not work for me. My card is kakute f4 V2. Maybe you gave me the firmware for Kakute f4.
thank you.

[azolyoung]

@Bobi456789

Sorry, although you have repeatedly stressed v2:(. I still generated a v1 for you. . Here is the correct V2 firmware:
https://s3.amazonaws.com/rctmpfiles/inav_test_fws/inav_2_1_fix_rcsplit_telemetry_control/inav_2.1.0_KAKUTEF4V2.hex

[teckel12]

What is everyone's experience when using the Split and GPS? Lots of reports of the Split causing GPS issues.

[azolyoung]

I tried making a box with Aluminum EMF Foil, wrapping the splits and exposing only the 3 PIN nests. In this case, when the GPS and the Split are firmly connected together (one above, one below), the GPS can search for stars normally. On our company's balcony, we can also search for 6-8 stars.
The box made last time has lost. I will do another for testing.

When the Split is powered on, it will interfere the gps search. We find that as long as the Split and the GPS module are not particularly close, the GPS will work normaly. The split can cause high frequency interference to the GPS, so it is impossible to search for stars. Adding a shielded box to the split will improve the situation.

[teckel12]

@azolyoung So unfortunate. I'd love to try split, but the GPS interference is a deal-breaker for me

[putimir]

I get the best results (which are very good actually), if I don't power the split until I get sat fix, which is usually within 30 secs or so from cold start, and then power on the split ..try it

[Bobi456789]

Hello, I tested the firmware, split 2s works but I had a problem with the configuration system. So I'm going back to 2.0.0. Thanks anyway for your help

[Nihilistic]

@teckel12

I have a BN-880 mounted on the middle of the top plate of a Kensun KK210 frame, a little bit rearward of the stack. Individual ESC's on the arms, F405-CTR mounted on rubber bobbins, the Split 2S above it on spacers and the included gummies. And my GPS gets a lock with low HDOP in the normal amount of time, and just gets better throughout the flight. My Crossfire Nano RX will cause more interference if it's too close, so it's mounted forward, and the VTX is at the rear. POS & ALT HOLD works great, and RTH works great.

What I like to do is wire the GPS, RX, and VTX, with longer wires than necessary at first, so you can play around with placement while everything is powered up. You could try putting your VTX on the bottom plate behind the stack, and your BN-880 above it on the top of the top plate. That's enough clearance to avoid mag or GPS interference from the VTX, and then your GPS isn't sitting directly above the Split 2S.

Maybe other GPS modules are more sensitive. I have a mini M8N I got from banggood that's in a puck, and it costs twice as much as the BN-880, weighs twice as much, and locks in half the satellites, and takes twice as long to do it. It's sitting unused in my parts bin. BN-880 for the win!

[Nihilistic]

@azolyoung Is this fix going to get rolled into a future release? I hate to keep bugging you to add the fix to all these targets every time they release a new RC.

[teckel12]

@Nihilistic Even though the BN-880 is a clone, it's a damn good GPS module, and only $18. The only GPS I fly with.

I've heard such bad stories about the Split and GPS signal strength that it's really got me worried about wasting the $$ on the Split or losing the entire quad due to GPS interference.

So you find that the Split stack is where the interference is, it's not with the camera or cable between the camera and the stack?

I wonder if there's much difference in interference between thr Split and the Caddx Turtle.

[Nihilistic]

@teckel12 I have my BN-880 almost directly above the stack, sticky taped to the top side of the top plate. It's maybe a centimeter rearward of being directly above the stack, to make room forward for where I used to mount my Mobius Mini. It has enough clearance from the VTX and Crossfire Nano RX and other stuff that I get plenty of satellites, and haven't noticed any issues with the magnetometer. There might be an even more optimal arrangement, but this one works well enough I feel I can trust RTH to work manually or upon fail safe.

I've never actually tried mounting the GPS on a staff to see if there would be a noticeable improvement (quicker 3D fix and/or more satellites). I typically get as many as 17 satellites with HDOP below 2, and I don't even have Galileo enabled, so I don't feel the need to bother. If I needed waypoints or wanted rock solid POS/ALT hold to turn my quad into a flying selfie stick, than I might find further tweaking beneficial.

Good question. I'd like to see one of the youtube reviewers that has the Split 2S, Caddx Turtle V2, and the new Fox Mix, do some interference testing with a spectrum analyzer or something. I've seen Bruce at RCmodelreviews test various key chain style cameras (like the Mobius) for interference before.

[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.

[stale[bot]]

Automatically closing as inactive.