Charly86
I- j'ai lu le code qui marche pour le décodage d'Oregon avec ESP8266 et il n'y a rien de particulier......
------
explication plus détaillée
a) L'algo est adapté spécifiquement à l'Oregon (1000 usecondes le bit),donc plus dépouillé...
il n'utilise pas la méthode consistant à mesurer la durée d'un pulse pour détecter une inversion du bit (pulse long) .. mais une autre méthode très proche consistant à déterminer après 1/4 de 1000 usec du départ d'un bit, puis à 3/4 du départ du bit si la valeur du bit est inversée ou pas.... Je n'ai pas le sentiment que le problème vient de là (même s'il y a quelques valeurs seuil différentes : exemple 750 usecondes d'un côté versus 675 usecondes de l'autre...
b) Une petite différence c'est que l'algo ESP8266 utilise la fonction "delayMicroseconds()" alors que pour ta version de RFLINK tu utilises micros()...
QUestion : tu constates des pertes de trames oregon avec RFLINK sur Esp8266 comment ? avec une console sur le port USB/série de l'esp8266 comme pour l'arduino ? ou après retransmission via le WIFI ?
si c'est via le WIFI : Je ne suis pas expert de l 'ESP8266.. mais en lisant
https://github.com/esp8266/Arduino/blob ... ference.md je crois comprendre que le wifi et TCp/ip est "traité" pendant les délais d'attente - delayMicroseconds()- et en fin de "loop()" sur Esp8266.
Or des fins de boucle loop il n'y en a pas beaucoup ainsi que des delayMicroseconds() dans le code RFLINK.. le problème peut-il venir de là ? (des pertes de trames WIFI en fait...)???
c) une autre différence c'est dans la structure du programme : RFLINK.. il "écoute" le 433 mhz et si un signal est détecté, il bloque une fenetre d'écoute... puis ensuite écoute la liaison série et peut bloquer une fenetre d'écoute de la liaison série.
je ne sais pas si un problème peut venir de là (RFLINK écouterait moins le 433 dans la version esp8266)
II- je ne sais pas si tu as aussi converti les fonctions de débug du RFLINK sur ESP8266 sur console série, si oui cela vaut le coup de faire un RFUDEBUG (trame inconnue) ou RFDEBUG (protocole identifié)
ou en console série (terminal) taper :
10;RFUDEBUG=ON;
ou
10;RFDEBUG=ON;
cela permet de voir si certaines trames oregon sont bien reçues par l'ESP8266 mais pas reconnues (RFUDEBUG)... et avoir la durée des pulses permettant de localiser les problèmes
et si celles qui sont reconnues (RFDEBUG)mais avec une durée des pulse qui "glissent" par rapport à version RFLINK / Arduino, ce qui peut aussi donner une piste.
P.S. tu peux aussi m'envoyer ton programme RFLINK pour ESP8266, je viens de recevoir mon NODEMCU et je suis prêt à "débuguer".
