Presentation de la telemetrie OpenTX 2.1- Traduction de "OpenTX 2.1 telemetry system preview"

Il y a deux choses différente ici :

- ton cdif indique l'état de l'équilibre des cellules, donc l'état "de santé" de la lipo

- tu mentionne les C de la lipo. Le cdif ne reflète pas ça du tout. Ce qui importe dans ce cas, c'est la chute de tension sous la charge. Perso je gère ça dans mes scripts de télémétrie, ou j'affiche la tension cel la plus basse mesuré durant le vol et l'actuelle, l'écart entre les deux indique de combien tu a plongé sous la charge. Mais dans les usages extrêmes, la meilleure indication de demande excessives sur les lipos est leur température.

G

D'accord pour le Cdif, en fait si le pack est déséquilibré, le Cdif va être d'autant grand que la décharge de la batterie va être importante.

Sinon pour le C, si j'ai bien compris, tu compares la valeur minimum du pack pendant le vol à la valeur courante après le vol ce qui te donne la chute de tension maximale.
Après je ne vois pas bien le lien avec les C de la lipo car dans l'histoire, sans une mesure de courant, je ne vois pas ce que l'on peut en tirer ?

Pour un pack en bon état, le cdif en fin de vol seras d'autant plus petit que la décharge est douce. Si tu tire fort sur un pack donné, le cdif en fin de vol sera plus important. Sur un pack fatigué, c'est pareil, sauf que les valeurs de cdif seront plus grandes (que la décharge soit douce ou violente). Je parlait bien de cdif.

Il y a un autre phénomène qui est la chute de tension sous la charge. Dans un pack parfait, toute les cellules chutent de la même valeur, ton cdif reste a 0, malgré la chute sous la charge. La chute de tension dépend de la charge ET du C rating de ta lipo (de sa résistance interne en fait, mais je simplifie). Pour un même modèle, un lipo chargé a 100%, un lipo 20c va descendre plus qu'une 40C , qui elle même descend plus qu'une 60C. Une chute importante sous la charge indique donc que tu demande trop a ton pack (ce qui va immanquablement se traduire par un pack chaud en fin de vol).

Le soucis est qu'il n'existe pas vraiment de norme pour la mesure des C, et que chacun y va de sa sauce et que les C sont souvent assez fantaisiste. Mesurer la chute de tension sous la charge me donne donc une bonne idée du courant que la lipo est réellement capable de délivrer, en l’absence de mesure spécifique du courant.

G

Merci pour tes explications très claires et instructives .
Si tu as un script LUA donnant la chute de tension sous la charge pendant le vol à partager, je suis preneur !

