Décodage SPORT depuis la sortie Module Externe

Toujours sur la base d'un Teensy 3.1

L'idée finale ( celle de Nicephore) était de récuperer les données de télémetrie pour actionner au sol une antenne pour suivre le modèle

sur la sortie module, on alimente et récupere les données de télémetrie

module -- > Teensy 3.1 --> mini tx 433

un peut plus loin

mini recepteur 433 -- Arduino --> servo pour orienté les antennes

Cette première partie ne traite que la récupération des données sur la radio

voici une ébauche de code qui permet la récupération des données  et qui peut servir a plein d'autres choses.

Code:


#define SPORT Serial1
#define SPORTEvent serialEvent1

int led = 13;
int buf[25];
int voie[18];
int memread;
int cpt;
int ser;



void setup() {
  pinMode(led, OUTPUT); // led de controle utiliser sur une réception SPORT
  SPORT.begin(57600, SERIAL_8N1_RXINV_TXINV); // activation de la liaison SPORT
  Serial.begin(115200); // activation de la sortie serie pour le debug
  cpt = 0 ;
  memread = 255;
}

void loop() { 
    delay(20); // un petit delay a ajuster selon ce que l'on fait dans la boucle principale
}

void SPORTEvent() {  // reception de donnée sur la ligne SPORT
digitalWrite(led, HIGH); // on alume la led :)

  while ( SPORT.available() ) { // tant qu'un octet arrive sur le SPORT
    int val = SPORT.read();
    if ( val == 0x7E ) {
     
            if (cpt > 2){
                  int id = buf[3] + (buf[4] *256);
                  Serial.print(cpt,DEC);
                  Serial.print("id:");
                  if ( id == 0x100 ){Serial.print("ALTITUDE ");}
                  if ( id == 0x110 ){Serial.print("VARIO    ");}
                  if ( id == 0x200 ){Serial.print("COURRANT ");}
                  if ( id == 0x300 ){Serial.print("TENSIONS ");}
                  if ( id == 0x400 ){Serial.print("TEMP1    ");}
                  if ( id == 0x410 ){Serial.print("TEMP2    ");}               
                  if ( id == 0x500 ){Serial.print("RMP      ");}
                  if ( id == 0x800 ){Serial.print("LAT-LON  ");}

                  if ( id == 0x820 ){Serial.print("GPS-ALT  ");}
                  if ( id == 0x830 ){Serial.print("GPS-SPEED");}
                  if ( id == 0x840 ){Serial.print("HEADING  ");}                 
                  if ( id == 0xF101){Serial.print("RSSI    ");}
                  if ( id == 0xF104){Serial.print("BAT-RADIO");}
                  if ( id == 0xF105){Serial.print("SWR      ");}
                                 
                 
                  Serial.print(",");
                  Serial.print(id,HEX);
                  Serial.print("    ");
                  for(int x = 5; x < cpt ; x++ ){
                    Serial.print(buf[x],HEX);
                    Serial.print(",");
                   
                  }
                  Serial.println();
             
            }
      cpt = 0;
    }
    if ( memread == 0x7D){
      buf[cpt] = val ^ 0x20 ;
      cpt += 1 ;
    }else if ( val != 0x7D ){
      buf[cpt] = val;
      cpt += 1 ;
    }
    memread = val;

  } // fin du while
 
  digitalWrite(led, LOW); //on eteind la led
}






En l'état avec les sondes suivantes :

Module tension,RMP temp 1 et 2, courrant, vario précision, gps

La lecture sur un terminal donne :



les connexions sont
RADIO ---> TEENSY

GND    ---> GND
SPORT ---> 0 RX1






A suivre Bonne lecture

Intéressant tout ça.

N'oublie pas le bytestuffing lorsque tu rencontres le caractère 0x7D dans le flux de donnée.

Par ailleurs, est-ce que tu rencontres des séquences 0x7E Sensor-Id ou seulement des séquences 0x7E 0x10 Data_Id ... crc

Dernière question, combien de Teensy as-tu ?

Yes pas pensé au bytestuffing je vais vérifier ca

en fait j'ai filtré un peut l'affichage mais il y a des 0x10 et des valeur derriere les 0x7E !

pour les teensy le stock baisse j'ai vu que lextronic en avait et nicephore doit en recommander on va se débrouiller a partir de 6 le port est gratuit normalement !

Je comprend pas bien de qu'ils font ....


3.1. Host end
 11 bytes frame started and ended with 0x7E, with byte stuff.
 Byte stuffing method:
Output
Byte in frame has value 0x7E is changed into 2 bytes: 0x7D 0x5E
Byte in frame has value 0x7D is changed into 2 bytes: 0x7D 0x5D
Input:
When byte 0x7D is received, discard this byte, and the next byte is XORed with 0x20;

Si j'ai bien compris, il faut juste faire un truc du genre.

Code:


    if (last_val == 0x7D) {
        buf[cpt] = val ^ 0x20;
        cpt += 1 ;
    } else if (val != 0x7D) {
        buf[cpt] = val;
        cpt += 1 ;    
   }
   last_val = val;



Ok merci entre temps j'ai trouvé ça dans open TX frsky_sport.cpp, je vais donc faire la correction. Merci de ton aide et de tes yeux vigilants

Code:


// Receive buffer state machine state enum
enum FrSkyDataState {
  STATE_DATA_IDLE,
  STATE_DATA_IN_FRAME,
  STATE_DATA_XOR,
};

void processSerialData(uint8_t data)
{
  static uint8_t numPktBytes = 0;
  static uint8_t dataState = STATE_DATA_IDLE;


  if (data == START_STOP) {
    dataState = STATE_DATA_IN_FRAME;
    numPktBytes = 0;
  }
  else {
    switch (dataState) {
      case STATE_DATA_XOR:
        frskyRxBuffer[numPktBytes++] = data ^ STUFF_MASK;
        dataState = STATE_DATA_IN_FRAME;
        break;

      case STATE_DATA_IN_FRAME:
        if (data == BYTESTUFF)
          dataState = STATE_DATA_XOR; // XOR next byte
        else
          frskyRxBuffer[numPktBytes++] = data;
        break;
    }
  }

  if (numPktBytes == FRSKY_RX_PACKET_SIZE) {
    processSportPacket(frskyRxBuffer);
    dataState = STATE_DATA_IDLE;
  }
}

Si je comprends bien une frame est de ce type:


et si nous avons HEAD = 0x7E PRIM = 0xFE ou 0xFD nous sommes en présence d'une frame qui doit également se terminer par 0x7E Afin de récupérer de façon certaine une frame pourquoi ne pas faire un double test par exemple:

7E FD 3 11 1 2 3 4E E F 7E
7E FD 5 12 4D A B C D 13 7E

byte  Temp = Serial.read()
if ((Temp = 0xFE) and (Temp_old = 0x7E)) then
*/
traiter les données
*/
Temp_old = Temp

