Manuel Taranis/OpenTX/… (epub)

Bonsoir,

Loin de moi, le plaisir de te contredire ni de te blesser: Murphy.

Simplement, le fait de penser aux autres utilisateurs, qui, je pense, seront heureux de voir qu'on ne les a pas oubliés.
Comme exemple, nous avons pris une 304, bien sur avec l'évolution nous en sommes à la 308. Mais des personnes comme toi, moi et les membres de ce forum estiment que ce savoir ne doit pas se perdre.
Heureusement, des techniciens ont crées des revues techniques qui permettent,à l'heure actuelle,d'avoir cette source de connaissance et les particularités de leurs matériels.

C'est ce que nous faisons tous par l'intermédiaire de ce forum. Il ne faut en aucun cas exclure l'origine de ce magnifique matériel qu'une société et des passionnés ont su créer.

chewi a écrit:[…]utilisateurs, qui, je pense, seront heureux de voir qu'on ne les a pas oubliés.

Il y a néanmoins certaines particularités intéressantes à connaître (sur les différences).
De mémoire - au risque de me tromper - (je n'ai que des X9D+) merci de me corriger :
- batterie (peu d'importance, cela se remplace aisément)
- connecteur U.FL - sous réserve - (cas d'un changement d'antenne)
- S3 non accessible sur la carte 'mère'
Y aurait-il autre chose de majeur ?
(Le proc. est le même, donc il ne devrait pas y avoir d'incidence logicielle. sauf si ?)

Pour ma part, étant - sauf détails précédents - plus attaché au logiciel utilisable qu'au reste, je m'attache à l'utilisation (principalement). Bien sûr, si une différence matérielle a un impact sur ce dernier, cela m'intéresse (pour citer problème/solution,…)

Taranis Vs. Taranis Plus:
- 800mAh Vs 2000mAh
- Nouvel écran LCD avec rétroéclairage Bleu et Blanc, couleur réglable
- Nouveaux sliders
- Fonction hapic/vibreur
T+ B01: pas de SWR
T+ B02: retour du SWR

Juste un petit up, pour savoir si tu as continué de travailler sur cette doc ?? Perso, avec le boulot et la rentrée scolaire, je n'ai pas eu le temps de la lire et de te donner mon retour.
C'est sur ma TODO list !

LapinFou a écrit: pour savoir si tu as continué de travailler sur cette doc ??

Pour le travail effectué, la réponse est oui.
Pour savoir si cela vaut le coup de publier -ou si cela m'intéresse encore, naïvement - je suis beaucoup plus dubitatif.
Simplement, parce que je crois que la plupart des gens s'en foutent, ou ne sont pas concernés.
Accessoirement, il est beaucoup plus facile de travailler pour soi (on connait ses limites), que pour les autres. Surtout quand il n'y a aucun retour aux travaux antérieurement faits.
Que ce soit critiques ou suggestions !

Perso j'adore l'idée.

Mais mon niveau est trop faible pour pouvoir vous aider, que ce sois sur la Taranis ou en rédaction.
Donc je pense que je fait partie de la majorité silencieuse pour ce projet.

Nicolas le Banni a écrit:Perso j'adore l'idée.

Mais mon niveau est trop faible pour pouvoir vous aider, que ce sois sur la Taranis ou en rédaction.
Donc je pense que je fait partie de la majorité silencieuse pour ce projet.

idem pour moi

serge

elj4Taranis a écrit:Surtout quand il n'y a aucun retour aux travaux antérieurement faits.
Que ce soit critiques ou suggestions !

Pour ma part j'ai pas mal échangé avec toi sur le format epub, j'ai fournit un tuto S.Bus, j'ai compilé le simu 2.1 en FR pour que tu puisses faire des écrans en français directement depuis ton PC.
Ensuite j'ai eu une période de vacances en aout mais depuis j'ai lu la doc epub RAS sinon les illustrations mais j'ai déjà échangé sur le sujet.
J'ai cru comprendre que tu avais besoin de relecteurs plutôt que d'écrivains donc j'attends la suite ....

Peut-être que tu pourrais donner un coup de main pour faire les capture d'écran en version Française ?

@elj4Taranis Que penses-tu de la suggestion de ?
Dans ton epub, tu as au moins 4 sortes d'illustrations:
1-photos
2-recréations d'écrans en EN
3-snapshots EN
4-snapshots EN + annotations
Dis moi sur lesquelles tu aurais besoin d'un coup de main sachant qu'à mon avis tu auras qd même + vite faire de les faire sur ton PC avec le simu 2.1 FR.
Par contre le passage en FR  de certaines illustrations entraine une traduction du texte:

Alarms

   Battery Low : seuil d'alarme (v)
   Inactivity : Si vous avez oublié d'éteindre la radio au bout de…
   Memory Low
   Sound off : la radio n'émettra aucun son d'avertissements même en cas de batterie faible.

Backlight

   Mode : Si la valeur est Keys, Controls ou les deux, le rétro-éclairage s'allume quand un manche est déplacé et/ou une touche.
   Duration : durée de cet éclairage.
   Brightness : intensité de l'éclairage
   Alarm : le rétroéclairage clignote lorsqu'une alarme retentit.

dev.fred a écrit:@elj4Taranis Que penses-tu de la suggestion de ?
Dans ton epub, tu as au moins 4 sortes d'illustrations:
1-photos
2-recréations d'écrans en EN
3-snapshots EN
4-snapshots EN + annotations
Dis moi sur lesquelles tu aurais besoin d'un coup de main sachant qu'à mon avis tu auras qd même + vite faire de les faire sur ton PC avec le simu 2.1 FR.

[/quote]
En fait, je suis preneur de tout écran jugé par vous peu clair, ou en remplacement/complément d'autres illustrations.
Je pourrais faire, mais cela prend à chaque fois du temps. Donc là c'est une aide appréciable.
Sachant que je désire garder en double anglais ET français autant que possible.
Dans ces cas, je note(rai) sous la forme double. ex. Backlight [Rétroéclairage]
Je fais des recréations, surtout - et vais sans doute limiter aux … continuations (quand l'écran fait plusieurs pages, il est intéressant de combiner.) Mais, dans certais cas, il s'agit d'essais, pour voir ce qui est le mieux perçu.

Ce qui me manque, surtout :
** des demandes, du genre : intégration de tel tuto. i.e. savoir ce qui manque le plus
À chaque fois, que parait un tuto, je l'examine, et si je l'ajoute, le transforme (car, comme il s'intègre dans un tout, j'élimine les redondances, j'ajoute des liens. Les besoins d'un tuto isolé n'étant pas les mêmes qu'un tuto 'intégré'.
Mais là, j'ai besoin de distinguer les priorités… des autres (de deux sortes):
- ceux qui débutent
- ceux qui veulent faire plus 'pointu'
(En l'absence de 'retour', j'ai du mal à distinguer ce qui importe (sauf pour moi )

** J'ai également besoin d’éclaircissements sur la philosophie d'OpenTX.
Pour l'instant, je suis dubitatif sur l'écran 'entrées' car, soit il est redondant avec mixer, soit je ne vois pas pourquoi seules quelques unes des entrées sont nécessaires/présentes.
Il est difficile d'expliquer/simplifier, si on a soi même un doute

-----------------
sur ce, une nouvelle mouture est disponible ce jour avec un changement dans l'ordre.
Mais seront rajoutés ultérieurement, des mini-TOC dédiées aux approches différentes.

Rappel : à chaque nouvelle mouture, :
le directory :
https://www.dropbox.com/sh/c91zj161ifikcr1/AAAIpz54-Hb8y13nDJjEVhAVa?dl=0
le dernier fichier:
https://www.dropbox.com/s/lq7f4oxlnjk7ux4/OpenTX_FrSky_Manuel-FR.epub?dl=0

- remplacement du (dernier) fichier "OpenTX_FrSky_Manuel-FR.epub"
- ajout d'un fichier daté (dans \versions), ici : "OpenTX_FrSky_Manuel-FR - 2015-09-05.epub"

elj4Taranis a écrit:soit je ne vois pas pourquoi seules quelques unes des entrées sont nécessaires/présentes.

Comment ça?
L'idée c'est que les entrées "de base" utilisées la plupart du temps sont présentes d'office, après si t'en veux d'autres tu les rajoutes toi.

C'est l'équivalent des "fonctions" chez Futaba par exemple.

Kilrah a écrit:L'idée c'est que les entrées "de base" utilisées la plupart du temps sont présentes d'office,

Que ce soit l'équivalent de,… m'importe peu a priori quand j'essaye de donner des explications claires. Sauf si j’avais une Futaba
Ce que je ne comprend pas :
je crée - par exemple - un modèle type 'avion' (avec l'assistant), mettons, avec aéro-freins, donc pour moi, l'entrée aéro-freins existe.
Je ne trouve en entrées que DGPA, rien d'autre.
Je retrouve en mixer beaucoup plus (dont les AF.)
Donc 'entrées' comme nom, me pose problème, puisque je trouve PAS TOUTES les entrées.
Donc, soit la terminologie est ambiguë - mais on peut s'habituer, soit … il faut suffixer par quelque chose.

Mais en tout cas il faut pouvoir expliquer la raison de l'obligation de présence ou de l'absence.
Qu'est-ce qui justifie - par exemple - que les AF ne soient pas dans entrées ?
Tout bête comme question
C'est la logique sous-jacente qui me pose problème. Sauf si on m'explique la logique (si possible pas de la 'fuzzy logic"), ou la terminologie.
Je cherche donc l'explication : pourquoi l'entrée AF n'existe pas dans les entrées. (Ce qui suggère qu'il existe un critère supplémentaire du genre : "seules les entrées de tel type existent dans entrées.)
Mais dans ce cas, il faut pouvoir le dire clairement, et peut être changer le titre de l'écran s'il est ambigu. (ex. "Entrées de type A, en explicitant les conditions)
"Être ou ne pas être, that is the question"

Il y a un post (je ne le trouve plus !) qui explique la différence entre les entrées et les mixages.
En fait les entrées ne sont pas obligatoires mais plus pratique dans certains cas. Prenons par exemple un avion avec 1 servo par aileron. Dans les mixages si tu veux du dual/rate il faudrait programmer cela sur le servo de droite et celui de gauche.
Si au contraire tu mets cela dans les entrées alors tu programmes 1 seule fois et cela s'applique aux 2 ailerons.

Dans ton exemple, si les aéro-freins ne font que ça (il ne s'agit pas d'ailerons qui se lèvent par exemple), il me parait plus clair de créer une entrée effectivement.

Les possibilités de la Taranis sont tellement importantes qu'il y a plusieurs façon de faire la même chose, même si on peut essayer de tous faire de la même façon, la bonne à mon avis c'est celle que l'on a trouvé soi-même ! et que l'on accepte de remettre en question dès que l'on apprend autre chose.

L'autre intérêt des ENTREES est de pouvoir déclarer des dual/triple (voir plus) rate à un seul endroit.
Sinon, comme l'explique Eric, tu serais obligé de dupliquer les prog pour chaque aileron utilisant le manche aileron.

L'autre grosse différence, c'est que dans ENTREE une seule ligne peut êre active à la fois, alors que dans mixages, tu peux avoir une ou plusieurs lignes d'active en même temps.
ENTREE = un genre d'aiguillage
MIXAGE = un mélangeur

elj4Taranis a écrit:...
Ce que je ne comprend pas :
je crée - par exemple - un modèle type 'avion' (avec l'assistant), mettons, avec aéro-freins, donc pour moi, l'entrée aéro-freins existe.
Je ne trouve en entrées que DGPA, rien d'autre.
Je retrouve en mixer beaucoup plus (dont les AF.)
Donc 'entrées' comme nom, me pose problème, puisque je trouve PAS TOUTES les entrées.
Donc, soit la terminologie est ambiguë - mais on peut s'habituer, soit … il faut suffixer par quelque chose.
...

Ce que tu dis est juste mais n'oublie pas qu'OpenTx a évolué avec le temps et les entrées telles qu'elles sont aujourd'hui ne sont là que depuis la version 2.0.

Si créer une entrée AF est une bonne chose selon moi, il me semble que peu le font. Les habitudes vont changer, ça va évoluer gentiment, la création des modèles ça va changer aussi, tu verras.

J'ai trouvé un magnifique diagramme qui peut aider à visualiser comment s'articulent les différents blocs fonctionnels d'OpenTX et leurs rôles: http://rcadev.info/OpenTX%2003%20Data%20Flow.htm
C'est vrai dans le bloc d'entrées, il n'y a que 4 entrées affectées à des organes physiques et donc les 28 restantes sont disponibles.
Le bloc d'entrée est donc majoritairement inutilisé c'est peut-être cela qui déconcerte.
La logique utilisée est très mathématique, ici le nombre magique est 32 voies pour chaque bloc et l'on retrouve les mêmes fonctions mathématiques dans les blocs entrées et mixages d'où la possibilité de faire la même chose de différentes façons.

elj4Taranis a écrit:
je crée - par exemple - un modèle type 'avion' (avec l'assistant), mettons, avec aéro-freins, donc pour moi, l'entrée aéro-freins existe.
Je ne trouve en entrées que DGPA, rien d'autre.
Donc 'entrées' comme nom, me pose problème, puisque je trouve PAS TOUTES les entrées.
Qu'est-ce qui justifie - par exemple - que les AF ne soient pas dans entrées ?

C'est simplement que personne n'a pris le temps de s'occuper de l'assistant et de lui faire suivre les évolutions du reste du soft... Mais oui il serait plus logique d'avoir une entrée pour les AF.

L'avantage des entrées est simple à comprendre, surtout avec ce genre de fonctions. Prends un planteur à 4 ailerons, tu veux configurer un butterfly. Si tu fais tout dans les mixages, et que par la suite tu veux changer de commande de butterfly ou changer la "quantité" que la commande va donner tu dois aller éditer 4 mixages, alors que si tu as fait une entrée il n'y a qu'elle à changer.

En gros tout ce qui est une "fonction" du modèle que tu souhaites commander mérite son entrée.

dev.fred a écrit:Le bloc d'entrée est donc majoritairement inutilisé c'est peut-être cela qui déconcerte.

Cela peux paraître 'provoc' de poser des questions de ce genre. (Nota : étant - entre autres - ingénieur en informatique et systèmes asservis - de formation, traquer erreurs et imprécisions devient une seconde nature. [en 3e nature, je rajoute mes propres erreurs ])
Mais le job que je me suis assigné, est de faire un manuel, ce qui peux difficilement tolérer le 'à peu près' (sauf par inadvertance )
Par formation, j'ai appris (en théorie) logique et rigueur. Je subodorai bien quelque chose comme cela, mais il faut que les choses soient claires pour pouvoir les expliquer clairement.
Le plus 'dérangeant', c'est sans doute cette terminologie "d'entrées" qui pour moi évoque l'ensemble des entrées existantes, alors que ce n'est pas le cas (optionalité).
Sans doute les développeurs/traducteurs, devraient-ils choisir un autre mot clé pour l'écran. Quant à savoir lequel serait adapté ?
C'est le pouvoir - et danger - de la sémantique/lexicologie.
La carte n'est pas le territoire, mais le mot est porteur d'un concept. Et ici, il est trompeur (par ambiguité)

Après, effectivement, se poseront les problèmes :
- quand est-il utile de définir une entrée. Avec un début de piste - avec les dual/triple rate;
- quand, vaut-il mieux s'en passer.
- que se passe-t-il si on définit deux entrées avec le même nom ? (mauvaise idée, mais que fait la RC dans ce cas ?)

Pour le mixer, pas de problème, c'est clair : une servo sans mixer reste au neutre. Donc, une entrée (au moins) est obligatoire. Pas trop d'ambiguité sauf - parfois - dans la répartition du travail entre "entrées" et "mixer"

Kilrah a écrit: butterfly. […] éditer 4 mixages, alors que si tu as fait une entrée il n'y a qu'elle à changer.

En gros tout ce qui est une "fonction" du modèle que tu souhaites commander mérite son entrée.

- Pourrais-tu définir le nom ? (butterfly => ? empennage papillon ou => AF du type [volets descendants & ailerons qui se lèvent ? 2nd, i presume)

- Pourrais-tu me donner copie écran/companion des deux cas de figure que tu évoques :
l'un sans "entrée", l'autre avec afin que je l'intègre dans la doc - à titre d'exemple

- Le terme "fonction" continue à me poser question (pour moi, cela invoque une fonction mathématique). Fonctionnalité, ou autre chose ?

Je parlais évidemment des "volets descendants & ailerons qui se lèvent".

Fonction/entrée = effectivement une "fonctionnalité" du modèle (Ailerons, AF, train, tilt caméra...)

L'ordre de traitement est simple:
- Tu pars d'un organe de de commande
- Celui-ci actionne une entrée
- Les entrées sont mélangées entre elles pour donner un ordre adéquat à chaque sortie.

Hello,

je crée - par exemple - un modèle type 'avion' (avec l'assistant), mettons, avec aéro-freins, donc pour moi, l'entrée aéro-freins existe.
Je ne trouve en entrées que DGPA, rien d'autre.
Je retrouve en mixer beaucoup plus (dont les AF.)
Donc 'entrées' comme nom, me pose problème, puisque je trouve PAS TOUTES les entrées.

1) Tu ne trouves pas toutes les entrées parce que celui qui programme son modèle ne les y a pas mises...
Rien n'empêche d'utiliser l'écran 'Entrées" pour les définir toutes.
2) Les AF sont une sortie; la COMMANDE d'AF serait une entrée.

Par formation, j'ai appris (en théorie) logique et rigueur. Je subodorai bien quelque chose comme cela, mais il faut que les choses soient claires pour pouvoir les expliquer clairement.
Le plus 'dérangeant', c'est sans doute cette terminologie "d'entrées" qui pour moi évoque l'ensemble des entrées existantes, alors que ce n'est pas le cas (optionalité).

Si si ! C'est bien le cas et le but...

Ce qui induit en erreur, c'est que l'entrée [E]GAZ se voit attribuer comme paramètre d'entrée...GAZ. Ceci semble être une redondance. Dès le début, certaines entrées se voient attribuer une pseudo fonction de sortie ce qui complique la compréhension.
Il eut été plus clair de dire que l'entrée [E]GAZ se voit attribuer comme valeur d'entrée "Manche Droit Vertical" (en mode 1) et que, toujours dans le même mode, l'entrée [E]Profondeur se voyait attribuer la valeur "Manche Gauche Vertical".

Dans ce cas, il y aurait clairement un découplage entre la valeur d'entrée et la fonction qui lui est attribuée, ce qui est le but de l'écran.
Et en plus, il n'y aurait plus de distinction nécessaire entre les modes 1,2,3 et 4.

Si les AF doivent être commandés par un slider par exemple, il faudrait créer une entrée "AF" qui prend la valeur de SR (ou SL) avec le bon ration ou le décalage ou la courbe qui va bien.

En bonne logique, un trains rentrant devrait également avoir une entrée basée sur l'interrupteur qui le déclenche.

Dès lors, la page mixage ne sert (plus) qu'à attribuer les entrées vers les voies ad-hoc en tenant compte des combinaisons, des influences d'une entrée sur plusieurs voies, des conditions particulières, ...

Entre autres avantages de cette solution, il y a la possibilité de changer d'avis facilement.  Si mon réglage d'AF se base sur SL dans les mixages et que je souhaite passer à SR, je dois probablement modifier plusieurs lignes...
Par contre, si mes mixages se basent sur l'entrée AF, il suffit de modifier celle-ci pour que tout le reste soit toujours valable.
De même si mon train rentrant serait plus accessible via un autre interrupteur, ...

L'écran "Entrées" permet le découplage entre une grandeur d'entrée et son utilisation dans le modèle.
Cela simplifie aussi l'écran des mixages qui reprend son rôle de base : assurer le routage des commandes vers les voies ad-hoc.

A la création d'un modèle, il faudrait se demander
1) Quelles sont les fonctions utilisées par mon modèle ?
- Par exemple : Gaz, Ailerons, Profondeur, direction, train rentrant, lumières, flaps, crochet de largage, ...
Ceci détermine les voies utilisées dans l'écran de mixage

2) Ensuite quelles sont les commandes que je veux utiliser pour piloter mon modèle ?.
Gaz, ailerons, direction, profondeur, flaps,  crochet de largage.
(Dans cet exemple, le train rentrant serait automatique ainsi que les lumières)
Pour chacune des commandes, une entrée devrait être créée dans la page Entrées avec les caractéristiques (dual rate, courbe, ...)

Ensuite, on attribue ces entrées aux voies dans la page mixages. On y ajouter la gestion automatique des lumière et du train sur base de l'altitude...

Minute ! L'altitude est une valeur utilisée pour déterminer le déploiement ou pas du train ?  C'est donc une valeur d'entrée...
On crée une entrée ALTI qui reprend la valeur Altitude. Et c'est cette entrée que l'on utilise dans les interrupteur logiques pour déclencher ou pas la sorite du train.
Avantage : Le jour ou j'installe une sonde GPS, je dois simplement changer l'entrée ALTI pour utiliser "Altitude GPS" et le reste fonctionne "comme avant".

Voilà pour ce qui est de ma compréhension de l'intérêt de l'écran "Entrées".

Bons vols à tous,

Coyotte

Très bonne explication.

Une précision également... avant que le système actuel d'entrées existe il y avait un équivalent mais qui était "limité" à permettre de définir débattements et expo pour les 4 manches seulement.

Pour tous les autres cas si on voulait "grouper" des réglages on était obligé de le faire dans un canal libre (non transmis), et référencer ce canal dans les "vrais" canaux de sortie. Ca forçait donc à utiliser le mixeur pour des choses qui n'avaient rien à y faire. Rendre la page Entrées flexible permet de grouper ce qui va ensemble plus proprement.

CoyotteDundee a écrit:Rien n'empêche d'utiliser l'écran 'Entrées" pour les définir toutes.

- rien n'empêche yes. mais la question reste : quand est-ce que cela amène un plus. (début de clarification en cours) Problème restant : l’ambiguïté de la terminologie (écran) 'entrée'. Bon, on peut faire avec.

CoyotteDundee a écrit:Ce qui induit en erreur, c'est que l'entrée [E]GAZ se voit attribuer comme paramètre d'entrée...GAZ.

- [E]GAZ != GAZ. Ici, le problème de compréhension est majeur. On a deux notions # portant le même nom, qui ne représentent pas la même chose !

Ma première solution - mais j'aurais préféré que ce soit clairement différencié dès le début, est de renommer [E]"GAZ" en [E]"Gaz_" (on a une entrée "GAZ_" ayant pour source un manche 'Gaz')
Et là, miracle, on commence à distinguer l'un de l'autre. En particulier, on s'aperçoit, dans mixer, que la source dans mixer devient "GAZ_", donc, le résultat de l'entrée, si j'ose m'exprimer ainsi.
Cela devrait être fait (à mon avis) - de base - pour différencier, pour enlever l’ambiguïté entre "l'entrée" nommée et la "source" de l'entrée.

Kilrah a écrit:avant que le système actuel d'entrées existe il y avait un équivalent mais qui était "limité" à permettre de définir débattements et expo pour les 4 manches seulement.

En tant qu'ex développeur (dans mes vertes années (soupir ;( ), en tant qu'ex dirigeant d'un centre de développement, je comprend tout à fait le poids de l'histoire.
En tant qu'utilisateur 'pour les nuls', je me montre beaucoup moins accommodant.
Mais je peux envisager de me réconcilier avec moi-même sauf effort drastique !

elj4Taranis a écrit:
Ma première solution - mais j'aurais préféré que ce soit clairement différencié dès le début, est de renommer [E]"GAZ" en [E]"Gaz_" (on a une entrée "GAZ_" ayant pour source un manche 'Gaz')
Et là, miracle, on commence à distinguer l'un de l'autre.

Euh... c'est bien pour ça qu'il y a un [E]! Tu penses vraiment qu'un _ ferait la différence?