On devrait empêcher la corruption de données entre le arduino et le ESP #35
Comments
|
Pour l'autocorrection, il y a aussi le code de hamming : https://en.wikipedia.org/wiki/Hamming_code |
|
J'avais oublié celui-là, I like this ^ |
|
Ça a tu déjà arrivé un flip de bit dans le projet ou de la corruption? Y'a seulement déjà eu de la corruption à cause d'un fil qui n'était pas connecté au bon endroit, c'était pas la faute du ESP ou du Arduino. |
|
Ce n'est surement pas arrivé puisque ça peut être rare, mais ça va arriver un jour et envoyer des valeurs éroné à l'esp. C'est combien de temps entre chaque envoie d'info de l'arduino? Si c'est haut faudrait le mettre, mais si on envoie souvent c'est pas trop pire. |
|
C'est aux secondes. Ça nous a déjà été proposé pae Sam St-André, je vais l'ajouter dans la liste de choses à faire et référencer cette issue |
|
Ouain, j'ai pas changer de nom lolz. Je suis Sam! Mais si c'est au secondes je pense que ça va être correct sans ça puisqu'on joue avec de la température qui bouge pas très vite! L'envoie d'après devrait remettre les bonnes values (si on ce dit que celui-la non plus va pas être corrupted) |
|
Précédemment, j'avais évalué que c'était possible qu'après plusieurs heures, la communication entre le Arduino et le ESP désynchronise. J'ai jamais essayé de faire boguer la communication par exprès, mais présentement les deux utilisent les fonctions
Non, c'est aux 2020 millisecondes. Pour une raison quelconque, ça semble aller plus vite quand le Arduino et le ESP ne sont pas connectés ensemble d'après mes observations avec la serial console. Faudrait aussi un mécanisme pour que par exemple, un ESP qui détecte un message erroné puisse le redemander au Arduino. J'avais ouvert un issue pour ça: #24 Faudra mettre en place un protocole de communication entre les deux. |
|
Pour éviter les problèmes de synchronisation, ça prend des flags de débuts et de fin de transmission. C'est normal que ça se désynchronise car l'erreur de synchronisation est accumulé. L'autre solution, c'est un moyen de synchroniser les 2 appareils. Toutefois, puisqu'ils n'ont pas de |
|
Oh snap boi waddup!
Mais je crois qu'on pourrait l'implémenter quand même si ça nous vole pas
trop de cycles de CPU, ça va seulement faire en sorte qu'on a un projet
plus robuste.
Le 11 mai 2017 4:27 PM, "Knorax" <[email protected]> a écrit :
… Ouain, j'ai pas changer de nom lolz. Je suis Sam! Mais si c'est au
secondes je pense que ça va être correct sans ça puisqu'on joue avec de la
température qui bouge pas très vite! L'envoie d'après devrait remettre les
bonnes values (si on ce dit que celui-la non plus va pas être corrupted)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#35 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGv1fV70dRuay6SaPtoVzni3KOAmZEUhks5r428YgaJpZM4NYcl3>
.
|
|
J'ai un gros hate sur l'utilisation des delay pour le esp. Il devrait juste attendre de recevoir de quoi pour commencer ses opérations et c'est l'arduino qui ferait juste garocher c'est infos à chaque seconde. Je vais être là demain si tu veux des détail de comment je pense faire ça. Ou ce soir par chat parce que damn boi sur le cell ça va mal D: |
J'ai pas dit que ça se désynchronisait présentement, mais c'est une crainte. Je sais pas comment le Arduino et le ESP vont réagir à long terme. Y'a un délais de 2020 millisecondes entre chaque envoie, sauf que y'en a tout le temps un qui prendra plus de temps de traitement que l'autre. Présentement, ça doit pas désynchroniser beaucoup si ça désynchronise. Comme un attend tout le temps après l'autre pour lire ses données, ça se peut qu'il n'y ait aucune désynchronisation à long terme. Présentement, j'en observe aucune.
C'est la seule raison pourquoi il faut le faire. Fuck les cycles de CPU! ;-) Peut-être qu'à moment donné quelqu'un va l'utiliser dans une place où il y a des interférences très fortes ou du magnétisme. À ce moment là, ça devient une nécessitée. |
Il faudrait se déterminer combien de temps ça prend pour considérer que le jardinIOT est autonome avec que l'on doivent y toucher pour la synchronisation. Si l'on doit faire une opération manuelle avant ce temps, ça devrait être un seuil de mesure pour considérer la robustesse du projet.
On s'entend je crois. |
|
La désynchronisation n'est pas en fonction du nombre de donnés à la minute (à moins que le CPU soit overloadé; une raison de ne pas avoir un baud rate trop haut) mais du temps de fonctionnement. |
Légit comme idée. Celui-ci dans la loop du ESP n'est surement pas nécessaire: https://github.com/ClubCedille/jardiniot/blob/master/jardiniot-emb/esp/src/main.ino#L173 Ceux dans la fonction Le Arduino utilise le delay pour envoyer des données à chaque 2 secondes. Il le fait seulement parce que envoyer plus de données serait inutile. Même qu'à chaque minute, je pense que recevoir une donnée serait assez. Il y aura un système dans le Arduino pour maintenir la température stable. |
|
D'ailleurs, le code les plus récent, c'est Gauthier qui l'a, mais je sais pas il est où. Surement dans l'ordi Fedora. Le ESP peut recevoir des données qui viennent de topics et elles sont encodées sur un |
Pour préciser, la nature des interférences peuvent être :
Finalement, un des éléments ci-dessus ne cause pas de problème aussitôt l'impact étant faible. Ainsi, l'erreur accumulé causera un trouble de synchronisation avec le temps surtout. |
|
@Knorax J'suis intéressé de savoir comment ditcher le delay sur le ESP. T'en laisseras une trace icitte! |
|
@aubguillemette vite comme ça, si je comprends bien le code (lolz) faudrait juste ajouter genre while(!Serial.available) avant celui sans le "!", ça ferait en sorte qu'on attendrait de recevoir dequoi avant de passer au reste des commande. À moins qu'on veuille faire des iteration aux deux secondes, faudrait faire ça autrement dans ce cas, don't know how vite comme ça, mais faudrait :P il y a d'autres moyens sans doute plus smart pour le !available, faudrait je dig un peu! |
|
Veuillez voir #36. Je summon aussi @AlexBrochu puisqu'il travaille présentement sur l'Arduino/l'ESP et j'aimerais avoir son point de vue sur le sujet. |
|
C'est effectivement une excellente idée de mettre un checksum sur les messages que le esp reçoit. Pour ce qui est des delay, il faudrait assurément trouver un autre mécanisme de synchro entre les 2. Pour l'instant, j'ai des problèmes pour faire la communication entre le ESP et le arduino lorsque je reçoit une commande par le serveur MQTT et je soupsonne que c'est causé par les delay. Je vais avoir besoin de l'aide pour cette partie si il y a quelqu'un de disponible. |
|
@AlexBrochu : @Knorax a travaillé un peu sur le code Arduino ce pm. Considérant que c'est "The Last Arduino Master", probablement qu'il pourrait te donner un coup de pouce là-dessus. Puisque vous êtes les seuls qui travaillent sur le Arduino/ESP en ce moment, je vous invite à vous synchroniser sur le travail fait dans RocketChat ou en qqpart. Aussi, vous pouvez créer une issue sur ce qu'il reste à faire, comme ça ça va permettre aux autres de connaître l'avancement de cette facette là du projet. BTW, "The Last Arduino Master", ça ferait un bon film ça. |
Le danger de la communication série sans checksum, c'est le flip de bits. Je penses qu'ajouter un checksum CRC serait nécessaire pour empêcher ça.
C'est facile à implémenter et j'ai un exemple dans un de mes projets antérieur.
The text was updated successfully, but these errors were encountered: