Vous prendrez bien un peu de Wifi avec votre RFLink ?

[deennoo]

Si tu es avec une sp01 :
Il faut respecter les conditions d'alimentation de l'ESP :
- Tension + capa + condo
- Il te faudrait également, un shift level register qui abaisse la tension du port serie de la Mega (5v) pour le passer au niveau de l'esp (3v).

J'ai aussi ce genre de petit désagrement, Domoticz envoi un PING et RFLINK doit repondre par un PONG, sauf que des fois le message est mangé dans les infos que le RFLink envoie a la reception de tes capteurs RF ou a l'envoie d'ordre depuis Domoticz, plus tu as de "dispositifs" plus il y a de risques.

Pas vraiment de solution mis a part demander a domoticz de redemarrer le hardware en cas de non reception : delai d'attente des données a 5 minutes.

Tu vois comme c'est "compliquer" a mettre en place et pourquoi cette solution 'a pas été officielement retenu par la Team RFLink ?

[rimram31]

...Pas vraiment de solution mis a part demander a domoticz de redemarrer le hardware en cas de non reception : delai d'attente des données a 5 minutes...

C'est en théorie ce que fait le hardware de domoticz. Le hardware envoie un PING et, a défaut de réponse dans les nnn secondes (30 secondes je crois), il effectue un "close" qui va plus loin demander une réouverture (via l'usb).

Toutefois je ne jurerais pas que ça marche impeccable car j'ai du désactiver ce mécanisme avec ma carte (qui émule un rflink) car le fonctionnement (sans PONG) était plantage, au sens plus de hardware, point barre.

[jackslayter]

ok et pour le couple mega/aurel , il y a des composants à ajouter pour fiabiliser l'ensemble ?
j'ai vu qu'il y avait une 20k sur la pin 8

[deennoo]

Oui je confirme pour la 20k

[Charly86]

Bonjour tout le monde

Alors voilà j'ai fait quelques tests avec ESP8266, Un Mega2560 5V et un mega 1284P 3.3V (moteino mega) et différents récepteurs (j'ai pas essayé l'émission), voilà ce qu'il en ressort

Au niveau Hard j'ai mis le 2560 avec un RXB6 en 5V pour comparer les réceptions en simultané avec mes autres tests

1) le module Aurel TRX-MID 3V3 (du moins en réception) est bien moins bon que le RXB6. Étonnant hein ?
2) le module RXB6 bien qu'indiquant 5V fonctionne parfaitement si alimenté en 3.3V, pas bonne la surprise ?. Et je me suis fait chier a essayer de faire un conv 5V=>3V3 a pont diviseur et/ou FET sans succès (impédance de sortie du module ou entrée GPIO bref ça n'a jamais fonctionné correctement)

Au niveau Soft, j'ai tordu le cou à la fonction de réception qui fonctionne avec un LoopPerMilli dont la méthode de calcul semble OK sur mega mais je ne sais pas la calculer sur ESP8266. Comme le but est de mesurer les intervalles en microseconde, j'ai changé le code pour le faire sans utiliser le LoopPerMilli. J'ai comparé en // le nouveau code tournant sur Moteino Mega et l'ancien sur Mega 2560, le moteino reçoit bien les mêmes trames que la référence 2560 donc le code est bon

La mauvaise nouvelle c'est qu'avec le même code sur ESP8266 je rate 60% des trames, même en essayant aussi différentes valeurs de LoopPerMilli (ancien code) et en changeant la lecture de l'I/O via des direct read de ports, que ce soit a 80MHz ou 160MHz. Par contre avec un autre code (https://github.com/zoid921/esp8266_osc_to_mqtt) je les reçois parfaitement donc je pense qu'il y a une subtilité dans le décodage Oregon que je ne maitrise pas dans RFLink

Je crains qu'on ne doive malheureusement se contenter d'une solution Mega+ESP et pas ESP tout seul, du moins pour le moment

[snips]

Bonjour,
RXB6 : je ne suis pas surpris, j'en ai pris un pour mon rflink.

Pour le reste : le bout de code qui gere Oregon (plugin_48.c) du code source public est buggué et rate des trames Oregon (par rapport aux dernieres versions du firmware RFLINK dont le code source n'est pas public). Si vous le voulez je vous envoie en MP une version améliorée du Plugin_48.c à tester pour voir si vos pertes de trames ne viennent pas simplement de là.

P.S. Enfin, je ne sais pas si vous avez collé des condensateurs de découplage entre le VCC et GND du RXB6, peut être que les problèmes de réception viennent aussi delà (je ne sais pas si l'ESP génère beaucoup de bruit ou pas sur le RXB6).
Condensateur de découplage : un 100nf au minimum si possible.. sur le schéma j'en ai mis 2 autres en plus au cas où : 0,47 et 10 uF http://www.nemcon.nl/blog2/images/RXB6.jpg

[Charly86]

Bonjour,

Ah oui, carrément je veux bien tester la dernière version du plugins pour Oregon, mon mail est ch.hallard at gmail.com

Oui j'ai vu pour les condensateurs, je vais essayer aussi ainsi qu'avec les autres récepteurs (SYN480R) que j'ai reçu, je posterais les résultats ici

[Charly86]

Bon alors 1er test avec le récepteur SYN480R, en 3.3V faut oublier ça rate trop de trame, et en 5V ça en rate aussi.

A titre indicatif sur la même période de temps (environ 5/10min) et fonctionnant au même moment
RXB6 en 3.3V (160 trames reçues)
SYN480R en 5V (109 trame reçues)

snips, ce serait abuser que tu me donnes aussi le RawSignal.ino de la dernière version que je vois si des choses on changées dans la réception du signal brut ?

Promis je garde pour moi.

Merci à toi.

[snips]

je viens d'envoyer le plugin048.

Désolé ! je n'ai que celui là de plus à jour que les sources publiques !!! (pas la dernière version de RawSignal.ino donc...)

Cependant je ne pense pas que tu aies besoin de vérifier RawSignal.ino car tu reçois quand même 40% des trames... Si des modifications majeures avaient été apportées tu aurais reçu 0% de trames....

[deennoo]

Vous me confirmez tout les deux ce que j'avais constaté avec mes rflink au rabais a base de rx6b.

J'ai équipé mon voisin avec et il capete mieux que moi certaines de mes sondes...