Ben oui c’est ça ! sinon il existe une balise de chez Educadrone qui a fait cette fonction https://frskytaranis.forumactif.org/t11665p75-dgac-construire-sa-balise-de-signalement#126679.
Pour ce qui est de la liaison de télémétrie GPS avec la balise, la liaison smartphone/balise est non seulement trop lente avec une période d’échantillonnage des points GPS de 3 secondes mais la porté est très faible surtout sans antenne en tout cas bien moins bonne que via une connexion S.port.
Et un dernier petit projet qui ajoute une sortie MSP vers une caméra DJI FPV Air Unit ou Caddx Vista, ce qui permet d’afficher les infos provenant du GPS de la balise dans l’OSD d’un casque DJI : https://github.com/dev-fred/GPS_Tracker_ESP8266/blob/main/GPS_Tracker_ESP8266V1_WEB_FRSKY_OSD-DJI-AIR-UNIT
On reçoit :
La latitude, la longitude
Le nombre de satellites (clignote tant que la position de départ n’est pas définie)
La vitesse sol
La direction du point de départ
La distance au point de départ
La partie FRSKY, également connectée, envoie les données de télémesure à la radio. Ce projet nécessitant 2 UARTs utilise un NodeMCU de la famille ESP8266.
Ce projet s’appuie sur un projet Ardupilot : https://github.com/d3ngit/djihdfpv_mavlink_to_msp_V2
Testé et approuvé.
Reste la question de la portée : quelqu’un a t-il testé ?
Merci
Boujour, dans le code Decode_balise_ESP32, je me suis posé une question sur la ligne de code suivante :
//Filter OUI from 6A:5C:35
if (snifferPacket->payload[offset_OUI + 1] != FRAME_OUI[0] && snifferPacket->payload[offset_OUI + 2] != FRAME_OUI[1] && snifferPacket->payload[offset_OUI + 3] != FRAME_OUI[2])
Je pense que cette forme serait plus correcte, puisque on cherche différent de, donc OU et pas ET
if (snifferPacket->payload[offset_OUI + 1] != FRAME_OUI[0] || snifferPacket->payload[offset_OUI + 2] != FRAME_OUI[1] || snifferPacket->payload[offset_OUI + 3] != FRAME_OUI[2])
Qu’en pensez-vous?
C’est vrai que NON ((A==6A ET B==5C ET C==35) VRAI ) = (A!=6A OU A!=5C OU C!=35) FAUX
Cependant les 2 expressions permettent un filtrage correcte de la séquence OUI , c’est le test qui le dit Sans doute parce que dés que l’on a 6A à l’offset offset_OUI+1 on a nécessairement une trame OUI complète.
//Filter OUI from 6A:5C:35
int OU=1;int ET=1;
if(snifferPacket->payload[offset_OUI+1] != FRAME_OUI[0] || snifferPacket->payload[offset_OUI+2] != FRAME_OUI[1] || snifferPacket->payload[offset_OUI+3] != FRAME_OUI[2]){ Serial.print("OUI-OU != NOK ");OU=0;}
if(snifferPacket->payload[offset_OUI+1] != FRAME_OUI[0] && snifferPacket->payload[offset_OUI+2] != FRAME_OUI[1] && snifferPacket->payload[offset_OUI+3] != FRAME_OUI[2]){ Serial.println(“OUI-ET != NOK”);ET=0;}
Serial.println();
if ((OU==0) || (ET==0)) {return;}if(snifferPacket->payload[offset_OUI+1] == FRAME_OUI[0] && snifferPacket->payload[offset_OUI+2] == FRAME_OUI[1] && snifferPacket->payload[offset_OUI+3] == FRAME_OUI[2]){
Serial.print("OUI-ET == OK ");
Serial.print("OUI+1 “);Serial.print( FRAME_OUI[0],HEX);Serial.print(” OUI+2 “);Serial.print( FRAME_OUI[1],HEX);Serial.print(” OUI+3 ");Serial.println( FRAME_OUI[2],HEX);}
Serial.println();if(snifferPacket->payload[offset_OUI+1] == FRAME_OUI[0] || snifferPacket->payload[offset_OUI+2] == FRAME_OUI[1] || snifferPacket->payload[offset_OUI+3] != FRAME_OUI[2]){
Serial.print("OUI-OU == OK ");
Serial.print("OUI+1 “);Serial.print( FRAME_OUI[0],HEX);Serial.print(” OUI+2 “);Serial.print( FRAME_OUI[1],HEX);Serial.print(” OUI+3 ");Serial.println( FRAME_OUI[2],HEX);
}
22:23:18.232 → OUI-OU != NOK OUI-ET != NOK
22:23:18.232 →
22:23:18.326 → OUI-OU != NOK OUI-ET != NOK
22:23:18.326 →
22:23:18.326 → OUI-OU != NOK OUI-ET != NOK
22:23:18.326 →
22:23:18.326 → OUI-OU != NOK OUI-ET != NOK
22:23:18.326 →
22:23:18.373 →
22:23:18.373 → OUI-ET == OK OUI+1 6A OUI+2 5C OUI+3 35
22:23:18.373 →
22:23:18.373 → OUI-OU == OK OUI+1 6A OUI+2 5C OUI+3 35
22:23:18.373 → ID: ILLEGAL_DRONE_APPELEZ_POLICE17 LAT: 48.78141 LON: -3.03455 ALT ABS: 12 HAUTEUR: 0
Edit: j’ai mis à jour mes programmes
Bonsoir,
Tout d’abord bravo et merci aux contributeurs de ce projet !
J’ai assemblé une balise à l’aide de ce modèle d’ESP8266 (ESP-WROOM-02) :
https://fr.rs-online.com/web/p/modules-wlan/1359773/
J’utilise un GPS TBS M8.2 et une alim Traco 3.3V1A
J’utilise le code de Francis https://github.com/fanfanlatulipe26/BaliseDGAC_GPS_Logger
J’ai effectué des tests avec la réception du Github de la Gendarmerie et une carte Alfa AWUS036NHA et une grande antenne.
La réception à fonctionnée à plus d’un km en vol à 50~100m sol.
La balise est montée dans un moto-planeur en bois et est callée entre l’accu et l’esc, avec l’antenne qui dépasse un peu au-dessus de l’accu.
Jean-Philippe
Edit : ESP8266 pas ESP32
Je n’avais pas essayé mon code sur un ESP32. Tu as fait des modifs ??
Je suis entrain de faire des modifs pour générer aussi une trace GPX. L’enregistrement de la trace ne sera plus synchrone avec l’envoi de la trame Beacon mais on pourra choisir la longueur du déplacement qui provoque l’enregistrement d’un point.
Je me bats avec le GPS pour avoir des mises à jour à 10hz et tester si un enregistrement rapide de nombreux points ne perturbe pas trop la fréquence d’émission des trame Beacon …J’ai un comportement très bizarre du GPS qui semble renvoyer de temps en temps une longitude 0.0
A suivre !.
Bonsoir,
Le fait d’avoir un serveur WIFI ne perturbe pas le récepteur ?
Sur la doc de la balise NAVEOL il est spécifié qu’il y a des risques et ils déconseillent de voler avec le 2ème canal WIFI actif
Qu’en pensez-vous ?
Philippe
Edit : J’utilise un ESP8266 pas un ESP32
Je n’ai pas fait de modif particulière, simplement changé la pin GPS_RX_PIN de 0 vers 13
Voici ma config dans arduino :
Concernant la trace GPS j’ai du ajouter des décimales dans les latitudes et longitudes pour qu’elle soit exploitable.
Dans fsBalise.cpp, j’ai modifié la ligne 301 :
logMessage = String(gps.location.lat()) + "," + gps.location.lng();
par
logMessage = String(gps.location.lat(), 6) + "," + String(gps.location.lng(), 6);
Autrement tout fonctionne, l’AP, programmation OTA, enregistrement des traces et bien sûr la trame wifi.
Petite précision, ta carte est basée sur un ESP8266 et pas sur un ESP32
Bonjour Philippe,
En effet la balise Naveol coupe le point d’accès wifi après 30s de fix GPS d’après la notice, et recommande de ne pas voler avec le point d’accès actif.
C’est une très bonne recommandation et d’une manière générale il faut éviter les sources de perturbation du lien RC.
Dans les essais que j’ai fait avec l’ESP8266 et le code open source je n’ai pas constaté de différence particulière avec et sans balise au niveau du retour du RSSI de la radiocommande FrSky.
Cela ne signifie pas qu’il n’y à aucune perturbation dans toutes les situations.
Lorsque la balise ESP8266 est présente dans le modèle le point d’accès est actif en permanence.
On à pu se connecter depuis un smartphone et lire les infos sur la page web de la balise avec le modèle en condition de vol à environ 30~50m, sans constater de problème particulier avec la RC.
En vol je me suis éloigné à environ 300m de moi. La réception wifi était posée chez moi soit à environ 1km avec vue directe sur le modèle.
J’ai tenté de modifier le code pour éteindre le point d’accès sur l’ESP8266 mais sans succès pour le moment.
Bien vu, je les confonds toujours ! Merci
Un grand merci pour ce test, j’ai investi également dans un récepteur WIFI Alfa AWUS036NHA avec un Raspberry Pi 4 Model B 4Gb mais je n’ai pas pu encore faire un essai sur le terrain pour vérifier mes balises qui utilisent le même soft et quasiment le même hardware que toi. Je suis rassuré, les gendarmes pourront détecter correctement la trame beacon et je ne risque pas une amende.
1 Like
Merci pour ces renseignements.
J’avais modifié le fichier de Fred pour garder le FRSKY et supprimer le serveur WIFI.
Je vais peut être resté sans le serveur WIFI
Merci
Philippe
Ça fait sens,
je suis en train de faire la même chose ! j’ai cette version sur github
https://github.com/dev-fred/GPS_Tracker_ESP8266/tree/main/GPS_Tracker_ESP8266V1_FRSKY
Hey there…
I with a t-beam v1.1. Actually i adjusted the .h to v10 - however the module is not fixing a position. In this treat (I read over it) I couldn’t find any inducation that the v10 is not working for the v1.1. So my question is, If there’s anyone having an idea - what I could try to fixe this problem…
By the way am I rift that I could use on and the same module for different plains if they are in the same category respectively the same weight but registered with different registrations to AT?
Best and thanks…
Stefan
Ps I am writing in English since my french is to be trained…
Bonjour, je suis effectivement sur le projet de Balise,
Je travaille sur le code de Pierre Kancyr.
J’ai pu modifier le code pour faire fonctionner l’écran OLED sur la balise.
J’avance un peu tout les soir le code sera déposé sur le GITHUB.
hello,
I have check ttgo documentation and v1.0 and v1.1 got the same pinout, so you should have the GPS.
You should check on the TinyGPS++ lib that you can communicate with the GPS or if that only the GPS that doesn’t get signal. On the second case, check your antenna and the connector. On first usage, it could take some time to get a fix, so try to go outdoor with a clear sky and wait !
Salut 
as-tu deja deposé le code?
merci pour ton travail!
je suis entrain de cree un git pour mettre a disposition mon travail.
je vous le ferai savoir en temps voulu.