[Résolu] virtualWire et TX/RX 433MHz

Bonjour à tous,

J'ai dans un tiroir un Tx/Rx en 433MHz que je suis en train d'essayer.
http://www.belectronique.fr/modules/82-emetteur-recepteur-433mhz-rf.html

Je suis confronté à un souci à la réception des trames qui, au bout d'un moment, sont tronquées sans avoir d'explications :

Voici quelques exemples :

RX : 143 : //20:30:47/045081708N005494029E044580_ good : 199
RX : 144 : //20:30:48/045081708N005494027E044540_ good : 200
RX : 145 : //20:30:54/045081708N005494027E044420_ good : 202
RX : 146 : //20:30:59/045081708N005494029E044280_ good : 204
RX : 147 : //20:31:00/045081708N005494029E044250_ good : 205
RX : 148 : //20:31:06/045081708N005494031E044170_ good : 206
RX : 149 : //20:31:11/045081708N005494032E044060_ good : 208
RX : 150 : //20:31:12/045081708N005494035E044040_ good : 209
RX : 151 : //20:31:18/045081708N005494038E044040_ good : 211
RX : 152 : //20:31:20/045081708N005494038E044040_ good : 212
RX : 153 : //20:31:23/045081708N005494041E044080_ good : 213
RX : 154 : //20:31:24/045081708N005494043E044110_ good : 214
RX : 155 : //20:31:30/04_ good : 217
RX : 156 : //20:31:32/04_ good : 218
RX : 157 : //20:31:35/04_ good : 219
RX : 158 : //20:31:40/04_ good : 221
RX : 159 : //20:31:44/04_ good : 223
RX : 160 : //20:31:47/04_ good : 224
RX : 161 : //20:31:52/04_ good : 225
RX : 162 : //20:31:54/04_ good : 226
RX : 163 : //20:31:59/04_ good : 228
RX : 164 : //20:32:00/04_ good : 229
RX : 165 : //20:32:03/04_ good : 230
RX : 166 : //20:32:06/04_ good : 231
RX : 167 : //20:32:11/04_ good : 233
RX : 168 : //20:32:12/04_ good : 234
Tuto VirtualWire
Taille max du tableau : 80
RX : 0 : //20:43:50/045081720N005494071E043640_ buflen : 37_ good : 2
RX : 1 : //20:43:55/045081712N005494073E043640_ buflen : 37_ good : 4
RX : 2 : //20:43:56/045081712N005494073E043640_ buflen : 37_ good : 5
RX : 3 : //20:44:02/045081712N005494073E043640_ buflen : 37_ good : 7
RX : 4 : //20:44:04/045081712N005494073E043640_ buflen : 37_ good : 8
RX : 5 : //20:44:07/045081712N005494073E043640_ buflen : 37_ good : 9
RX : 6 : //20:44:08/045081712N005494073E043640_ buflen : 37_ good : 10
RX : 7 : //20:44:14/045081712N005494073E043640_ buflen : 37_ good : 12
RX : 8 : //20:44:16/045081712N005494073E043640_ buflen : 37_ good : 13
RX : 9 : //20:44:18/045081712N005494073E043640_ buflen : 37_ good : 14
RX : 10 : //20:44:20/045081712N005494073E043640_ buflen : 37_ good : 15
RX : 11 : //20:44:26/045081712N005494073E043640_ buflen : 37_ good : 17
RX : 12 : //20:44:28/045081712N005494073E043640_ buflen : 37_ good : 18
RX : 13 : //20:44:32/045081712N005494073E043640_ buflen : 37_ good : 19
RX : 14 : //20:44:38/045081712N005494073E043640_ buflen : 37_ good : 21
RX : 15 : //20:44:40/045081712N005494073E043640_ buflen : 37_ good : 22
RX : 16 : //20:44:44/045081712N00549407_ buflen : 29_ good : 24
RX : 17 : //20:44:50/045081712N00549407_ buflen : 29_ good : 26
RX : 18 : //20:44:52/045081712N00549407_ buflen : 29_ good : 27
RX : 19 : //20:44:56/045081712N00549407_ buflen : 29_ good : 29
RX : 20 : //20:45:02/045081712N00549407_ buflen : 29_ good : 31
RX : 21 : //20:45:04/045081712N00549407_ buflen : 29_ good : 32
RX : 22 : //20:45:08/045081712N00549407_ buflen : 29_ good : 34
RX : 23 : //20:45:11/045081712N00549407_ buflen : 29_ good : 35
RX : 24 : //20:45:14/045081712N00549407_ buflen : 29_ good : 36
RX : 25 : //20:45:16/045081712N00549407_ buflen : 29_ good : 37
RX : 26 : //20:45:20/045081712N00549407_ buflen : 29_ good : 39
RX : 27 : //20:45:23/045081712N00549407_ buflen : 29_ good : 40
RX : 28 : //20:45:26/045081712N00549407_ buflen : 29_ good : 41

