Who can help? looks like Ailerons has mix with throttle
- Thread starter fatik
- Start date
Just a guess.
Check the Graupner setup and see if you have Aileron Output set greater than 100% or maybe reduce the output.
Sounds like it bleeding over somehow.
That is assuming that it only happens at full aileron. If it happens the entire aileron stick movement, I don't have a clue!
Check the Graupner setup and see if you have Aileron Output set greater than 100% or maybe reduce the output.
Sounds like it bleeding over somehow.
That is assuming that it only happens at full aileron. If it happens the entire aileron stick movement, I don't have a clue!
12oclockhigh
Banned
One test that I would do is to look at the raw USB data in the properties of the game controller. When you move ailerons, is the throttle moving. If you see movement in the throttle channel, it is not the RF software causing the problem. This will help determine where it is happening. Good Luck.
I also celebrated my Interlink DX. We had cake and soda. LOL
I also celebrated my Interlink DX. We had cake and soda. LOL
uncle twist
Well-known member
Any actual radio has the ability to do channel mixing in the radio. RF has to account for game controllers and the InterLink controllers which do not have that ability. The one capability that every radio and controller has is to provide simple separate control on each channel.
Load a new default airplane model with a single wing and standard tail, rather than trying to use a model that you fly a real RC plane with. That should separate the channels. If you want to add dual rates and channel mixing back to the radio model, you can do that after getting things correctly set up.
Load a new default airplane model with a single wing and standard tail, rather than trying to use a model that you fly a real RC plane with. That should separate the channels. If you want to add dual rates and channel mixing back to the radio model, you can do that after getting things correctly set up.
12oclockhigh
Banned
If you would just listen to me... my test would prove whether or not the problem is in the radio or the RF software. No, you have to walk all over me. One thing at a time.
I would fully expect someone with that particular radio to know what they are doing. I am suspicious of the dongle.
I would fully expect someone with that particular radio to know what they are doing. I am suspicious of the dongle.
an_ok_flyer
New member
Both myself and a buddy are having this same issue of aileron affecting the throttle channel with RealFlight + FrSky. If the throttle channel is at midpoint, the aileron has no coupling. If the throttle channel is below midpoint, then any aileron input reduces the throttle channel value. If the throttle channel is above midpoint, then any aileron input increases the throttle channel value. This persists even if software radio mixes are disabled in Real Flight.
We both checked the "Game Controller" settings in Windows 10. The channels are independent there. Also, the FrSky dongle as a game controller works fine in AccuRC for me without any interactions on the various channels.
I also noticed that the throttle channel in RealFlight has a "dead spot" around center stick that doesn't exist in the Game Controller properties in Windows 10. The X axis is perfectly smooth in there, but not in Real Flight when it is assigned to the throttle channel (regardless of the software radio mix setting in RF9).
Any ideas?
We both checked the "Game Controller" settings in Windows 10. The channels are independent there. Also, the FrSky dongle as a game controller works fine in AccuRC for me without any interactions on the various channels.
I also noticed that the throttle channel in RealFlight has a "dead spot" around center stick that doesn't exist in the Game Controller properties in Windows 10. The X axis is perfectly smooth in there, but not in Real Flight when it is assigned to the throttle channel (regardless of the software radio mix setting in RF9).
Any ideas?
Thx for you clearly explain what the problem we both have
an_ok_flyer
New member
Thanks phil! I actually came back here to say that I just figured out by accident that this setting fixes the problem while playing around in RF9 this morning. Thank you for the help!
Why on earth deadband couples aileron to throttle is very confusing, but hey... at least there is no more problem with it set to zero!
Why on earth deadband couples aileron to throttle is very confusing, but hey... at least there is no more problem with it set to zero!
12oclockhigh
Banned
I would suggest that everyone hit the report link and get Knife Edge to take a look at this. Some people are reporting this all the way back to RF8. How this has gone on for so long is unbelievable.
In my experience, ownership has never been a reliable indicator of technical knowledge. Your actual mileage may vary.
I think it's safe to treat the dongle the same as a wired connection, so long as RF is able to receive any non-noise control input with a dongle in the chain. It's the least likely culprit. Electronically speaking, both the 1000 and 2000 are just receivers with USB connectivity. They are pass-through transport devices that do nothing but pass data from their receiver chip to their USB chip. There would be absolutely no benefit in making them do anything else, as it would only create the need for additional software and firmware coding and technical support at a substantially greater manufacturing cost. They are just wires without the wire.
The deadband setting is designed for gamepad-type controllers. It is not intended for use with RC radios or similar devices.
There is a reason for the apparent cross-talk you see between unrelated channels with an RC radio, but it gets a bit complicated. The main thing to know is that disabling deadband will make that go away.
There is a reason for the apparent cross-talk you see between unrelated channels with an RC radio, but it gets a bit complicated. The main thing to know is that disabling deadband will make that go away.
I have to admit that I'm also a bit curious to hear the explanation for the apparent crosstalk between unrelated channels.
If it isn't happening on the input side, the software radio, or the electronics, then it's happening in the simulation model, but I can't for the life of me imagine why.
If it isn't happening on the input side, the software radio, or the electronics, then it's happening in the simulation model, but I can't for the life of me imagine why.
I suspect it's the difference between a true gimbal controller and a game controller.
A gimbal stick moves in a square - full up and right is +100% in both directions.
Game controllers only have circular motion of the stick - if you are at full up then moving the stick right decreases the up value as stick travels around the edge of the circle. The code is probably trying to compensate for this.
The default is obviously set up for game controllers, the problem is for anyone using a real radio the experience is very strange. Turning above 50% throttle and the plane would suddenly climb, come out of the turn and the nose drops as the power reduces. Turning in for a landing at < 50% throttle and suddenly you stall as the power is reduced.
I was initially pretty disappointed with RF when using my FrSky radio until I worked this out.
A gimbal stick moves in a square - full up and right is +100% in both directions.
Game controllers only have circular motion of the stick - if you are at full up then moving the stick right decreases the up value as stick travels around the edge of the circle. The code is probably trying to compensate for this.
The default is obviously set up for game controllers, the problem is for anyone using a real radio the experience is very strange. Turning above 50% throttle and the plane would suddenly climb, come out of the turn and the nose drops as the power reduces. Turning in for a landing at < 50% throttle and suddenly you stall as the power is reduced.
I was initially pretty disappointed with RF when using my FrSky radio until I worked this out.
Hmm, I never knew about this, either. But here are the notes anyone sees when going in to change the setting:
"The size of the deadband applied to the stick channels of game controllers. The axes of each stick will register as centered until moved this far from center, expressed as a percentage of total stick travel.
Deadband may make it easier to fly with "gamepad" devices. For RC radios and similar devices, it is not recommended.
To disable deadband, set this value to 0.
Note: This setting does not apply to InterLink devices, which never have deadband applied.
Minimum: 0
Maximum: 50
Default: 0"
BTW - even if default is supposed to be "0", in my RF8.5, it was at 10. Never knowing about this, I'm pretty sure I never changed it!
I wonder how RF "knows" a game controller is being used? I occasionally use my Taranis via direct USB rather than my Interlink, and have had no issues. Nothing obvious in the profile that would seem to enable/disable deadband....
"The size of the deadband applied to the stick channels of game controllers. The axes of each stick will register as centered until moved this far from center, expressed as a percentage of total stick travel.
Deadband may make it easier to fly with "gamepad" devices. For RC radios and similar devices, it is not recommended.
To disable deadband, set this value to 0.
Note: This setting does not apply to InterLink devices, which never have deadband applied.
Minimum: 0
Maximum: 50
Default: 0"
BTW - even if default is supposed to be "0", in my RF8.5, it was at 10. Never knowing about this, I'm pretty sure I never changed it!
I wonder how RF "knows" a game controller is being used? I occasionally use my Taranis via direct USB rather than my Interlink, and have had no issues. Nothing obvious in the profile that would seem to enable/disable deadband....
There are a few typos in the editor descriptions, DeadBandbeing one. The default deadband is 10.
Yes, RF knows what kind of controller is being used because it gets the information from Windows. Each device on the USB bus registers with the USB controller as a particular device type. There are multiple types of game controllers that can be used to determine what sort of inputs to expect from that device. Also, the device manufacturer name/ID and device name/ID can further be used to provide the correct communication and operation between RF and the controller.
You are correct, however that nothing in the controller profile you can see will alter the setting or use of deadband, as that decision happens in the sim. The controller profile is intended to provide a patch board that the user can configure to map the physical controls of the controller used to the Input Channels that the sim will use for pilot control.
KE really has developed an amazingly versatile capability into RF, even if it can be a bit complex and obscure at the start.
Yes, RF knows what kind of controller is being used because it gets the information from Windows. Each device on the USB bus registers with the USB controller as a particular device type. There are multiple types of game controllers that can be used to determine what sort of inputs to expect from that device. Also, the device manufacturer name/ID and device name/ID can further be used to provide the correct communication and operation between RF and the controller.
You are correct, however that nothing in the controller profile you can see will alter the setting or use of deadband, as that decision happens in the sim. The controller profile is intended to provide a patch board that the user can configure to map the physical controls of the controller used to the Input Channels that the sim will use for pilot control.
KE really has developed an amazingly versatile capability into RF, even if it can be a bit complex and obscure at the start.
I think you hit the nail on the head.
I'm betting that the game controllers use a distorted coordinate grid with all of the normal square coordinates remapped linearly to the available circular values that the game controller can produce. It would provide a best case for both gimble controllers and game controllers.
It seems that some radios are registering as game controllers in Windows and fooling RF into applying the remapping even though it is not necessary. KE probably added the 0 value check in DeadBand as a way to force RF to use the the input values without remapping them.
As an aside, this would also provide a partial answer to why we cannot use DeadBand on the InterLink. If the setting for DeadBand is non-zero, then the sim applies game controller mapping to the input values. Basically DeadBand = game controller. The solutions chosen for game controllers and dealing with radios claiming to be game controllers had the unintended consequence of creating a new group that isn't accounted for: true game controllers, like the InterLinks, that don't require mapping, but might benefit from deadband, which is normally handled internally in the radio.
It's the age old engineering reality of Problem Migration. Fixing A will break B. Fixing B will break A AND C, ad infinitum.