Go Down

Topic: Communication LoRa (Read 224 times) previous topic - next topic

Lacuzon

Bonjour,

je teste actuellement des couples de ESP32 TTGO LoRa et j'observe parfois un comportement anormal, les données sont transmises avec un signal RSSI correct et stable puis j'ai une donnée aberrante avec un RSSI très faible.

Voici le retour du moniteur :

Code: [Select]
2:51:48.787 -> Received packet 'hello 551' with RSSI -70
12:51:54.835 -> Received packet 'hello 552' with RSSI -69
12:52:00.883 -> Received packet 'hello 553' with RSSI -69
12:52:06.931 -> Received packet 'hello 554' with RSSI -70
12:52:09.510 -> Received packet '12.93' with RSSI -116
12:52:12.932 -> Received packet 'hello 555' with RSSI -70
12:52:18.980 -> Received packet 'hello 556' with RSSI -70
12:52:25.028 -> Received packet 'hello 557' with RSSI -68
12:52:31.076 -> Received packet 'hello 558' with RSSI -70


J'observe cela avec les fichiers lorasender.ino et lorareceiver.ino mais aussi avec mes propres adaptations intégrant l'option deepsleep (que je teste pour une application particulière). J'ai utilisé divers ESP32, fait varié la vitesse de transfert série, bref, je suis dans l'inconnu.

Seul problème, je teste sur banc avec des distances très faibles entre émetteur et récepteur.

En situation, je n'ai pas observé ce type de valeur aberrante (ou tout du moins avec une telle fréquence,  toutes les 20 à 30 données)

Une idée ?

al1fch

#1
Nov 18, 2019, 01:35 pm Last Edit: Nov 18, 2019, 01:54 pm by al1fch
Bonjour

Quote
Code: [Select]
2:52:06.931 -> Received packet 'hello 554' with RSSI -70
12:52:09.510 -> Received packet '12.93' with RSSI -116
12:52:12.932 -> Received packet 'hello 555' with RSSI -70

J'observe le même genre d'évènements et pour moi ce sont des 'paquets venus d'ailleurs' , émis par d'autres dispositifs LoRa (dont  LoRaWAN) du voisinage avec les mêmes paramètres (fréquence, SF....) que ceux des paquets désirés.

Volà par exemple un extrait de log d'une passerelle LoRaWAN TTN perso avec des paquets TTN venus de 'devices' autres que les miens, paquets qui arrivent de temps  à autre  sur 868,1 MHZ avec un SF de 7 . Le faible RRSI montre l'éloignement de la source.

Monday 18-11-2019 13:28:1626 01 11 4408681000007-75
Monday 18-11-2019 13:25:2460 3b dc e608681000007-121
Monday 18-11-2019 13:23:3226 01 11 4408681000007-75

Autre piste : j'ai lu quelque part (Où ?) qu'il existe une possiblité de 'paquets fantômes' créés au sein des puces LoRa en raison d'un artefact de ces puces LoRa en réception.

Artouste

#2
Nov 18, 2019, 01:57 pm Last Edit: Nov 18, 2019, 01:58 pm by Artouste
Bonjour
J'observe le même genre d'évènements et pour moi ce sont des 'paquets venus d'ailleurs' , émis par d'autres dispositifs LoRa (dont  LoRaWAN) du voisinage avec les mêmes paramètres (fréquence, SF....) que ceux des paquets désirés.

Volà par exemple un extrait de log d'une passerelle LoRaWAN TTN perso avec des paquets TTN venus de 'devices' autres que les miens, paquets qui arrivent de temps  à autre  sur 868,1 MHZ avec un SF de 7 . Le faible RRSI montre l'éloignement de la source.

Monday 18-11-2019 13:28:1626 01 11 4408681000007-75
Monday 18-11-2019 13:25:2460 3b dc e608681000007-121
Monday 18-11-2019 13:23:3226 01 11 4408681000007-75

Autre piste : j'ai lu quelque part (Où ?) qu'il existe une possiblité de 'paquets fantômes' créés au sein des puces LoRa en raison d'un artefact de ces puces LoRa en réception.
Bonjour
  ?
Quote
Phantom Packets

It is an artefact of a LoRa receiver that data and packets can appear as if from nowhere, they come from within the device itself. The rate of phantom packets depends on the bandwidth in use by the receiver and can be at the rate of around 5 to 10 phantom packets per hour. Care is needed in software libraries to ensure that these phantoms are identified and rejected.

al1fch

#3
Nov 18, 2019, 02:04 pm Last Edit: Nov 18, 2019, 02:20 pm by al1fch
OUI !!

Pour ce qui est des "paquets venus d'ailleurs", les vrais pas les fantômes, on doit pouvoir réduire l'occurence en se positionnnt vers le haut de la bande des 868MHZ, partie peu utilisée : la pluspart des utilisateurs laissant 868 dans LoRa.begin !!!

Code: [Select]
LoRa.begin(869500000)
ou
Code: [Select]
LoRa.begin(870000000)
Voilà la bande et les puissances autorisées


Lacuzon

Bonjour,

Merci à vous pour le retour.

Sur la première hypothèse, je n'y avais pas pensé mais j'ai un deuxième système qui fonctionne, et les valeurs du signal  RSSI devraient coller avec cette possibilité.

Ce que je ne comprends pas c'est que j'ai ajouté pour chacun des systèmes une clé de synchronisation (setSyncWord) différente...

Pou l'autre hypothèse, je n'observe pas ce comportement sur mon dispo en fonctionnement réel.

J'ajoute que j'ai fait un essai avec un autre module émetteur, même symptome.

L'hypothèse 1 reste la plus plausible. Je vais couper l'émission de mon autre système, j'aurai la réponse.

Pour les données fantôme, la solution est l'élimination dans le programme, comme je procède souvent quand j'ai des données aberrantes, mais ce n'est pas propre...

Lacuzon

al1fch,

Je n'avais pas vu ton dernier message, je vais essayer ...

Artouste

OUI !!

Pour ce qui est de l'hypothèse "paquets venus d'ailleurs", les vrais pas les fantômes, on doit pouvoir réduire l'occurence en se positionant vers le haut de la bande des 868MHZ, partie peu utilisée : la pluspart des utilisateurs laissant 868 dans LoRa.begin !!!

Code: [Select]
LoRa.begin(869500000)
ou
Code: [Select]
LoRa.begin(870000000)

oui , c'est un des 1ers reflexes à avoir , changer la valeur de F° pour du plus exotique
C'est aussi "une bonne pratique" que de regarder avec un petit rtl/sdr ce qui traine dans dans l'environnement de test

al1fch

#7
Nov 18, 2019, 02:16 pm Last Edit: Nov 18, 2019, 03:11 pm by al1fch
Quote
Ce que je ne comprends pas c'est que j'ai ajouté pour chacun des systèmes une clé de synchronisation (setSyncWord) différente...
le paramétrage est bien effectué après LoRa.begin() ?  (LoRa.begin remet les valeurs par défaut, à part la fréquence)
d'autre part il n'est pas évident que la librairie utilisée ( celle -ci ?) colle avec toutes les subtilités de LoRa....

+ détail de la bande des 868MHz au message #3

Lacuzon

C'est réglé !

J'avais bien introduit la clé de synchronisation mais avant le LoRa.begin() donc il ne devait pas faire grand effet... en conséquence, je captais le signal de mon pèse-ruche lui-même en test à 50 mètres.

Après coup, j'aurais pu m'en douter, la donnée aberrante étant le poids témoin (12.9) (environ 13 kg).

Du coup, j'ai corrigé l'erreur et profité pour changer de bande de fréquence comme vous me l'avez conseillé.

Donc dans mon cas, pas de fantôme...

Merci à vous pour le coup de main.

Lacuzon

Bonjour,

je viens de faire quelques tests intéressants :

Je rappelle que j'ai deux systèmes, un sur banc en test, un autre in situ en fonctionnement et considéré comme parasite éventuel.

j'ai comparé les réceptions avec ou sans synchronisation sur le système en test (ligne de commande (LoRa.setSyncWord(0xF5);

Les résultats m'ont étonné :

- J'ai changé la bande de fréquence (867E6) du système en test , le système parasite lui est resté en 868E6 et n'est pas synchronisé.

- avec la ligne (LoRa.setSyncWord(0xF5) sur la réception et l'émission, la transmission est correcte, MAIS quelques paquets sont issus du système parasite.

- avec la ligne (LoRa.setSyncWord(0xF5) sur la réception seule, une partie des paquets légitimes sont captés ainsi que des paquets parasites.

- avec la ligne (LoRa.setSyncWord(0xF5) sur l'émission seule, seuls les paquets parasites sont captés de temps en temps.

Donc le filtrage (LoRa.setSyncWord(0xF5) n'est pas totalement efficace sauf si j'en fais un mauvais usage...

Pas sûr d'avoir été clair......

al1fch

#10
Nov 19, 2019, 05:13 pm Last Edit: Nov 19, 2019, 05:42 pm by al1fch
Si , c'est clair !

Cela amène  une question sur la portée théorique de ce mot de synchronisation, son 'pouvoir de séparation', ainsi que la mise en oeuvre par la librairie utilisée

Içi sandeepmistry , auteur d'une librairie LoRa souvent utilisée,  laisse entendre qu'il s'agirait d'un bug matériel de la puce LoRa qui laisserait parfois passer des paquets dotés d'un 'syncword' différent
https://github.com/sandeepmistry/arduino-LoRa/issues/16

Si c'est le cas il en est sans doute question sur un forum de Semtech


Lacuzon

Merci pour l'info, j'ai lu les commentaires, je ne semble pas être le seul.

Demain, je vais modifier mon système en fonctionnement pour y intégrer le deepsleep mode et un word sync spécifique. Je vais voir ce que ça donne par rapport à mon système en test.

Ce qui est étonnant, c'est que les paquets qui passent ne sont qu'occasionnels, tout ne passe pas.

Actuellement, depuis un peu moins d'une heure, ça détecte sans aucun paquet parasite mais dans 10 minutes je peux en avoir deux ou trois dans le quart d'heure suivant.

J'ai oublié de préciser que dans mes tests précédents, mon émetteur fonctionnait en deepsleep mode.


al1fch

#12
Nov 19, 2019, 06:13 pm Last Edit: Nov 19, 2019, 06:28 pm by al1fch
OK

Mais est-ce vraiment grave que quelque intrus arrivent les mailles du filet si dans la 'charge utile' du paquet il y a un identifiant de la source ?
(Un filtrage logiciel pour compenser les imperfections éventuelles du filtrage matériel de la puce LoRa)

Lacuzon

Non bien sûr, c'est ce que fais sur mes différents systèmes.

L'ESP32 reste un super MCU et il ne faut pas oublier qu'on est dans une logique de développement donc des scories sont bien normales.

Cordialement

Go Up