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

Les nightly sont... des nightly, donc générés automatiquement "dans l'état actuel" chaque nuit sans aucune vérification, donc même si l'état en question est complètement foireux ou casse tout.

Ce sont donc des versions de test réservées aux tests par les développeurs ou ceux qui ont reporté des problèmes pour confirmer qu'ils sont bien corrigés, et pas recommandés pour utiliser "pour de vrai".

Les releases officielles sont annoncées sur la page d'accueil/de téléchargement d'open-tx.org et par le système de mise à jour de companion.

Pour les donations y'a aussi une page dédiée sur open-tx.org, merci

voila c'est fait pour le don et merci pour les précisions

serge

Gandalf a écrit:passer le calcul du pourcentage uniquement dans le model script

Je me suis lancé à titre d'exercice en réutilisant le code de TELEMETRY.zip pour le calcul du % de charge restant.
Le fichier .lua est à mettre sous SCRIPTS\MIXES :

Code:

-- LUA model script
local inputs = { {"Capteur", SOURCE}, {"nb-cell", VALUE}}
local outputs = { "out" }

function findPercentRemaining(targetVoltage )
 local myArrayPercentList =
{
{3.683, 10},
{3.715, 15},
{3.747, 20},
{3.769, 25},
{3.791, 30},
{3.802, 35},
{3.812, 40},
{3.826, 45},
{3.839, 50},
{3.861, 55},
{3.883, 60},
{3.910, 65},
{3.936, 70},
{3.986, 75},
{3.999, 80},
{4.042, 85},
{4.085, 90},
{4.142, 95},
{4.170, 97},
{4.200, 100}
}
 local result = 10

 if targetVoltage > 4.200 or targetVoltage < 3.683
 then
 -- trap for odd values not in array
 if  targetVoltage > 4.200
  then
 result = 100
 end
 if  targetVoltage < 3.683
  then
 result = 0
 end
 else
 -- method of finding percent in my array provided by on4mh (Mike)
  for i, v in ipairs( myArrayPercentList )
  do
 if v[ 1 ] >= targetVoltage
 then
 result =  v[ 2 ]
 break
 end
  end
 
 end
  
 return result
end

local function run(parametre,nbcell)
  
    percent = findPercentRemaining(parametre/nbcell)

 return percent * 10.24
end

return { run=run, input=inputs, output=outputs }


Configuration du model script LUA= Capteur et nombre de cellules de la batterie:


Configuration d'une alarme à l'aide de L5 ici:


Ensuite il ne reste plus qu'à configurer l'écran  SPECIAL FONCTIONS


Il est à noter que les valeurs remontées par les scripts model LUA sont divisées par 10.24 :

Code:

-- LUA model script

local outputs = { "out" }

local function run()
 return 100
end

return { run=run, output=outputs }

Produit :


C'est expliqué ici:

https://docs.google.com/document/d/1ILh9lSW4d05qJD2rSKxep0WnJUfNCcAPCafKZeESweE/edit?pli=1#

J'ai procédé différemment en prenant la tension totale du pack, ce qui me permet de prendre n'importe quel capteur flvss, a1, vfas, multiwii,... et d'avoir directement le %

Code:

-- LUA model script
local inputs = { {"lipo", SOURCE}}
local outputs = { "Celp" }

function findPercentRemaining(targetVoltage )
 local myArrayPercentList =
{
{3.683, 10},
{3.715, 15},
{3.747, 20},
{3.769, 25},
{3.791, 30},
{3.802, 35},
{3.812, 40},
{3.826, 45},
{3.839, 50},
{3.861, 55},
{3.883, 60},
{3.910, 65},
{3.936, 70},
{3.986, 75},
{3.999, 80},
{4.042, 85},
{4.085, 90},
{4.142, 95},
{4.170, 97},
{4.200, 100}
}
 local result = 10

 if targetVoltage > 4.200 or targetVoltage < 3.683
 then
 -- trap for odd values not in array
 if  targetVoltage > 4.200
  then
 result = 100
 end
 if  targetVoltage < 3.683
  then
 result = 0
 end
 else
 -- method of finding percent in my array provided by on4mh (Mike)
  for i, v in ipairs( myArrayPercentList )
  do
 if v[ 1 ] >= targetVoltage
 then
 result =  v[ 2 ]
 break
 end
  end
 
 end
 
 return result
end

local function run(voltage)
 
    percent = findPercentRemaining(voltage / (math.ceil(voltage / 4.25)))

 return percent * 10
end

return { run=run, input=inputs, output=outputs }

Ce que j'ai fait aussi, c'est utiliser l'inter instantané SH pour obtenir en audio la valeur du pourcentage

G

Je vais un peu pinailler   return percent * 10 -> return percent * 10.24 (après tout ce que je viens d'expliquer ...)

Est-tu sûr que  math.ceil(voltage / 4.25) donne tout le temps le bon nombre de cellule quelque soit la charge de la batterie.

Pour l'inter instantané SH, je ne connais pas la technique, peux-tu m'en dire + ?

Pour l'instant, je n'ai pas pu prendre cet algo en défaut, qui est donné comme juste jusqu'a 12s.

Pour SH :

Merci pour l'astuce .

Et j'adopte math.ceil() qui retourne l'entier le plus proche, supérieur ou égal au réel passé en paramètre pour calculer le nombre de cellules.

J'ai lu sur le post http://openrcforums.com/forum/viewtopic.php?f=96&t=7275

Kilrah » Mon Jul 27, 2015 a écrit: OK, then when "Serial Port" is set to "Telemetry" on the hardware tab, the internal module is OFF and the external one is set to PPM you should have a setting on the telemetry page whether the telemetry supplied on the serial port is "D-type with hub" or Smart Port type

Effectivement, c'est ce que je viens de vérifier dans companion.

Je peux configurer le port série sur télémétrie dans l'écran 8/9 (j'ai aussi Ecolage SBUS et Recopie S-Port):



