tu disposes librement de 8 kilo octets dans cette RAM particulière restant almentée pendant le deep sleep !
Me souviens pu... trop vieux (le post, pas moi... quoique)
Mais il y a peut-être quelque chose à creuser ici :
Trouvé !
Il existe un exemple avec la librairie qui fourni les OFFSET :
Bon il ne me reste plus qu'un problème... le INT PIN ne change jamais d'état...
J'ai testé avec une LED et c'est pas en rapport avec le setInterruptMode, dans les 2 sens, une LED connecté au INT ne change pas d'état quand on bouscule le MPU6050.
@lesept pour ta station météo quelle était ton critère de sensibilité (humainement parlant)... Je veux dire, pour que ça s'allume, il faut le retourner ? juste le pencher ? juste le toucher ?
EDIT : Le INT est en 3.3V... j'imagine que ça ne suffit pas à passer l'entrée de l'ESP à HIGH...
EDIT 2 : ...rien à voir, je suis juste un boulet qui ne sait pas câbler 
EDIT 3 : je vais pouvoir entrer dans la phase de réglage des capteurs PIR et MPU afin de trouver la sensibilité qui me va bien... et pour le MPU va falloir que ça soit très subtil
Pas trop quand même sinon le passage d'un camion dans la rue va déclencher l'alarme.
INT est en 3.3V... j'imagine que ça ne suffit pas à passer l'entrée de l'ESP à HIGH...
ça suffit largement
Si l'entrée n'est pas considrée comme étant en état haut avec 3,3V elle ne le sera jamais 
data sheet ESP32, p 46 : une tension supérieure à 3/4 de la tension d'alimentation fait un bon état haut
2,48V suffisent donc, c'est le VIHmin, le VIH max étant 3,6V pour un ESP32 alimenté en 3,3V
Par la data Sheet (p 46 et 47) Espressif dégage sa responsabilité en cas de tension supérieure à 3,6V appliquée sur un GPIO ou sur l'alimentation VDD
1 Like
Ca se voit dans la vidéo : je cherchais à détecter un changement d'orientation, dont une rotation de 90°. Mais ça n'a rien à voir avec le réveil qui est fait lorsque le MPU détecte au dessus d'un certain seuil pendant une certaine durée :
1 Like
Merci,
Je viens de tester la liaison LoRa et c'est vrai que c'est mieux en terme de fiabilité, portée et traversement des murs.
J'arrive à envoyer de ma place de parking jusqu'à chez moi, mais c'est pas encore à l'intérieur du véhicule.
En revanche je ne comprends pas comment ça peut être blindé aux parasites si il n'y a pas d'appairage entre les 2 équipements...
tout dépend ce qu'on mets sous le terme 'parasites'
L'appairage augmenterait la sécurité
Lora passera mieux que d'autres modulations radio dans un environnement très bruité et chargé en signaux radio de même fréquence, en 868 MHz ça commence à devenir dense. en particulier avec les Verisure et autres qui utilsent maintenant cette bande ISM pour les capteurs multiples
La modulation radio Lora produit également des signaux très particuliers qui peuvent être extraits du bruit .......s'ils ne sont pas trop en dessous du niveau de bruit (chose impensable pour les modulations radio basiques en amplitude, fréquence ou phase)
D'autre part la correction d'erreur passe pour être efficace
Pour maximiser la portée avec le matériel dont tu dsposes pousses au maxi le paramètre puissance d'émission ainsi que SF, le facteur d'étalement, soignes également le positionnement des antennes
Comme je disais plus haut, tu n'as pas une grande diversité de données à transmettre. Au minimum, un signal qui indique une détection de situation anormale par un des capteurs, mais tu peux avoir aussi d'autres informations à transmettre (à voir).
Dans le cas minimal, tu peux décider d'envoyer un bit à 1 lors de la détection. Tu comprends aisément que s'il y a des parasites, tu vas recevoir ce '1' très souvent et tu ne sauras jamais s'il s'agit d'une vraie ou d'une fausse alarme. Tu vas passer tes soirées dans l'ascenseur... 
Par contre, si tu décides que le signal de détection est 0x73795F1EC4DA (12 octets donc une suite déterministe de 96 bits). Lorsque tu reçois un signal sur ton récepteur et que ce signal ressemble (par exemple) à 90% au signal de détection ci-dessus (c'est à dire que 90% des 1 et des 0 sont bien placés), il est fort probable que c'est une vrai alarme et pas du bruit de communication.
Tu as ainsi robustifié ta liaison. Pour moi, c'est ça être "blindé aux parasites". Ca ressemble à de l'étalement mais en donnée et pas en fréquence.
Oui, @lesept
Profiter de la robustesse du 'véhicule' LoRa (étalement de fréquence de type chirp, CRC....) pour lui faire transporter dans sa trame une charge utile ('payload') conçue pour ajouter de la robustesse à la communication !
En ajoutant un accusé de réception , réémission sans reception de l'accusé de réception, ça devrait le faire même dans les situations où le signal d'alarme entre en collision avec d'autres signaux forts sur la même bande ISM
recevoir toutes les alertes et éviter les faux positifs !!
Bonjour
Augmenter la portée ?
Quelle valeur de SF (Spreading Factor) utilises tu actuellement ? (la valeur par défaut ?)
il me semble que les exemples de base utilsent une valeurpar défaut plutôt basse (SF7 ?) ne favorisant pas la portée.
Une valeur élevée comme SF12 a pour effet d'augmenter la sensibilité du récepteur dont la portée..... avec comme conséquence un allongement de la durée des trames émises et donc une réduction de l'autonomie. Compromis à trouver dans chaque cas particulier....
ici un tableau montrant l'impact de SF sur la portée, le débit et la durée d'émission d'un message de 11 octets
L'exemple LoRaSetSpread.ino de la bibliothèque arduino-LoRa montre comment imposer une valeur de SF entre 6 et 12 (la valeur doit être identique aux deux bouts !)
LoRa.setSpreadingFactor(12);
Merci à vous, je vais tester le SF8 dans un premier temps.
Par contre je me pose des questions existentielles sur la façon de communiquer et le protocole à utiliser, afin d'économiser sur la longueur de la trame, je compte écrire un mot en HEXA, par exemple :
A123B1C
Qui exprimerait :
A: début de trame
123 : valeur batterie
B : Séparateur pour raison du réveil :
1 : 1=PERIOD / 2=PIR / 3=MPU
C : Fin de trame
J'envoi le mot 3 fois et le récepteur les compare afin de pouvoir en confirmer la conformité.
Par contre je galère entre LoRa.print et LoRa.write, je n'arrive pas à savoir ni le quel utiliser ni quelle syntaxe utiliser pour envoyer mon "mot" binaire.
LoRa.write(0xA123B1C);
...ne semble pas fonctionner.
certainement pas une réponse totale et définitive pour ton code, mais la fonction semble attendre du uint8_t.
Plutot passer par une string de type char message[] = uint8_t lettre_1, uint8_t lettre_2 .....} et composer ton message à l'intérieur.
Tu pourras toujours le re découper à l'arrivée, et comme tu as bien réduit tes infos à transmettre au minimum, tu n'auras pas de soucis de taille de donnée avec un 8bit.
chopé ici: arduino-LoRa/LoRa.h at master · sandeepmistry/arduino-LoRa · GitHub
En fait, je voudrai composer mon message en une suite des mots de 4 bits (uint4) ...donc il faut que je les couplent pour former des mots de 8 bits (uint8).
Mon mot :
AA1234B1CC
Peut en fait être décomposé en byte :
AA-12-34-B1-CC
Mais du coup je dois écrire une mécanique de composition/décomposition du message...
à moins de faire tenir tout dans un byte, tu n'y "couperas" pas (huhuhu).
Plus sérieusement, y'a des ruses mathématiques qui pourraient te l'éviter, mais il faut regarder soigneusement l'ensemble des possibilités de message qui peuvent être générées.
Si je reste sur une valeur max de 8bit, j'ai quand même 256 valeurs différentes disponibles.
Une représentation raisonnable du pourcentage de batterie met déjà le bazar dans mes projets, mais imagine qu'on parle en "dizaine de pourcent", j'ai plus que 10 valeurs différentes (0%, 10%, 20%...). Si je multiplie par ta proposition de "raison de réveil" (de 1 à 3) j'ai 30 valeurs disponibles, mais des recouvrements existent, et on en veut pas (par exemple tu reçois 90 en valeur: est-ce que c'est réveil MPU * 30% de batterie ou réveil PERIOD * 100% de batterie?)
du coup ruse: je mets ta raison de réveil dans les centaines:
0 pour Period, 1 pour PIR et 2 pour MPU.
je mets la valeur de "dizaine de % batterie" en lieu de dizaines et d'unité: tadam!
exemple:
210: réveil MPU et 100% de batterie
003: réveil period et 30% de batterie.
C'est qu'un exemple, le tout c'est de pas avoir 2 résultats identiques qui traduisent des configuration différentes (recouvrement) et assez de place pour tout faire tenir dans un nombre inférieur à 255.
Et ça n'empêche que ton récepteur devra connaitre ta manière de "crypter" et bien sur être capable de revenir aux valeurs initiales.
1 Like
Merci pour vos retours, ça fait bien réfléchir sur le protocole.
Pour éviter les interférence, y compris avec d'autre LoRa, il existe ça :
// Change sync word (0xF3) to match the receiver
// The sync word assures you don't get LoRa messages from other LoRa transceivers
// ranges from 0-0xFF
LoRa.setSyncWord(0xFF);
Bon j'ai cramé un LoRa et son ESP32 en voulant faire une mesure de tension 
Du coup je suis retourné sur l'aspect Sleep PIR et MPU et j'ai trouvé des réglages qui me vont bien pour le réveil via MPU :
accelgyro.setDHPFMode(MPU6050_DHPF_5);
accelgyro.setMotionDetectionThreshold(2); // Threshold in 2mg (ajouté by me)
accelgyro.setMotionDetectionDuration(5); //Duration in ms
accelgyro.setAccelerometerPowerOnDelay(1); // Set accelerometer power-on delay
accelgyro.setFreefallDetectionCounterDecrement(1); // Set Free Fall detection counter decrement
accelgyro.setMotionDetectionCounterDecrement(1); // Set Motion detection counter decrement
J'ai aussi commandé un SIM800 qui pourrait remplacer la liaison LoRa, en simplifiant le tout, je l'espère.
tu m'intéresses. C'est le genre de module qui pourrait me servir dans un futur proche mais je suis trop lâche pour me lancer tout seul.
De mémoire c'est un module qui demande du 5V (et donc ne tournera pas en +3,3V selon ta carte).
T'as bien du réseau téléphonie à l'intérieur du garage ? voir même à l'intérieur de la voiture?
Et puis penses bien à la facturation, si jamais tu payes au texto et que tu as mis un déclenchement très sensible.
LA consommation n'est pas la même qu'avec un module Lora je crois.
Attention aussi à la durée de vie de ce type de service de téléphonie.
bonjour
j'utilse souvent LoRa (en fait LoRaWAN , pas le LoRa en pointà point)
j'utilse encore un peu le SIM800 (duex types de cartes, une petite carte rouge très coutante et une carte EVB supportant une alimentation 5V)
Pour bien fontionner les modules et cartes SIM800 gagnent à être alimentés directement autour entre 3,3V et 4,1V avec un accu LI-ON. (SIMCOM a conçu son module pour ce type d'alimentation)
- Il faut pouvoir fournir au module des brèves pointes de courant dépassant 1A !!**
Je n'ai plus le moindre défaut de fonctionnement en soudant un condensateur (1000µF à 4700µF) sur les bornes d'alimentation de la carte SIM800 , ce dernier alimenté en, avec des fils courts, par un accu Li-On 3,7V de 5000mAh!
Niveaux logiques ? le SIM800 (=module sous capot métallique), contient ses propres régulateurs de tesnion et accepte tout à fait des liaisons Rx et TX sous 3,3V,
Voilà un montage qui bien fontionné dans le passé à la belle saison et que je vais remettre en service ayant maintenant la possibilité de lui donner une bonne exposition au rayonnement solaire
Je profite ici du TP4056 et d'un regulateur de tension 3,3v réellement'Low drop) sur la carte Lolin D32 Lite.
( Il me semble , pour cet assemblage, avoir tenu compte des spécifications , schémas de tous les éléments, data sheet par datasheet )
Veille : Apès avoir envoyé les données (publication MQTT dans mon cas ) je mets , par une commande AT+CSCLK=2 en veille le SIM800 sans qu'il perde totalement sa connection au réseau, place ensuite l'ESP32 en deep Sleep, ce dernier se chargeant , à son réveil de réveiller le SIM800. (AT puis immédiatement AT+CSCLK=0 )
Conso quand tout le mode veille (ESP et SIM800) ? 2mA (environ 20 fois plus qu'un ESP32+ module LoRa en sommeil)
Même avec cela , pour un accu de capacité donnée l'autonomie de la solution LoRa est bien meilleure que la solution GSM/GPRS qui pour sa connertivité au réseau a besoin de davantage de puissance
Les jours du réseau GRPS sont comptés. L'échéance de la fin du roaming 2G de Free vers Orange aussi.
On n'a donc pas ici une solution d'avenir
par ailleurs les modules 4G SIM7xxx sont encore d'un coût élevé 
Merci pour toutes ces infos.
Le gros point fort du SIM800 pour moi est la simplicité du dispositif de réception : mon téléphone.
Je ne compte pas lui faire envoyer des SMS mais uniquement déclencher des appels
@al1fch A-t-on vraiment besoin de laisser le SIM800 en veille ?
Faut-il un abonnement pour LoRaWAN ?