OrangeRx R610V2 Lite DSM2 Binding

[QUERB]

Greetings, My Turnigy 9xr Pro is fitted with the module "iRangeX IRX4 Plus 2.4G CC2500 NRF24L01 A7105 CYRF6936 4 IN 1 Multiprotocole STM32 TX Module avec Coque" from Banggood bought 2 months ago. I have binded without any issue a receiver "FS-A8S 2.4Ghz 8CH Mini Receiver With PPM I-BUS SBUS Output". It works correctly in PPM mode and serial mode with the last revision of the 9xrshy software. However, I have an other model fitted with receiver "OrangeRx R610V2 Lite DSM2 Compatible 6CH 2.4GHz Receiver W/CPPM". In PPM or serial mode, when the binding seems to be finished, the servos of the model don't work correctly exactly as when the protocole is not the right one. But, before to fit my radio with the STM32 module, I had a "2.4g CC2500 a7105 FlySky FrSky devo DSM2 multiprotocole module tx avec antenne - FlyskySo" from Banggood too. The receiver works correctly with the DSM2 protocole of this module. So, I think that I don't parameter correctly the DSM2 protocole on the STM32 module. May you indicate me how parameter correctly the DSM2 protocole of the STM32 module in accordance with them of the Atmega328p module ? My first idea was to update the STM32 module but I'm not comfortable with the updating method. In addition, I'm afraid to change the AFHDS2A protocle which work correctly during this updating. Thank you for your answer. Regards.

Bruno

[pascallanger]

DSM (2 or X) are working perfectly fine on MPM modules. The purchased modules are coming with an unknown and probably old version of the software. You need to upgrade. The process seems complicated on the web page but is in fact really easy with only a few steps. The steps to configure for DSM an Atmega328 or STM32 module are exactly the same. You should use DSM / AutoDetect or Auto and then launch a bind. The parameters to work for that RX should be set automatically. Pascal

[QUERB]

Thank you for your answer. I will try to update the STM32 module and contact you back after (next week probably). Bruno

[QUERB]

I have updated the STM32 ! Effectively, it's easy when we have all equipment and apply correctly the different steps. So, the communication with the receiver FS-A8S works correctly ; as before. However, when I bind the receiver OrangeRx R610V2 Lite DSM2, the same issue than before appears. On the transmitter, I have selected Auto for the DSM protocole defined on multiprotocole menu and bind the receiver. I have of course apply the protocol of binding of the receiver before. Result : it doesn't work. Screenshot before binding : Screenshot during binding :
Screenshot after binding : I have noted that the Rate is 7ms and can be increased to 11ms but it isn't possible to define 22ms to be in accordance with the DSM22 protocole. Is that the cause of the issue ? Thank you. Regards.

[pascallanger]

Forget the rate setting and leave it to 7ms, this is not the issue. What do you mean by "when the binding seems to be finished, the servos of the model don't work correctly"? What is the LED status on the RX and the module during all phases? Please check the doc on how to bind it: https://cdn-global-hk.hobbyking.com/media/file/576564029X1606554X8.pdf

1. Install a bind plug into BIND connector.
2. Apply power to the receiver.
3. You will see the orange LED rapidly blinking. That means the receiver is in Bind mode.
4. Launch a Bind from the TX, the system will connect within a few seconds. Once connected, the orange LED on the receiver will blink several times and go solid indicating the system is connected.
5. Remove the bind plug from the BIND and THRO ports on the receiver before you power off the transmitter and store it in a convenient place.

Also the LED status:

Orange LED is blinking rapidly. After receiving binding signal from the transmitter blinks slowly for several seconds and then becomes solid if connection is correct. In normal operation In presence of transmitter signal: Orange LED is solid. If the transmitter signal is lost Orange LED is OFF. Red LED blinks number of holds(up to 256) – signal losses with more than 1 second when receiver had to trigger a fail safe event. The LED will flash the number of holds then pause (e.g., flash, flash, flash, pause, flash, flash, flash, pause indicates three holds occurred since the receiver was last turned on). Note that holds are reset to zero when the receiver is turned off. During the first flights of a new airplane, it’s recommended to check the red LED hold indicator. If it’s flashing, it’s important to optimize the installation (move or reposition antennas) until no hold occurs. On later flights, the LED Hold Indicator can be used to confirm RF link performance.

[pascallanger]

You also might want to post on rcgroups, may be someone has the same receiver: https://www.rcgroups.com/forums/showthread.php?2165676-DIY-Multiprotocol-TX-Module/page905#post41424905

[QUERB]

