Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SPI-RX frsky_x lockup #6172

Closed
brycedjohnson opened this issue Jun 19, 2018 · 94 comments
Closed

SPI-RX frsky_x lockup #6172

brycedjohnson opened this issue Jun 19, 2018 · 94 comments
Labels

Comments

@brycedjohnson
Copy link
Contributor

@brycedjohnson brycedjohnson commented Jun 19, 2018

Example of the issue and my cat grooming. At about 1:02 you can see the on time stop incrementing at 1:33. If you were flying it would fall out of the air. Seen this issue with Matek411RX and crazybeeFR F3.

https://www.youtube.com/watch?v=GtK06Mvrtwc

The debug info is the spi_frsky_x debugging. I was walking around out of the room and holding the antenna so it might have missed some packets. Not sure if that causes the issue to happen more?

In this issue I was looking at the root cause and it seemed like it was related to smartport telemetry:
#5576 (comment)

Haven't tried disabling the telemetry slidered on the configurator. That may stop this from happening, but you loose telemetry.

You can also switch to frsky_d and it doesn't have this issue.

Diff all is the same as from #6171

@mikeller
Copy link
Member

@mikeller mikeller commented Jun 20, 2018

FrSky D still has a problem with occasional lockups when telemetry is on as well - it seems to be tied to the pre-existing CPU load, i.e. it happens more often if faster loop times are used.

Recommendation: Do not use telemetry when using FrSky SPI RX.

Loading

@brycedjohnson
Copy link
Contributor Author

@brycedjohnson brycedjohnson commented Jun 20, 2018

I haven't had any lockups on frsky D and telemetry on pre-3.4RCs, but I was only running at 4k/4k.

Loading

@mikeller
Copy link
Member

@mikeller mikeller commented Jun 21, 2018

@brycedjohnson: Interesting. My suspicion is that the lockups are caused by the generation of telemetry frames taking up too much time, and causing the SPI RX to get out of synch. If this is the case, then whether or not it's happening on a given setup will be dependent on the MCU type, and also on the number of present / activated features.

Loading

@JamilFayad
Copy link

@JamilFayad JamilFayad commented Jun 21, 2018

Hey I am facing the same problems it is just locking up and I'm losing controls mid-air. That's not good at all. It is not falling out of the sky tho as someone noted here before. https://youtu.be/RA1teE-yYfc
Provided is a link to the DVR footage recorded as such issues were faced. Important moments to note out in the video is the 26th second, 41st, and 2 minutes and 15 seconds into the video. Any recommendations so I could have this flying the way it should? Thanks :)

Loading

@pkruger
Copy link
Contributor

@pkruger pkruger commented Jun 23, 2018

I have the same problem. Didn't see this ticket and got a replacement FC from Banggood, still have the issue. Tried different option PID loop and Gyro speeds, also tried disabling telemetry, but it made no difference.

Loading

@JamilFayad
Copy link

@JamilFayad JamilFayad commented Jun 23, 2018

I personally asked for a refund when banggood offered a replacement and I got my money back. Though my problem with this FC wasn't just that and that's probably why. I ended up just switching my entire FC with an FrSky XSRF4O which is an fc with an integrated receiver however its PDB-less so I had to use a Matek PDB that was hanging around. Haven't tested it yet nevertheless as far as reviews can go, I was told that this FC is a lot better and doesn't seem to encounter such problems so I am expecting good results on a fine day. Will update you tho for sure :)

Loading

@Ask1me
Copy link

@Ask1me Ask1me commented Jun 24, 2018

I'm sorry if this is Out Of Topic, I stressed Out becouse of this problems :

My board FC CrazybeeF3 BNF Frysky,
my latest firmware : betaflight_3.3.3_crazybeeF3FR (Stable)
SPI_Rx Support Receiver Mode

I accidently choosing wrong SPI Reciever Provider to A7105_Flysky_2A and save it

now my FC can not connect to USB anymore, everytime connect it is says " Unkown USB device (Device descriptor request Failed) for windows 10"

is there any suggestions to fix it? please help me anyone..

Loading

@stale
Copy link

@stale stale bot commented Jul 24, 2018

This issue / pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

Loading

@stale stale bot added the Inactive label Jul 24, 2018
@pkruger
Copy link
Contributor

@pkruger pkruger commented Jul 28, 2018

This is still an issue, it can't be closed because it has not been fixed - yet.

Loading

@stale stale bot removed the Inactive label Jul 28, 2018
@mikerc2017
Copy link

@mikerc2017 mikerc2017 commented Aug 8, 2018

midelic who create version FC integrade FRSKY . i think he can fix it . Matek fc using his code .

Loading

@d3c0deFPV
Copy link

@d3c0deFPV d3c0deFPV commented Aug 13, 2018

I found this when searching and wanted to add that I'm still experiencing this with Betaflight 3.5 RC2.

Flash target: CRAZYBEEF3FR
Board model: Racerstar Crazybee F3 Flight Controller
ESC protocol: D600
FrSky protocol: D16 (8 channel with telemetry)
4K/4K loop timings.

D8 works fine, even with telemetry. I've not had any dropouts. However with D16 8 channel and telemetry my quadcopter falls out of the sky seemingly randomly, and I can only re-establish a link when I power cycle the flight controller.

I will disable telemetry and test tonight.

Loading

@d3c0deFPV
Copy link

@d3c0deFPV d3c0deFPV commented Aug 13, 2018

Update:

D16 working now with no failsafes/rx failure after 6 packs when disabling telemetry both on the Taranis when binding, and within Betaflight. I still get RSSI, which is all I really want.

About to fly another 6. Will report back if things change, but this workaround appears to be ok so far.

Loading

@mikeller
Copy link
Member

@mikeller mikeller commented Aug 14, 2018

@H4xus: You should also get battery voltage in A1.

Loading

@ghost
Copy link

@ghost ghost commented Sep 2, 2018

Hi all, I just stumbled on this page looking for the "drop out of the sky" issue..

What is the best thing to do lately?
I have the CrazyBee F3 FR FC, (snapper7)
BF 3.3.0 installed right now.
Bind in D16 mode
I have tried D8 mode, but when arming, it directly disarms.

Loading

@mikeller
Copy link
Member

@mikeller mikeller commented Sep 2, 2018

@pd5dj: Update to 3.5.0. FrSky D works with telemetry, FrSky X works with telemetry off.

Loading

@ghost
Copy link

@ghost ghost commented Sep 3, 2018

Loading

@mikeller
Copy link
Member

@mikeller mikeller commented Sep 3, 2018

@pd5dj: You will have to make sure the feature 'TELEMETRY' is enabled. And you might have to rescan the sensors.

Loading

@ghost
Copy link

@ghost ghost commented Sep 3, 2018

Loading

@mikeller
Copy link
Member

@mikeller mikeller commented Sep 4, 2018

Hmm, I've seen this before, and I think there was a bug causing this at some stage. But that got fixed in 3.5.

Loading

@d3c0deFPV
Copy link

@d3c0deFPV d3c0deFPV commented Sep 6, 2018

I was still seeing it in Betaflight 3.5 RC2, and just tested again with 3.5. Still get lockups with telemetry on, fine without.

Loading

@mikeller
Copy link
Member

@mikeller mikeller commented Sep 7, 2018

@H4xus: Yes, this has not yet been identified / fixed.

Loading

@19Gerhard85
Copy link

@19Gerhard85 19Gerhard85 commented Sep 24, 2018

Yesterday I flew 10+ packs on the Crazybee F3. After 5 packs I had a "failsafe", the rebooted and the status message in OSD display "BADRX".

  • Board: CRAZYBEEF3FR
  • Betaflight Version: 3.5.1
  • Rx Mode: D8 w/ Telemetry
  • ESC Protocol: DSHOT600
  • Enabled Features: OSD, TELEMETRY
  • PID Loop: 4k/4k