Mais PRIM est-il toujours = 0xFE a moins que ce ne soit 0xFD (la chose n'est pas simple) ?
D'après ce que j'ai pu lire oui mais ceci reste à vérifier.

Sylvain SVP tu nous postes des lignes brute de fonderie.

Un truc qui serait bien, c'est de te créer une librairie qui fait aussi bien la lecture que l'écriture sur le S.Port comme ça, tu la mets bien au point et tu peux la réutiliser à ta guise.

c'est une bonne idée

@Sacre100 Avec nicephore on va recommandé des teensy 3.1 dit nous si tu en a besoin

on fait un commande groupé ça evite les frais de port !


Correction du BYTESTUFF faite dans le code du 1er Post

Sylvain
Prévoir aussi des CAN

djsyl a écrit:...
@Sacre100 Avec nicephore on va recommandé des teensy 3.1 dit nous si tu en a besoin
...

C'est gentil de me le proposer mais je doute que ça vaille la peine avec les frais de ré-expédition pour la Suisse.

Et puis j'ai assez de chenit (désordre) chez moi avec plusieurs cartes qui traînent dans les tiroirs.

Vous les commandez où vos Teensy car 4a ne court pas les rues ?

Sacre
Ici: http://snootlab.com/pjrc-teensy/517-teensy-31-usb-fr.html

A partir de 6 les frais de port sont offert.
Après, moi je connais pas trop la suisse, tu m'invite pour un weekend et je te livre.

@SYLVAIN tu fait le voyage avec moi ?

Merci pour l'adresse d'autant plus que les frais de port pour la Suisse sont très raisonnables chez eux.

Et puis avec l'Euro qui a baissé ces derniers temps de 20% face au Fr. Suisse, ça vaut vraiment la peine.

De mon coté j'attaque la partie émission / réception des données via modules 433 Mhz.

Liste du matériel:
1 x Kit RF433

1 x Arduino Nano (pour la station de base)

1 x Teensy 3.1 (coté émission des données)

Nacelle Pan / Tilt

Librairie:
VirtualWire

=====================
Montage coté émission:


D'après la doc alimenter le module RF433 en 5 volts nous donnera une portée de 40m en indoor et 100 en extérieur pour une consommation de 25mA.

Montage coté réception:

=====================

Code partie émission:

Code:

#include <VirtualWire.h>

void setup()
{
    vw_setup(2000);              
    vw_set_tx_pin(3);              }

void loop()
{
   const char *msg = "$PAK;LONGITUDE;LATITUDE;ALTITUDE;CHKSUM";     // ou "$PAK;PAN;TILT;CHKSUM"             
   vw_send((uint8_t *)msg, strlen(msg));
   vw_wait_tx();                                        
   delay(200);                                              
}


Code partie réception:

Code:

#include <VirtualWire.h>

void setup()
{
    Serial.begin(9600);    
    vw_setup(2000);                
    vw_set_rx_pin(11);            
    vw_rx_start();              
}

void loop()
{
    uint8_t buf[VW_MAX_MESSAGE_LEN];
    uint8_t buflen = VW_MAX_MESSAGE_LEN;

    if (vw_get_message(buf, &buflen)){
     int i;
 
     for (i = 0; i < buflen; i++){
        Serial.write(buf[i]);  
      }
      Serial.println("");
    }
}


Pour le moment ces codes ne s'occupent que d'envoyer / recevoir une phrase, le reste a faire est :

1°) Récupération des données GPS
2°)
  Option 1: constituer la phase
  Option 2: faire les calcules de PAN et TILT et les envoyer
3°) Récupération et parsing de la phrase
4°) Vérifier le check sum
5°)
  Option 1: calculer les position PAN et TILT et positionner les servo
  Option 2: positionner les servo.

=====================

Ces codes seront à adapter car en discutant avec Sylvain, le mieux serait de faire les calcules de PAN et TILT coté émission (là y-a une teensy qui pédale plus fort qu'une Arduino).
Coté réception L'Arduino n'aura qu'a utiliser la librairie servo afin de les positionnés.

Dans une premier temps il est possible d'imaginer le processus ainsi:
1°) Placer la station de base.
1.1°) Initialiser les servos à une position zéro pour le PAN et TILT (au GPS Fixe)
2°) Placer le modèle a coté de la station de base.
2.1°) Alimenter le modèle
3°) Attendre le GPS Fixe
4°) Placer le modèle sur son lieu de décollage (mais en restant en face de l'angle zéro du PAN)

* suggestion de Sylvain: disposer d'un magnéto ou d'un GPS dans la station d’accueil afin d'éviter de devoir a attendre le GPS Fixe avant de placer le modèle sur l'aire d'envol.

Bon maintenant je dois retourner en classe afin de revoir les fonctions de trigonométrique car franchement je devais être malade ce jour là

Après coté station de base il reste aussi possible d'avoir un PC et décoder les informations reçus afin de les afficher sur l'écran (position Google MAP, tension lipo, GPS Fixe, des alertes là aussi ...) (cf. sous Delphi voir l'objet comPort).

Si vous avez des suggestions ...

Juste une question (un peu pavé dans la mare) : Pourquoi ne faites vous pas ça tout bêtement en LUA ?

Sacre100 a écrit:Juste une question (un peu pavé dans la mare) : Pourquoi ne faites vous pas ça tout bêtement en LUA ?

Sacre,
mais non c'est pas un pavé dans la marre
oui j'avais y-a un certain temps posé la question. Mais donc comment le faire sans fil à la patte, de plus même si nous acceptons un fil à la patte (fil entre la Taranis et la station de base) est-il possible en LUA d'utiliser la sortie écolage et donc ainsi positionner les servo ?
Ou encore en LUA envoyer des données à la station de base, mais dans ce cas comment: un module externe et son récepteur en face ? (pourquoi pas)

nicephore a écrit:

Sacre100 a écrit:Juste une question (un peu pavé dans la mare) : Pourquoi ne faites vous pas ça tout bêtement en LUA ?

Sacre,
mais non c'est pas un pavé dans la marre  
oui j'avais y-a un certain temps posé la question. Mais donc comment le faire sans fil à la patte, de plus même si nous acceptons un fil à la patte (fil entre la Taranis et la station de base) est-il possible en LUA d'utiliser la sortie écolage et donc ainsi positionner les servo ?
Ou encore en LUA envoyer des données à la station de base, mais dans ce cas comment: un module externe et son récepteur en face ? (pourquoi pas)

En première idée, oui, un module externe et un récepteur.

D'un autre côté, un système indépendant tel que vous le faites, n'exige pas de programmation particulière de chaque modèle et peut être facilement prêté à un copain.

nicephore a écrit:...
est-il possible en LUA d'utiliser la sortie écolage et donc ainsi positionner les servo ?
...

Pour répondre à cette question, LUA ne permet pas d'écrire directement sur la prise écolage mais avec les "model script" tupeut calculer des valeurs qui peuvent être utilisées comme sources dans un mixage.

Autrement dit, le script calcule deux output (pan & tilt) qui sont repris comme source dans le mixage sur deux voies de ton choix.

Du reste, pour la mise au point des algorithmes, ça peut être pratique de les programmer et tester en LUA puis de les retranscrire en C pour l'Arduino.

attends je suis à l'école je fait de la trigo

nicephore a écrit:attends je suis à l'école je fait de la trigo

Jette un coup d'oeil sur mon délire d'horizon artificiel, tu as déjà quelques calculs qui peuvent t'intéresser (heading et distance) dans la fonction gpsCalculation() : https://frskytaranis.forumactif.org/t1291-arduimu-v3-gps-s-port

Autre réflexion, si vous faites un systèmes indépendant, c'est d'avoir un GPS sur la station de base. Il existe des GPS qui ont aussi un magnétomètre (une boussole), c'est l'idéal car vous obtiendrez non seulement la position de la station de base mais aussi son orientation et ça vous simplifiera grandement la vie.

Exemple de GPS avec magnétomètre : http://hobbyking.com/hobbyking/store/__64142__HKPilot_Micro_GPS_and_Compass_Module_U_BLOX_7_8g_.html

Y-a un prof de trigo ici ... voici ce que j'ai fait :

Code:

long getPAN_TILT(
  float homeLAT, // latitude station de base
  float homeLNG, // longitude station de base
  float quadLAT, // latitude du modele
  float quadLNG, // longitude du model
  float ALT,     // altitude du model - altitude de la station de base
  ) {
    
    earth_radius = 6371000; // rayon de la terre 6371kms
    
    homeLNG = homeLNG / 180 * PI;
    homeLAT = homeLAT / 180 * PI;
    quadLNG = quadLNG / 180 * PI;
    quadLAT = quadLAT / 180 * PI;

    // Calcul du PAN
    tmpPAN = atan2(sin(quadLNG - homeLNG)* cos(quadLAT), cos(homeLAT) * sin(quadLAT) - sin(homeLAT) * cos(quadLAT) * cos(quadLNG - homeLNG));
    PAN = tmpPAN * 180 / PI;
    if (PAN < 0)
      PAN = 360 + PAN;
  
    // Calcul de la distance
    dLAT = (quadLAT - homeLAT);
    dLNG = (quadLNG - homeLNG);
    a = sin(dLAT / 2) * sin(dLAT / 2) + sin(dLNG / 2) * sin(dLNG / 2) * cos(homeLAT) * cos(quadLAT);
    c = 2 * asin(sqrt(tmpPAN));
    d = earth_radius * c;

    // Calcul du TILT
    TILT = atan(ALT / d);
    TILT = TILT * 360 / (2 * PI);
    
    return PAN, TILT
    
  }// end getPAN_TILT

Ca me semble bon ... mais c'est tellement vieux tous ça, si une âme charitable pouvait vérifier.
Par avance merci.

Sacre100 a écrit:

Jette un coup d'oeil sur mon délire d'horizon artificiel, tu as déjà quelques calculs qui peuvent t'intéresser (heading et distance) dans la fonction gpsCalculation() : https://frskytaranis.forumactif.org/t1291-arduimu-v3-gps-s-port

merci je vais regarder.

Sacre100 a écrit:
Autre réflexion, si vous faites un systèmes indépendant, c'est d'avoir un GPS sur la station de base. Il existe des GPS qui ont aussi un magnétomètre (une boussole), c'est l'idéal car vous obtiendrez non seulement la position de la station de base mais aussi son orientation et ça vous simplifiera grandement la vie.

Exemple de GPS avec magnétomètre : http://hobbyking.com/hobbyking/store/__64142__HKPilot_Micro_GPS_and_Compass_Module_U_BLOX_7_8g_.html

Ok mais en fait si nous avons déjà les coordonnées GPS (dépose du modèle auprès de la station de base et attendre le fixe GPS) ça reviens au même car en fait la station de base ne bouge pas (a moins quelle ne soit portable et/ou attachée à la Taranis) ...
Réflexion:
  donner le choix à l'utilisateur via un DEFINE dans le code arduino de la station de base.

Mais idée effectivement a conserver car ce n'est jamais plus que 19 euros de +.

nicephore a écrit:...

Sacre100 a écrit:
Autre réflexion, si vous faites un systèmes indépendant, c'est d'avoir un GPS sur la station de base. Il existe des GPS qui ont aussi un magnétomètre (une boussole), c'est l'idéal car vous obtiendrez non seulement la position de la station de base mais aussi son orientation et ça vous simplifiera grandement la vie.

Exemple de GPS avec magnétomètre : http://hobbyking.com/hobbyking/store/__64142__HKPilot_Micro_GPS_and_Compass_Module_U_BLOX_7_8g_.html

Ok mais en fait si nous avons déjà les coordonnées GPS (dépose du modèle auprès de la station de base et attendre le fixe GPS) ça reviens au même car en fait la station de base ne bouge pas (a moins quelle ne soit portable et/ou attachée à la Taranis) ...
Réflexion:
  donner le choix à l'utilisateur via un DEFINE dans le code arduino de la station de base.

Mais idée effectivement a conserver car ce n'est jamais plus que 19 euros de +.

Oui pour la position mais non pour l'orientation.

La plupart des headtracker, tu dois les initialiser en posant ton engin à une certaine distance (30m) de ton antenne puis orienter ton antenne en direction de l'appareil. Lors de cette procédure d'initialisation, l'antenne repère bien sa position en utilisant celle de l'appareil mais elle ne repère pas automatiquement son orientation, c'est pourquoi tu dois le faire manuellement.

Avec un tel GPS, tu ne te poses plus de question. Tu poses ton antenne, t'allumes et quand les GPS ont fait leur fix et que le système s'est initialisé tout seul, tu lances, elle n'est pas belle la vie  

Sacre100,

Oui ce qui dans ma procédure:

Dans une premier temps il est possible d'imaginer le processus ainsi:
1°) Placer la station de base.
1.1°) Initialiser les servos à une position zéro pour le PAN et TILT (au GPS Fixe)
2°) Placer le modèle a coté de la station de base.
2.1°) Alimenter le modèle
3°) Attendre le GPS Fixe
4°) Placer le modèle sur son lieu de décollage (mais en restant en face de l'angle zéro du PAN)

Ce qui retire les points 1.1, 2 et 4 ...
Je conserve en mémoire.

Ce qui est sûr, c'est que ça va vous simplifier la vie.