analyse de trame de 27 octets

[medeloualidi]

Exactement t'as raison J-M-L  lorsque je passe à un débit élevé je trouve la bonne trame à chaque fois

255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144


c'est le code de kamill que j'ai utilisé

mais pour le cas de mon application je dois pas dépasser 4800 baud :/ est ce qu'il y a une solution ?

[medeloualidi]

oui exactement lorsque j'augmente le debit je trouve des bonne résultat !

par contre mois j'envoie 26 octets à un debit de 4800 bit/s ce qui donne le temps de transmission est de 26x8/4800 =43,33 ms .

à l'émission

Code: [Select]



Serial.write((unsigned byte)255);

  for (int i = 0; i < 25; i++)
  {

  Serial.write((unsigned byte)pac[i]);
 
  }



sinon si je veux transmettre pendant ces 43 ms les 26 octets chaque 100 ms qu'est ce qu'il faut ajouter à ce programme ?

[kamill]

255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144 trame correcte
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144 trame correcte
255 137 31 80 116 133 176 122 46 153 144 92 12 201 144 255 137 168 176 219 14 165 12 232 154 153 trame fausse
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 144 92 12 201 144 255 137 168 176 trame fausse
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144 trame correcte

Tu envoie toujours la même chose ?
Si c'est le cas, je pense que ce n'est pas un problème du programme de réception, mais plutot un problème de transmission (parasites, problème de niveau, problème de baudrate...)

C'est quoi l'émetteur?

[medeloualidi]

Tu envoie toujours la même chose ?
Si c'est le cas, je pense que ce n'est pas un problème du programme de réception, mais plutot un problème de transmission (parasites, problème de niveau, problème de baudrate...)

C'est quoi l'émetteur?

l'émetteur c'est un diode IR pilotée par une carte arduino et je ne dois pas dépasser 4800 baud sinon la diode va être grillée

[medeloualidi]

L'envoi d'un octet est toujours accompagné d'un bit de start et d'un bit de stop, ce qui fait 10 bits au total. Donc l'envoi de 26 octets prend au moins 10x26/4800 = 54,17 ms.

Le code que tu indiques mets les 26 octets dans le tampon. L'envoi de ces octets est ensuite réalisé pratiquement sans attente. La période d'envoi des trames de 100 ms ne dépend que du reste du programme.

Mais si la perte des octets persiste alors que les trames sont envoyées toutes les 100 ms, alors c'est à la réception que le problème doit être réglé.

pourquoi 10x26 .. t'as ajouté les 2 bits de RS232 c'est ça ?

[kamill]

Bonjour _pepe_,

Je n'ai pas très bien compris ce que tu veux dire, mais quand tu parles d'émission, je me dis que c'est peut être effectivement l'émission (pour affichage de vérification) qui perturbe la réception. En effet on envoie entre 2 et 4 fois plus d'octets qu'on en reçoit et peut être que le temps d'émission fait que le buffer de réception finit par saturer.

[J-M-L]

@medeloualidi

si vous enlevez les traces de debug - toute la partie qui imprime tous les code sur la console alors vous n'aurez sans doute plus de pb

à 4800 bauds vous envoyez 480 octets par seconde, comme vous voulez envoyez vos 27 octets 10 fois par seconde, ça veut dire que vous envoyez 270 octets par secondes et avez la capacité d'en lire 480. ça devrait tenir sans pb si le reste du code côté récepteur ne bloque pas trop longtemps (ce que vos print sur la console faisaient).

l'émetteur de vos 27 caractères va prendre disons 30ms en arrondissant puis va re-émettre 70ms plus tard (si le premier octet est envoyé toutes les 100ms).

Donc côté récepteur vous êtes bloqué pendant 50ms pour recevoir tous les octets et vous devez être prêt à recevoir de nouveaux octets 50ms plus tard. Donc en gros il faut que votre code côté récepteur gère tout ce qu'il doit faire en moins de 40ms après avoir reçu une trame par exemple comme ça vous avez 10ms d'avance pour attendre la trame suivante ce qui devrait être suffisant pour éviter tout pb.

la question est donc: que devez vous faire une fois que vous avez reçu cette trame et est-ce que c'est exécutable en 40ms?

[medeloualidi]

@medeloualidi

si vous enlevez les traces de debug - toute la partie qui imprime tous les code sur la console alors vous n'aurez sans doute plus de pb

à 4800 bauds vous envoyez 480 octets par seconde, comme vous voulez envoyez vos 27 octets 10 fois par seconde, ça veut dire que vous envoyez 270 octets par secondes et avez la capacité d'en lire 480. ça devrait tenir sans pb si le reste du code côté récepteur ne bloque pas trop longtemps (ce que vos print sur la console faisaient).

Envoyer l'émetteur de vos 27 caractères va prendre disons 30ms en arrondissant puis va re-emetter 70ms plus tard (si le premier octet est envoyé toutes les 100ms).

Donc côté récepteur vous êtes bloqué pendant 30ms pour recevoir tous les octets et vous devez être prêt à recevoir de nouveaux octets 70ms plus tard. Donc en gros il faut que votre code côté récepteur gère tout ce qu'il doit faire en moins de 50ms après avoir reçu une trame par exemple comme ça vous avez 20ms d'avance pour attendre la trame suivante ce qui devrait être suffisant pour éviter tout pb.

la question est donc: que devez vous faire une fois que vous avez reçu cette trame et est-ce que c'est exécutable en 50ms?

une fois je reçois cette trame (qui est codé avant l'émission ) je fait le décodage .. je ne sais pas combien du temps prendre  l'exécution du code de décodage ... peut etre je dois faire ça pour mesurer le temps de decodage

Code: [Select]


duration = micros();
decodage();
duration = micros() - duration;


[medeloualidi]

@ J-M-L

Merci pour votre aides les amis, apparemment oui c'est exécutable en moins de 50 ms

[J-M-L]

oui par exemple juste pour le debug - ça vous donnera une idée

vous pouvez utiliser milli() plutôt que micros(), pas besoin d'être précis à la microseconde près...

Code: [Select]

unsigned long duration;

....


duration = millis();
decodage();
duration = millis() - duration;
if (duration > 50) { // on a pris plus de 50ms
      Serial.print("Attention calcul trop long: ");
      Serial.print(duration);
      Serial.println(" ms"");
}


comme ça vous n'imprimez que si vous prenez plus de 50ms et sinon vous n'imprimez rien. bien sûr appeler millis() (soit 4 microsondes) deux fois faire une soustraction et un test prend un peu de temps en plus... mais pas trop juste quelque microsondes. ce qui serait pas bien c'est d'imprimer la duration à chaque fois

[J-M-L]

Petite correction effectivement à 4800 bauds il faut plutôt 50ms pour émettre les 27 octets donc il faut que votre code tourne en moins de 40ms pour avoir 10ms d'avance sur la prochaine trame. (en fait avoir 1ms d'avance serait suffisant, on joue la sécurité là avec 10ms)


donc changer les 50ms en 40ms ci dessus pour voir si vous êtes tranquille ou pas pour l'exécution de votre code

[medeloualidi]

ah! non haha il tourne en 47 ms si ma méthode de mesure est correcte.

[medeloualidi]

@ _pepe_ 

oui t'as raison , lorsque je fait un delay(200); à l'émission   je reçois la trame tel qu'elle est, par contre lorsque je fait un delay(150); je e reçois pas ce que je veux

En tout cas merci beaucoup pour vos réponses, j'ai bien compris le problème je vais penser à une autre solution pour coder mes donnée et réduire la taille de la trame à envoyer.

avez vous une idée sur le CRC-8 pour coder 5 nombre de type float ? (c'est mieux de créer un nouveau Topic :p)   

[J-M-L]

En tout cas merci beaucoup pour vos réponses, j'ai bien compris le problème je vais penser à une autre solution pour coder mes donnée et réduire la taille de la trame à envoyer.

la question est vraiment de savoir si vous avez besoin d'envoyer toutes les 90ms. c'est quoi comme émetteur (qu'est-ce que vous mesurez et est-ce que ça change si souvent que ça?)

Si une seule ou peu des 27 valeurs changent de temps en temps, il serait plus efficace d'envoyer une trame un peu plus compliquée mais qui aura l'avantage d'être plus rapide

vous envoyez FF
vous envoyez le nombre de valeur qui ont changé
Pour chaque valeur qui a changé vous envoyez sa position entre 0 et 25 puis la valeur

si vous avez 5 valeurs qui ont changé par exemple ça ne fait envoyer que

255 5 Pos1 Val1 Pos2 Val2 Pos3 Val3 Pos4 Val4 Pos5 Val5

soit 12 octets au lieu des 27

si plus de 12 valeurs on changé alors il vaut mieux renvoyer toute la trame

donc côté réception si le chiffre après 255 est 26 alors vous savez qu'il n'y a pas de positions et  que c'est toute la trame. (et c'est ce que vous faites lors de la première trame)

avez vous une idée sur le CRC-8 pour coder 5 nombre de type float ? (c'est mieux de créer un nouveau Topic :p)   

jetez un oeil ici

[medeloualidi]

la question est vraiment de savoir si vous avez besoin d'envoyer toutes les 90ms. c'est quoi comme émetteur (qu'est-ce que vous mesurez et est-ce que ça change si souvent que ça?)

Si une seule ou peu des 27 valeurs changent de temps en temps, il serait plus efficace d'envoyer une trame un peu plus compliquée mais qui aura l'avantage d'être plus rapide

vous envoyez FF
vous envoyez le nombre de valeur qui ont changé
Pour chaque valeur qui a changé vous envoyez sa position entre 0 et 25 puis la valeur

si vous avez 5 valeurs qui ont changé par exemple ça ne fait envoyer que

255 5 Pos1 Val1 Pos2 Val2 Pos3 Val3 Pos4 Val4 Pos5 Val5

soit 12 octets au lieu des 27

si plus de 12 valeurs on changé alors il vaut mieux renvoyer toute la trame

donc côté réception si le chiffre après 255 est 26 alors vous savez qu'il n'y a pas de positions et  que c'est toute la trame. (et c'est ce que vous faites lors de la première trame)

Bonjour J-M-L ,

Oui c'est une très bonne idée mais la trame change à chaque fois car la charge utile sont des valeurs des différentes capteurs qui génèrent des valeurs float sur 4 octets, le débit c'est exigé par le récepteur (une diode IR + démodulateur+ filtre ), les 100 ms sont donné par le CDC