The binding protocol described is in accordance with the one I have applied. I have checked the LED status. The red led of the transmitter is blinking rapidly only during the binding and is solid after. Before binding the orange led of the receiver is blinking rapidly and becomes solid after binding. In fact the issue is that after binding, the receiver rings regularly and continuously during 20 to 30 seconds. Then the ring is stoped and the motor runs itself ! So, when this issue occurs, I stop the test. But today, I have noted that the order of the chanels is different ! As if the mode of the transmitter is 2 or 4 but not 1 as I use. So, I have checked the order of the chanels defined on general menu of the transmitter : AETR. That is ok. So, what should be the cause ? Thank you.

[pascallanger]

So it's basically working. You are just confused about the channel order. If the multi module is configured to use AETR (default in _config.h) then ALL your MODELS MUST BE configured AETR. For DSM, it also implies that the module will REMAP the channels to TAER like stated in the documentation, which means on the RX that CH1=T, CH2=A, CH3=E, CH4=R.

[QUERB]

I have checked connections of the RX : it's correct. The chanels are defined correctly on the transmitter too. Ended, the order of chanels is AETR on general menu of the transmitter. So, I have tested with another model of plane fitted with the same part number of receiver : the issue is the same. Have you another Idea ? Thank you.

[pascallanger]

Are the servos moving correctly? From your previous comment you are saying that you stop everything because your motor start spinning. Disconnect your motor and see if the servos are reacting normally. I bet that the servos work but not on the sticks you expect them. I'm still thinking there is a config mismatch. Please take pics of the mixers you are using and the rx connections. Again if the mixers on the radio are: CH1=Ail CH2=Elev CH3=Thr CH4=Rud Then on the RX the connection must be: CH1=ESC+mottor CH2=Ail servo CH3=Elev servo CH4=Rud servo

• Pascal

[QUERB]

This is a picture of the model Hexafly with only 2 flaps : This is a picture of the rx : Ended, the picture of the mixers : The servos are moving correctly but not with the right stick. In addition, the mixing of the chanels doesn't work.

[pascallanger]

Your mixers are wrong... The module is configured to be AETR so you must use AETR IN ALL YOUR MODELS. Les mixeurs ne sont pas bon. Le module est configuré en AETR donc tous les modèles doivent être configuré en AETR (ou APGD en français). Donc vos mixeurs doivent être: CH1=125 Prf + -125 Ail CH2=-125 Prf + -125 Ail CH3=Gaz C'est ce que je vous dis depuis le début... Les mixeurs ne sont pas configurés correctement pour fonctionner avec le module. Encore une fois, celui-ci est en AETR (par défaut) donc il faut que les mixeurs de tous les modèles soient réglé en AETR. Pascal Merci de penser à un don: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/docs/Donations.md

[xjrphilippe]

Bonjour,Effectivement aetr pose des problèmes en particulier avec les récepteurs spektrum du type as3x ( compensation automatique taer sur les 3 axes ailerons, profondeur et dérive) car là impossible d'inverser les servos, t devient compensé et la profondeur n'y est pas...Le module multiprotocol ne me sert donc à rien, j'ai donc démonté une vieille dx6i et réalisé un module pour l'installer dans ma taranis. Domage de ne pouvoir utiliser le multiprotocol avec les modèles eflite...J'ai bien essayé de modifier le protocole sous arduino mais Windows 10 bloque certains pilotes...donc point mort.Une solution?CordialementxjrphilippeLe 23 mars 2019 18:14, pascallanger notifications@github.com a écrit :Your mixers are wrong... The module is configured to be AETR so you must use AETR IN ALL YOUR MODELS.

Les mixeurs ne sont pas bon. Le module est configuré en AETR donc tous les modèles doivent être configuré en AETR (ou APGD en français).

Donc vos mixeurs doivent être:

CH1=125 Prf + -125 Ail

CH2=-125 Prf + -125 Ail

CH3=Gaz

C'est ce que je vous dis depuis le début... Les mixeurs ne sont pas configurés correctement pour fonctionner avec le module. Encore une fois, celui-ci est en AETR (par défaut) donc il faut que les mixeurs de tous les modèles soient réglé en AETR.

Pascal

Merci de penser à un don: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/docs/Donations.md

—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.

[pascallanger]

Vous ne comprenez toujours pas!!! Le multiprotocol fait ce qu'on lui demande. Les récepteurs spektrum du type as3x fonctionnent très bien. Si vous suivez mes indications et changer les mixeurs sur votre émetteur vous verrez que vous n'avez pas besoin de modifier la position des servos et de l'esc sur vos modèles et que toues les vois seront affectés comme il le faut. Pourquoi ? tout simplement car le module fait automatiquement une translation entre AETR vers TAER et ceux-ci pour les radios non programmables. Si il est trop difficile pour vous de comprendre cela alors il vous suffit de faire une mise à jour du module en modifiant l'ordre des canaux du module vers TAER sur cette ligne: `/*****/ /* TX SETTINGS */ /*****/ //Modify the channel order based on your TX: AETR, TAER, RETA... //Examples: Flysky & DEVO is AETR, JR/Spektrum radio is TAER, Multiplex is AERT... //Default is AETR.

define AETR`

