Discussion Si nous fabriquions Notre balise?
- Initiateur de la discussion F1FNW
- Date de début
Tr@nquille
Eternel débutant
donc il manque dans le dossier le fichier droneID_FR.h
dans le principe, pour utiliser ce sketch, il faut:
créer un dossier nommé exactement du nom du fichier sans le .ino
y mettre dedans le fichier .ino et le fichier droneID_FR.h
exemple:
nom du dossier: balise_dgac_web
dans le dossier: balise_dgac_web.ino et droneID_FR.h
pour commencer
dans le principe, pour utiliser ce sketch, il faut:
créer un dossier nommé exactement du nom du fichier sans le .ino
y mettre dedans le fichier .ino et le fichier droneID_FR.h
exemple:
nom du dossier: balise_dgac_web
dans le dossier: balise_dgac_web.ino et droneID_FR.h
pour commencer
Tr@nquille
Eternel débutant
ModHélic;2703504 à dit:
en fait, ça serait intéressant de voir comment fonctionne la naveol pour le wifi...
vu les potentiels dangers de laisser le wifi s'annoncer tout le temps, je pense qu'ils masquent le ssid dès que le fix est fait, ou qu'il le supprime et en créent un autre caché...
en tout cas, j'ai pas mal parcouru les docs pour le wifi, les api etc, et je n'ai pas vu de solution pour émettre des trames beacon sans avoir le wifi et une AP actifs, sur nos balises esp8266 (esp01s)
on perd de vue le principe de cette balise:
chaque balise émet des trames sur le canal 6 (pour celles qu'on peut passer d'un modèle à l'autre, restons simples) et c'est tout, pas de wifi en vol pour se connecter dessus et contrôler la balise, pas de sauvegarde ou quoi que ce soit d'autre dans la balise, suivant la norme en tout cas.
du coup, la seule chose importante pour identifier une balise, c'est son ID complet, vu dans la trame.
je suis en train de penser que si on veut quelque chose de notre côté pour vérifier que tout est ok, c'est du côté du récepteur qu'il faut agir, pas du côté de la balise qui doit rester très simple donc.
ce qu'il faut aussi voir, c'est que du côté du récepteur, nous on pense une balise donc une trame toutes les 3s (restons simple aussi), mais dans la réalité, plusieurs balises, toutes sur le canal6, donc plusieurs trames qui arrivent les unes "derrière" les autres et encore (certaines pourraient être émises en même temps, mais pas de bol là ahahah).
donc dans l'absolu, il faudrait un récepteur qui scanne le canal 6 wifi, qui récupère toutes les trames reçues, qui les classe par identifiant.
j'ai pas essayé encore avec deux balises en route pour voir comment se comporte l'appli smartphone...
en ce qui concerne l'identifiant donc, quelqu'un qui va contrôler va récupérer la trame, l'identifiant dedans, puis va avoir une connexion sur alphatango pour récupérer le propriétaire, le type de modèle, et les modèles associés à cette balise, je pense.
Il faut donc dans l'absolu qu'une balise corresponde bien à un type.
Et pour savoir laquelle de nos balises va pouvoir équiper un modèle, soit on l'écrit sur la balise, soit on la met en route et on récupère la trame, donc l'id... et donc effectivement c'est bien de mettre dans l'ID le type de modèle...
voilà on j'en suis, désolé c'est un peu lng, mais ça fixe mon esprit
Robert-67
Membre actif
Tr@nquille;2703516 à dit:
Tout à fait d'accord .... En résumé, le type symbolique dans le SSID, dans l'identifiant aussi, et écrit sur la balise. Sur le terrain c'est ce qui est écrit dessus qui est le plus pratique.
Par exemple :
- SSID : MOT2000TO4000 ou bien NOMOT2000TO4000 ou bien HELICO2000TO4000
- et la même chose dans l'identifiant à 26 caractères en plus du trigramme principal "000" et du trigramme-personnel "XYZ".
(EDIT) Pour un "vendeur de balises" la question se pose différemment puisque le vendeur ne sait pas dans quel modèle la balise servira.
Robert-67
Membre actif
Tr@nquille;2703516 à dit:
Le récepteur ESP32 et l'appli smartphone réagissent parfaitement bien lorsque 2 balises sont en marche simultanément : à chaque émission beacon d'une trame valide l'appli smartphone affiche la balise qui vient d'émettre.
On voit donc un écran qui affiche alternativement les 2 balises en marche
Cela s'explique par le fait que notre récepteur wifi ESP32 n'est pas sélectif, et "ramasse" tout ce qui se passe à proximité en wifi sur le canal 6. Puis il converti en bluetooth à chaque fois qu'un identifiant à 30 caractères valides passe à proximité sans attribuer d'exclusivité à l'une des 2 balises puisque il n'y pas de connexion wifi à un point d'accès particulier.