Et si je configure un module externe en PPM :



J'ai un nouveau choix de protocole dans l'écran de télémétrie:



Maintenant petite devinette : si j'ai un module DJT externe connecté et que je choisis le protocole Frsky D, est-ce qu'il me suffirait de brancher un câble série (à définir/bricoler) entre le module et le port série interne de la X9D pour récupérer la télémétrie  ?

Ouaip c'est le but.

Trop fort

Donc on pourrait avoir une Taranis plus en EU avec un DJT + D8 non EU par exemple ou un XJT externe avec un antenne 5dB démontable ...

Sinon quel est le but des 2 autres configurations de port série: Ecolage SBUS et Recopie S-Port ?
Ecolage je vois mais avec SBUS, je vois moins (c'est du série mais on peut-on décoder du SBUS sur un port série?)

Ecolage sans fil en branchant par exemple le SBUS d'un X4R-SB. Perso je préfère la connexion dans l'emplacement module pour ça, même pas de câble spécial à faire.

Recopie S-Port transfère simplement la télémétrie reçue du module interne sur le port série.

Pour un XJT externe y'a aucune connexion à faire, la télémétrie passe directement par les pins du module.

Merci pour toutes ces confirmations et toutes ces possibilités de connections  

Ecolage sans fil en branchant par exemple le SBUS d'un X4R-SB. Perso je préfère la connexion dans l'emplacement module pour ça, même pas de câble spécial à faire.

Un câble 3 fils de servo vers Vmain, GND et Heart_Beat.

Recopie S-Port transfère simplement la télémétrie reçue du module interne sur le port série.

Pour connecter un Dashboard par exemple et faire une sorte de X9E?

Pour un XJT externe y'a aucune connexion à faire, la télémétrie passe directement par les pins du module.

Le signal passe par la pin Sport .

dev.fred a écrit:Pour connecter un Dashboard par exemple et faire une sorte de X9E?

Ceux qui demandaient ça voulaient en général soit connecter un PC soit un téléphone/tablette mais oui, même genre...

En fait cette fonctionnalité est là depuis la 2.0.X.
A ta connaissance, y-a-t-il un programme sur PC Windows téléchargeable?

En fait je viens de trouver ça : https://github.com/Swifter/TaranisTelemetry

Mais il faut le compiler, il n'y a pas l'exécutable.

Non j'en connais pas.

A la sortie de la Taranis on a eu au moins 3 développeurs qui avaient déjà fait des apps pour le matos D et le hub p.ex. FrSky Dashboard pour Android qui nous ont demandé d'implémenter ça... mais une fois que c'était fait plus personne.

Ils ont dû comprendre qu'avec les annonces vocales intégrées y'avait plus trop d'intérêt d'avoir un appareil séparé, et du coup ont pas fait l'effort d'implémenter le protocole smart port.

dev.fred a écrit:Ç'est tout bon.

Quelqu'un sais comment utiliser la sortie d'un custom mixer script comme ci dessus dans un script de télémétrie ?J'ai essayé sans succès : getvalue("Vcel") ou getvalue("LUA1a")

G

Tu m'as déjà écrit que tu n'aimais pas utiliser les VGx à cause des phases de vol (d’ailleurs je n'ai pas capté pourquoi car on peut renseigner tous les VGx).
Mais est-ce qu'au moins, le passage de paramètre est fonctionnel car la fonction model.setGlobalVariable(gvar, flightmode, value) a dû être écrite pour faire ça. Et vu le nom, on est sûr que c'est une variable à portée maximale.

J'ai fait comme cela pour l'instant, mais le grand danger de procéder comme ca, c'est qu'il faut que dans aucun des modèle la combinaison gvar/flighmode ne soit utilisée, c'est la qu'est le risque principal

G

Je vois,
dommage qu'il n'y ait pas des VG réservés aux scripts (encore un ER en perspective)!

dev.fred a écrit:Je vois,
dommage qu'il n'y ait pas des VG réservés aux scripts (encore un ER en perspective)!

Ce que tu dis est tout à fait pertinent. Les variables globales sont conservée dans l'eeprom tout comme la position des trims et les changer constamment ce n'est pas l'idéal, alors avoir un jeu de variables temporaires, ça serait une excellente idée.

Heu à moins que ça ait changé récemment n'importe quelle variable déclarée globale dans un script est accessible à l'environnement lua entier... donc du coup aussi par d'autres scripts qui tournent en même temps.

Donc il me semble que tu n'as même pas besoin de passer par OpenTX pour transmettre la valeur.

Vue du coté des script tout va bien mais Gandalf, si j'ai bien compris, indique qu'il y a un conflit potentiel car depuis l'écran compagnon on peut utiliser les VG sans savoir qu'un script est susceptible d'en modifier la valeur. Mais bon en même temps un utilisateur qui utilise des scripts est censé savoir ça mais le risque existe.

Oui mais si ce que j'ai dit est correct il n'a pas besoin d'utiliser de GVAR et le problème est réglé!
Je parle de "variable déclarée globalement" dans le script lua évidemment.

Si on ne précise pas local, une variable d'un script LUA est global ?

Si elle est déclarée en dehors de toute fonction oui