Vi, bien sur, j'ai ca. Il est pour opentx 2.1, et pour l'utiliser, il faut renommer le senseur Cels en lipo (ou un crée un second qui s'appelle lipo et copie la valeur de Cels, ou VFAS, ou A2 selon). Idéalement, il faut aussi sur FLVSS crée un senseur calculé nommé lowc qui pend la cel la plus basse.

G

ps : j'ai mis avec quelques BMP que j'utilise dans le script

C'est du très bon travail et je suis ravi de retrouver le % de charge, c'est + simple à utiliser que de lire une table de décharge.
J'ai comparé à mon outil digital checker de Robbe, il donne la même mesure (au moins sur 3 points)  :



Il me reste à pratiquer et faire la synthèse de tout ce que j'ai appris hier et aujourd'hui et donc un grand merci à toi et à Kilrah .

Sujet intéressant je vais devoir le digérer tranquillement.

Kilrah a écrit:

pp340 a écrit:A Kilrah: Le chrono 1 était déclenché par le manche des Gaz, et le chrono 2 par un interrupteur.
Après la migration, je les ai retrouvés associés à des inter logiques.

Migration faite dans la radio ou dans companion? Avec la version finale ou une préversion? Parce que personne d'autre n'a reporté ce problème, et mes modèles sont OK...

Bonjour,

Suite à la migration de la 2.017 et 2.1 j'ai perdu les annonces sur le chrono 1. J'ai un interlogique pour tester chrono 1 et il est resté mais à la place de chrono 1 j'avais rien dans companion et un + dans la radio. Idem dans les fonctions spéciales lire valeur chrono1 a disparu. Ce n'est pas très grave, c'est facile à remettre. Je le signale quand même au cas où d'autres auraient le même problème.

Félicitation à l'énorme travail accompli encore une fois avec cette nouvelle version.

Bonjour,

Je tenterais bien l'expérience mais avant je voudrais savoir si le retour à la version 2.0.17 aura des conséquences?

Ce que je pense faire c'est une sauvegarde de mes modèles puis de les effacer, ensuite je charge la version 2.1 d'openTX et je recharge mes modèles.

Cela permet de convertir mes modèles non pas à la mise en place de la 2.1 mais au rechargement, peut être moins de bug!!!

Qu'en pensez vous?

serge

Et pour ceux que cela intéresse, on peut également passer le % de charge en variable globale et activer une alarme:

Dans le script LUA de TELEMETRY.zip après:
local percent = findPercentRemaining(autolowc)
on ajoute la ligne
--model.setGlobalVariable(gvar, flightmode, value)
model.setGlobalVariable(0, 0, percent)

Que l'on peut exploiter en utilisant le couple inters logiques/fonctions spéciales




Sympa non?

Le soucis de procéder comme ça, c'est que si tu as de multiple phase de vols, ça va poser des soucis. L'idéal serait sans doute d'ajouter un petit script modèle qui ferais le calcul. je dois avoir un modèle qui n'a pas de FLVSS, je regarderai ca dans la journée

G

Ce n'est peut être pas très élégant, mais ne suffirait-il pas de faire une boucle pour alimenter un VGx sur toutes les phases de vols par exemple ?

Sinon un script modèle peut alimenter les LUA1a,b etc... , c'est çà ?

Oui, exactement, le script modèle peut positionner les LUA.xx, qui sont accessible indépendamment des phases de vols.

G

@ dev.fred : va voir la, tout ce dont tu a besoin y est :Doc lua

G

YA+KA   merci.
Le model script est très adapté à la génération d'une alarme.
Avec la fonction getValue(getTelemetryId("Vcel") (Vcel est l'output dans l'exemple); je dois pouvoir l'articuler avec un script d'affichage de télémétrie comme tu l'as fait.

Petit souci en 2.1 : https://github.com/opentx/opentx/issues/2589

Vivi, tu m'a grillé pour le ticket que j'avais ouvert  Il est tagué pour la 2.1.1, donc ca devrais être réglé bientôt. J'ai prévu de :
- passer le calcul du pourcentage uniquement dans le model script
- retourner les % dans un senseur dédié, sur lequel on pourra mettre une alarme et par exemple une annonce vocale sur demande

G

Bonjour,

Je tenterais bien l'expérience mais avant je voudrais savoir si le retour à la version 2.0.17 aura des conséquences?

serge

@Gandalf
3djc c'était toi, j'étais étonné que 2 personnes découvrent le même problème à 3h d'intervalle, j'aurais dû m'en douter.
Sinon, en fait je n'ai pas trop besoin de programmer    au moins dans un premier temps, car je pensais faire la même chose dans le model script mais comme tu maitrises mieux que moi, j'attends avec impatience le résultat   .

@Diiity
La réponse est déjà dans le post, en page 3, Présentation des nouveautés d'OpenTX 2.1 auquel tu as participé

LapinFou le Lun 6 Juil 2015 a écrit:J'ai fait un test hier soir en 2.1.0. Au premier démarrage, la Taranis a affiché un message annonçant le conversion dans le nouveau format EEPROM.
Quand je suis revenu en 2.0.17, la Taranis a affiché un message que l'EEPROM était corrompue et la formaté.
Après j'ai remis ma sauvegarde 2.0.17. Tout est revenu normal (en 2.0.17)

Tous les conseils pour passer dans cette version casse-cou se trouvent ici http://openrcforums.com/forum/viewtopic.php?f=45&t=7239
Tu n'es vraiment pas obligé de le faire, tu peux attendre la sortie de la 2.1.1. Ils en sont à + de 50 bugs corrigés) c'est une affaire de semaine pas plus.

Alors là je suis un gros navets et désolé, je reviens de vacances il va falloir que je reparte!!  

Je ne retrouve pas ce post il est dans qu'elle rubrique? c'est bon j'ai trouvé, c'est dingue ça, pas bon pour ma tête tout ça

serge

Ç'est tout bon.

Eh eh, ou as tu eu cette version, on peut DL les dailies quelque part ?

G

dev.fred a écrit:

Gandalf a écrit:Il est tagué pour la 2.1.1, donc ça devrais être réglé bientôt.

Trop fort, B.Songis vient de corriger dans la branche principale.
Donc le fix devrait être dispo demain dans la version 2.1.1N397 de companion

Bonjour,

Une première question idiote peut être:
est ce que la versions 2.1.1Nxxx sont considéré comme une version 2.1.1 ou bien est ce la version "finale" sera bien la 2.1.1?

Une seconde question:
vu le travaille effectué, je désire faire un don. Ou dois je m'adresser?

serge