Modifier le délai d'apparition "RXLOSS"

[spid99]

Bonjour, comme vous le savez, je cherche à diminuer voir supprimer mes "RXLOSS" avec la RCv2 DJI

A priori les RXLOSS se déclenchent malgré que le signal est plein pot. 

La plupart (tous les miens en tout cas) des RXLOSS sont de moins 1.5 secondes (paramètre par défaut pour le déclenchement du Failsafe) et ne déclenchent donc pas de failsafe.

J'ai augmenté ce délai à 3 secondes. (pas encore testé). Ce qui entrainera un délai équivalent pour retrouver la radio après coupure (en sachant que la RC dji met déjà environ 5s, donc bon ..)

En cherchant comment rendre le O3 moins "sensible" aux dégradations du signal j'ai trouvé ça :

 

• RX_LOSS_COUNT : ce paramètre contrôle le nombre de paquets radio perdus avant que le drone ne considère le récepteur radio comme perdu. Vous pouvez augmenter ce nombre pour rendre le système plus tolérant aux perturbations radio.

Dans votre fichier de configuration Betaflight (.cfg), vous pouvez ajouter les lignes suivantes pour modifier les paramètres  RX_LOSS_COUNT :

[rx]
RX_LOSS_COUNT 10

Problème je ne trouve pas de fichier de configuration ".cfg" dans Béta. Et ça ne passe pas dans le CLI. Peut-être dans les options firmware ? Mais où ?

Quelqu'un genre @Jerome (the best !) ou un autre aussi  aurait-il une idée comment modifier ce paramètre ?

Je ne veux pas trop l'augmenter pour ne pas perdre en stabilité, mais juste faire des tests en l'augmentant progressivement pour voir si c'est la source du problème, j'avais entendu dire que ce problème apparaît sous béta et pas sous INAV, donc peut-être ce paramètre est-il différent sous INAV ?

OUais je sais, je me prends la tête pour rien si je passe en ELRS ce serait réglé ...Mais j'aime tellement ne pas avoir à ajouter des RX ...  

[Jerome]

Je pense que le fichier en question est utilisé au moment de la compilation du firmware, donc à moins de compiler toi-même tu n'y aura pas accès car il ne s'agit pas d'une variable configurable via CLI.

Et de toute façon, c'est une très mauvaise idée : pour régler un problème, il faut en corriger la cause. Masquer les symptômes ne fera qu'augmenter les risques : tu vas prendre confiance en te disant que le problème est corrigé alors qu'il est toujours présent  

[spid99]

il y a 9 minutes, Jerome a dit :

Et de toute façon, c'est une très mauvaise idée : pour régler un problème, il faut en corriger la cause. Masquer les symptômes ne fera qu'augmenter les risques : tu vas prendre confiance en te disant que le problème est corrigé alors qu'il est toujours présent  

Oui, j'suis d'accord. Mais le signal RC (Mbps) est toujours à fond quand un RXLOSS apparaît, je pense donc que c'est une mauvaise interprétation de BF, peut-être que les paquets ne sont pas correctement interprétés ? Bref, de toute façon je ne vais pas compiler le firmware donc ... Merci quand même 

[Motard Geek]

J'ai aussi l'impression que ça merde côté BF, j'ai jamais eu aucun RXLOSS avec iNav et visiblement y'a pas de problème avec les drones DJI.

Côté BF j'ai joué des presets, SBUS Fast, normal, j'arrive pas à faire disparaitre le problème  

[spid99]

il y a 22 minutes, Motard Geek a dit :

J'ai aussi l'impression que ça merde côté BF, j'ai jamais eu aucun RXLOSS avec iNav et visiblement y'a pas de problème avec les drones DJI.

Ouais exactement ce que je pense aussi, Jérôme a peut-être un contact dev béta ? Ce serait sympa si quelqu'un de BF se penchait sur ce problème.

J'ai vu une vidéo où le gars à l'air d'utiliser la Rcv2 et il n'a aucun RXLOSS pourtant il va loin, et on voit que le signal est toujours plein pot ... INAV ?

Bizarre ? https://www.youtube.com/watch?v=4entYx5lCU4

 

Modifié (le) il y a 1 heure par spid99

[Jerome]

Non, je n'ai pas de contact, mais depuis le temps, je pense qu'ils sont au courant