...
RX : 78 : //20:51:58/045081712N00549406_ buflen : 29_ good : 113
RX : 79 : //20:52:00/045081712N00549406_ buflen : 29_ good : 114
RX : 80 : //20:52:03/045081712N00549406_ buflen : 29_ good : 115
RX : 81 : //20:52:08/045081712N00549406_ buflen : 29_ good : 117
RX : 82 : //20:52:10/045081712N00549406_ buflen : 29_ good : 118
RX : 83 : //20:52:12/045081712N00549406_ buflen : 29_ good : 119
RX : 84 : //20:52:15/045081712N00549406_ buflen : 29_ good : 120
RX : 85 : //20:52:20/04_ buflen : 13_ good : 123
RX : 86 : //20:52:22/04_ buflen : 13_ good : 124
RX : 87 : //20:52:24/04_ buflen : 13_ good : 125
RX : 88 : //20:52:27/04_ buflen : 13_ good : 126
RX : 89 : //20:52:32/04_ buflen : 13_ good : 128
RX : 90 : //20:52:34/04_ buflen : 13_ good : 129
RX : 91 : //20:52:39/04_ buflen : 13_ good : 131
RX : 92 : //20:52:44/04_ buflen : 13_ good : 133
RX : 93 : //20:52:46/04_ buflen : 13_ good : 134
RX : 94 : //20:52:51/04_ buflen : 13_ good : 136
RX : 95 : //20:52:56/04_ buflen : 13_ good : 138
RX : 96 : //20:52:58/04_ buflen : 13_ good : 139
RX : 25 : //07:45:39/045081668N005494081E042270_ buflen : 37_ good : 38
RX : 26 : //07:45:44/045081664N005494082E042190_ buflen : 37_ good : 40
RX : 27 : //07:45:46/045081664N005494082E042110_ buflen : 37_ good : 41
RX : 28 : //07:45:48/045081664N005494082E042110_ buflen : 37_ good : 42
RX : 29 : //07:45:51/045081664N005494084E042080_ buflen : 37_ good : 43
RX : 30 : //07:45:56/045081664N005494085E042010_ buflen : 37_ good : 45
RX : 31 : //07:45:58/045081664N005494085E042000_ buflen : 37_ good : 46
_ INIT_Rx?... _
RX : 32 : //07:46:03/045081668N00549408_ buflen : 29_ good : 48
_ INIT_Rx?... _
_ INIT_Rx?... _
RX : 33 : //07:46:08/045081676N00549409_ buflen : 29_ good : 50
_ INIT_Rx?... _
RX : 34 : //07:46:10/045081676N00549409_ buflen : 29_ good : 51
_ INIT_Rx?... _
_ INIT_Rx?... _
RX : 35 : //07:46:15/045081680N00549409_ buflen : 29_ good : 53
_ INIT_Rx?... _
RX : 36 : //07:46:17/045081680N00549409_ buflen : 29_ good : 54
_ INIT_Rx?... _
RX : 37 : //07:46:20/045081680N00549409_ buflen : 29_ good : 55
_ INIT_Rx?... _
RX : 38 : //07:46:22/045081680N00549408_ buflen : 29_ good : 56
_ INIT_Rx?... _
_ INIT_Rx?... _
void loop() // Fonction loop()
{
    static int nbreRx = 0;
    // if (vw_wait_rx_max(20)) // Si un message est reçu dans les 200ms qui viennent
    if (vw_have_message())  // Returns true if an unread message is available
    {
        if (vw_get_message(buf, &buflen)) // On copie le message, qu'il soit corrompu ou non
        {
            Serial.print("RX : "); Serial.print(nbreRx++); Serial.print(" : ");
            for (byte i = 0; i < buflen; i++) // Si il n'est pas corrompu on l'affiche via Serial
                Serial.print((char) buf[i]);
            Serial.print("_ buflen : "); Serial.print(buflen);
            Serial.print("_ good : "); Serial.println(vw_get_rx_good());
        }
        if (buflen != 37) {   // 37 est la longueur d'une trame 'normale'
          Serial.println("_ INIT_Rx?... _"); 
          vw_rx_stop();
          delay(2000);
          vw_rx_start();
        }
    }
}

Le problème arrive au bout d'un certain temps (voire d'un temps certain) qui me semble aléatoire.

J'ai vérifié ce qui est envoyé par le Tx : tout me semble cohérent : les trames sont bien complètes.
Lorsque je redémarre le moniteur tout remprend normalement, ce qui me fait dire que le problème vient du Rx.

Je constate que la longueur de trame se réduit d'un seul coup!
J'ai essayé de réinitialiser la transmission en cours de programme mais je ne suis pas sur que cela se fasse comme cela.

Les plus curieux auront reconnus des données GPS dans la trame transmise et pourront en déduire mon lieu d'habitation.
Le plus perspicasses pourront penser que le GPS m'envoi des données toutes pourries mais ça fera l'objet d'un autre sujet :D.

Vos idées sur les trames tronquées sont les biens venues.
Olivier

Ca sent le problème de dimensionnement de variable, il faudrait le code complet

Le code ressemble fortement à ce qui se trouve ici :

avec quelques modifications mineures pour essayer de corriger le problème

#include <VirtualWire.h> // inclusion de la librairie VirtualWire
 
uint8_t buf[VW_MAX_MESSAGE_LEN]; // Tableau qui va contenir le message reçu (de taille maximum VW_MAX_MESSAGE_LEN)
uint8_t buflen = VW_MAX_MESSAGE_LEN; // Taille maximum de notre tableau
 
void setup() // Fonction setup()
{
    Serial.begin(9600); // Initialisation du port série pour avoir un retour sur le serial monitor
    Serial.println("Tuto VirtualWire"); // Petit message de bienvenue
 
    vw_setup(2000); // initialisation de la librairie VirtualWire à 2000 bauds (note: je n'utilise pas la broche PTT)
    vw_rx_start();  // Activation de la partie réception de la librairie VirtualWire

    Serial.print("Taille max du tableau : "); Serial.println(VW_MAX_MESSAGE_LEN);
}
 
void loop() // Fonction loop()
{
    static int nbreRx = 0;
    // if (vw_wait_rx_max(20)) // Si un message est reçu dans les 200ms qui viennent
    if (vw_have_message())  // Returns true if an unread message is available
    {
        if (vw_get_message(buf, &buflen)) // On copie le message, qu'il soit corrompu ou non
        {
            Serial.print("RX : "); Serial.print(nbreRx++); Serial.print(" : ");
            for (byte i = 0; i < buflen; i++) // Si il n'est pas corrompu on l'affiche via Serial
                Serial.print((char) buf[i]);
            Serial.print("_ buflen : "); Serial.print(buflen);
            Serial.print("_ good : "); Serial.println(vw_get_rx_good());
        }
        if (buflen != 37) {
          Serial.println("_ INIT_Rx?... _"); 
          vw_rx_stop();
          delay(2000);
          vw_rx_start();
        }
    }
}

La je vois rien de suspect ...

Bonjour,

A tout hazard, je vous mets le code de la partie emmission, mais il y a que des modifications mineures par rapport aux exemples fournis pour le GPS : ajout de Virtualwire.

// Test code for Adafruit GPS modules using MTK3329/MTK3339 driver
//
// This code shows how to listen to the GPS module in an interrupt
// which allows the program to have more 'freedom' - just parse
// when a new NMEA sentence is available! Then access data when
// desired.
//
// Tested and works great with the Adafruit Ultimate GPS module
// using MTK33x9 chipset
//    ------> http://www.adafruit.com/products/746
// Pick one up today at the Adafruit electronics shop 
// and help support open source hardware & software! -ada

#include <VirtualWire.h> // inclusion de la librairie VirtualWire

#include <Adafruit_GPS.h>
#include <SoftwareSerial.h>

// If you're using a GPS module:
// Connect the GPS Power pin to 5V
// Connect the GPS Ground pin to ground
// If using software serial (sketch example default):
//   Connect the GPS TX (transmit) pin to Digital 3
//   Connect the GPS RX (receive) pin to Digital 2
// If using hardware serial (e.g. Arduino Mega):
//   Connect the GPS TX (transmit) pin to Arduino RX1, RX2 or RX3
//   Connect the GPS RX (receive) pin to matching TX1, TX2 or TX3

// If you're using the Adafruit GPS shield, change 
// SoftwareSerial mySerial(3, 2); -> SoftwareSerial mySerial(8, 7);
// and make sure the switch is set to SoftSerial

// If using software serial, keep these lines enabled
// (you can change the pin numbers to match your wiring):
SoftwareSerial mySerial(3, 2);

Adafruit_GPS GPS(&mySerial);
// If using hardware serial (e.g. Arduino Mega), comment
// out the above six lines and enable this line instead:
//Adafruit_GPS GPS(&Serial1);


// Set GPSECHO to 'false' to turn off echoing the GPS data to the Serial console
// Set to 'true' if you want to debug and listen to the raw GPS sentences. 
#define GPSECHO  false

#define LED 13

// this keeps track of whether we're using the interrupt
// off by default!
boolean usingInterrupt = false;
void useInterrupt(boolean); // Func prototype keeps Arduino 0023 happy


void setup()  
{
    
  // connect at 115200 so we can read the GPS fast enough and echo without dropping chars
  // also spit it out
  Serial.begin(115200);
  Serial.println("Adafruit GPS library basic test!");

  // 9600 NMEA is the default baud rate for Adafruit MTK GPS's- some use 4800
  GPS.begin(9600);
  
  // uncomment this line to turn on RMC (recommended minimum) and GGA (fix data) including altitude
  GPS.sendCommand(PMTK_SET_NMEA_OUTPUT_RMCGGA);
  // uncomment this line to turn on only the "minimum recommended" data
  //GPS.sendCommand(PMTK_SET_NMEA_OUTPUT_RMCONLY);
  // For parsing data, we don't suggest using anything but either RMC only or RMC+GGA since
  // the parser doesn't care about other sentences at this time
  
  // Set the update rate
  GPS.sendCommand(PMTK_SET_NMEA_UPDATE_1HZ);   // 1 Hz update rate
  // For the parsing code to work nicely and have time to sort thru the data, and
  // print it out we don't suggest using anything higher than 1 Hz

  // Request updates on antenna status, comment out to keep quiet
  GPS.sendCommand(PGCMD_ANTENNA);

  // the nice thing about this code is you can have a timer0 interrupt go off
  // every 1 millisecond, and read data from the GPS for you. that makes the
  // loop code a heck of a lot easier!
  useInterrupt(true);

  // Indicateur GPX Fix
  pinMode(LED, OUTPUT);

  vw_setup(2000);     // initialisation de la librairie VirtualWire à 2000 bauds (note: je n'utilise pas la broche PTT)


  delay(1000);
  // Ask for firmware version
  mySerial.println(PMTK_Q_RELEASE);
}


// Interrupt is called once a millisecond, looks for any new GPS data, and stores it
SIGNAL(TIMER0_COMPA_vect) {
  char c = GPS.read();
  // if you want to debug, this is a good time to do it!
#ifdef UDR0
  if (GPSECHO)
    if (c) UDR0 = c;  
    // writing direct to UDR0 is much much faster than Serial.print 
    // but only one character can be written at a time. 
#endif
}

void useInterrupt(boolean v) {
  if (v) {
    // Timer0 is already used for millis() - we'll just interrupt somewhere
    // in the middle and call the "Compare A" function above
    OCR0A = 0xAF;
    TIMSK0 |= _BV(OCIE0A);
    usingInterrupt = true;
  } else {
    // do not call the interrupt function COMPA anymore
    TIMSK0 &= ~_BV(OCIE0A);
    usingInterrupt = false;
  }
}

uint32_t timer = millis();
void loop()                     // run over and over again
{
  // in case you are not using the interrupt above, you'll
  // need to 'hand query' the GPS, not suggested :(
  if (! usingInterrupt) {
    // read data from the GPS in the 'main loop'
    char c = GPS.read();
    // if you want to debug, this is a good time to do it!
    if (GPSECHO)
      if (c) Serial.print(c);
  }
  
  // if a sentence is received, we can check the checksum, parse it...
  if (GPS.newNMEAreceived()) {
    // a tricky thing here is if we print the NMEA sentence, or data
    // we end up not listening and catching other sentences! 
    // so be very wary if using OUTPUT_ALLDATA and trytng to print out data
    //Serial.println(GPS.lastNMEA());   // this also sets the newNMEAreceived() flag to false
  
    if (!GPS.parse(GPS.lastNMEA()))   // this also sets the newNMEAreceived() flag to false
      return;  // we can fail to parse a sentence in which case we should just wait for another
  }

  // if millis() or timer wraps around, we'll just reset it
  if (timer > millis())  timer = millis();

  // approximately every 2 seconds or so, print out the current stats
  if (millis() - timer > 2000) { 
    timer = millis(); // reset the timer
    
//    Serial.print("\nTime: ");
//    Serial.print(GPS.hour, DEC); Serial.print(':');
//    Serial.print(GPS.minute, DEC); Serial.print(':');
//    Serial.print(GPS.seconds, DEC); Serial.print('.');
//    Serial.println(GPS.milliseconds);
//    
//    Serial.print("Date: ");
//    Serial.print(GPS.day, DEC); Serial.print('/');
//    Serial.print(GPS.month, DEC); Serial.print("/20");
//    Serial.println(GPS.year, DEC);
//    
//    Serial.print("Fix: "); Serial.print((int)GPS.fix);
//    Serial.print(" quality: "); Serial.println((int)GPS.fixquality); 
    
    if (GPS.fix) {
      digitalWrite(LED, HIGH); 

//      Serial.print("Location: ");
//      Serial.print(GPS.latitude, 4); Serial.print(GPS.lat);
//      Serial.print(", "); 
//      Serial.print(GPS.longitude, 4); Serial.println(GPS.lon);
//      
//      Serial.print("Speed (knots): "); Serial.println(GPS.speed);
//      Serial.print("Angle: "); Serial.println(GPS.angle);
//      Serial.print("Altitude: "); Serial.println(GPS.altitude);
//      Serial.print("Satellites: "); Serial.println((int)GPS.satellites);
      
      char gps433[] = "//00:00:00/000000000x000000000x000000";
      myLtoA(GPS.hour, &gps433[3]);
      myLtoA(GPS.minute, &gps433[6]);
      myLtoA(GPS.seconds, &gps433[9]);
      myLtoA(GPS.latitude * 10000, &gps433[19]);
      gps433[20] = GPS.lat;
      myLtoA(GPS.longitude * 10000, &gps433[29]);
      gps433[30] = GPS.lon;
      myLtoA(GPS.altitude * 100, &gps433[36]);
      
      Serial.println(gps433);
      
      vw_send((uint8_t *)gps433, strlen(gps433)); // On envoie le message
      vw_wait_tx(); // On attend la fin de l'envoi
      
    }
  }
}


void myLtoA(long const n, char *s) {
  if ((n / 10) > 0) {
    myLtoA((long) n / 10, s - 1);
    *s = n%10 + '0';
  }
  else {
    *s = n + '0';
  }
}

Dans les essais effectués jusqu'à présent, la partie Tx était alimentée par une LIPO 3S (12v) + un régulateur 5v pour alimenté l'ARDUINO NANO et le GPS.
Ce matin j'ai fait l'essai avec le Tx alimenté en 5v via l'USB : c'est pire, aucune trame n'arrive à bon port!

Est-ce que cela veut dire que mon Tx est défectueux?
Vos idées/réflections sont les biens venues
Olivier

Bernardino:
Bonjour,

Dans les essais effectués jusqu'à présent, la partie Tx était alimentée par une LIPO 3S (12v) + un régulateur 5v pour alimenté l'ARDUINO NANO et le GPS.
Ce matin j'ai fait l'essai avec le Tx alimenté en 5v via l'USB : c'est pire, aucune trame n'arrive à bon port!

Est-ce que cela veut dire que mon Tx est défectueux?
Vos idées/réflections sont les biens venues
Olivier

bonjour
les emetteurs cheap de ce genre sont tres chatouilleux vu de l'alim en ce qui concerne la P de sortie.
tu a quelle distance pour tes tests entre E et R ?
ceci etant , si j'en crois tes "logs" , quand ça coince , ça coince toujours apres le meme nombre de byte reçus ?
tu reçois/decode toujours le meme debut de trame , c'est toujours à partir de la meme "position dans la trame"" que la reception foire ?

si c'est le cas je ne crois pas que ce soit du à un probleme d'alim, il devrait y avoir si c'etait le cas un caractere plus aleatoire du survenance du "defaut"

Les Tx/Rx sont à moins d'un mètre de distance.

ça merde de façon aléatoire, dans les logs fournies :

  • au bout de 154 trames dans la première log (soit 154*37 caractères)
  • au bout de 15 trames
  • au bout de 31 trames

La trame fait 37 caractères, ça se réduit à 29 caractères puis à 13 caractères reçu en général.

Bernardino:
...
La trame fait 37 caractères, ça se réduit à 29 caractères puis à 13 caractères reçu en général.

Ok
quand ça commence à "merder"
tu recupere quand meme 29 infos OK puis ensuite 13 OK et ce pour des lots de trames successives ?

37 OK pendant X trames
29 OK " Y "
13 OK " Z "

suggestion :ça donne quoi si tu envoi au meme rythme une trame prealablement reçue OK
en emission forgée ?

Le Tx envoie toutes les 2 secondes une trame GPS, toutes les trames ont le même format :
//20:31:20/045081708N005494038E044040
//HH:MM:SS/Longitude(sur 9 num + 1 car)Latitude(sur 9 num + 1 car)Altitude (sur 6 num)

Le Rx reçoit ce qu'il peut...

Bernardino:
Le Tx envoie toutes les 2 secondes une trame GPS, toutes les trames ont le même format :
//20:31:20/045081708N005494038E044040
//HH:MM:SS/Longitude(sur 9 num + 1 car)Latitude(sur 9 num + 1 car)Altitude (sur 6 num)

Le Rx reçoit ce qu'il peut...

meme format peut etre , mais pas necessairement meme contenu :grin:

RX : 153 : //20:31:23/045081708N005494041E044080_ good : 213
RX : 154 : //20:31:24/045081708N005494043E044110_ good : 214

c'est juste un test pour levée de doute
ça donne quoi si tu envoi toutes les 2" une trame forgée prealablement reçue OK

C'est peut être un brouillage par un autre émetteur sur la fréquence 433

Voilà le test effectué :

J'ai modifé le Tx pour envoyer en boucle une trame qui était reçue correctement :
"//20:31:23/045081708N005494041E044080"
pour voir si le Rx reçoit toujours correctement cette trame.
Bilan : j'ai attendu un bon moment et pas de problème.

J'ai ensuite identifié une trame qui pouvait poser problème :
"//14:54:03/045081752N005494079E045290"
De la même manière, je l'ai envoyé en boucle.
Bilan : elle ne passe pas dès le premier envoi!
Voilà ce qui est reçu :
RX : 502 : //14:54:03/045081752N00549407_ buflen : 29_ good : 196

Alors quel est la différence entre ces 2 trames :
"//20:31:23/045081708N005494041E044080" OK
"//14:54:03/045081752N005494079E045290" KO

Pour quelle raison la deuxième provoque une erreur?...

Bernardino:
Voilà le test effectué :

J'ai modifé le Tx pour envoyer en boucle une trame qui était reçue correctement :
"//20:31:23/045081708N005494041E044080"
pour voir si le Rx reçoit toujours correctement cette trame.
Bilan : j'ai attendu un bon moment et pas de problème.

J'ai ensuite identifié une trame qui pouvait poser problème :
"//14:54:03/045081752N005494079E045290"
De la même manière, je l'ai envoyé en boucle.
Bilan : elle ne passe pas dès le premier envoi!
Voilà ce qui est reçu :
RX : 502 : //14:54:03/045081752N00549407_ buflen : 29_ good : 196

Alors quel est la différence entre ces 2 trames :
"//20:31:23/045081708N005494041E044080" OK
"//14:54:03/045081752N005494079E045290" KO

Pour quelle raison la deuxième provoque une erreur?...

C'est déjà une bonne avançée
à voir si le motif d'envoi des caracteres en fin de trame ne correpond pas à une detection erronnée de preambule qui met le recepteur dans les choux. (motif binaire fantome)

à suivre plus tard pour moi

Les choses ne semblent pas aussi simple que des trames bonnes ou mauvaises.

J'ai fait le test suivant, j'ai envoyé des trames OK avec de temps en temps une trame KO :

Trames envoyées :
//20:31:23/045081708N005494041E044080
//20:31:23/045081708N005494041E044080
//20:31:23/045081708N005494041E044080
//14:54:03/045081752N005494079E045290
//20:31:23/045081708N005494041E044080
//20:31:23/045081708N005494041E044080
//20:31:23/045081708N005494041E044080

Voilà ce qui est reçu :
RX : 135 : //20:31:23/045081708N005494041E044080_ buflen : 37_ good : 195
RX : 136 : //20:31:23/045081708N005494041E044080_ buflen : 37_ good : 196
RX : 137 : //20:31:23/045081708N005494041E044080_ buflen : 37_ good : 198
RX : 138 : //14:54:03/045081752N005494079E045290_ buflen : 37_ good : 199
RX : 139 : //20:31:23/045081708N005494041E044080_ buflen : 37_ good : 200
RX : 140 : //20:31:23/045081708N005494041E044080_ buflen : 37_ good : 201
RX : 141 : //20:31:23/045081708N005494041E044080_ buflen : 37_ good : 203

Parce qu'apparamment même des trames identifiées comme KO peuvent être reçues correctement :

Trames envoyées :
//14:54:03/045081752N005494079E045290
//14:54:03/045081752N005494079E045290
//14:54:03/045081752N005494079E045290
//14:54:03/045081752N005494079E045290
//14:54:03/045081752N005494079E045290
//14:54:03/045081752N005494079E045290

Voilà ce qui est reçu :
RX : 237 : //14:54:03/045081752N005494079E045290_ buflen : 37_ good : 73
RX : 238 : //14:54:03/045081752N005494079E045290_ buflen : 37_ good : 75
RX : 239 : //14:54:03/045081752N005494079E045290_ buflen : 37_ good : 76
RX : 240 : //14:54:03/045081752N00549407_ buflen : 29_ good : 78
RX : 241 : //14:54:03/045081752N00549407_ buflen : 29_ good : 80
RX : 242 : //14:54:03/045081752N00549407_ buflen : 29_ good : 81

Bernardino:
Les choses ne semblent pas aussi simple que des trames bonnes ou mauvaises.

J'ai fait le test suivant, j'ai envoyé des trames OK avec de temps en temps une trame KO :

OK
si je je resume
avec certaines trames ça ne coince à prori jamais ?
avec certaines trames ça peut passer , mais si ça coince , le systeme ne se recupere pas , meme en cas d'envoi de trames validée derriere OK ?
tu a quelle version de VW (à priori la derniere est 1.20)

ça donne quoi en modifiant/diminuant le parametre : vw_setup(2000)

Bon résumé.
La version VW est bien la 1.20

En jouant sur la vitesse de transmission :

  • à 1000 : même problème
  • à 3000 : sa semble meilleur. J'ai fait l'essai avec les trames GPS réel mais au bout de 5 minutes, les trames sont tronquées!

Bonjour,

Déplace cette ligne :

uint8_t buflen = VW_MAX_MESSAGE_LEN; // Taille maximum de notre tableau

dans loop() directement.

Si ça marche fait le moi avoir, je pense avoir déniché un jolie petit bug bien vicelard dans mon code de tuto.
Indice : que vaut buflen à la prochaine réception si (buflen != 37) retourne faux à la réception précédente ?

Bonjour,

J'ai fait le test cet après midi en mettant la taille maximum du tableau directement dans loop() .
Verdict : je n'ai pas eu de problème. Quasiment 1H de test sans problème de réception.

--> Modification validée.

Question subsidiaire :
La méthode vw_get_rx_good() donne le nombre de trames bonnes reçues.

RX : 237 : //14:54:03/045081752N005494079E045290_ buflen : 37_ good : 73
RX : 238 : //14:54:03/045081752N005494079E045290_ buflen : 37_ good : 75
RX : 239 : //14:54:03/045081752N005494079E045290_ buflen : 37_ good : 76
RX : 240 : //14:54:03/045081752N005494079E045290_ buflen : 29_ good : 78
RX : 241 : //14:54:03/045081752N005494079E045290_ buflen : 29_ good : 80
RX : 242 : //14:54:03/045081752N005494079E045290_ buflen : 29_ good : 81

Le programme de réception en laisse passer environ 30%.
En passant vw_setup(3000); à 3000bps, ça améliore les choses mais il y a environ 20% de trames qui passent à la trappe!

Est-ce qu'il y a une solution?

Bernardino:
J'ai fait le test cet après midi en mettant la taille maximum du tableau directement dans loop() .
Verdict : je n'ai pas eu de problème. Quasiment 1H de test sans problème de réception.

J'en était sûr ... J'ai modifié mon tuto en conséquence.

Bernardino:
Est-ce qu'il y a une solution?

Trouver un meilleur émetteur moins sensible au bruit, ou un sur une fréquence moins parasitée.

skywodd:

Bernardino:
Est-ce qu'il y a une solution?

Trouver un meilleur émetteur moins sensible au bruit, ou un sur une fréquence moins parasitée.

:grin:
Plutot un recepteur ? non ? :grin: