search

couin3 / RFLink

RFLink for ESP, with MQTT client
Other
72 stars 37 forks source link

question compréhension algo #75

Closed aschor closed 3 years ago

aschor commented 3 years ago

Hello, ça n'est pas une issue, mais j'ai du mal à comprendre cette partie de code, quelqu'un pourrait-il m'expliquer SVP ?

(qui commence ici : https://github.com/couin3/RFLink/blob/e55d202a1e60aab70bf45d4b2e8e19bf20730b73/RFLink/2_Signal.cpp#L50)

  // ***   Init Vars   ***
  Toggle = true;
  RawCodeLength = 0;
  PulseLength_us = 0;

  // ***********************************
  // ***   Scan for Preamble Pulse   ***
  // ***********************************
  RESET_SEEKSTART;

  while (PulseLength_us < SIGNAL_MIN_PREAMBLE_US)
  {
    //toggle == true
    while (CHECK_RF && CHECK_TIMEOUT) // ( HIGH == LOW )^true     se traduit par true. Donc on boucle tant qu'on a un signal (ou timeout)... donc on discard le signal ?
      ; // sortie de la boucle : signal LOW  ce qui est la plupart du temps le cas si pas de signal a receptionner

    RESET_TIMESTART; // là on "sait" que le pin data est à LOW (ou qu'on est parti en timeout de recherche de signal)
    SWITCH_TOGGLE;   // toggle == false
    while (CHECK_RF && CHECK_TIMEOUT)   // ( LOW == LOW )^false     se traduit par true. Donc on boucle tant qu'on n'a pas trouvé de signal (ou timeout)
      ; 
    // sortie de la boucle : signal HIGH
    GET_PULSELENGTH; //temps passé sur LOW ?? puisqu'on fait micros() - temps juste avant de boucler sur LOW ??
    SWITCH_TOGGLE;   //toggle == true
    if (!CHECK_TIMEOUT)
      return false;
  }

J'ai l'impression que le "scan for preamble pulse" décompte le temps passé sur un signal "low" ......... hors ça devrait être sur un signal high ?!? (j'ai rajouté des commentaires pour essayer de comprendre)

quelle est mon erreur de logique svp ?

cpainchaud commented 3 years ago

bonjour,

Cette boucle recherché un LOW "assez long" pour être considéré comme le début d'un signal, la durée de ce LOW est mise dans Pulses[0] qu'aucun plugin n'utilise au final car un signal commence par HIGH et donc dans Pulses[1] .

Ce repo a repris le dernier code opensource RFLink pour le rendre compatible ESP et donc cette boucle a été peu touchée et hérite de certains design parfois curieux des développeur originaux qui ont surement vus leur "erreur' mais n'ont jamais voulu décaler tous les Pulses d'une position en arrière car ça obligerait à revoir tous les plugins et introduirai beaucoup d'erreurs à coup sur !

Sur quel plugin travailles-tu ?

couin3 commented 3 years ago

Rapidement, un préambule c'est quoi? Coté émetteur, c'est une pulse (1 électrique), suivi d'un long gap (0). Coté récepteur aussi, mais pas exactement! La pulse initiale provoque une ajustement de la sensibilité (à la baisse), ce qui fera que le récepteur sera "adapté" à l'émetteur et ignorera les bruits de plus faible puissance. En gros, le long gap sera vraiment interprété comme un gap.

En pratique, dans le code original, on commence à retenir la 1er gap, qui devient Pulse(0), mais ne contient pas de donnée. Donc les plugins n'analysent qu'à partir de pulse(1).

Retenir :

aschor commented 3 years ago

oooooooki, merci @cpainchaud et @couin3 , ça confirme ce que je pensais, je n'ai pas encore perdu toute ma tête ! Du coup le commentaire du code indique "faussement" qu'il recherche un préambule ... car cette boucle s'arrête "avant" le préambule de tout protocole RF ! au passage, je me suis fait avoir par le code #define STORE_PULSE RawSignal.Pulses[RawCodeLength++] = PulseLength_us / RAWSIGNAL_SAMPLE_RATE ==> je pensais que le codelength était incrémenté avant l'affectation ... les "subtilités" du c++ ...

Pour l'instant je débute vraiment mon analyse du code (je ne suis pas développeur à la base, ni radio amateur, le C++ c'est niveau scolaire ...), histoire de comprendre comment ça marche.

En fait j'ai pour but de piloter mes volets : j'ai du somfy (le protocole n'est pas dans le code source rflink, mais il est "cracké" sur le net), donc ça me semble de l'ordre du faisable (surtout qu'il y a d'autres exemples d'utilisation du somfy), et j'ai aussi d'autres volets, un "nice" (fréquence et protocole inconnus pour l'instant, j'ai galéré pour trouver une commande de rechange quand la seule que j'avais s'est mise à déconner, pour l'appairer c'était sportif aussi !), et un autre "easywave" en 868.3, je n'ai pas trouvé d'infos sur ce protocole (et je n'ai qu'1 commande) ... donc ya du taf !

En prime j'aimerais interfacer tout ça avec home assistant ^^. c'est à dire non seulement piloter, mais aussi avoir un état correct dans la domotique quand une télécommande est utilisée.

côté matériel, j'ai :

cpainchaud commented 3 years ago

Bienvenue @aschor , je t'invite à discuter sur notre Discord si le coeur t'en dis https://discord.gg/x67Pgsbe . fais nous part de tes avancées et question là bas!

Enfin plusieurs remarques:

A bientot !

aschor commented 3 years ago

super ! top @cpainchaud merci !

ça tombe bien, j'ai commandé des RFM69HCW 433 et 868 sur ali ... cool, merci vraiment pour toutes ces infos ! dès que j'ai moins de TAF je m'y mets :) Je cloture l'issue vue que j'ai eu la réponse et bien plus !

@bientôt maybe sur le discord (j'avais trouvé un lien discord sur le forum arduino, qui m'avait ammené là d'ailleurs ^^)

edit : je regarde dans le repo cité, mais pour l'instant je ne trouve pas la trace du protocole somfy en dehors du readme oO