Dans ce cas TOUS VOS MODELES DEVRONT ETRE CONFIGURES EN TAER. Pascal

[QUERB]

Dear all, I have defined, this morning, the chanels as described by Pascal and I confirm that all my models work perfectly now with the multiprotocol module ! Thank you very much for your help Pascal !

[pascallanger]

Vous pensez de trop. Le module fait en sorte que tous les modèles soient configurés de la même façon. Donc quand le module est configuré pour avoir l'ordre des canaux Ail(A), Prof(E), Gaz(T), Dir(R), il faut configurer tous les modèles en utilisant cette convention. Pour DSM et d'autres protocoles les sorties sont automatiquement réassignées. Dans le cas de DSM, il faut configurer le modèle en utilisant la convention Ail(A), Prof(E), Gaz(T), Dir(R) mais le récepteur recevra de son côté Gaz(T), Ail(A), Prof(E), Dir(R) comme l'attendent tous les modèles DSM. Donc n'impote quel modèle Spektrum fonctionne, j'ai fait volé un Beast as3x, le T28 as3x sans aucun problème et beaucoup d'autres modèles DSM, il suffit de suivre la convention du module. Pascal

[xjrphilippe]

Bizarre mon visionaire lui ne fonctionnait pas avec as3x ar 635 dsmx donc première génération autrement je n'aurai pas réagit à ce message...  Je ne peux pas modifier l'ordre des voies car je fais de l'écolage entre ma taranis x9 et spectrum dx7s et dx6i du club. Tous nos modèles club sont eflite.Je vais refaire des essais mais la dernière fois ma profondeur était en butée et l'ESC ne s'activait pas...Cdt En tous cas c'est un sacré travail de faire vivre ce forum, bravo.Le 24 mars 2019 14:23, pascallanger notifications@github.com a écrit :Vous pensez de trop. Le module fait en sorte que tous les modèles soient configurés de la même façon. Donc quand le module est configuré pour avoir l'ordre des canaux Ail(A), Prof(E), Gaz(T), Dir(R), il faut configurer tous les modèles en utilisant cette convention. Pour DSM et d'autres protocoles les sorties sont automatiquement réassignées. Dans le cas de DSM, il faut configuré le modèle en utilisant la convention Ail(A), Prof(E), Gaz(T), Dir(R) mais le récepteur recevra de son côté Gaz(T), Ail(A), Prof(E), Dir(R) comme l'attendent tous les modèles DSM. Donc n'impote quel modèle fonctionne, j'ai fait volé un Beast as3x, le T28 as3x sans aucun problème et beaucoup d'autres modèles DSM.

Pascal

—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.

[pascallanger]

Il suffit donc de recompiler le firmware en modifiant l'ordre des canaux vers TAER par défaut dans le _config.h comme dit plus haut et le problème est réglé. par contre tous les modèles doivent être en TAER après ça. Pour les débattements du protocole DSM, il y a une option qui permet soit d'avoir le même débattement que les Spektrums, soit d'avoir un débattement étendue. Il faut lire les détails dans le protocole: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/Protocols_Details.md#dsm---6 . Sachant que les Spektrums utilisent très souvent un débattement étendue (qu'il faut activé dans OpenTX ou ersky9x) au niveau de la voie des gazs pour la coupure. Pascal

[xjrphilippe]

C'est ce que j'ai essayer de faire mais pour l'instant j'ai des problèmes de drivers arduino pour win10 et pas d'accès en écriture au firmware..enfin je ne désespère pas d'y arriver.J'ai conservé toutes les conversations sur le sujet ( plus de 80 depuis la sortie du module)  bon mon anglais d'école ne me permet pas de tout comprendre mais le sens général est là..Merci encore.CdtLe 24 mars 2019 16:41, pascallanger notifications@github.com a écrit :Il suffit donc de recompiler le firmware en modifiant l'ordre des canaux vers TAER par défaut dans le _config.h comme dit plus haut et le problème est réglé. par contre tous les modèles doivent être en TAER après ça.

Pour les débattements du protocole DSM, il y a une option qui permet soit d'avoir le même débattement que les Spektrums, soit d'avoir un débattement étendue. Il faut lire les détails dans le protocole: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/Protocols_Details.md#dsm---6 . Sachant que les Spektrums utilisent très souvent un débattement étendue (qu'il faut activé dans OpenTX ou ersky9x) au niveau de la voie des gazs pour la coupure.

Pascal

—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.