Thread Tools
Dec 01, 2016, 02:41 PM
Registered User
Quote:
Originally Posted by jhsa
They should all be able to reverse the channels? C'mon, even the more basic 35Mhz radios could do that..

Joćo

Quote:
Originally Posted by hpnuts
Personnaly I've said my word I think people can do a channel reverse as this is really the basic stuff of a radio...
I'm fine if you want to state in the doc that people have to reverse channels based on the different transmitters' manufacturers.
I'm also fine to add a line like #define Reverse_Aileron in the _config.h if that can help people...
Just let me know.

Pascal
Sadly, no, not all transmitters allow the user to reverse channels. My spiffy new TBS Tango doesn't do squat. Creating a model asks for a model name and only one setting, [CleanFlight, DJI Naza, 3DR Pixhawk, OP-Taulabs, Blade] which is used for channel order (AETR, RETA, etc). No stick adjustments, no directions, no switch to Aux settings. A disappointing transmitter unless they improve the firmware.
Sign up now
to remove ads between posts
Dec 01, 2016, 02:41 PM
Pascal
hpnuts's Avatar
Quote:
Originally Posted by benzo99
Solid LED again now. I'm going to have to start using velcro to attach the cover on my module
Ben, have you tried the latest version posted on github? I would like to know if I got the freq hopping algo right...
Pascal
Dec 01, 2016, 02:52 PM
Flying a Chipmunk in Portugal
jhsa's Avatar
Quote:
Originally Posted by demiller9
Sadly, no, not all transmitters allow the user to reverse channels. My spiffy new TBS Tango doesn't do squat. Creating a model asks for a model name and only one setting, [CleanFlight, DJI Naza, 3DR Pixhawk, OP-Taulabs, Blade] which is used for channel order (AETR, RETA, etc). No stick adjustments, no directions, no switch to Aux settings. A disappointing transmitter unless they improve the firmware.
That radio reminds me of the toy transmitters that come with the BNF stuff/toys.. I know the hardware is for sure 5 stars because of who developed it, but it seems that the software spoils everything.. Certainly not a radio for me if it can't do a simple task like reversing a channel.. One might say it was developed with multirotors in mind. Ok, but obviously some need channels to be reversed as it turns out to be the case.. Anyway, I'm drifting off topic now

Joćo
Dec 01, 2016, 04:17 PM
Registered User
Quote:
Originally Posted by hpnuts
Ben, have you tried the latest version posted on github? I would like to know if I got the freq hopping algo right...
Pascal
Sorry - was waiting for my logic analyzer to arrive before resuming testing - I wanted to try to get you the captures as well.

I just tried your latest version and I can confirm that it binds - solid red LED on the Rx.

Ben
Dec 01, 2016, 04:25 PM
Pascal
hpnuts's Avatar
Quote:
Originally Posted by benzo99
Sorry - was waiting for my logic analyzer to arrive before resuming testing - I wanted to try to get you the captures as well.

I just tried your latest version and I can confirm that it binds - solid red LED on the Rx.

Ben
Good it means that the protocol is still working and the table not far off since the LED is solid.
Still interrested by your dump ;-)
Pascal
Dec 01, 2016, 04:35 PM
Pascal
hpnuts's Avatar
New version available on github with channel reverse (untested...)

Pascal
Dec 02, 2016, 01:09 AM
Registered User
Quote:
Originally Posted by jhsa
Hmm, Daedalus66 is one of the most knowledgeable people here as far as spektrum is concerned. We wrote the new er9x manual together a couple years ago. There must be a good reason why he says you should "Limit" the servos to 80% in the "Limits" menu.. Maybe that is also absolute in spektrum world?
IJoćo
Many transmitters can use 125% max travel (~ 1000 - 2000ms) and use 100% as default. But OpenTX use 100% (~ 1000 - 2000ms) max travel and use 100% as default. So, for models that can't use travel over common 100% (~ 1200 -1800ms), you need limit OpenTX travel to 80%.

Not for Spektrum only. For example, Hubsan H107c can work with OpenTX 100%, but throttle start from -80%, not from -100%. So, you need limit all channels travel to 80%.
Last edited by vlad_vy; Dec 02, 2016 at 01:16 AM.
Dec 02, 2016, 02:39 AM
Pascal
hpnuts's Avatar
OpenTX/er9x/ersky9x are all using -100%..100% = 1000..2000µs by default and can go even beyond by enabling 125%.

Hubsan is a wrong example since there is mapping between -100%..100% of any type of radio (if you've configured correctly the endpoints in _config.h) to 0x00..0xFF.

But more generally all the protocols where you see "Extended limits supported" on the protocol page can possibly go over the capabilities of certain models. This is where you might need to apply limits on the radio channels others are remapped.
Gerry you might want to update the doc with that detail.

Pascal
Last edited by hpnuts; Dec 02, 2016 at 10:14 AM.
Dec 02, 2016, 04:20 AM
Pascal
hpnuts's Avatar
Quote:
Originally Posted by cmeer
Hi Pascal,
I've tested the change: Bayang_nrf24l01.ino -> packet[13] = 0x34 and the flipping button works OK with CH05. .
Is it possible to decode the other captures?
The inverted mode/button . Speed conversion button might be nice too (low and high).
Kind regards and thanks for all your effort in this project.
Carlo
Carlo,
I've looked at all the captures and they use exactly the same flags but with packet[13] = 0x34 instead of 0x0A.
So you should be able to control your H8S3D with exactly the channels as described here.
I've pushed on Github a new Bayang's sub_protocol called H8S3D (Protocol: 14 Sub_protocol: 1).

@Plaisthos,@Mike: Can you add this sub-protocol?

Pascal
Dec 02, 2016, 07:03 AM
ErskyTx Developer
Mike Blandford's Avatar
Since Bayang didn't have any sub-protocols, what should sub-protocol 0 be called?
For ersky9x, I released r219 yesterday (30-Nov-2016). I've put a copy of "multi.txt" on http://www.er9x.com/. Just put this file in the root of your SD card. To add sub-protocols to the Bayang entry simply change the Bayang line to:
14,Bayang,Bayang,H8S3D
so protocol 14 is Bayang with 2 sub-protocols "Bayang" and "H8S3D".
If your multi module doesn't have a protocol, simply delete the line from multi.txt and it will not be displayed.

Mike.
Dec 02, 2016, 07:50 AM
flying beam
blackmoon's Avatar
I just bought a Taranis, and waiting for a MM.

What's the right version of OpenTX that supports the MM in serial mode?

Thanks

EDit: found it, (lazy ass ) should have looked at the doc on github
Dec 02, 2016, 08:15 AM
Pascal
hpnuts's Avatar
Quote:
Originally Posted by Mike Blandford
Since Bayang didn't have any sub-protocols, what should sub-protocol 0 be called?
For ersky9x, I released r219 yesterday (30-Nov-2016). I've put a copy of "multi.txt" on http://www.er9x.com/. Just put this file in the root of your SD card. To add sub-protocols to the Bayang entry simply change the Bayang line to:
14,Bayang,Bayang,H8S3D
so protocol 14 is Bayang with 2 sub-protocols "Bayang" and "H8S3D".
If your multi module doesn't have a protocol, simply delete the line from multi.txt and it will not be displayed.

Mike.
Hi Mike,
I've modified the Multi.txt with quite a lot of updates in fact. It's attached for reference and may be you could update it on http://www.er9x.com/ ? Should I host the Multi.txt file on multi github or ask you to upload a new version on er9x.com each time?
Multi.txt is only valid for ersky9x and I'm thinking we still want to maintain er9x to the same level.

I have 2 more requests not addressed by Multi.txt:
- modify Option to Rate when protocol AFHD2SA is selected
- modify Option to VTX when protocol Hubsan is selected

Thanks, Pascal
Dec 02, 2016, 08:36 AM
Registered User
Quote:
Originally Posted by hpnuts
Hi Mike,

- modify Option to Rate when protocol AFHD2SA is selected
- modify Option to VTX when protocol Hubsan is selected

Thanks, Pascal
I have addtionally for CC2500 protocols:
#define TR_MULTI_RFTUNE TR(INDENT "Freq tune",INDENT "RF Freq. fine tune")

and you should also use #channels in DSM mode (if ersky9x does not use the normal channels as I now do in Opentx)

Other labels in OpenTX are:


#define TR_MULTI_VIDFREQ TR(INDENT "Vid. freq.", INDENT "Video frequency")
#define TR_MULTI_OPTION TR(INDENT "Option", INDENT "Option value")
#define TR_MULTI_SERVOFREQ TR(INDENT "Servo rate", INDENT "Servo update rate")
Dec 02, 2016, 08:57 AM
Pascal
hpnuts's Avatar
Quote:
Originally Posted by plaisthos
I have addtionally for CC2500 protocols:
#define TR_MULTI_RFTUNE TR(INDENT "Freq tune",INDENT "RF Freq. fine tune")

and you should also use #channels in DSM mode (if ersky9x does not use the normal channels as I now do in Opentx)

Other labels in OpenTX are:


#define TR_MULTI_VIDFREQ TR(INDENT "Vid. freq.", INDENT "Video frequency")
#define TR_MULTI_OPTION TR(INDENT "Option", INDENT "Option value")
#define TR_MULTI_SERVOFREQ TR(INDENT "Servo rate", INDENT "Servo update rate")
Thanks for the recap :-)
ersky9x/er9x already have some of these this is why I have only given the differential.
Are you ok in sync with the Multi.txt file content? There has been quite some movement lately...
Pascal
Dec 02, 2016, 09:46 AM
Registered User
Hello,
Sorry but I am a little puzzled with this story of limits. Let's take an example:
config.h with TX_ER9X selected
Taranis, throttle low (-100%) = 988ms (micro sec)
I fly a V922 (Hisky protocol). Low throttle on Hisky is 1100ms, so it is the value expected by the rx.
Is there an automatic scaling made by multiprotocol sw to adapt OpenTx value (988) to the expected one by Hisky (1100) or do have I to do it via Limit in OpenTx (988/1100=90%)?

Thank you in advance for the clarification.

Didier


Quick Reply
Message:

Thread Tools