Discussion :

[Caxton]

A l'origine vous vouliez une Communication radio mono directionnelle.

C'est toujours le cas.

Synchroniser les 2 cartes sur la base d'un protocole asynchrone n'est pas simple. outre le rajout de matériel il faudra développer une machine à état des deux côtés, et un mécanisme robuste de reprise en cas d'erreur. Si vous voulez explorer cette voie, le RH_ASK n'est pas le bon hardware, vaudrait mieux passer sur du nRF24L01+ qui est multicanal et bi-directionnel.

C'est une solution, mais ce n'est pas celle que je compte développer.

en restant sur l'architecture actuelle, à mon avis vous pouvez vous en sortir avec l'émetteur qui envoie plusieurs trames, charge au receveur de bien gérer ces différents éléments. Si quelque chose ne va pas, il aura raté un message complet et se remet en attente du prochain message complet

Pour faire simple. Je ne parle que du côté TX. Nous savons car ça fonctionne que la trame entière passe bien de carte à carte. On y change rien. Mais par contre niveau PC vers TX là ça coince sérieusement pour les raisons évoquées au dessus. En d'autre terme, la carte Tx se charge de récupérer les données et de renvoyer éventuellement un ACK au PC. Par contre entre TX et Rx là, il n'y a aucune synchronisation. Sinon, j'aurais en effet utilisé un protocole bidirectionnel à base de nRF24L01 ou mieux.

A ce stade ce que je cherche c'est la bonne façon de parser les données pour les reconstituées afin de les transmettre au TX. Je vois ce que je peux faire comme code en ce sens et on en reparle pour l'optimisation

[Jay M]

votre émetteur Tx n'a aucun moyen de savoir si la réception s'est bien passée, sinon il faudrait un canal retour.
le PC va donc balancer à son rythme à l'émetteur (Tx) des données à envoyer.

l'émetteur (Tx) analyse ce qui vient du PC pour bâtir le message à envoyer. Il faut donc un protocole convenu entre le PC et l'émetteur. (marqueur début de message, fin de message).

Comme ce message ne tient pas dans un seul paquet, l'émetteur met en forme les paquets et les balances les uns après les autres en croisant les doigts pour que le récepteur les voit bien arriver

Le récepteur lui voit un flot de paquets et doit reconstituer le message

un paquet pourrait être une structure avec

- un octet pour le N° de paquet dans le message (paquet 0, paquet 1, paquet 2, ....)
- un octet pour un identifiant de paquet (charge à l'émetteur de ne pas balancer deux paquets de suite avec le même identifiant)
- un payload (une partie du message)

dans le paquet N° 0, le payload pourrait dire combien de paquets attendre par exemple pour reconstituer le message et éventuellement un CRC ou autre information d'en-tête pertinente

Si le PC parle trop vite à l'émetteur et que l'émetteur est occupé à envoyer le paquets, on risque de rater un message... l'émetteur verra un flot de données arriver mais aura raté le marqueur de début de message par exemple et pourra donc signaler au PC qu'il n'a pas compris.

côté récepteur (Rx), il voit un flot continu de paquets. il attend celui dont le N° de paquet est 0 et sait que c'est un début de message, il lit dans le payload le nombre de paquets à attendre et se met en attente de tous ces paquets en vérifiant bien que le N° de paquet est bien croissant. une fois qu'il a re!u le bon nombre de paquets, il vérifie le CRC et remet en forme le message d'origine.

[Caxton]

Reprenons !
J'ai essayé d'envoyé toute la chaine "Addr;0x00AB:0xCF2A:0x153D:0x2ABC:0x2384:0xA23D:0xF2FF:0xCA2D". L'idée ici c'est d'avoir:

Addr
0x00AB
0xCF2A
0x153D
0x2ABC
0x2384
0xA23D
0xF2FF
0xCA2D

Pour ce faire j'ai cherché une solution pour que ça passe en entier. J'ai fini par y arrivé. Mais, il y a un mais !

Niveau code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
 
#include <RH_ASK.h>
#include <SPI.h> // Not actually used but needed to compile
 
#define speedTR 1000
#define TX_PIN 4
 
const uint16_t sizeMaxData = 43;  //Taille max du data à envoyer
 
struct data_t {
  uint16_t addr[8];
  uint8_t dataSend[sizeMaxData];  //Nombre d'octets
} data;
 
RH_ASK driver(speedTR, "", TX_PIN);
 
//char serData;
 
void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600);
  driver.init();
}
 
char string[100];
 
void loop() {
  // put your main code here, to run repeatedly:
 
  //Data reçu
  if(Serial.available() > 0) { 
    int availableBytes = Serial.available();
    for(int i=0; i<availableBytes; i++) {
      string[i] = Serial.read();
    }
    //Ici j'ai bien ma chaine entièrement reçu
    //On tente de parser
    char * pch;
    pch = strtok(string, ";:");
    while(pch != NULL) {
      Serial.println(pch);
      pch = strtok(NULL, ";:");
    }
 
   //If(pch == "Addr") {
         //Parser de nouveau
         //data.addr[0] = 0x00AB;
         //data.addr[1] = 0xCF2A;
         //data.addr[2] = 0x153D;
         //data.addr[3] = 0x2ABC;
         //data.addr[4] = 0x2384;
         //data.addr[5] = 0xA23D;
         //data.addr[6] = 0xF2FF;
         //data.addr[7] = 0xCA2D;
   //}
   //If(pch == "Message") {
         //Parser de nouveau
         //Colonne
         //Ligne
         //Message
   //}
   //Envoyer à RX
   Serial.flush();
  }
}

Des résultats encourageants



J'espère que je ne perd pas tout le monde. J'i mis en pseudo code ce que je compte faire ensuite. Mais avant, j'aimerais quand même savoir quelle est la meilleure façon de traiter tout ça. Car en l'état, j'ai pas l'impression que ça soit correct pour tester avec un if.

[Jay M]

non on ne peut pas faire un == avec les cStrings, il faut utiliser strcmp() ou strstr() par exemple

mais j'ai l'impression que vous repartez à l'envers, sur l'envoi en ASCII de votre adresse. on l'avait envoyé en binaire auparavant

Si on part du principe que vous allez découper le message en petits paquets, il vous faudrait une structure décrivant le paquet 0 qui contiendrait une information particulière et une structure décrivant un paquet générique

On sait qu'en tout on peut avoir 60 octets pour TOUT le paquet

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
struct paquetEntete {
  uint32_t sentinelle; // 4 octets magiques pour identifier un début de paquet par exemple 0xDEADBEEF
  uint16_t idMessage; // 2 octets pour un identifiant unique pour tout le message découpé en n paquets
  uint8_t nbPaquets; // 1 octet en combien de paquets le message a été découpé (0 si on ne l'a pas découpé et qu'il tient dans ce message)
  uint16_t addr[8]; // les 8 octets d'adresse cible
  uint8_t taillePayload; // 1 octet pour le nombre d'octets dans le payload principal
  uint8_t payload[44]; 
};

ce paquet fait donc 60 octets, il contient l'adresse de destination et un petit payload de 44 octets.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
struct paquetGenerique {
  uint32_t sentinelle; // 4 octets magiques pour identifier un paquet générique, par exemple 0xBADCAFFE
  uint16_t idMessage; // 2 octets pour un identifiant unique pour tout le message découpé en n paquets
  uint8_t idPaquet; // au maximum on a 255 paquets, si on dit que le paquet 0 est l'enTete, on compte à partir de 1 donc ici
  uint8_t taillePayload; // le nombre d'octets effectifs dans le payload
  uint8_t payload[52]; 
};

Ce second paquet fait 60 octets et contient un plus gros payload de 52 octets

côté Tx vous recevez le message depuis le PC et fabriquez le paquetEntete et autant de paquetGenerique que nécessaire puis vous les balancez. Côté Rx vous écoutez en attendant d'avoir reçu un paquet qui contient comme sentinelle la valeur de paquetEntete (0xDEADBEEF). à partir de là vous vous mettez en mode reception de message. Si le nbPaquets est 0 vous avez tout votre message dans le premier paquet, sinon c'est qu'il a été envoyé par petits bouts et il faut les recevoir.


avec cette approche vous Pourrez comparer l'adresse avec un memcmp() comme on l'avait déjà fait avant.

[Caxton]

Ok, je comprends beaucoup mieux comment faire.

Le projet à évolué entre temps. Bon, c'est un peu le problème entre ce que nous faisions au départ et ce qui sera réellement mis au point. Comme je travaille en avance de phase, je vais donc devoir repenser l'intégralité du projet.

Ce que l'on garde dans le sens Pc -> RX :
Une entête (voir ton dernier message)
Une adresse
Un message
Ce que l'on ajoute dans le sens RX ->Pc :
Un système de retour d'info
Une entête
Une valeur qui n'est autre que le message précédent)
Une valeur Qté 0.

Ce qui fait que :
Le logiciel Pc dit :
Addr;0x00AB:0xCF2A:0x153D:0x2ABC:0x2384:0xA23D:0xF2FF:0xCA2D
Message;C0;L0;35262 5 B
Quantite;10
Rx reçois
Addr;0x00AB:0xCF2A:0x153D:0x2ABC:0x2384:0xA23D:0xF2FF:0xCA2D
-> Si c'est son adresse
--> Afficher en Colonne 0, Ligne 0 : 35262 5 B
--> Afficher la quantité 10
-> Si appuie sur le bouton quantité 0
--> Retourne au broadcast
--> Addr;0x00AB:0xCF2A:0x153D:0x2ABC:0x2384:0xA23D:0xF2FF:0xCA2D
--> Quantite;0
Tx reçois
Addr;0x00AB:0xCF2A:0x153D:0x2ABC:0x2384:0xA23D:0xF2FF:0xCA2D
Quantite;0
-> Il le transmet au PC

L'échange devient bidirectionnel. Ce n'étais pas prévus au début !!! Bref, je vais donc passer à d'autres composants du style nRF24L01. Il me semble que tu avais évoquer le cas Jay. Mais je me trompe.

Je dois m'absenter quelques jours pour raison de formation. Mais je vais bien vite, à mon retour me remettre à travailler sur ce sujet. Soit j'enterre le sujet tel que (je ferais le rappel dans un autre) et à ce moment là j'ouvrirais un nouveau sujet tout neuf. Soit je le garde ouvert et je reprendrais à mon retour.

Voili voilà

[Jay M]

OK - oui là ça devient hors de portée de votre module, effectivement comme je l'avais mentionné il faut passer à un autre composant comme le nRF24L01+ (prendre des +) ou nRF51 et autres NRF51822.. il y a pas mal d'options y compris le Wi-Fi ou le bluetooth suivant votre environnement