Le branchement est en série, les capteurs ont 2X3 broches connectés 2 à 2 pour permettre de faire un chainage, mais toute la chaine est connectée en parallèle sur +, - et S.port.
L’ordre de connexion est juste dictée par des raisons pratiques, d’un coté le récepteur a un connecteur S.port 3 broches mâle, de l’autre, la balise a un connecteur femelle. Les capteurs sont livrés avec une petite rallonge qui permet une insertion entre le récepteur et la balise.
d’accord mais chaque capteur a une entrée et une sortie, et la balise n’a qu’une entrée, non?
Oui et non, sur un capteur l’entrée = la sortie, c’est juste pour chainer les câbles de connexion. Le fil S.port est bidirectionnel : il est en half-duplex sur 1 fil. La balise est faite pour se brancher sur le récepteur, j’appellerai cela plutôt une sortie que je branche sur l’entrée du récepteur 
ok donc du coup comme il y a deux connectiques sur mon récepteur, je branche le vario sur l’un et la balise sur l’autre, et si je dois chainer j’envoie à partir du vario,
bon ça va le faire en fait merci
Le vario est particulier il est smart-port (avec le râteau 2X3 de chainage) d’un coté et hub série D de l’autre !
The new Variometer sensor can act as “BRIDGE” between NON-S.Port FrSky telemetry sensor system and S.Port system.
Bonjour Fred,
Je vois dans tes derniers codes que tu fais une config du GPS, change le baudrate et le rate du GPS. quel est l’intérêt de faire ca ?
La config du GPS permet d’aller plus vite dans les fix GPS à froid ?
cette config doit être faite pour chaque balise ou elle est valable pour tous ?
Merci d’avance !
Damien
@BL08FR tu peux changer par exemple le canal d’un sniffer, pour voir si tu reçois sur les autres canaux.
Salut Damien,
L’accroissement Rate+Baudrate permet un échange plus rapide entre le GPS et l’ESP, le gain dépend vraiment de l’appli qui tourne dans l’ESP, le fix ne sera pas plus rapide. L’outil permet de connaitre les séquences d’octets à envoyer au GPS pour le configurer depuis l’appli, à chaque démarrage plutôt qu’avec u-center + sauvegarde qui sort le GPS de sa config usine, c’est une question de goût.
La configuration des 3 satellites (GNSS) par défaut dans le cas des BN220 permet d’avoir le trio GPS + Galileo + Glonas.
La vitesse du fix est plutôt dépendante des conditions d’environnement: en intérieur, en ville (bâtiments hauts, etc) l’accroche des satellites GPS est toujours plus difficile et longue. Le premier “fix” doit être fait autant que possible en zone dégagée pour que la puce puisse accrocher au minimum 4 satellites.
1 Like
Bonjour !
Je suis nouveau sur ce blog et tiens à saluer et remercier tous les contributeurs à ce projet. Plein de bonnes informations et idées à collecter ici.
J’amène aussi ma pièce à l’édifice avec une nouvelle version de la balise BaliseDGAC_GPS_Logger, avec enregistrement des traces, dérivée de GPS_Tracker_ESP8266V1_WEB de “dev-fred”
La réalisation a été faite avec un ESP01 (ESP8266) et un GPS QUECTEL L80 ce qui donne une réalisation très compacte, mais elle doit tourner sans problèmes sur un ESP8266 D1 avec GPS BN220 etc…
Disponible sur https://github.com/fanfanlatulipe26/BaliseDGAC_GPS_Logger
Les commentaires sont les bienvenus 
Quelques nouveautés:
- Extension de l’interface Web
- Ajout d’une fonction d’enregistrement des traces dans le système de fichiers de l’ESP avec interface Web de gestion (effacer / télécharger / choix des champs).
- Modification de l’identificateur de la balise: l’adresse MAC est utilisée comme numéro de série.
- Ajout d’une fonction de mise à jour du logiciel à travers la liaison WiFI (OTA Over The Air)
- Ajout d’un portail captif: lors de la connexion au réseau créé par la balise, le navigateur est lancé et on se retrouve directement dans l’interface utilisateur, sans besoin de donner une adresse IP
- Interface utilisateur pour la gestion des préférences, la gestion “système” etc …
1 Like
Bon travail, plusieurs bonnes idées dont l’OTA surtout avec les ESP01.
Edit: c’est magique la connexion automatique, pas sûr de comprendre le fonctionnement, je vois ces lignes en + :
const byte DNS_PORT = 53;
DNSServer dnsServer;
Et dans mon smartphone j’ai le titre > captive.apple.com
et le SSID de la balise
1 Like
J’ai finalement trouvé un exemple https://github.com/esp8266/Arduino/blob/master/libraries/DNSServer/examples/CaptivePortal/CaptivePortal.ino
1 Like
Hello fred ! (et tous les autres ! ^^ )
ca faisais un moment que j’étais pas venu, vin dieux ca avance a la vitesse de la lumière lol.
j’ai eu un bug sur un de mes flash today, sur le code https://github.com/dev-fred/GPS_Tracker_ESP8266/tree/main/GPS_Tracker_ESP8266V1_MAP , en effet quand j’affiche ma map (que ce soit avec speedify et android ou iphone) , la balise me situe sur paris (alors que je suis dans la yaute).
Une petite idée ? y à t’il quelque chose a modif pour qu’elle soit fonctionnel ? les coordonnées et l’export gpx sont ok par contre!
@fanfanlatulipe26 ta modif est vraiment cool ! le fais de ne pas avoir a taper l’ip dans le navigateur est génial, et les modifs système également.
Je pense que l’implémentation d’une petite map interactive et surtout de l’export directement en GPX serait un vrai plus pour amélioré l’interface !
Les requêttes DNS se font sur le port TCP 53.
Lorsque on se connecte à un réseau, les systèmes envoient des demande http sur le réseau vers des sites spécifiques pour voir si il y a quelqu’un (??). En général ils reçoivent en retour une simple réponse texte du genre “Success” ou " Connect Test" etc…
Ici le server DNS va récupérer toutes les requêtes sur le port 53 en redirigeant les demandes vers l’IP de notre server qui va recevoir une demande d’URL inconnues. L’événement server.onNotFound lui renvoie alors le code HTML de notre home page, ce qui provoque l’ouverture automatique de la page dans le navigateur. Dans la barre d’adresse du navigateur on retrouve alors le nom du site demandé à l’origine (d’où le captive.apple.com que tu as vu)
L’affaire se complique un peu quand il y a une requête https car le server DNS ne la voit pas: c’est en particulier le cas des navigateurs qui font appel à https://www.google.com. On peut alors les tromper en donnant une adresse qui semble correcte du genre xxx;fr car ils appellent alors directement le site xxx.f ren http au lieu de faire une demande à google en https.
Voilà ce que j’ai compris du système. J’espère que mes explications ne sont pas trop confuses. !!
2 Likes
Normalement, la carte démarre sur le point zéro de la France = la cathédrale Notre-Dame de Paris mais dés que tu as la position de départ, la carte se déplace dessus et met une balise rouge
1 Like
Merci pour tes explications, c’est un mode de fonctionnement subtil pour hackeur. J’ai pu modifier mon code pour ajouter cette possibilité qui fonctionne parfaitement sur iOS par contre sur un vieux Android désaffecté,la magie n’opère pas, peut-être un pb de config ou une version trop ancienne, mais ça fonctionne comme avant ce qui ne retire rien, je peux tjrs utiliser l’adresse IP.
1 Like
Alors du coup j’arrive à récupérer la carte avec mon point de départ lorsque j’ai un hdop suffisamment haut.
Par contre je n’arrive pas à retracer le chemin avec des points intermédiaire comme tu as pu le montrer sortez images . Faut-il pour cela générer un GPX tous tes X secondes à la main ?
On est d’accord que le GPX est censé récupérer les données du trajet au fur et à mesure de l’évolution du parcours ?
Au final quand Gex porte mon fichier dans GPX viewers je ne retrouve que mon point de départ qui a été fixée ainsi que la position au moment où j’ai généré le fichier.
Il n’y a peut-être tout simplement pas quelque chose que j’ai compris dans le déroulement des process si c’est le cas est-ce que tu peux me l’indiquer et sinon m’aider à trouver comment récupérer le parcours au fur à mesure ? Par exemple en générant un fichier GPX automatiquement toutes les X secondes ça pourrait être intéressant afin de cartographier le parcours.
J’ai du coup réussi à implanter le GPS avec les performances améliorer dedans il ne me manque plus que cette feature.
Merci d’avance:blush:
Je retesté avec un drone que je n’avais pas quand j’ai fait le projet, où j’ai fait un test à pied qui est un cas trop idéal et pas réaliste.
C’est très décevant et je m’excuse d’avoir un peu trop rêvé avec cette méthode, je me suis laissé entrainé par l’affichage de la carte qui est un vrai boulet en fait, je n’obtiens que très peu de points, le départ et 3 points c’est tout, dû à un gros problème de porté. Je vais retirer le projet MAP et si tu veux avoir un équivalent avec carte, il y a le projet de Xav_YeYe qui utilise un apk sur Android comme le projet de modèle magazine ou le projet de fanfanlatulipe26 qui enregistre directement dans la balise la trace mais sans carte. De mon coté, ayant du matériel FRSKY, je suis maintenant convaincu que la meilleure solution en termes de porté et de flux de donnée passe par la télémétrie FRSKY, là on est dans des conditions idéales de portée, il y a des antennes des 2 cotés et le rythme d’actualisation des points se fait au rythme de la télémétrie et pas au rythme assez lent de la trame beacon toutes les 3 secondes. Je peux directement enregistrer la télémétrie dans la radio via les fonctions natives de log d’Opentx ou faire un fichier via un script LUA. Encore toutes mes excuses, c’est un peu la douche froide pour moi.
1 Like
Merci pour ton retour, ca me rassure car j’ai fais plus de 80km today voiture et a pied sans succès, je me disais que je devais louper un truc ^^ en tout cas merci pour le travail fournis dans tous les cas, concernant le code de @fanfanlatulipe26 , ce dernier m’intéresse beaucoup également mais j’ai des erreurs de compilation :
> sketch\fsBalise.cpp: In function 'void sendChunkDebut(bool)': fsBalise.cpp:255:10: error: 'using ESP8266WebServer = class esp8266webserver::ESP8266WebServerTemplate<WiFiServer>' has no member named 'chunkedResponseModeStart' server.chunkedResponseModeStart(200, "text/html"); ^
>
> sketch\fsBalise.cpp: In function 'void handleCockpit_()': fsBalise.cpp:262:10: error: 'using ESP8266WebServer = class esp8266webserver::ESP8266WebServerTemplate<WiFiServer>' has no member named 'chunkedResponseFinalize' server.chunkedResponseFinalize(); ^
>
> sketch\fsBalise.cpp: In function 'void gestionSpiff(String)': fsBalise.cpp:438:10: error: 'using ESP8266WebServer = class esp8266webserver::ESP8266WebServerTemplate<WiFiServer>' has no member named 'chunkedResponseFinalize' server.chunkedResponseFinalize(); ^
>
> sketch\fsBalise.cpp: In function 'void handleOptionsPreferences()': fsBalise.cpp:541:10: error: 'using ESP8266WebServer = class esp8266webserver::ESP8266WebServerTemplate<WiFiServer>' has no member named 'chunkedResponseFinalize' server.chunkedResponseFinalize(); ^
>
> sketch\fsBalise.cpp: In function 'void handleReset()': fsBalise.cpp:553:10: error: 'using ESP8266WebServer = class esp8266webserver::ESP8266WebServerTemplate<WiFiServer>' has no member named 'chunkedResponseFinalize' server.chunkedResponseFinalize(); ^
>
> sketch\fsBalise.cpp: In function 'void displayOptionsSysteme(String)': fsBalise.cpp:582:10: error: 'using ESP8266WebServer = class esp8266webserver::ESP8266WebServerTemplate<WiFiServer>' has no member named 'chunkedResponseFinalize' server.chunkedResponseFinalize(); ^
>
> sketch\fsBalise.cpp: In function 'void handleOTA_()': fsBalise.cpp:593:10: error: 'using ESP8266WebServer = class esp8266webserver::ESP8266WebServerTemplate<WiFiServer>' has no member named 'chunkedResponseFinalize' server.chunkedResponseFinalize(); ^ exit status 1
>
> 'using ESP8266WebServer = class esp8266webserver::ESP8266WebServerTemplate<WiFiServer>' has no member named 'chunkedResponseModeStart'
Une idée de l’erreur ? je n’arrive pas à situé le soucis.