Loading

@mikeller
Copy link
Member

@mikeller mikeller commented Sep 24, 2018

@19Gerhard85: For now, try disabling TELEMETRY - the voltage will still be received on the TX as A1.

Loading

@jdedonato1
Copy link

@jdedonato1 jdedonato1 commented Sep 30, 2018

I have the latest firmware 3.5.1. 2 quads using the target MATEKF411RX. Tried D8 and D16. D8 with telemetry still doesn't work. D16 telemetry works. One quad ( this one is a brushed) will keep at full throttle randomly and would cause a runaway so can go outdoors ( mostly when crashing) and one falls out of sky for no reason. I just lose all control and it freaks out( brushless on dshot600). Please tell me this will be fixed and I will be able to use telemetry

Loading

@jflyper
Copy link
Contributor

@jflyper jflyper commented Sep 30, 2018

@jdedonato1 We at least your CLI diff output to say anything meaningful.

Loading

@jflyper
Copy link
Contributor

@jflyper jflyper commented Sep 30, 2018

@jdedonato1
At least, local bench test (no flight test) with a bare MATEKF411RX flashed with 3.5.1 basically works with
D8 : OK
D16 Ch1-8 Telem On : OK

Although issue involves in-flight failure, your issue with D8 suggest there is something wrong with your setup.

Loading

@jdedonato1
Copy link

@jdedonato1 jdedonato1 commented Sep 30, 2018

Loading

@chupocro
Copy link

@chupocro chupocro commented Oct 15, 2019

@mikeller Well, I just wanted to mention the similar problem but with SBUS hoping someone might take a look the SBUS code too and then I misunderstood the new firmware resolves all problems with FrSky receivers. It may be true the #7084 was marked as a hardware problem but by reading through all the messages (and other reports) it could be noticed:

  • Some people reported while the same receiver worked well with Cleanflight, it didn't work well with Betaflight
  • Many reported the problem is only when using the telemetry
  • Many reported the problem is only when using D16 mode
  • There are reports everything worked well before Betaflight 3.x.x

My conclusion is the problem is not as visible because:

  • Many don't use the telemetry
  • Many don't use D16 mode (which is not possible with EU firmware)
  • Many switched to some other receivers
  • Some think this is a hardware problem
  • Some think this is a problem with the receiver firmware

I think much more people is using non-EU firmware where they have the D8 mode which works well and that is the major reason why this problem is not exposed more.

Loading

@Asizon
Copy link
Member

@Asizon Asizon commented Oct 16, 2019

This problem with sbus is completely absurd, sbus has been working perfectly for years, they can be problems of specific flighr controller, you are mixing diferrent type of issues, as mikeller said this is only for frsky spi rx comments

Loading

@Asizon
Copy link
Member

@Asizon Asizon commented Oct 17, 2019

@drewzh any news??

Loading

@drewzh
Copy link

@drewzh drewzh commented Oct 17, 2019

@Asizon I've had my Tinyhawk S in D16 LBT for 5+ batteries without a single drop out with telemetry disabled in betaflight. I haven't tested with telemetry enabled in 4.1 Dev because the tuning is wildly different and I'm a noob. I'll report back here as and when I try it though. I'm just waiting for somebody to tune it on 4.1 or for me to get to grips with doing it myself.

Loading

@mikeller
Copy link
Member

@mikeller mikeller commented Oct 17, 2019

@drewzh, @fOmey, @deepdigger: Can you please test again with FrSky X, telemetry enabled, with 4.1.0?

Loading

@mikeller
Copy link
Member

@mikeller mikeller commented Oct 19, 2019

For users of CRAZYBEEF3FR / MIDELICF3, here are some test binaries to check if this fixed the problem on F3 as well:

