Multi Orange (ou comment donner une 2nd vie)

Merci chewi,

Tu as bien raison de le mentionner.
Mais dans ce cas, les firmwares que j'ai posté ne sont pas correct. Ces firmware sont uniquement compilés pour OpentX.

Ca ne change rien, le passage à ersky9x c'est juste le temps de faire le flashage, après réinstalle OpenTX.

C'est vrai, j'ai oublié que ersky9X tournait aussi sur Taranis...

chewi a écrit:  Bonsoir,

 Il y a une autre solution que le programmateur, mais faut avoir une 9x avec carte ar9x et pour une fois le firm ersky9x en mode maintenance le temps de programmer le module orange
Oui, je sais, c'est un peu compliqué tout çà ,mais comme je vais recevoir mon AR9X, çà va m'éviter soit d'acheter ce programmateur, soit d'aller à mon ancien centre d'ingénierie

Salut chewi t'es chanceux de l'avoir acheté il y a pas longtemps, car seulement dispo demain, je l’espère en tous cas...

Kilrah a écrit:Ca ne change rien, le passage à ersky9x c'est juste le temps de faire le flashage, après réinstalle OpenTX.

LapinFou a écrit:C'est vrai, j'ai oublié que ersky9X tournait aussi sur Taranis...

Ceci dit, il ne suffit pas de juste installer ersky9x sur la Taranis pour pouvoir flasher le XMega. Il faut aussi faire un petit modif hardware à l'intérieur de la Taranis.

Bonjour,

Oui c'est vrai, il faut faire une petite modif sur la taranis, mais rien de bien compliqué si on n'a pas Parkinson.
Je le ferai certainement plus tard.

Perso quand je recevrai mon AR9X (elle est en chemin), j'en profiterai pour faire aussi la petite modif de ma 9X (quoique je pense qu'elle est déjà faite, mais pas sur, à vérifier) et aussi pour flasher le module orange.

D'ailleurs, dilemme pou moi, ma 9X, soit je la laisse en ersky9x et profite de l'encodeur rotatif, soit je la repasse en OTX mais là, adieu l'encodeur et en plus il faut que je retrouve une face avant pour réinstaller les switch de l' ar9x. En plus, pas sur de retrouver cette face avant, les pièces détachées pour cette radio n'éxiste pas en vente.plus qu'à passer une annonce pour trouver quelqu'un qui en aurait une ou une radio morte
L'espoir fait vivre, je pense que je vais vivre très vieux

pendant que j'y pense voici le lien pour les modifs: modif pour utiliser sa radio en programmateur PDI

pour l'encodeur rotatif sur AR9X https://www.rcgroups.com/forums/showpost.php?p=33184864&postcount=697

Si l'encodeur ne marche pas sur AR9X/OpenTX il devrait d'ici quelque temps vu que je compte me monter une radio basée là-dessus.

Bonjour,

Je me doutais bien que les dev d'OTX allaient s'en occuper d'ici peu, j'ai juste voulu avoir confirmation par mes propos

Merci d'avance

Bonjour à tous. Petit retour d'expérience.

J'avais un module OrangeRX v1.2 qui se morfondait dans un tiroir depuis que j'utilisais un hack module cannibalisé d'une Dx5e donc acte...
Bein ça fonctionne plutôt bien cette histoire, hormis le fait que l'ordre des voies côté récepteur n'est pas du cohérent avec celui défini dans OTX : mes radios (X9D et X12S) sont en mode 1, l'ordre des voies par défaut dans OTX est GAPD et pourtant, je me retrouve avec PGAD sur le récepteur .
Je dois avouer que je l'ai joué fainéant et ai utilisé le hex (version normale) tout prêt de LapinFou... ceci explique peut-être cela.

Qu'en pense le Lapin ?

Je me cite:

LapinFou a écrit:Note importante: Par défaut l'ordre des 4ères voies est APGD. Le module se chargera de remettre ses 4 voies dans l'ordre qui va bien suivant si vous sélectionnez J6PRO, DSM2, DSMX, Devo ou Walkera.
Ceci est vrai uniquement pour les 4 premières voies. Donc, attention si vous récupérer une programmation d'une personne possédant un Hack Module ou un module Orange normal. Vérifiez bien les 4 premiers mixages (VOIE1-VOIE4).
Vous devez faire comme cela quelque soit le mode utilisé, sans oublier de régler les limites correctement (du moins pour Spektrum):

Code:


VOIE01 Ail 0.0 -78.2 78.2 INV
VOIE02 Prf 0.0 -78.2 78.2 NOR
VOIE03 Gaz 0.0 -100  78.2 NOR
VOIE04 Dir 0.0 -78.2 78.2 INV

Mais je suis content que tout a bien fonctionné pour toi ! Tu es le 1er sur le forum à avoir tenter la modif.

Yep, j'avais bien vu ça mais je n'ai pas trouvé trace de ce code dans le source !

