Need some help with a mix please

[Allan Bennett]

Having figured how to get my X4RSB receiver to output SBUS as well as channels 9 and 10 PWM, I'm having problems getting Ch9 to work properly. The Rx is working okay, for the SBUS channel is controlling my fbl controller properly, using Ch1 - 8, and Ch9 PWM output is reponding when I connect a servo to it. BUT, !SG^ on my Taranis X9D+2019 is supposed to inhibit Ch9 (used for throttle). In OTX Companion simulation mode it does inhibit Ch9, but at the receiver it doesn't. Attached is a screen dump of my Mixes page, which is similar to that I've used with two other helis, on which the inhibit function works correctly.

On the Input page I6:Coll is Thr Weight (+100%) and, as you can see in the mixes, it's also used to control the collective, which it does correctly.

Any ideas, please, why my SG inhibit function isn't working?

[Philip Lewis 3]

On your TX go to the mix page, edit the line, highlight switches so it is flashing and then flick your kill switch to where you want it to kill the motor.

In theory it shouldn't make any difference but then again it just might.

[Bob Cotsford]

Is there a reason channels 6 and 9 use I6 rather than just I3:Throttle or whichever input is assigned as throttle? Are you saying that a servo works off throttle without the switch SG line but doesn't respond with the line in and SG up? I've found on some versions of Companion that on the sim screen some switches work in reverse to how they worked on my tx, the one I remember was SH which I used as engine kill. The other question is - have you checked the switch configuration on the transmitter, particularly that SG is configured as a switch?

I only have one heli set up which uses a sticky logical switch to prevent the beast powering up again until I'm ready.

and the switch:

[Allan Bennett]

Philip, I'll check that on my Tx tomorrow.

Bob, the reason I'm not using Ch3 for throttle is because channels 1 - 8 are for the BeastX fbl controller, so I didn't want to confuse it or myself by using Ch3. Ch6 is the standard BeastX channel for collective and, since this is the same stick on the trannie as throttle, it seemed right to use it.

But my issue really boils down to, a servo plugged into Ch9 on my receiver responds correctly to movement of the throttle/collective stick without the MAX (-100%) !SG^ line; but it also responds with the MAX (-100%) !SG^ line with switch SG in any position. And, yes, the Multiplex option is REPLACE, and SG holds Ch9 correctly at -100% in the OTX Companion simulator

I don't understand the bit about SG being configured as a switch in my trannie. Where do I check that, or change it? Surely it must be a switch though, because it announces 'Throttle active' and 'Throttle disabled' at its appropriate positions.

[MattyB]

Hi Allan. I suspect the issue is actually simpler than it looks - a broken switch. I had very similar behaviour on my Taranis for about 6 months; at first SF was intermittently working, then finally it failed completely in a single position. Unfortunately the switches on the Taranis X9D and X7 TXs are not of the highest quality. 

A simple test is to use the switch as single input to a free channel and plug in a servo; you should get +100, 0 and -100 at each of the three positions. Give it a try, it will at least eliminate the hardware as a potential root cause.

Edited By MattyB on 07/11/2020 21:45:01

[Allan Bennett]

Doesn't the fact that the switch is triggering the correct voice announcements prove that it's working? I'll check again tomorrow using your suggested method.

[Philip Lewis 3]

Posted by Allan Bennett on 07/11/2020 22:01:10:

Doesn't the fact that the switch is triggering the correct voice announcements prove that it's working? I'll check again tomorrow using your suggested method.

Yes I would have thought so as I can't see what else could be triggering them..

[MattyB]

Hmmm... Yes, if you’re getting the voice alerts correctly I agree a hardware issue is unlikely. When mine first started to fail I was getting occasional voice switch alerts without the physical switch being moved. When it failed completely all the voice alerts on that switch stopped completely, as you’d expect.

Still worth a quick check though, just to cross it off the list of possible root causes. You could also try setting up the same mix on a different physical switch to see if the behaviour on the TX changes to match what you see in Companion.

Edited By MattyB on 07/11/2020 22:56:15

[Philip Lewis 3]

Posted by Allan Bennett on 07/11/2020 21:02:12:

I don't understand the bit about SG being configured as a switch in my trannie. Where do I check that, or change it?

Long press on SYS then sixth page in is the hardware page, scroll down and SG should show as a 3POS (switch). This is where you would make the change to the software if you had for example changed a 3POS switch for something else like a 2POS or momentary switch.

[Allan Bennett]

Thanks Philip, I wasn't aware of that option. But, going back to the suggestion of a bad switch, SG is what I use in all my models to disable throttle, and it's working at the moment on another model, so I think the bad switch, or even its mis-configuration, can be discounted.

[MattyB]

In that case I would say the most likely cause is something to do with the way that RX is being used with SBUS + the two PWM outputs; this is Frsky after all, FW bugs are far from unknown... Is it running v2 ACCST? Maybe they mangled this mode of operation when they created the new version. Could you move the throttle to one of the vacant SBUS channels (3 or 7), or will that not work with the FBL controller? If so, then I suggest the following tests...

1. Bind another X4R on ACCST v2 in the same mode and see if it does the same thing.
2. Bund another X series RX on ACCST v2 in the same mode;
3. Flash X4R and TX back to ACCST v1 temporarily and see if that changes anything.

[Philip Lewis 3]

Posted by MattyB on 08/11/2020 09:01:30:

In that case I would say the most likely cause is something to do with the way that RX is being used with SBUS + the two PWM outputs; this is Frsky after all, FW bugs are far from unknown... Is it running v2 ACCST? Maybe they mangled this mode of operation when they created the new version. Could you move the throttle to one of the vacant SBUS channels (3 or 7), or will that not work with the FBL controller? If so, then I suggest the following tests...

1. Bind another X4R on ACCST v2 in the same mode and see if it does the same thing.
2. Bund another X series RX on ACCST v2 in the same mode;
3. Flash X4R and TX back to ACCST v1 temporarily and see if that changes anything.

I would doubt very much it is the firmware, if the firmware were to have a bug chances are it wouldn't work at all, if the channel is working correctly but just the inhibit isn't working that sounds more like an Open TX problem rather than firmware.

I would certainly check if it works or not on another channel and also with another RX if you can, preferably the same model.

You could also try altering Open TX by using SG- up in place of !SG^ and adding an extra line with the switch SG (down arrow) which should do the same thing.

Not easy to diagnose as it should work but doesn't.

[Allan Bennett]

I can try it on Ch10 on the same receiver, and with various combinations of SG^ and SGv for motor on or off. I can also use the same Tx model but with a different receiver bound to it. Something to keep me occupied this afternoon! I'll report back.

[Philip Lewis 3]

Posted by Allan Bennett on 08/11/2020 11:25:16:

I can try it on Ch10 on the same receiver, and with various combinations of SG^ and SGv for motor on or off. I can also use the same Tx model but with a different receiver bound to it. Something to keep me occupied this afternoon! I'll report back.

While you are there you might as well try a different switch entirely as well, EG SA, should keep you busy for a while!

[Allan Bennett]

Posted by MattyB on 08/11/2020 09:01:30:

In that case I would say the most likely cause is something to do with the way that RX is being used with SBUS + the two PWM outputs; this is Frsky after all, FW bugs are far from unknown... Is it running v2 ACCST? Maybe they mangled this mode of operation when they created the new version. Could you move the throttle to one of the vacant SBUS channels (3 or 7), or will that not work with the FBL controller? If so, then I suggest the following tests..

The Rx and Tx are on v2 firmware. The Rx is working okay in that it provides 8 channels on SBUS to the flight controller, and also provides a PWM output to Ch9 as verified by plugging in a servo there. The issue seems to me to be that the Tx is not inhibiting the Ch9 signal (i.e. setting it to -100%) to the receiver with !SG^, even though the configurator's simulation says it is.

I can check the vacant SBUS Ch3 by plugging in a servo to the appropriate slot on the flight controller, and see if that works. Come to think of it, if it does work then that could be the permanent working configuration, instead of using Ch9. I'm going to try the other suggestions as well though, because according to my understanding the programming should work the way I've done it, and it would be nice to see why it doesn't.

[Allan Bennett]

It's the receiver

I tried SG^ and SGv, but no change. But then I noticed that the test servo appeared to be responding linearly, rather than in accordance with the throttle curve I had on Ch9. So I then deleted the Ch9 mix completely, but the servo still responded linearly to Ch6:Coll input

This X4RSB receiver is a new model replacing the old white CPPM and black SBUS X4R versions. It's supposed to be configurable as SBUS + CPPM + two PWM channels (9 & 10), or SBUS + three PWM channels (1, 2, and 3), depending on whether or not you jump signal pins 2 and 3 when binding. Well, mine's not working like that: With or without the 2-3 jumper, if I bind in Ch1-8 mode I get the SBUS + 1,2,3 option; if I bind in Ch9-16 mode I get SBUS and CPPM as I should, but Ch9 is in fact mimicking the Ch6 input, ignoring any Ch9 output from the trannie, and Ch10 is inactive. I don't know if this is a fault with my unit, or something missing from the instructions. I'll be in touch with T9 tomorrow to see if they have an answer.

In the meantime I can live with it, for using Ch3 for the throttle, via the flight controller, works as it should, with SG acting as throttle shut-off, as intended.

Thanks for all your input.

[MattyB]

Sounds like yet another Frsky beta firmware released in production for paying customers to fix for them...

I have to say I am losing confidence in them at this point; their D8 and early X series RXs have been bulletproof for me over ~7 years, but their more recent releases (G-RX8, redundancy buses, ACCST v2 and ACCESS bug ridden firmwares etc) have me wondering whether it is worth continuing with Frsky. Given it looks doubtful the next generation X20 and X24 TXs will feature OpenTX at all, will anyone trust them to write a brand new TX firmware from scratch? FrOS was awful, and nothing they have done recently exactly builds confidence that ETHOS will be bug free at launch. At least they have hired Bertrand from the OpenTX team to mastermind it, but that in itself doesn’t matter if the company culture is still to have paying customers beta test the products for them.

Fingers crossed, but I certainly won’t be an early adoptor...

Edited By MattyB on 09/11/2020 00:19:09

[Allan Bennett]

Posted by MattyB on 09/11/2020 00:17:54:

Sounds like yet another Frsky beta firmware released in production for paying customers to fix for them...

I have to say I am losing confidence in them at this point; their D8 and early X series RXs have been bulletproof for me over ~7 years, but their more recent releases (G-RX8, redundancy buses, ACCST v2 and ACCESS bug ridden firmwares etc) have me wondering whether it is worth continuing with Frsky. Given it looks doubtful the next generation X20 and X24 TXs will feature OpenTX at all, will anyone trust them to write a brand new TX firmware from scratch? FrOS was awful, and nothing they have done recently exactly builds confidence that ETHOS will be bug free at launch. At least they have hired Bertrand from the OpenTX team to mastermind it, but that in itself doesn’t matter if the company culture is still to have paying customers beta test the products for them.

Fingers crossed, but I certainly won’t be an early adoptor...

At least with my early white-cased X4R receivers, which I'm using for CPPM output, FrSky don't pretend the v2 CPPM firmware is anything other than Beta -- it's only available on Github at the moment. Been working fine for me though since we came out of the first lock-down earlier this year.

I saw that thread about next-generation TXs, but dismissed it as unnecessary (for me). After all, if you want 24 channels you can do it at the moment with twinned receivers.

By our club's standards I think I am an early adopter of v2 firmware, but I did it because I'm convinced I experienced an Uncommanded Servo Movement incident in January, when I crashed my TwinStar. Normally I'm a firm believer in 'if it ain't broke, don't fix it'.

Edited By Allan Bennett on 09/11/2020 08:19:37

[MattyB]

Posted by Allan Bennett on 09/11/2020 08:11:15:

At least with my early white-cased X4R receivers, which I'm using for CPPM output, FrSky don't pretend the v2 CPPM firmware is anything other than Beta -- it's only available on Github at the moment. Been working fine for me though since we came out of the first lock-down earlier this year.

I saw that thread about next-generation TXs, but dismissed it as unnecessary (for me). After all, if you want 24 channels you can do it at the moment with twinned receivers.

tbh I don't truly need any of the new features in the ETHOS based sets (the channel count is the least useful; ACCESS compatability with the wireless binding and updates would be nice, as would the better interface on the colour screen). I would like a TX with better physical ergonomics and quality than my current X9D though. The X10 addresses the latter but the ergonomics are pretty awful, so I had great hopes for these new sets. Unfortunately the move to a home grown and no doubt bug laden Frsky OS instead of OpenTX fills me with dread.

[Philip Lewis 3]

Wireless updates and binding do nothing at all for me, I only have three models, all quite big with very easy to reach RX's. Currently using an X10S so have colour but I do NOT want a touch screen, I have a laptop with touchscreen but never touch it, more trouble to wipe of the finger prints than it's worth. Ergonomics are fine for me but then I fly with it in a tray so they would be.

Learning a new OS is something I would only do if I had no other choice, wouldn't exactly relish the thought of converting over my current models either,

I did flash to 2.1.1 firmware though, never experienced the USM personally but it was definitely possible that it could happen, so given the extensive testing of V2 I converted.

[Allan Bennett]

FWIW the guy at T9 has told me that FrSky are not really supporting my X4RSB because it's no longer produced but, if I want to get CPPM output and Ch9 and 10 from it I need to flash it with the X4R firmware. On reflection, after that call, I realised that the official FrSky X4R v2 firmware doesn't give CPPM output, which is why I'm using the Github version on my other X4Rs. Since I can work around the lack of Ch9, I'm going to stick with the official X4RSB firmware for this one.

[Mike Blandford]

From my direct contact with FrSky, they have NOT ruled out open source firmware being ported to the X20 (I was asking about putting erskyTx on the X20).

To an extent, FrSky have needed to protect their investment in development. Certain other companies are producing radios that are mainly hardware copies of FrSky radios, and also run openTx/erskyTx. All these radios also use the multiprotocol module. This module started life as a DIY module, mainly used by people who fully understand what using it meant. There is, however, a significant problem if using FrSky protocols on the multiprotocol module. The transmitter unique identifier (UID) needs to be unique(!) for all radios using a particular protocol (remember the problem Futaba had with this once). All FrSky radios do have a unique UID, but there is no control at all over the UID used in the multiprotocol module. Consequently, this means that a radio using a multiprotocol module and a FrSky protocol could easily have the same UID as your radio. This is similar to operating two, 35MHz radios on the same channel, they will interfere with each other, your receiver will think it is bound the "other" radio.

Bertrand has been employed by FrSky for over a year and a half. As I understand it, he is writing most of the new OS.

BTW, if you move to an ACCESS radio, and still have some D8 receivers you wish to continue using, I have firmware available that opearates in D16 mode on a D8 receiver, see here: **LINK**

This also provides a number of features of the ACCESS protocol (e.g. dual transmitter binding, map receiver outputs to any channel, SPort or hub telemetry, auto protocol detection at binding (V1/V2, FCC/LBT).

Mike