Communication LoRa

Lacuzon · November 18, 2019, 12:06pm

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 :

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 · November 18, 2019, 12:35pm

Bonjour

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:16	26 01 11 44	0	868100000	7	-75
Monday 18-11-2019 13:25:24	60 3b dc e6	0	868100000	7	-121
Monday 18-11-2019 13:23:32	26 01 11 44	0	868100000	7	-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 · November 18, 2019, 12:57pm

al1fch:
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:16 26 01 11 44 0 868100000 7 -75

Monday 18-11-2019 13:25:24 60 3b dc e6 0 868100000 7 -121

Monday 18-11-2019 13:23:32 26 01 11 44 0 868100000 7 -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
là ?

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 · November 18, 2019, 1:04pm

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 !!!

LoRa.begin(869500000)

ou

LoRa.begin(870000000)

Voilà la bande et les puissances autorisées

Lacuzon · November 18, 2019, 1:08pm

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 · November 18, 2019, 1:10pm

al1fch,

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

Artouste · November 18, 2019, 1:12pm

al1fch:
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 !!!
LoRa.begin(869500000)
ou
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 · November 18, 2019, 1:16pm

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 · November 18, 2019, 3:44pm

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 · November 19, 2019, 3:27pm

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 · November 19, 2019, 4:13pm

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

github.com/sandeepmistry/arduino-LoRa

Sync word issue

opened 10:18AM - 28 Apr 17 UTC

tigoe

Sync word checking appears to be inconsistent. (I'm using a variation of the LoR…aReceive sketch here, not the callback sketch). What follows is a set of collected findings and questions, but unfortunately not a solution (sorry). Using two radios, I set the sync word of one to 0xAA and the other variable. I ran through all values from 0x01 to 0xFF. The following "matched" with 0xAA: `a8, a7, a6, a5, a4, a3, a2, a1, a0, 9d, a8, a9, aa, ab, ac, ad, ae, af, b0, b3, a2, a3, a4, a5, a6, a7, a8, a9, aa, ab, ac, ad, ae, af, b0, b3, b4, b5, b9, bc, c3, c5, c6, c9, ca, d3, d6, d7, d9, e3, e8, ea, f0, f7, 13, 1a, 2c, 2f, 33, 36, 39, 3a, 43, 44, 45, 46, 4f, 5d, 67, 69, 6f, 70, 7a, 7c, 7f, 88, 89, 8e, 94, 95, 9e, a3, a4, a5, a6, a7, a8, a9, aa, ab, ac, ad, ae, af, b0` It seems like the device should be in sleep mode when you set the sync word, so perhaps it would make sense to wrap the writeRegister() in setSyncWord() in a call to sleep mode, then return the radio to its normal mode before the function is over. Also, "The bit synchronizer must also be activated in Continuous mode (automatically done in Packet mode)" (from the [Semtech datasheet](http://www.semtech.com/images/datasheet/sx1276.pdf)), which makes me wonder if sync word detection doesn't work in single receive mode? The HopeRF datasheet is unclear on this, and doesn't even detail the LoRa mode registers. It is worth noting somewhere in the docs that single receive mode is intended for battery operation, and continuous receive mode consumes more power, and is intended for non-battery operation. Will test more when I've got the hardware in hand again.

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

Lacuzon · November 19, 2019, 5:03pm

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 · November 19, 2019, 5:13pm

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 · November 19, 2019, 6:47pm

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

system · May 6, 2021, 3:26pm