Uniquement ça ou je présume devoir remplacer AETR par TAER :

/*******************/
/*** 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

Cela étant, ça n'explique pas pourquoi je me retrouve avec un mapping ETAR

Peux-tu stp poster ton _Config.h en fichier joint afin que je le compare au mien. Merci d'avance.

Ben si, parce que le module remappe automatiquement l'entrée (configurée par le define) en TAER pour les RX DSM opour que tu n'aies pas à changer tes habitudes spécifiquement pour ceux-ci (et surtout en cas d'utilisation d'une radio que ne permet pas de réorganiser les canaux).

Bonjour Kilrah,
tu peux développer stp.

Pour récapituler, j'ai utilisé le hex compilé par LapinFou en AETR (si je me fie à l'extrait de code qu'il a posté) : si le module me remappait ça en TAER pour le DSM, ça m'irait très bien mais il me sort du ETAR

Comme je me voyais bien parti pour plusieurs essais successifs, j'ai préférer greffer un petit connecteur barrette femelle sur le module. L'utilisation d'une barrette coudée à 90° pour le connecteur mâle fait office de détrompeur et empêche toute inversion (à moins d'y mettre vraiment de la bonne volonté ).



My 2 cents

Le module veut sur les 4 premières voies que l'ordre soit APGD. C'est ce qui est dans le fichier _Config.h (et c'est ce que recommande le développeur du firmware Multi Protocol).

Code:

#define AETR

Donc, le module sait que l'ordre envoyé vers le module est APGD/AETR. Et c'est lui, qui va remapper les 4 sorties dans l'ordre qui va bien au moment de la transmission.
Comme l'a expliqué Kilrah, c'est pratique pour ceux qui ont des radios qui ne permettent pas de remaper les sorties.

Le module fait cela:
Radio → Ce qu'envoie le Multi Orange
A → G
P → A
G → P
D → D

En clair, le firmware fait cela:
Voie 1 → Voie 3
Voie 2 → Voie 1
Voie 3 → Voie 2
Voie 4 → Voie 4

Si tu lui balance GAPD en entrée, du coup (avec la conversion interne), cela va faire cela PGAD sur le module:
G → P
A → G
P → A
D → D

Maintenant, je peux te recompiler un binaire avec cela dans le _Config.h

Code:

#define TAER

Ainsi, cela fonctionnera comme le Hack module.

Je viens de régénérer les fichiers avec la dernière version.
MultiOrange -=version Bleue=- v1.1.6.21 - APGD.zip MD5: DB347485C3D02B89657B7F492401D9BF
MultiOrange -=version Bleue=- v1.1.6.21 - GAPD.zip MD5: 6ACE6EC57B45AE046282853DC1FEBE77
MultiOrange -=version Normal=- v1.1.6.21 - APGD.zip MD5: 69139F4D2240AC3845A0DC91DDDC3B89
MultiOrange -=version Normal=- v1.1.6.21 - GAPD.zip MD5: 7B9696CF8BA166AA6A2D211C29A28A6C

Merci pour ces réponses. Je regarde ça ce soir.

JohnLenine a écrit:Pour récapituler, j'ai utilisé le hex compilé par LapinFou en AETR (si je me fie à l'extrait de code qu'il a posté) : si le module me remappait ça en TAER pour le DSM, ça m'irait très bien mais il me sort du ETAR    

Parce que si tu as pris un hex en AETR il faut configurer ta radio en AETR, PAS en TAER.

Ca roule ! Merci à tous pour vos réponses.

Question subsidiaire  :
Est-il possible de masquer les protocoles inactifs dans le menu de sélection d'OpenTX ou bien est-ce codé en dur dans OTX? Concrètement, dans le cas du module OrangeRx, de voir accessibles à la sélection uniquement les protocoles compatibles avec la puce CYRF6936, soit DSM, DEVO et J6PRO.
J'ai recompilé et re-flashé après avoir mis en commentaire toutes les lignes inutiles dans _config.h mais j'ai toujours une liste de protocoles longue comme le bras dans le menu MULTI de la Horus.

Pas besoin de faire cela !
Sur la radio en-dessous de la ligne "Mode", il y a une ligne "Etat module".
Si le protocole est supporté, cela affiche la version du firmware.
Par exemple "V1.1.6.21"
Si le protocole n'est pas supporté, alors cela affiche "Protocole invalide".

Oui, j'avais bien constaté ça , n'empêche que c'est quand même un peu bête d'avoir à faire défiler x protocoles pour choisir le bon quand seulement 3 sont fonctionnels. Non ?
Je t'accorde que ce n'est pas bien pénalisant mais ma question était plus par curiosité intellectuelle que par intérêt pratique vu que pour ma part, seul le DSM m'est utile.

Oui mais non, il n'y a pas de mécanisme permettant au module de donner " à l'avance" les protocoles supportés.

Okey dokey ! Merci.

Alors ? Au final tout marche bien ?