betaflight_4.1.0_CRAZYBEEF3FR.zip (FEATURE_CUT_LEVEL increased to 4)
betaflight_4.1.0_MIDELICF3.zip

Loading

@drewzh
Copy link

@drewzh drewzh commented Oct 21, 2019

@drewzh, @fOmey, @deepdigger: Can you please test again with FrSky X, telemetry enabled, with 4.1.0?

I've been testing BetaFlight 4.1 stable on my Tinyhawk S today and it seems, for me at least, the lockup issue is fixed :) I'll continue to monitor, but I've been through 5 batteries now and not had a single drop out. I tested just before I flashed 4.1 and the lockouts were consistent (multiple times during each battery). Thanks for your support.

Loading

@Asizon
Copy link
Member

@Asizon Asizon commented Oct 21, 2019

Good to know!! The loockup fixes is completly confirmed

Loading

@turboed13b
Copy link

@turboed13b turboed13b commented Oct 21, 2019

Unfortunately most tiny whoops dont fly that good on anything greater than 3.5.7. Fix came a little too late.

Loading

@mikeller
Copy link
Member

@mikeller mikeller commented Oct 21, 2019

@turboed13b: You can use the binaries in #6172 (comment) on the whoop.

Loading

@turboed13b
Copy link

@turboed13b turboed13b commented Oct 21, 2019

@mikeller are those 4.1? I am still flying 3.4.1 because it has the gyro/acc fix. Newer versions have horrible crash recovery and takes forever to reset the gyro/acc. Tuning on 4.1 is also a nightmare for whoops.

Loading

@mikeller
Copy link
Member

@mikeller mikeller commented Oct 21, 2019

@turboed13b:

Newer versions have horrible crash recovery and takes forever to reset the gyro/acc. Tuning on 4.1 is also a nightmare for whoops.

Do you have any pointers to the bug reports for these problems?

Loading

@turboed13b
Copy link

@turboed13b turboed13b commented Oct 21, 2019

@mikeller Not sure if there is any. The initial fix was done for 3.4.1 then after that I'm not sure if they implemented it again. I can make a new report if you want to look into it.

#5425 is the original fix.

Loading

@mikeller
Copy link
Member

@mikeller mikeller commented Oct 22, 2019

@turboed13b: This fix is in all versions after 3.4.1, including 4.0 and 4.1.

Loading

@d3c0deFPV
Copy link

@d3c0deFPV d3c0deFPV commented Oct 22, 2019

For users of CRAZYBEEF3FR / MIDELICF3, here are some test binaries to check if this fixed the problem on F3 as well:

betaflight_4.1.0_CRAZYBEEF3FR.zip (FEATURE_CUT_LEVEL increased to 4)
betaflight_4.1.0_MIDELICF3.zip

@mikeller I'm trying to figure out which lost features correspond to each Feature Cut Level. I've looked around but am having trouble finding info. if anyone has documentation they can link me, that'd be great.

Loading

@turboed13b
Copy link

@turboed13b turboed13b commented Oct 22, 2019

@mikeller Definitely not the same fix. First bump into a gate and I am flying sideways already. It takes a lot longer to flush doing the disarm trick also. I have to count to 5 each time to make sure it resets. On 3.4.1 crashing is more resilient I wouldn't have to flush the gyro so much. Took me 4 hours to try to tune 4.1and didnt get anywhere. Lol Its just terrible for tiny whoops.

Spi rx is still twitching on mine by the way using x lite pro.

Loading

@airlessdylan
Copy link

@airlessdylan airlessdylan commented Oct 22, 2019

Before updating to 4.1, I upgraded my failed CrazybeeF3FR to the CrazyBeeF4FR PRO V3. Never had any problems with lockouts at all using D16, but then I upgraded to 4.1 and now it drops out after maybe 20-30 feet. TX is a Xlite S, and I haven't changed anything fundamental. I've tried refreshing, resetting, rebinding, etc on just about everything. I've tried using the CRAZYBEEF4FR HAMO and Legacy FW's. I tried reverting to 4.0.6 and the problem still occurs with that. I've tried telemetry on/off, and still no matter what I try, the problem persists.

Loading

@turboed13b
Copy link

@turboed13b turboed13b commented Oct 23, 2019

I swear its just the f4 boards with the problem. I can't fly any of mine in d16 all they do is twitch and lag. The f4 have more hardware over the f3 which is a pa/lna however I tested a f4 board without the pa/lna and range was still terrible. Something has to be different between the crazybeef3 and matekf411rx targets.

F3 boards have much better range and are flyable in d8 and d16 even without the pa/lna.

Loading

@airlessdylan
Copy link

@airlessdylan airlessdylan commented Oct 23, 2019

I’m not sure what I’m planning to do with it at this point. It’s almost completely un-flyable. and I just upgraded the board a couple weeks ago, never had any problems until flashing it. Can’t test D8 because of my radio, either.

Loading

@Asizon
Copy link
Member

@Asizon Asizon commented Oct 23, 2019

@airlessdylan it seems related to hardware or configuration problems, Note that some crazybee f4 V3 boards have come out defective and have lockup problems

Loading

@airlessdylan
Copy link

@airlessdylan airlessdylan commented Oct 23, 2019

The problems only just started once I updated to BF 4.1 though, which was supposed to actually fix telemetry for Frsky

Loading

@Asizon
Copy link
Member

@Asizon Asizon commented Oct 23, 2019

Not suposed, this is completly fixed

Loading

@markusbrand
Copy link

@markusbrand markusbrand commented Oct 23, 2019

@mikeller Definitely not the same fix. First bump into a gate and I am flying sideways already. It takes a lot longer to flush doing the disarm trick also. I have to count to 5 each time to make sure it resets. On 3.4.1 crashing is more resilient I wouldn't have to flush the gyro so much. Took me 4 hours to try to tune 4.1and didnt get anywhere. Lol Its just terrible for tiny whoops.

Spi rx is still twitching on mine by the way using x lite pro.

I have exactly the same problem with my 5" quad using a MATEKF411RX target - also using SPI. I always got twiches and random failsafes with D16 (since 3.5 until 4.1 - currently I run 4.1 with RPM filters), so I switched to D8. I don't get it there, but I also have the issue that my quad is drifting sideways after a crash (sometimes it's not even necessary to have a crash - it happens all of a sudden). When I unplug the quad - wait a few seconds - plugin, it works fine again most of the time (until it appears again).

Loading

@mikeller
Copy link
Member

@mikeller mikeller commented Oct 23, 2019

@H4xus:

#if ((FLASH_SIZE > 256) || (FEATURE_CUT_LEVEL < 12))
#define USE_CMS
#define USE_MSP_DISPLAYPORT
#define USE_MSP_OVER_TELEMETRY
#define USE_OSD_OVER_MSP_DISPLAYPORT
#define USE_LED_STRIP
#endif
#if ((FLASH_SIZE > 256) || (FEATURE_CUT_LEVEL < 11))
#define USE_VTX_COMMON
#define USE_VTX_CONTROL
#define USE_VTX_SMARTAUDIO
#define USE_VTX_TRAMP
#endif
#if ((FLASH_SIZE > 256) || (FEATURE_CUT_LEVEL < 10))
#define USE_VIRTUAL_CURRENT_METER
#define USE_CAMERA_CONTROL
#define USE_ESC_SENSOR
#define USE_SERIAL_4WAY_BLHELI_BOOTLOADER
#define USE_RCDEVICE
#endif
#if ((FLASH_SIZE > 256) || (FEATURE_CUT_LEVEL < 9))
#define USE_GYRO_LPF2
#endif
#if ((FLASH_SIZE > 256) || (FEATURE_CUT_LEVEL < 8))
#define USE_LAUNCH_CONTROL
#define USE_DYN_LPF
#define USE_D_MIN
#endif
#if ((FLASH_SIZE > 256) || (FEATURE_CUT_LEVEL < 7))
#define USE_THROTTLE_BOOST
#define USE_INTEGRATED_YAW_CONTROL
#endif
#if ((FLASH_SIZE > 256) || (FEATURE_CUT_LEVEL < 6))
#define USE_ITERM_RELAX
#define USE_RC_SMOOTHING_FILTER
#define USE_THRUST_LINEARIZATION
#define USE_TPA_MODE
#endif
#if ((FLASH_SIZE > 256) || (FEATURE_CUT_LEVEL < 5))
#define USE_PWM
#endif
#if ((FLASH_SIZE > 256) || (FEATURE_CUT_LEVEL < 4))
#define USE_HUFFMAN
#define USE_PINIO
#define USE_PINIOBOX
#endif
#if ((FLASH_SIZE > 256) || (FEATURE_CUT_LEVEL < 3))
#ifdef USE_SERIALRX_SPEKTRUM
#define USE_SPEKTRUM_BIND
#define USE_SPEKTRUM_BIND_PLUG
#define USE_SPEKTRUM_REAL_RSSI
#define USE_SPEKTRUM_FAKE_RSSI
#define USE_SPEKTRUM_RSSI_PERCENT_CONVERSION
#define USE_SPEKTRUM_VTX_CONTROL
#define USE_SPEKTRUM_VTX_TELEMETRY
#define USE_SPEKTRUM_CMS_TELEMETRY
#define USE_PIN_PULL_UP_DOWN
#endif
#endif
#if ((FLASH_SIZE > 256) || (FEATURE_CUT_LEVEL < 2))
#define USE_TELEMETRY_HOTT
#define USE_TELEMETRY_LTM
#define USE_SERIALRX_SUMH // Graupner legacy protocol
#define USE_SERIALRX_XBUS // JR
#endif
#if ((FLASH_SIZE > 256) || (FEATURE_CUT_LEVEL < 1))
#define USE_BOARD_INFO
#define USE_EXTENDED_CMS_MENUS
#define USE_RTC_TIME
#define USE_RX_MSP
#define USE_ESC_SENSOR_INFO
#define USE_CRSF_CMS_TELEMETRY
#define USE_CRSF_LINK_STATISTICS
#define USE_RX_RSSI_DBM
#endif

@turboed13b: Not sure why this isn't working any more, the code from #5425 is definitely still in there and in use: https://github.com/betaflight/betaflight/blame/master/src/main/flight/imu.c#L372. Can pinpoint what the first firmware version was that didn't work?

Re FrSky TX lite pro, it looks like FrSky has made changes to the protocol used for this TX, which make it not work correctly with the FrSky SPI RX code. Unfortunately I do not have the hardware (yet) to figure out what needs to be changed to make it work.

@markusbrand: Can you specify what TX you are using?

Loading

@drewzh
Copy link

@drewzh drewzh commented Oct 23, 2019

@mikeller Definitely not the same fix. First bump into a gate and I am flying sideways already. It takes a lot longer to flush doing the disarm trick also. I have to count to 5 each time to make sure it resets. On 3.4.1 crashing is more resilient I wouldn't have to flush the gyro so much. Took me 4 hours to try to tune 4.1and didnt get anywhere. Lol Its just terrible for tiny whoops.
Spi rx is still twitching on mine by the way using x lite pro.

I have exactly the same problem with my 5" quad using a MATEKF411RX target - also using SPI. I always got twiches and random failsafes with D16 (since 3.5 until 4.1 - currently I run 4.1 with RPM filters), so I switched to D8. I don't get it there, but I also have the issue that my quad is drifting sideways after a crash (sometimes it's not even necessary to have a crash - it happens all of a sudden). When I unplug the quad - wait a few seconds - plugin, it works fine again most of the time (until it appears again).

I've just got into FPV and the Tinyhawk S (running Betaflight 4.1 to fix the D16 issues I had with my FrSky X-Lite Pro) is the only quad I've been flying recently, even though I have 2 HD quads fully built already (british weather and can't risk damaging anything before I can fly properly). I don't really have a reference point to how the quad should behave when hitting an obstacle but let me tell you, the quad bumping into anything and then instantly flipping on it's side and vacuuming itself to that object is becoming old quite fast! There's also a lot of oscillation/twitching when running on Betaflight 4.1 that I didn't notice when running on 3.x. I may revert back to Betaflight 3.x, using the default emax tune and then try pairing to the Jumper on D8 and seeing if this improves things.

Loading

@fOmey
Copy link

@fOmey fOmey commented Nov 7, 2019

For users of CRAZYBEEF3FR / MIDELICF3, here are some test binaries to check if this fixed the problem on F3 as well:

betaflight_4.1.0_CRAZYBEEF3FR.zip (FEATURE_CUT_LEVEL increased to 4)
betaflight_4.1.0_MIDELICF3.zip

Flashed the binaries onto my crazybee F3, however when entering the video transmitter tab betaflight configurator (10.6.0) is locking up.

Hopefully a default table is included? Should I be using a specific configurator version?

EDIT: Just finished testing the binaries and they seem to have solved the drop outs for me.. Frsky X with telemetry enabled, no drop outs.. fantastic!

Loading

@mikeller
Copy link
Member

@mikeller mikeller commented Nov 7, 2019

@fOmey: I suspect there will be no easy way to make the UI for VTX control work with F3 based boards running 4.1 - VTX tables are not supported on these boards, since there is no space for it, but the configurator expects all (supported) boards running 4.1 to support VTX tables. You will have to use the CLI to configure VTX control for these targets.
But glad to hear that the drop out issues have been solved.

Loading

@fOmey
Copy link

@fOmey fOmey commented Nov 7, 2019

@fOmey: I suspect there will be no easy way to make the UI for VTX control work with F3 based boards running 4.1 - VTX tables are not supported on these boards, since there is no space for it, but the configurator expects all (supported) boards running 4.1 to support VTX tables. You will have to use the CLI to configure VTX control for these targets.
But glad to hear that the drop out issues have been solved.

vtx_channel & vtx_freq commands no longer work on 4.1.. neither does the vtx table commands.

Unless I'm missing something? Have new commands been added to 4.1 to configure VTX without a table?

Loading

@mikeller
Copy link
Member

@mikeller mikeller commented Nov 7, 2019

@fOmey:

vtx_channel & vtx_freq commands no longer work on 4.1.. neither does the vtx table commands.

Have you tried this with the F3 builds I posted above? These should behave like the official builds before 4.1, so vtx_channel and vtx_freq should work.

Loading

@fOmey
Copy link

@fOmey fOmey commented Nov 8, 2019

@fOmey:

vtx_channel & vtx_freq commands no longer work on 4.1.. neither does the vtx table commands.

Have you tried this with the F3 builds I posted above? These should behave like the official builds before 4.1, so vtx_channel and vtx_freq should work.

I tried this earlier this morning and CLI returned command not found.

However I tried again to verify and it seems to be working, I must of made a typo earlier on.. sorry about that.

All is well, seems to be working as it should:

# Betaflight / CRAZYBEEF3FR (CBFR) 4.1.0 Oct 19 2019 / 16:41:56 (c37a7c91a) MSP API: 1.42 / FEATURE CUT LEVEL 4

# set vtx_channel = 4
vtx_channel set to 4
# set vtx_freq = 5800
vtx_freq set to 5800
# get vtx_channel
osd_vtx_channel_pos = 234
Allowed range: 0 - 3071

vtx_channel = 4
Allowed range: 0 - 8
Default value: 1

# get vtx_freq
vtx_freq = 5800
Allowed range: 0 - 5999
Default value: 5740

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet