Labomedia Ressources

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Réalisation d'un kit de test du signal LoRa ======

{{ media_06:lora_signal_test_kit.jpg?direct&600 |}}

Réalisation d'un kit de test LoRa composé de 2 modules émetteur/récepteur [[ e45-ttl-100 ]]. Le but est de tester les capacités de transmission du protocole LoRa en zone urbaine.

{{ media_06:lora_signal_test_kit_tracker.jpg?direct&600 |}}

Un premier module portable, "le tracker", émet un message que l'on appel un "ping" et attend une réponse. Si une réponse arrive, alors on sait que le lien radio est possible et on peut mesurer le temps de réponse. Ce module est équipé d'un écran pour afficher les informations relatives à la qualité du signal radio.

{{ media_06:lora_signal_test_kit_repeater.jpg?direct&600 |}}

Le second module, "le répéteur",  attend perché en hauteur dans un endroit approprié de récevoir un message pour émettre une réponse.


Les modules [[ e45-ttl-100 ]] ne permettent pas de mesurer la puissance du signal radio (RSSI ou SNR), néanmoins, ils disposent de différents débits (air rate) configurable. Pour rappel, avec LoRa, plus le débit est grand plus la portée du signal est faible. Le problème est que les différents débits sont strictement incompatbles. Nous allons donc essayer de quantifier la puissance du signal en fonction du débit que les deux modules peuvent atteindre pour communiquer.

===== Materiel =====
  * 2 ESP32 [[ esp32_devkit ]]
  * 2 modules LoRa [[ e45-ttl-100 ]]
  * 2 modules d'alimentation USB breadbord 5V 3.3V
  * 1 écran TFT 240x240 px : le ST7789


===== Cablage =====

Il faut noter que l'on utilise également le GPIO2 en sortie pour controller la LED de l'ESP32.

==== Module e45-ttl-100 ====
On communique avec le module e45-ttl-100 via une liaison serie asynchrone (UART). Il faut alimenter le module, la puissance fournie par le micro controlleur est insuffisante. Il y a en outre 2 bit pour selectionner le mode du module et 1 sortie pour 

Sur le module e45-ttl-100 antene vers le haut, de gauche à droite :
  - M0   =>  GPIO19
  - M1   =>  GPIO21
  - RX   =>  GPIO17 (UART TX2)
  - TX   =>  GPIO16 (UART RX2)
  - AUX  =>  GPIO5
  - VCC  =>  +5V
  - GND  =>  GND


==== Ecran TFT 240px x 240px ST7789 ====
On communique avec l'écran via une liaison série synchorne (SPI). Je n'ai pas réussi à utiliser le SPI hardware pour l'occasion, j'utilise donc une SPI Software.

Sur l'écran connections en bas, de gauche à droite :
  - Blank  =>  pas utilisé ni connecté
  - DC     =>  GPIO15 (SPI Slave Select)
  - Reset  =>  GPIO4
  - SDA    =>  GPIO23 (SPI MOSI)
  - SCL    =>  GPIO18 (SPI Serial Clock)
  - VCC    =>  +3.3V
  - GND    =>  GND

===== Algorithme de négociation du débit radio (air rate) =====
Deux débits différents sont incompatibles pour les transmission radio. Il n'est pas possible avec les modules [[ e45-ttl-100 ]] d'écouter et de déterminer le débit de la communication reçu. Nous implémentons donc un protocole modeste de négociation du débit radio.

Le principe est le suivant pour le module tracker :
  - Initialisation d'une session avec le débit le plus faible possible pour maximiser les chances que le message puisse etre reçu
  - Emission d'un message (ping) contenant l'identifiant de la session et un numéro de séquence
  - Attente d'un message accusant réception (ack) pendant au maximum un temps "ack_timeout"
  - Si récéption d'un accusé de réception valide, on incrémente le numéro de séquence et on émet un nouveau message (retour au point 2)
  - Si on a déjà reçu N accusés de récéptions valide on indique dans le prochain message que l'on souhaite augmenter le débit de transmission
  - Si on a réçu 2 messages accusant réception d'une augmentation de débit, alors on augmente le débit
  - Si pas d'accusé de réception on réémet le message (retour au point 2)
  - Si pas de réception de message lisible depuis au moins un temps "too_fast_timeout" on réduit le débit de transmission et on réémet le message (retour au point 2)
  - Si pas de reception de messages lisible depuis au moins un temps "link_dead_timeout" on reinitialise la session (retour au point 1)

Le principe est le suivant pour le module répéteur :
  - Configuration du plus bas débit de transmission
  - Attente de la réception d'un message lisible
  - Si réception d'un message valide initialisant une nouvelle session, alors on initialise une session coté repeteur et on incrémente le numéro de séquence.
  - Si réception d'un message valide correspondant à une session en cours alors on incrémente le numéro de séquence.
  - Emission d'un acquitement avec le meme identifiant de session et le numéro de séquence.
  - Si réception de 2 demandes d'augmentation de débit on augmente le débit de transmission.
  - Après avoir émis un message on attent la réception d'un nouveau message (retour au point 2)
  - Si pas de réception de message lisible depuis au moins un temps "too_fast_timeout" on réduit le débit de transmission et on attend la reception d'un message (retour au point 2)
  - Si pas de reception de messages lisible depuis au moins un temps "link_dead_timeout" on reinitialise le débit de transmission (retour au point 1)


===== Code source =====
J'ai utilisé un ESP32 programmé avec l'IDE Arduino.

Le code source est actuellement sur mon githib ici : [[ https://github.com/mxbossard/laperco-capteurs/tree/master/arduino_sketches/lora_signal_test_kit ]]

Je n'ai pas trouvé de driver pour le module [[ e45-ttl-100 ]] j'ai donc implémenté laborieusement un driver avec quelques fonctions. Les 2 modules tracker et répeteur sont codés dans le meme sketch. Il faut commenter ou décommenter la ligne "#define REPEATER" pour compiler le code de l'un ou l'autre des modules.

{{tag>sans_fil realisations_materielles realisations_logicielles laperco max}}