Je suis également surpris par un tel taux d’erreur sur une transmission aussi courte.
Pour info, j’ai utilisé des XBee série 1 il y a plusieurs années pour des projets de recherche dans le domaine de l’instrumentation de lieux de vie par des réseaux de capteurs. Nous avons travaillé jusqu’aux limites de la portée des XBee, et n’avons pas enregistré de pertes de cet ordre. Les communications capteur->base étaient en broadcast pour éviter de devoir configurer un par un les transmetteurs embarqués sur les capteurs. La reconnaissance était faite par la base (ie le soft de la box de collecte) en se basant sur l’adresse MAC du XBee capteur.
A mon avis, il faudrait faire la part des choses entre les erreurs imputables aux XBee et celles qui sont la conséquence des divers overheads liés au protocole de test utilisé ici, à savoir :
– les autres traitements (ex : le LCD)
– la sur-couche Arduino.
Un test à faire serait donc de ré-écrire la manip en code AVR pur et dur (en reprenant par exemple certains exemples publiés sur ce site quelques années auparavant ;) et en supprimant les perturbations (ex : le LCD) pendant la mesure de la qualité de la communication. Ce qui veut dire qu’on peut par contre ré-organiser la logique en faisant tout d’abord une mesure de la qualité de communication, puis l’affichage de son résultat, et boucler globalement sur cette séquence.
Je suis également surpris par un tel taux d’erreur sur une transmission aussi courte.
Pour info, j’ai utilisé des XBee série 1 il y a plusieurs années pour des projets de recherche dans le domaine de l’instrumentation de lieux de vie par des réseaux de capteurs. Nous avons travaillé jusqu’aux limites de la portée des XBee, et n’avons pas enregistré de pertes de cet ordre. Les communications capteur->base étaient en broadcast pour éviter de devoir configurer un par un les transmetteurs embarqués sur les capteurs. La reconnaissance était faite par la base (ie le soft de la box de collecte) en se basant sur l’adresse MAC du XBee capteur.
A mon avis, il faudrait faire la part des choses entre les erreurs imputables aux XBee et celles qui sont la conséquence des divers overheads liés au protocole de test utilisé ici, à savoir :
– les autres traitements (ex : le LCD)
– la sur-couche Arduino.
Un test à faire serait donc de ré-écrire la manip en code AVR pur et dur (en reprenant par exemple certains exemples publiés sur ce site quelques années auparavant ;) et en supprimant les perturbations (ex : le LCD) pendant la mesure de la qualité de la communication. Ce qui veut dire qu’on peut par contre ré-organiser la logique en faisant tout d’abord une mesure de la qualité de communication, puis l’affichage de son résultat, et boucler globalement sur cette séquence.