Outils pour utilisateurs

Outils du site


max_lorawan_tracker

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision
Révision précédente
max_lorawan_tracker [2019/02/05 12:39] – [Le RFM95 de la Chistera Pi] bigMaxmax_lorawan_tracker [2020/02/04 16:19] (Version actuelle) – ↷ Liens modifiés en raison d'un déplacement. serge
Ligne 7: Ligne 7:
   * Utiliser un module GPS pour la première fois   * Utiliser un module GPS pour la première fois
   * Utiliser un [[ RFM95 ]] pour la premiere fois   * Utiliser un [[ RFM95 ]] pour la premiere fois
-  * Dépasser le duty cycle LoRaWAN pour permettre au tracker d'émettre beaucoup de messages +  * Installer une infrastructure capable de dépasser le TTN Fair Access Policy.
-  * Dépasser les 10 messages quotidiens autorisés par TTN+
  
 ===== Cablage ===== ===== Cablage =====
 +
 +J'ai envie de continuer à bricoler avec les ESP32, donc malgré que la Chistera Pi soit un shield Raspberry Pi, je vais la piloter avec un ESP32. 
 ==== Le RFM95 de la Chistera Pi ==== ==== Le RFM95 de la Chistera Pi ====
-{{ :max:chistera_pi_rfm95_pinout.png?direct&150|}}+{{ media_06:chistera_pi_rfm95_pinout.png?direct&150|}}
  
-cf [[ rfm95#la_chsitera_pi ]]+cf [[ rfm95#la_chsitera_pi  | La Chistera Pi]]
  
   * MOSI => Chistera Pi Pin 19 (Rasp Pi GPIO10) => ESP32 GPIO19   * MOSI => Chistera Pi Pin 19 (Rasp Pi GPIO10) => ESP32 GPIO19
Ligne 24: Ligne 25:
   * 3.3V => Chistera Pi Pin 17 (Rasp Pi 3V3)   * 3.3V => Chistera Pi Pin 17 (Rasp Pi 3V3)
   * DIO0  => Chistera Pi Pin 07 (Rasp Pi GPIO4) => ESP32 GPIO21   * DIO0  => Chistera Pi Pin 07 (Rasp Pi GPIO4) => ESP32 GPIO21
-  * DIO1  => Chistera Pi Pin 16 (Rasp Pi GPIO23) => ESP32 GPIO3 +  * DIO1  => Chistera Pi Pin 16 (Rasp Pi GPIO23) => ESP32 GPI26 
-  * DIO2  => Chistera Pi pin 18 (Rasp Pi GPIO24) => ESP32 GPIO1+  * DIO2  => Chistera Pi pin 18 (Rasp Pi GPIO24) => ESP32 GPI27
  
 Nous avons besoin d'alimenter le shield grace au pins **GND** et **3.3V**. Nous avons besoin d'alimenter le shield grace au pins **GND** et **3.3V**.
Ligne 34: Ligne 35:
  
 ==== Ecran TFT 240x240 px  ST7789 ==== ==== Ecran TFT 240x240 px  ST7789 ====
-{{ :max:tft_240px_screen.jpg?nolink&200|}}+{{ media_06:tft_240px_screen.jpg?nolink&200|}}
  
-  * SDA (SPI MOSI) => ESP32 GPIO19 +  * SDA (SPI MOSI) => ESP32 GPIO19 (ou GPIO12 si on utilise 2 ports SPI différents) 
-  * SCL (SPI SCLK) => ESP32 GPIO18+  * SCL (SPI SCLK) => ESP32 GPIO18 (ou GPIO14 si on utilise 2 ports SPI différents)
   * DC (SPI SS) => ESP32 GPIO15   * DC (SPI SS) => ESP32 GPIO15
   * Reset => ESP32 GPIO22 (voir si elle est utilisable)   * Reset => ESP32 GPIO22 (voir si elle est utilisable)
 +  * BLK => not connected
   * GND   * GND
   * 3.3V   * 3.3V
 +
 +<WRAP center round important 60%>
 +Je n'ai pas réussi à driver correctement les 2 modules (lora et écran) sur le meme port SPI, donc j'ai déplacé l'écran sur le port HSPI.
 +</WRAP>
  
 ==== Groove GPS ==== ==== Groove GPS ====
-{{ :max:groove_gps_module.jpg?nolink&200|}}+{{ media_06:groove_gps_module.jpg?nolink&200|}}
  
 Le module Groove GPS communique avec un port serie asynchrone. Le module Groove GPS communique avec un port serie asynchrone.
Ligne 54: Ligne 60:
   * 3.3V   * 3.3V
  
 +===== Programmation =====
 +==== Arduino-LMIC ====
 +  * cf [[ https://github.com/matthijskooijman/arduino-lmic ]]
 +  * cf [[ https://github.com/mcci-catena/arduino-lmic ]]
 +  * cf LMiC v1.5 doc: {{ media_06:lmic-v1.5.pdf |}}
 +
 +Configuration du cablage :
 +<code c>
 +const lmic_pinmap lmic_pins = {
 +    .nss = 5,
 +    .rxtx = LMIC_UNUSED_PIN,
 +    .rst = 4,
 +    .dio = {21, 26, 27},
 +    // optional: set polarity of rxtx pin.
 +    .rxtx_rx_active = 0,
 +    // optional: set RSSI cal for listen-before-talk
 +    // this value is in dB, and is added to RSSI
 +    // measured prior to decision.
 +    // Must include noise guardband! Ignored in US,
 +    // EU, IN, other markets where LBT is not required.
 +    .rssi_cal = 0,
 +    // optional: override LMIC_SPI_FREQ if non-zero
 +    .spi_freq = 0,
 +};
 +</code>
 +
 +Attention, il faut appeler SPI.begin() en fournissant le cablage du SPI pour le module RFM95. Le moment opportun est lors du setup() du code arduino.
 +<code c>
 +    // Configure SPI
 +    SPI.begin(18, 23, 19, 5);
 +</code>
 +
 +==== Pseudo code ====
 +  - Boot
 +  - Affichage du dernier évenement MAC (LoRaWAN) : néant et du statut GPS : "acquisition en cours ..."
 +  - Boucle infini
 +    - Acquisition des coordonnées GPS / Attente de coordonnées valides
 +    - Scheduling d'un envoie d'une payload CayenneLPP contenant les coordonnées GPS au maximum une fois par minute
 +    - Affichage des coordonnées GPS + affichage du dernier evenement MAC (LoRaWAN) retourné par LMIC
 +
 +==== Problèmes ====
 +Pour le moment je n'ai pas réussi à convenablement interfacer l'écran et le module lora sur le même port SPI. Soit le code du module LoRa crash, soit l'écran crash, mais je n'arrive pas à faire cohabiter les 2 devices sur le même port SPI. J'ai tenté de changer la librairie utilisé pour l'écran. 
 +\\
 +De plus, j'étais incapable d'utiliser la librairie Adafruit avec un port SPI hardware. Seul le SPI software fonctionnait. Je l'ai donc remplacé par la lib de Bodmer TFT-eSPI qui est capable de driver beaucoup d'écrans différents et est conçu pour fonctionner avec l'ESP.
 +\\
 +Même avec cette nouvelle librairie, je n'arrive toujours pas à faire cohabiter les 2 devices. Je pense donc changer mon cablage pour utiliser les 2 SPI hardware disponible sur l'ESP32. J'ai tenté plusieurs tweek sans succès :
 +  * Désactiver les interruptions de LMIC (il me semble que c'est indispensable pour éviter les conflits sur le port SPI)
 +  * Forcer la fin des transactions SPI avant de changer de slave
 +Il est possible que ce ne soit pas mon utilisation qui pose problème, mais les drivers eux même qui ne permettent pas de passer un port SPI pour coordonner son utilisation.
 +
 +===== Configuration TTN =====
 +  * Création d'une application dans TTN : pas de problème
 +  * Création d'un device dans TTN : pas de problème
 +  * Pour ABP et OTAA, il faut faire attention à copier les clés dans le bon sens (soit little ou big endian) dans le sketch Arduino.
 +  * Le tracker utilisera ABP ou OTAA ? De préférence OTAA, mais il est probablement problématique de faire plusieurs join. Il faudrait etre capable de conserver l'Id de session entre les reboot de l'ESP32 pour eviter les join successifs.
 +
 +
 +===== Notes =====
 +  * Duty Cycle 1%
 +  * Coordonnées GPS avec CyaenneLPP : 11 octets
 +  * TTN Fair Acces Policy limite à 30 sec / jour / device le uplink. et 10 messages downlink / jour / device cf [[ https://www.thethingsnetwork.org/forum/t/limitations-data-rate-packet-size-30-seconds-uplink-and-10-messages-downlink-per-day-fair-access-policy/1300 ]]
 +  * En comptant transmettre 11 octets de données GPS par message, on calcul un temps d'émission de 87ms pour SF7 jusque 1975ms pour SF12. La TTN Fair Access Policy autorise donc 347 messages/jour/device en SF7 jusqu'à 15 messages/jour/device en SF12. 
 +
 +===== Ressources =====
 +  * Utilisation de arduino-lmic sur un esp32 : [[ https://nathanmcminn.com/2018/09/12/tutorial-heltec-esp32-board-the-things-network/ ]]
 +  * Plus de code : [[ https://www.weargenius.in/amp/esp32-lorawan-node-using-arduino/ ]]
 +  * TTN threads: [[ https://www.thethingsnetwork.org/forum/t/big-esp32-sx127x-topic-part-1/10247 ]] [[ https://www.thethingsnetwork.org/forum/t/big-esp32-sx127x-topic-part-2/11973/845 ]] [[ https://www.thethingsnetwork.org/forum/t/big-esp32-sx127x-topic-part-3/18436 ]]
 +  * ABP vs OTAA : [[ https://www.thethingsnetwork.org/forum/t/what-is-the-difference-between-otaa-and-abp-devices/2723 ]]
  
 {{tag>sans_fil realisations_materielles realisations_logicielles laperco max}} {{tag>sans_fil realisations_materielles realisations_logicielles laperco max}}
max_lorawan_tracker.1549370366.txt.gz · Dernière modification : 2019/02/05 12:39 de bigMax