Si nous fabriquions Notre balise?

**Tr@nquille** · 15/03/2021, 16h21

je t'avouerais que je n'ai pas trop creusé le BT, va falloir s'y mettre :-(

**ModHélic** · 15/03/2021, 16h40

Correction. Au deuxième essai de connexion, il dit qu'il s'est bien connecté au récepteur dont il me donne le nom mais ne remplit aucun champ et, au bout de quelques secondes (10, 15, 20 ?) il dit qu'il s'est déconnecté.
A chaque nouvel essai pareil jusqu'à redémarrage du smartphone

**ModHélic** · 15/03/2021, 17h17

Encore une correction !

Cette fois, mon smartphone a repris l'apk normalement après juste un redémarrage (pas d'arrêt complet). Mais il a planté juste après.

Sur la balise, j'ai carrément supprimé le champ 7 puisque je n'envoie pas la hauteur (feignant, oui, je sais !). Déjà, sur cette trame, le champ 3, qui correspond à l'identifiant des balises intégrées dans le modèle, n'est tout simplement pas cité. Donc il semble logique d'en faire autant ... d'autant plus que c'est beaucoup plus facile !!!

Sur le serveur oueb, pas de souci : la hauteur est restée citée mais pas renseignée (...).
Mais l'appli apk m'a dit qu'elle cherchait le champ 14 d'une appli qui ne lui en fournissait que 13 ... Par contre, l'appli .apk ne s'est pas trompée sur les renseignements des champs suivant le champ 7 ... peut-être l'arrêter sur le n° du dernier champ et pas sur le nombre de champs ?

JC

**Tr@nquille** · 16/03/2021, 08h34

Salut @ModHélic

pour le BT est-ce que tu peux regarder dans ton récepteur (si tu n'utilises pas mon dernier code) cette ligne:

Code:

BLEDevice::setMTU(256);

il y a un certain temps j'avais oublié de mettre 256, il faut mettre 256 déjà.
Sinon, je suis en train d'approfondir BT car mon collègue a le même genre de comportement sur certains tél et pas d'autres...

pour le reste, je ne comprends pas. Tu as enlevé la hauteur côté balise ok, mais de toute façon côté récepteur, il reconstruit les données selon ce qu'il trouve dans la trame sniffée. S'il ne trouve pas la hauteur de toute façon il remplit cette zone avec "..."

donc au final, que ce soit côté web ou BT, ce sont les mêmes infos qui sont envoyées, et il y a toujours 14 champs car c'est moi qui les génère.

Je redis le système que j'utilise:
le sniffeur attrape la trame de la balise, la passe dans une moulinette pour l'éclater.
cette moulinette construit un tableau (en gros, en fait c'est une chaine séparée par des espaces) de 14 éléments, chaque élément a une valeur par défaut ("...") et cette valeur est écrasée si l'éclatement de la trame reçue contient quelque chose pour un champs donné. Il y a 14 champs car en plus de ceux de la balise, il y a aussi les infos wifi.
ensuite ce tableau est envoyé au site web et à l'apk.
le site web l'affiche en l'état, c'est pourquoi on peut avoir "..." dans la hauteur si la balise n'a pas émis de hauteur.
l'apk teste si la hauteur est un nombre, et si non, elle la calcule autrement pour faire bref.

**fanfanlatulipe26** · 16/03/2021, 09h37

Envoyé par MathJea

je n'ai fait qu'une balise avec l'ESP01S, elle fonctionne, pas encore fait d'essai en vols avec mes balises, le hic avec l'ESP01 est pour la reprogrammer, du moins, faut du coup passer par le fer à souder.

La réalisation me pose aussi un problème car l'ESP01 n'est pas très facile à intégrer si on veut pouvoir le reprogrammer (d'où l’intérêt d'avoir un mini serveur web pour faire une mise à jour OTA comme je l'ai fait dans mon adaptation du soft)
Ce qui complique l'affaire c'est que pour le reprogrammer il faut mettre la pin 0 à la masse lors d'un reset: hors cette pin est une SORTIE du GPS est il n'est pas sûr du-tout qu'il apprécie ce court circuit si on ne désolidarise pas la sortie du GPS avant de mettre la pin 0 à la masse.
Pour l'accès aux pins, un module ESP12 est peut être plus facile à intégrer mai les soudure deviennent scabreuses à faire