Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Une désinstallation/réinstallation n'a rien changé...
Bon, je vais continuer à fouiller, mais des suggestions seraient les bienvenue ! Pour les problèmes d'affichage aussi : si la désinstallation/réinstallation de pulseaudio n'a rien fait pour le son, j'ai depuis mon second écran systématiquement dans les choux ! 
À n'y rien comprendre !
Par contre, je comprends assez mal certaines erreurs signalées :
"Failed to start sound service", mais comme souvent, si je n'ai pas de son dans Firefox, VLC a bien le son de même que Chromium. En tous cas, ça fonctionnait avant l'ajout de la carte
"error resolving pool 0.debian.pool.ntp.org" Allons, bon, NTP est dans les choux aussi ? Je ne sais pas si c'est en rapport avec l'ajout de la carte graphique, mais il fonctionnait peu de temps avant, et je ne vois rien d'autre qui a changé depuis
Pour les autres erreurs, je ne peux trop rien dire : soit elles sont normales (kvm disabled...), soit elles ne m'ont jamais gêné et j'en ignorais l’existence (entre autres, le problème avec Avahi qui me semble faire malgré tout ce qu'il doit).
on est d'accord que sans le jeux installé , la machine tourne parfaitement ? (ou tu a des soucis aussi )
Non, comme je disais, ce n'est peut-être qu'une impression, confirmée d'ailleurs sur le forum FlightGear où j'ai posé la question : plusieurs membres l'utilisent avec Debian, il n'y a aucun souci et je l'ai installé selon la même procédure qu'eux. Ils ne voient vraiment pas comment FlightGear pourrait mettre la pagaille et n'ont jamais rencontré un tel cas.
tu précise que sans la carte nvidia tout est correct
Ça l'était avant de l'installer : vraiment aucun souci. Je n'ai pas essayé de la retirer (pas facile d'accès du tout...), et comme j'ai pas mal bricolé, ça ne va plus vraiment être significatif...
oui , ça fonctionne avec ou sans ce fichier. (xorg.conf)
Et s'il est présent, il est systématiquement pris en compte ? J'aurais assez l'impression qu'il l'est parfois, parfois non...
et pour ça je suis étonné quand même
depuis l'ajout de la carte vidéo, la config (essentiellement vidéo et peut-être son) change de manière assez aléatoire
Ben oui, moi aussi ! Pourtant, ça m'a encore fait le coup cet après-midi quand j'ai redémarré la bête : écran secondaire complètement brouillé (lignes blanches avec quelques couleurs, comme s'il était complètement désynchronisé horizontalement). Reboot sans rien toucher, et c'est reparti correctement 
. Ça me fait assez souvent ce coup, ou alors les écrans sont inversés, ou déplacés l'un par rapport à l'autre...
Donc comme tu le vois, le driver vidéo est "nouveau" (driver libre), et mes deux écrans sont connectés sur la carte vidéo.
donc une "DF stretch" ça va pas le faire
(ton profil) , même avec les backports
Ooops, pardon... Mon profil n'était pas à jour, j'ai corrigé. Donc, j'ai maintenant la version 10 (Buster).
pour les ressources matérielle lors de l'ajout d un gpu , tu a par exemple un changement de nom de la carte réseau mais c'est tout .
Je comprends mal ce que tu veux dire par là ? Il y a bien à minima à revoir la config des écrans ?
la GT 710B ne vaut rien pour jouer , mais je ne connais pas le gpu intégré au processeur
a priori ce jeux n' aime pas ta configuration ou est mal installé
j'ai pas trouvé la configuration minimale ici => https://www.flightgear.org/ (mémoire , cpu , gpu etc ..... )
On est bien d'accord que j'ai une config théoriquement bien insuffisante. Mais je ne suis pas du tout un gamer, j'ai juste quelques essais à faire avec FlightGear, qui fonctionnait très bien sans carte graphique, mais quand même trop lent pour mon besoin. J'ai donc ajouté la carte pour avoir (je pense ?) un peu mieux qu'avec les fonctions graphiques du processeur. Et j'ai effectivement une nette amélioration dans ce sens, qui me convient pour ce que j'ai à faire.
Mon souci n'est pas là, sauf si FlightGear arrive à modifier la manière dont le système démarre, ce qui me surprend mais qui semble être parfois le cas... ce qui n'est peut-être bien qu'une coïncidence. Mon souci est simplement que, depuis l'ajout de la carte vidéo, la config (essentiellement vidéo et peut-être son) change de manière assez aléatoire et que j'aimerais bien la refaire proprement. Mais pour cela, entre beaucoup d'autres choses, faut-il ou pas avoir un /etc/X11/xorg.conf ? Certains semblent dire que c'est la panacée, d'autres que c'est inutile...
Je me pose aussi la question sur ce qui peut faire que Firefox n'ait parfois plus de son, de manière assez aléatoire.
Note : je veux que le son sorte sur la carte intégrée (Advanced Micro Devices) et non sur le HDMI de la carte graphique.
et j'ai bien des tas de données qui défilent
Pas essayé encore en utilisation réelle : je viens aussi de rajouter une carte graphique, et mon simulateur de drone ne fonctionne plus (probablement juste à reconfigurer). FlightGear semble ne pas accepter ça comme joystick, à voir, mais je n'en suis pas vraiment surpris. En tous cas, je ne vois pas pourquoi, maintenant, la télécommande ne pourrait pas être utilisée comme joystick au moins avec un simulateur de drone (je poserai la question pour FlightGear sur le forum dédié), ce qui est mon but principal, au moins tant qu'un quadricoptère à peu près correct n'est pas dispo sous FlightGear.
Donc, merci infiniment pour ton aide précieuse et efficace, @raleur Je passe le sujet en résolu, le problème venait bien de toute évidence de cette UART. Je redonne à toutes fins utiles celle qui fonctionne bien : c'est ce modèle-ci, probablement dispo chez d'autres fournisseurs.
Un 4 couches serait séparé en 3 parties.
Evidemment ! Suis-je bête !
L'impédance d'entrée devrait être élevée.
Effectivement, d'après la DataSheet, ça semblerait... C'est pourquoi je suis assez étonné des mesures que j'ai faites ! Pourtant, elles sont assez confirmées par le comportement, en particulier l'écrasement du signal sans mon petit adaptateur...
Pourrait-il y avoir un court-circuit avec une des broches voisines du circuit intégré (TXD et RTS) ? Je sais bien que l'exemplaire sur la photo n'est pas le tien, mais on peut voir une masse claire entre les broches RXD et RTS (au niveau des lettres "SI" du marquage "SILABS") qui ne me plaît pas trop.
Ébédidon ! Je n'avais pas regardé la photo si attentivement ! C'est vrai qu'il semble bien y avoir un court-circuit entre les broches ! Mais mon exemplaire est assez clean de ce côté là.
Après, le PCB semble être du 4 faces, va savoir ce qui se passe sur les faces centrales ! Un via pourrait être placé trop près d'une masse ou va savoir...
Je commence à être à court d'idées.
Déjà, merci infiniment pour ton aide très précieuse et le temps que tu as passé sur ce problème C'est vraiment sympa !
Je propose qu'on attende une ou deux semaines que j'aie reçu la nouvelle UART que j'ai commandée. On peut effectivement se demander assez sérieusement si celle que j'ai n'a pas un gros défaut soit de conception soit de réalisation...
Je te tiens au courant dès que j'ai reçu et testé la nouvelle, ça confirmera/infirmera déjà cette question.
Si la valeur du courant varie peu en fonction de la tension, alors c'est peut-être le cas ici.
Peut-être. Mais reste que, comme tu dis, un courant de plus de 40mA, c'est trop...
Tu as revérifié si picocom recevait toujours l'écho avec le cavalier de rebouclage entre TX et RX ?
C'est ce qui me surprend : aucun problème de ce côté ! Mais bon, si cette UART n'est pas conforme aux normes et que le courant élevé qu'on constate est "normal" pour elle, encore heureux que la sortie TX soit compatible avec !
Tu les as bien exécutés sans avoir lancé (ou après avoir arrêté) l'instance d'inputattach sur le port avec --fsia6b ?
Pour picocom, oui. Pour inputattach, pas d'instance en cours et je lance :
J'ai essayé avec et sans le --baud 115200, puisque normalement --fsia6b positionne déjà à 115200bauds.
Je ne me serais pas embêté et j'aurais utilisé une porte logique non inverseuse quelconque (buffer, AND ou OR) ou deux portes logiques inverseuses (NAND ou NOR) en cascade,
Ben le problème, c'est que l'UART fout pas mal de trucs à genoux. Pas vraiment pu déterminer l'impédance, et le comportement est bizarre : avec une résistance de 47Ω vers la masse, j'ai encore plus de 2V sur RX, ce qui laisse supposer une résistance de pull-up sur le 3.3V de 30.5Ω. Par contre, chose curieuse, quand je court-circuite RX à la masse, j'ai un courant de 48mA, ce qui laisse supposer une résistance de pull-up de 68.8Ω... J'ai du mal à comprendre comment c'est foutu ! Donc, j'ai préféré un transistor qui mette RX à la masse (0V) lorsqu'il est saturé, au moins je suis sûr !
Tu devrais peut-être mettre une résistance en série sur la base du premier transistor, sinon si l'impédance de sortie du récepteur à l'état haut est faible, elle et le transistor risquent de souffrir.
C'est vrai, je n'y avais pas réfléchi...
Tu as relancé inputattach --dump ou bien picocom sur le port série ttyUSBx en 115200 bit/s pour voir s'il reçoit quelque chose ?
picocom ne reçoit rien du tout (mais je ne suis pas très sûr des bits de start/stop/parité... pas pris le temps de fouiller le net ou d'essayer toutes les combinaisons)
Par contre, à propos d'inputattach, quand j'ajoute --dump, il n'est pas content :
Quand je n'ajoute pas l'option, il semble se comporter normalement, mais on ne reçoit rien. Serait-ce le module que j'ai compilé qui n'est pas bon ?
Non, seulement le niveau des bits de données des octets transmis. Je répète, ce n'est pas du PWM. C'est une transmission de données numériques.
Ben... Excuse-moi de ne pas être d'accord, mais un octet donne une trace de ce genre, et un autre octet aura une trace différente, avec d'autres bits, et donc des largeurs et un nombre d'impulsions variable, ce qui devrait quand même se voir...
Bon, quoi qu'il en soit, il y a effectivement un problème d'adaptation d'impédances, reste à déterminer pourquoi. Un défaut du récepteur n'est pas impossible, mais j'en ai deux et je suis presque sûr de n'en avoir branché qu'un seul en USB, donc l'endommagement dû à ce branchement est très peu probable. Je vais essayer de voir ce qu'il en est...
Si tu veux visualiser l'effet de la manipulation des commandes, il faudrait l'augmenter afin de voir une trame d'octets entière.
J'ai tenté, mais je n'ai pas réussi à synchroniser correctement. Par contre, tu ne crois pas qu'on devrait quand même voir quelque chose bouger ? Les largeurs et nombre d'impulsions devraient varier, même sans synchro ça devrait se remarquer, or strictement rien ne bouge...
Je n'ai pas utilisé d'oscilloscope depuis environ 15 ans, donc ma science du déclenchement est complètement rouillée.
Donc, un peu plus récente que la mienne ! Reste que je ne vois pas comment on pourrait faire : pour autant que je me souvienne, on déclenche sur un niveau, en regardant ce qu'il y a juste avant ou après pour savoir si c'est un front montant ou descendant. Ou alors, il faudrait un déclenchement externe, et donc que l'UART ou le récepteur fournisse un top synchro au moment du start bit...
Donc il y a un problème qui écroule le niveau bas (actif). Tu es sûr du câblage ?
Oui, trois fils avec photos, je ne devrais pas me tromper, quand même ! Et si je me trompe, il va y avoir un problème d'alim (masse, plus, signal...) !
La sortie du récepteur sur l'entrée RX de l'UART et la masse/0V sur la masse ?
Ben oui, je répète : si c'était faux, le récepteur serait mal ou pas alimenté.
Tu as enlevé le pont entre TX et RX ?
Oui : je suis obligé pour brancher autre chose à la place.
Bon, je crois donc qu'on peut en conclure que mon UART chinoise ne vaut pas grand chose et qu'il faut que je m'en procure une autre ?
Je ne me suis pas trop préoccupé des impulsions télécommande arrêtée, juste de celles qui s'ajoutent quand on la met en route et qui font une largeur d'environ 2 à 3 ms.
Tiens, je n'y avais pas réfléchi, mais vu l'instabilité de la trace, une grosse erreur est très probable. Or, la largeur des impulsions PWM de la télécommande varient entre 1 et 2ms. Pas mesuré précisément d'une part parce que je n'avais pas vraiment pensé à cette possibilité et surtout parce que c'est difficile de bien se synchroniser dessus, mais la période totale semblerait bien être d'une vingtaine de ms, ce qui correspondrait bien à un signal PWM !
Observer un signal numérique pas vraiment périodique avec un oscilloscope analogique, ce n'est pas évident.
Ben oui, mais on fait ce qu'on peut avec ce qu'on a 
La sortie du récepteur était-elle à vide ou connectée à l'entrée RX de l'adaptateur USB-UART ?
Récepteur connecté sur l'UART par un câble de 20cm, sonde sur l'entrée RX de l'UART.
Comment as-tu fait la mesure ? Avec des fils volants ? avec une sonde d'oscilloscope branchée au plus près de la source ? une sonde compensée en impédance (1:10) ?
Je ne sais pas ce que tu appelles des fils volants... J'ai pris une petite nappe avec des connecteurs Dupont femelle de châque côté, et connecté ça d'une part au récepteur, d'autre part à l'UART. Exactement comme on fait pour une utilisation "normale" de la télécommande, quand on branche les canaux sur un servo ou un arduino...
Pour la sonde de l'oscillo, elle est tout à fait classique, utilisée en position x1.
Avec quel calibre ? Si je lis bien 0,5 V/division sur la photo, ça fait donc une hauteur moyenne entre niveaux haut et bas d'environ 1 V (2 divisions) sans compter le bruit, ce qui me semble insuffisant même pour du LVTTL.
Il ne faut pas trop regarder la photo, à part pour avoir une vague idée des signaux : vu les difficultés d'obtenir quelque chose de lisible, j'ai pas mal bricolé les réglages. Cependant, j'ai fait des mesures précises, avec un bon calibrage (lors de la photo, le potentiomètre d'amplitude verticale n'était pas en position "calibrée", donc les indications de V/div sont faussées).
En position DC, la trace est 2.2 divisions au-dessus du zéro (donc composante continue positive) avec un calibre de 1V/div. Là, les impulsions sont trop petites pour des mesures précises => passage en AC, calibre 0.1V/div, ce qui me donne les 220 et 300mV annoncés, qu'on pourrait effectivement plutôt considérer comme du bruit. Ce sont ces impulsions qu'on voit sur la photo.
Pour la base de temps, j'étais à 5ms/div, ce qui donne un peu moins de 5ms entre les trains d'impulsions. Je ne me suis pas trop préoccupé des impulsions télécommande arrêtée, juste de celles qui s'ajoutent quand on la met en route et qui font une largeur d'environ 2 à 3 ms.
Le signal émis par un UART n'a rien à voir avec du PWM.
Ben c'est ce qui m'étonne un peu... Les impulsions qui s'ajoutent lorsque la télécommande est en route y ressemblent assez, c'est ce qui me fait dire que c'est peut-être simplement une diaphonie avec les sorties PWM des canaux séparés, et donc que la télécommande serait mal programmée pour envoyer ce qu'il faut sur la sortie Ibus...
