Bonjour,
je suis intéressé par ta manip! peux tu la décrire un peux plus?
j’ai installé Speedify. une fois lancé, tu bascule ton wifi telephone de la box vers la balise?
Tu utilises quoi ensuite pour localiser ta balise? decode_balise lui ne marche qu’en BT?
Merci pour ton aide! :_)
Bonjour Guillaume,
Speedify permet de faire fonctionner le dev de Fred :
Il n’y a donc pas de décodage des balises dans ce cas, juste la connexion à l’AP de la balise pour avoir son statut sur une page Web et la position de la balise sur une Map…
Patrick
1 Like
Ok il faut juste que j’adapte le code de Fred pour mon module : https://fr.aliexpress.com/item/32958458278.html
Je suis en train de merger le code de Pierre Khancyr (https://github.com/khancyr/TTGO_T_BEAM) avec SoftRF (https://github.com/lyusupov/SoftRF) pour avoir aussi le FLARM, OGN, FANET+,…
Merci!
Bonjour ! désolé, je n’ai pas eu le temps de retravailler dessus, je partage ce que j’ai fait dès que c’est finalisé ! je ferai un depot sur github proprement…
Damien
@BL08FR je te dirais dès que j’ai finalisé, aujourd’hui pour le déclenchement je passe par deux relais commandés via PWM du récepteur. Je n’ai pas encore mis en ligne le code, je viens à peine de recevoir les relais et je n’ai pas eu le temps de m’en occuper depuis la dernière fois. Mon code est bancal encore, il faut que je le re-écrive pour qu’il soit non bloquant, afin de ne pas boquer l’envoi de la trame beacon si une action sur la camera est en cours.
Ca m’intéresse ta solution en PWM, tu pourras m’envoyer le lien du code que tu as détourné ? tu te sers de l’entrée analogique ? je n’ai jamais rien trouvé de concluant sur le net pour du PWM de recepteur 5V sur l’esp8266…
@damiend
Voici le lien pour le déclenchement d’une YI par wifi : https://github.com/BL08FR/ESP8266_Xiaomi_YI_WIFI_RemotePWM/
Je me sert pas de la broche A0 mais d’une broche pwm avec des seuils (entre 1350 et 1700 photo au dessus, vidéo), la limite du système dans le cadre d’un déclenchement automatique sur le drone (mission survey) c’est le temps que la cam met pour répondre (“photo ok, connexion disponible”, maxi 4s), si les intervalles sont trop court, elle bug.
Depuis j’ai terminé mon code pour lire les données GPS via mavlink (et donc se passer du bn220) pour la balise, tu peux en trouver une version quasi finie un peu plus haut, évidemment cela permettra aussi de lire sur mavlink les entrée RCIN et RCOU et donc se passer de l’utilisation du rail servo pour lire es pwm (j’ai juste un doute sur la capacité du pixhawk a fournir la D1 mini en jus).
Il me reste à intégré ce code dans le fichier balise_DGAC_web.ino.
Ce que je pensais, si je parviens à mes fins, une fois terminée je te jette le code et tu le modifie pour coller avec une gopro.
D’ici là je dois creuser pour le mode wifi AP_STA.
Salut à tous,
je reviens un peu sur cette histoire de hdop et de précision…
après moultes lectures, j’en arrive à la conclusion que la donnée qui pemret de vérifier que la précision est la meilleure est le pdop.
le hdop c’est une précision horizontale, qui suffit pour des applications genre routes au sol etc, du 2D.
le pdop est une donnée qui concerne la précision 3D, donc avec ajout de la partie altitude:
exemple:
(en bas de page)
on remarque d’ailleurs que le pdop est toujours supérieur au hdop…
pour récupérer cette donnée, il faut faire un petit truc, car pas prévu par défaut dans la librairie tinygpsplus.
l’exemple à suivre est ici:
moi j’ai fait comme ça:
// création de l’objet
TinyGPSCustom pdop(gps, “GPGSA”, 15); // $GPGSA sentence, 15th element
puis test de pdop pour définir si précision ok:
comme la donnée remontée est un tableau de char, et que je veux tester sur un nombre, j’ai fait à l’arrache une conversion etc, ça donne ça:
// là c’est parce que la première fois il remonte une chaine vide donc on n’en tient pas compte:
if (String(pdop.value())=="") {return;}
//et là c’est le test:
if (String(pdop.value()).toDouble() > 5.0)
voilà juste pour info
Article très intéressant. Dommage que le firmware des BN220/180 ne supporte pas le $GPGSA ; je n’arrive pas à récupérer le pdop.
bizarre je ne pensais pas que c’était lié au modèle de gps… et en plus dans le datasheet du bn220 ya le message de ce type:
C’est à cause de cette phrase
"If your GPS module doesn’t support the $GPGSA sentence, then you won’t get any output from this program.
En effet, ça devrait fonctionner, mon gps fonctionne et m’envoie la latitude et la longitude dans le programme de test mais pas de pdop, hdop et vdop.
Il y a peut-être qlq chose à configurer
moi je n’ai rien configuré de spécial, sur un gps basé sur une puce NEO6M…
Les BNXXX sont des clones des ublox, essaye avec UCenter pour voir si tu peux avoir la trame.
Grâce à ton projet, j’ai une carte LilyGO-T-Beam avec un NEO6M
et là ça fonctionne comme prévu 
on voit bien l’influence du vdop dans le calcul global du pdop, qui est quand-même important pour notre application…
Salut Guillaume,
Ah, joli projet le décodage FR-ID, FLARM et autres protocoles de signalisation… Je connaissais le décodage ADS-B avec RTL-SDR et la clef DVB sur Raspi, mais pas SoftRF…
Je vois que c’est avec un module Lora que l’on peut implémenter le décodage FLARM (et autres ?), et SoftRF tourne sur les microcontrôleurs compatibles Arduino…
C’est vraiment intéressant, bonne chance pour ce projet 
Patrick
1 Like
@ khancyr Le BN220 fonctionne avec $GNGSA, merci à u-center comme conseillé :
TinyGPSCustom pdop(gps, "GNGSA", 15); // $GPGSA sentence, 15th element
TinyGPSCustom hdop(gps, "GNGSA", 16); // $GPGSA sentence, 16th element
TinyGPSCustom vdop(gps, "GNGSA", 17); // $GPGSA sentence, 17th element
@ Xav_YeYe Va-t-il falloir réviser les critères de home position ?
oui j’ai fait déjà, comme indiqué plus haut…
moi, je ne le ferai pas car la vitesse GPS en statique n’est pas terrible en générale tout comme la précision en altitude… donc il y a un risque de ne jamais passer le check du home !
moi en intérieur mais proche d’une fenêtre, je fixe à chaque fois et sans que ça soit trop long.
j’ai un pdop de 4.5 en mioyenne à l’intérieur, ça passe le test que j’ai mis dans mon projet (inférieur à 5.0).
je n’ai pas compris du coup “la vitesse en statique” car je ne suis pas non plus un spécialiste GPS 
De mon coté, j’ai 3 arguments contre :
-
Il y a un problème pratique, le pdop s’obtient + difficilement et va compliquer les projets DIY puisque son obtention dépend du modèle de GPS utilisé.
-
A ma connaissance, il ne s’agit pas d’un requis de la loi, mais plutôt d’un peaufinage technique.
-
Je ne suis pas sûr de comprendre son intérêt, le résultat sur l’estimation d’erreur est moins bon:
critère PDOP < 5.0
(User Navigation Error) en mètres = UNE = 2 x PDOP x UERE = 10xUEREcritère HDOP < 2.0
(Estimated Position Error) en mètres = EPE = 2 x HDOP x UERE = 4xUEREUERE étant un terme rassemblant les différentes sources d’erreurs qui est constant pour une mesure donnée.
