Charlie Echo

Oui je sais... Mais justement, le FC dit probablement à l'OSD : "affiche le nombre de satellites en haut à gauche, puis affiche les coordonnées à droite". Si une étape plante, ça peut planter la suite... Par exemple, ça pourrait planter si le nombre de satellites est 0, ou si l'altitude est négative, ou je-ne-sais quel cas temporairement erroné / incomplet que l'OSD ne saurait pas gérer. D'où l'idée de jouer avec l'ordre dans lequel le FC donne les instructions à l'OSD, pour que ça plante le plus tard possible. Pour trouver les bugs logiciels, il n'y a pas 50 solutions, en fait. Il faut trouver LA étape qui fait planter la suite.

Essayons alors comme ça : - le GPS est bien connecté (sinon il ne donnerait rien) - le GPS envoie des infos au FC au format NMEA ; les lignes NMEA donnent plus ou moins d'infos, et ça se complète peu à peu (certaines trames donnent le fix et le nombre de satellites ; d'autres le fix et l'altitude ; etc.) - le FC décrypte probablement le format NMEA, et il envoie les infos à l'OSD. Je pense que le FC envoie à l'OSD l'image vidéo, et précise "place le texte Latitude à tel endroit sur l'écran". Et l'OSD affiche. Donc : soit le FC a un bug, soit l'OSD a un bug. "Un bug", ça peut être le fait de dire "si une info n'est pas bonne, j'arrête tous les affichages". A essayer : - rétrograder le FC (déjà proposé) - essayer de modifier l'ordre d'affichage des champs de l'OSD ; je ne suis pas sûr de la façon de faire, mais il y a forcément marqué quelque part "mets la latitude à gauche et la longitude à droite". Il faut modifier cet ordre, pour mettre les champs "problématiques" tout au début (auquel cas le risque est que rien ne s'affiche, et on saura...) ou tout à la fin (auquel cas le problème sera presque résolu). C'est peut-être dans la config textuelle de Betaflight. - jouer avec la config du GPS (cf le post épinglé sur le sujet) ; une solution pourrait être de ne prendre qu'un réseau de satellites... - simuler le GPS avec un Arduino : enregistrer pendant quelques minutes les trames reçues, et les "rejouer" dans un ordre ou dans un autre (en gérant le champ "heure"), pour voir ce qu'il se passe

et sont un peu contradictoires. Le premier point semble dire "les infos GPS sont là, mais on ne les affiche pas". Le deuxième point dit "les infos GPS ne sont pas là". (Pour ce que j'en comprends, l'OSD est juste un afficheur d'info. Il ne va pas empêcher le drone de décoller...) Je penche plutôt pour un problème de fix GPS, surtout si ton GPS est un peu ancien : on a perdu l'habitude d'attendre (Avec un BN 880, il me faut parfois 3 minutes avant d'avoir mon fix, quand l'horizon n'est pas très dégagé...)

Yep... J'ai bien l'impression que c'est en effet un fil déconnecté en interne, mais ça me semblait tellement improbable... Plus qu'à le changer (mais... c'est de la récupération, il n'est plus commercialisé... donc j'ai peur de devoir changer les 4...). Je vais aussi voir si ce ne sont pas les fils eux-mêmes qui ont un problème (suite à des torsions) : au point où j'en suis, je peux les couper à ras et les prolonger, pour essayer. Bref, j'aurai découvert les symptômes d'un fil déconnecté / désoudé. Merci @Motard Geek pour ton aide !

Le bruit sur la table, c'est un autre moteur posé, connecté en parallèle, qui a le même comportement (et qui n'a pas été vissé). Il s'allume et s'éteint en même temps, strictement. ESC : c'est une carte 4-en-1. Les 3 autres moteurs sont ok. Mais si je déconnecte l'un des fils des moteurs ok, j'ai ce type de comportement. Donc il y a probablement un fil déconnecté quelque part. Pour compléter, j'ai utilisé un oscilloscope pour sonder les 3 lignes des moteurs. J'envoie ici une photo de l'oscillo, pour un moteur "sain" et pour un moteur "malade". (La différence est assez claire...) Donc l'ESC envoie bien, sur les 3 fils, des infos, mais dans le cas "malade", les infos sont brouillées. Je finis par me demander si le moteur n'a pas, en interne, un fil déconnecté (?!?), puisque les soudures sont connectées.

Bonne idée. Elle est là :

Bonjour, J'ai un problème de moteur : il tourne... comme dans la vidéo (la vidéo est dans le zip, sinon je ne peux pas la charger ici...) Il tourne 1/2 seconde, il s'arrête 1/2 seconde, il tourne 1/2 seconde... (Il ne fait pas de bruit particulier ; le bruit, c'est un autre moteur en parallèle, qui a le même comportement). Ca semblait fonctionner avec un autre moteur (que j'ai flingué avec une vis mal positionnée qui a dû abîmer une bobine..) donc je pense que l'ESC est en bon état. L'ESC semble détecter le problème : il s'arrête après quelques secondes. Si je mets 2 moteurs en parallèle, les deux ont le même comportement en même temps, donc le moteur semble ok. Les soudures ont l'air solides, car quand je tire (légèrement) sur le fil, ça résiste (et je les ai déjà de-soudées et re-soudées). Donc : tout va bien, mais ça ne va pas... Ca évoque quelque chose à quelqu'un ? Merci !

C'était un problème de version ISRM : j'ai dû passer à la 2.10, et ça marche. (C'est assez peu documenté, cette histoire, en fait, ce problème de version). Pour les personnes qui ont un problème similaire : aller sur le site de FrSky télécharger la dernière version du firmware de l'émetteur de la télécommande le mettre sur une carte MicroSD placer la carte dans la télécommande, allumer la télécommande lire la carte (Menu_long puis Page) appliquer le firmware redémarrer la télécommande et ça devrait marcher. Et pour répondre à @cachecache (c'est gentil de m'avoir écouté... je me sentais seul...), c'était un problème d'appairage (je crois. La 1e étape de "register and bind" qu'on trouve décrite partout, et où tout se passe facilement...)

Bonjour, J'ai un RX tout neuf (Archer RS), une Taranis X9 lite d'occasion (juste un peu utilisée pour du simulateur, donc elle n'a pas fait ses preuves...), et je n'arrive pas à les Register. Je pense que ça importe peu, mais j'ai comme FC un SpeedyBee F405 v4 J'ai suivi les procédures : - mon RX affiche ses deux LEDS rouge et vert qui signifie "Status = Register" - ma X9 lite fait le bip-bip horrible qui dit qu'elle est en mode "register". Mais elle affiche "Attente". et rien ne bouge. Je peux démarrer l'un puis l'autre, ou l'autre puis l'un, ça ne change rien. Quel peut être le problème ? A défaut, est-ce que quelqu'un connaît la manière dont ça fonctionne : est-ce que le Rx écoute sur une fréquence spécifique, et la télécommande émet ? (surtout : quelle est cette fréquence : j'ai plein de matos pour tester ça...) Merci pour vos idées ! Tous les tutos disent "ça marche facilement", donc quand ça coince, on est perdu...

Pour info (si quelqu'un se pose la question un jour prochain...), je m'oriente vers : - un modem 4G / uart (40 euros en Chine, et un abonnement mobile en France) - l'envoi de données en MQTT vers un serveur, à partir de ce modem - la récupération des données en MQTT par mon PC. Pour le dire autrement, comme je n'ai pas de solution Tx+Rx sous la main, et que la latence n'est pas un gros problème, je bidouille un Tx et j'utilise les réseaux mobiles classiques : ça divise par 2 le problème.

Pas forcément par le FC, mais ça serait idéal. Si je "vois" quelque chose au sol, je pourrai m'en approcher et "regarder mieux". Donc si c'est via le FC, je peux automatiser. Sinon, je peux voir ça sur mon "écran" et gérer ça à la main. La version actuelle enregistre les données à partir de la puce externe qui les collecte. Je réfléchis à ajouter une puce qui envoie les données en WiFi vers un PC. Ca serait déjà mieux. Encore mieux, je reprends les matériels existants (VTX, VRX) et je les bidouille, parce qu'une grosse partie de la fiabilité sera gérée. Encore mieux, donc, j'intègre ça au FC.

Bonjour, Je débute en drones, parce que j'ai un besoin bien spécifique : je souhaite, à partir d'un drone volant à quelques mètres, faire des mesures du sol (avec une électronique perso) et les envoyer en temps réel. C'est un peu comme une télémétrie, sauf que je dois envoyer plein d'infos (plusieurs dizaines de ko / seconde), donc c'est trop lourd pour les "télémétries" classiques. C'est un peu comme envoyer une image vidéo, sauf que ce sont des mesures spécifiques : il ne s'agit pas de brancher une caméra, ni, à l'arrivée, de décoder le flux vidéo. Mais si j'arrivais à utiliser le "transport vidéo" pour envoyer d'autres infos, ça serait idéal. Est-ce ce que ce sujet évoque quelque chose à quelqu'un ? Peut-être que je pourrais trouver une "carte vidéo open-source" pour la bidouiller à la fois à l'émission (sur le drone) et à la réception ? Merci pour vos éclairages !