Vous n'êtes pas identifié(e).
S'il a des dépendances non chargées, il faut les lister et les charger avec
avant de ré-exécuter insmod.
Si ça fonctionne bien, tu peux copier le module dans son emplacement "naturel", /lib/modules/($uname -r)/kernel/drivers/input/joystick/ et exécuter
pour mettre à jour les fichiers modules.dep, modules.alias et compagnie qui permettent le chargement automatique du module et de ses dépendances.
Dernière modification par raleur (21-07-2020 08:33:20)
Il vaut mieux montrer que raconter.
Hors ligne
et
À 9600 baud, ça passe bien en mode dump, mais rien ne se passe quand j'agis sur la télécommande...
Hors ligne
J'ai bien maintenant un /dev/ttyUSB0 qui apparaît quand je branche le récepteur
Normalement ça apparaît quand tu branches l'adaptateur USB-UART, indépendamment du module fsia6b ou du récepteur.
inputattach: invalid mode '--fsia6b'
D'après la comparaison des pages de manuel, il faut au moins la version d'inputattach de testing pour supporter l'option --fsia6b.
Aucune idée de la vitesse utilisée.
Dernière modification par raleur (21-07-2020 16:47:30)
Il vaut mieux montrer que raconter.
Hors ligne
ne rend pas la main. Je ne pense pas que ce soit normal ? Aucune réaction à la télécommande non plus.
Ayant fait cet inputattach, que je laisse dans le terminal qui ne rend pas la main, je lance jstest-gtk (celui de Buster... Faudrait-il essayer celui de SID ?) qui me trouve bien :
FS−IA6B iBus receiver
Device: /dev/input/js0
Axes: 14
Buttons: 9
À part le nombre d'axes et boutons qui me parait un peu élevé (mais c'est peut-être normal, on peut changer le firmware de la FS-IA6 pour en faire une 10 canaux), ça semble bon ! Mais rien ne se passe quand j'agis sur la télécommande...
cette fois ne renvoie plus d'erreur, mais ne rend pas la main (je pense que c'est normal, il veut afficher le dump ?) et n'affiche rien quand je manipule la télécommande.
Je précise que le récepteur est bien appairé (d'origine, livré avec la télécommande) et que sa LED s'affiche bien fixement lorsque la télécommande est en marche.
Hors ligne
ne rend pas la main. Je ne pense pas que ce soit normal ?
D'après la page de manuel, il faut l'option --daemon pour que le processus passe en tâche de fond.
Tu es sûr de la vitesse de transmission ?
Il vaut mieux montrer que raconter.
Hors ligne
D'après la page de manuel, il faut l'option --daemon pour que le processus passe en tâche de fond.
Ooops ! Pas fait gaffe et pas pensé à ça ! Bon, je n'ai pas le matos sous la main, je ré-essaierai, mais ça doit expliquer et résoudre la question du rendu de main.
Tu es sûr de la vitesse de transmission ?
Ben... Pas vraiment, mais :
- On ne s'en préoccupe pas quand on utilise l'option --fsia6b, je suppose que cette option s'occupe de la positionner à la bonne vaieur...
- Les 115200 bauds sont tirés de cette doc, je n'en connais pas d'autre et je ne vois pas pourquoi elle serait fausse...
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Curieux quand même que les couleurs soient les mêmes que celles d'un câble USB
Je ne trouve pas. Le noir et le rouge sont très souvent utilisés pour la masse et le +5V (comme sur les fiches d'alimentation ATX, les fiches "Molex", les fiches d'alimentation SATA... Quant au blanc, c'est la couleur "bateau" par excellence pour n'importe quel signal.
je n'en ai jamais vu avec autre chose qu'un connecteur ou à la rigueur (comme la mienne), des Dupont Mâles...
Qu'appelles-tu Dupont ? Si c'est un connecteur Sub-D 9 ou 25 broches, il s'agit certainement d'une interface RS232 et non TTL et c'est normal que tu ne reçoives rien.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
il faudrait peut-être que je cherche un truc qui communique avec pour voir, mais je ne crois rien avoir sous la main.
Tu peux relier la sortie TX à l'entrée RX de l'adaptateur, envoyer des caractères et vérifier s'ils sont bien reçus en écho avec un émulateur de terminal série comme picocom.
Il vaut mieux montrer que raconter.
Hors ligne
Quels sont les signaux disponibles sur le connecteur ?
Connecteur de l'USB-UART :
3.3V
RST
5V
TxC
RxC
GND
Connecteur "iBus-Servo" du FSIA6B :
GND
+5V
Data
Comment l'as-tu câblé avec le récepteur ?
Donc, je connecte comme indiqué sur la doc les 2 masses ensemble, les deux +5V ensemble, et la sortie Data du récepteur sur RxC de l'USB-UART.
Tu peux relier la sortie TX à l'entrée RX de l'adaptateur, envoyer des caractères et vérifier s'ils sont bien reçus en écho avec un émulateur de terminal série comme picocom.
Ah ! Je ne connaissais pas picocom. Je l'ai donc installé et fait l'essai, quand je tape "azerty" au clavier, il s'affiche bien à l'écran. J'ai essayé aussi en forçant la vitesse à 115200 bauds (par défaut à 9600) qui semble être celle du récepteur, ça fonctionne aussi parfaitement. Pas essayé de bricoler les start/stop bits, puisque je ne sais pas ce qu'utilise le FSIA6B, mais il n'y a pas de raison que ça ne fonctionne pas quelle que soit leur config (mais est-elle à préciser avec inputattach ? AMHA, l'option --fsia6b devrait tout mettre aux bonnes valeurs ?)
Encore un truc, pour ne pas me faire accuser de cacher des choses : comme je l'avais évoqué dans ce post, j'avais eu une erreur de compil pour le module fsia6b. Un define manquant, qui selon cette page, est à définir ainsi :
et correspondrait au code constructeur. J'ai donc rajouté la ligne correspondante dans le source de fsia6b.c.
Dernière modification par jibe (24-07-2020 10:26:52)
Hors ligne
je connecte comme indiqué sur la doc les 2 masses ensemble, les deux +5V ensemble, et la sortie Data du récepteur sur RxC de l'USB-UART.
Ça me semble correct. Sur les photos de l'adaptateur on voit un voyant "DATA" ; est-ce qu'il s'allume lorsque le récepteur est branché et la radiocommande allumée ?
Je ne connaissais pas picocom. Je l'ai donc installé et fait l'essai, quand je tape "azerty" au clavier, il s'affiche bien à l'écran.
Tu as vérifié que ce n'est pas juste un écho local du terminal ? Rien ne doit s'afficher quand TXC et RXC ne sont pas reliés.
Il vaut mieux montrer que raconter.
Hors ligne
Ça me semble correct. Sur les photos de l'adaptateur on voit un voyant "DATA" ; est-ce qu'il s'allume lorsque le récepteur est branché et la radiocommande allumée ?
Il n'y a pas de voyant "DATA"... Tu parles peut-être du voyant noté "LED" ? Il clignotte quand la télécommande est éteinte et s'allume en même temps qu'elle. Et l'appairage entre les deux est bien bon : ça fonctionne parfaitement avec un servo-moteur (mais, il est vrai, sur un des "channels" et non pas sur la sortie iBus-servo).
Tu as vérifié que ce n'est pas juste un écho local du terminal ? Rien ne doit s'afficher quand TXC et RXC ne sont pas reliés.
Effectivement, si je ne relie pas TxC et RxC sur l'USB-UART, je n'ai plus d'écho. Correct de ce côté également...
En fouillant beaucoup le web, j'ai fini par trouver que, pour utiliser la sortie iBus-servo, il fallait aller dans le menu System de la télécommande, aller sur "RX Setup" et positionner "PPM Output" sur On. Il était sur Off dans mon cas, mais une fois mis sur On, ça ne change malheureusement rien. Sauf que ça me conforte un peu dans mon idée que ce n'est peut-être qu'une question de programmation de la télécommande, mais c'est très incomplètement documenté et je n'ai trouvé qu'une seule mention, en cherchant bien, concernant ce "PPM output". Et bien sûr, il n'en est pas question dans la doc qui semble la référence en la matière et que j'ai utilisée jusque là
Voilà où j'en suis... Je ne sais pas ce que tu en penses, mais soit c'est un problème de config de la télécommande, soit c'est le module que j'ai compilé qui, pour une raison quelconque, ne fonctionne pas correctement.
Hors ligne
Il n'y a pas de voyant "DATA"... Tu parles peut-être du voyant noté "LED" ?
Je parle de la led avec la sérigraphie "DATA" qu'on peut voir sur les photos de l'adaptateur USB-UART dans la page https://fr.aliexpress.com/item/40005192 … 6c37bG6vKY que tu as indiquée plus haut.
Je ne sais pas ce que tu en penses, mais soit c'est un problème de config de la télécommande, soit c'est le module que j'ai compilé qui, pour une raison quelconque, ne fonctionne pas correctement.
Le module n'intervient pas lorsqu'on écoute les données brutes reçues par l'UART avec inputattach --dump ou avec picocom.
L'idéal, ce serait un oscilloscope pour vérifier s'il y a bien du signal sur cette sortie.
Il vaut mieux montrer que raconter.
Hors ligne
Je parle de la led avec la sérigraphie "DATA" qu'on peut voir sur les photos de l'adaptateur USB-UART
Ooops, je croyais que tu parlais du récepteur de télécommande... Ah, ben non, elle ne s'allume pas (mais clignotte quand je teste avec picocom, effectivement).
Et du coup, je m'aperçois d'autre chose que j'ai dû oublier de vérifier : après le inputattach, voici ce que dit dmesg :
Il y a donc bien un problème quelque part entre l'USB-UART et le récepteur de télécommande, ou alors dans le truc que j'ai compilé !
L'idéal, ce serait un oscilloscope pour vérifier s'il y a bien du signal sur cette sortie.
Oui, bien sûr... Je peux essayer d'en emprunter un, mais ça ne sera pas pour tout de suite...
Hors ligne
voici ce que dit dmesg
C'est juste parce que tu charges un module externe compilé maison non signé sur un noyau signé qui vérifie logiquement si les modules qu'on lui demande de charger sont signés. Si tu avais démarré avec le secure boot activé, il aurait refusé. C'est la même chose avec les modules externes nvidia, virtualbox...
Dernière modification par raleur (25-07-2020 16:30:53)
Il vaut mieux montrer que raconter.
Hors ligne
Il existe des modules d'acquisition USB qui permettent de faire un oscilloscope virtuel, mais il faut le logiciel qui va bien avec.
Oui, et me semble-t-il que ce n'est pas simple d'avoir quelque chose qui va bien. Si je ne me trompe, il y a quelques rares trucs super, mais pas mal de m**
Bon, alors attendons que je puisse me procurer un oscillo et regarder ça de plus près...
Hors ligne
Dernière modification par jibe (08-08-2020 11:00:37)
Hors ligne
Dernière modification par raleur (08-08-2020 12:21:46)
Il vaut mieux montrer que raconter.
Hors ligne
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...
Hors ligne
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 !
Hors ligne
Récepteur connecté sur l'UART par un câble de 20cm, sonde sur l'entrée RX de l'UART.
Dans un premier temps essaie plutôt avec le récepteur à vide non connecté à l'UART pour éviter toute éventuelle interférence de ce dernier, sans nappe si possible.
Pour la sonde de l'oscillo, elle est tout à fait classique, utilisée en position x1.
Essaie plutôt avec la sonde en x10 (1:10) bien ajustée pour compenser l'impédance de l'oscilloscope et de la sonde, ainsi les transitions du signal seront moins déformé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
Pas normal. Dans ton message #5 tu écrivais que tu mesurais 3.3V sur la pin signal au multimètre. Est-ce toujours le cas ? Si oui, tu devrais retrouver à peu près la même valeur comme niveau haut à l'oscilloscope. Où prends-tu la masse ?
Pour la base de temps, j'étais à 5ms/div
A 115200 bit/s, la durée d'un bit est de 8,7 µs et la durée de transmission d'un octet de 87 µs (en supposant 1 bit de start à 0, 8 bits de données sans parité, 1 bit de stop à 1 donc 10 bits par octet). Il faut donc une base de temps beaucoup plus rapide pour observer un octet (20 µs/div serait un minimum). Déclenchement sur le front descendant du bit de start.
Dernière modification par raleur (08-08-2020 14:06:22)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Par contre, drôle de truc : quand je suis branché sur l'UART, cette composante persiste même en débranchant la masse de l'oscillo ! Bizarre retour par la terre ?
Oui, si la masse de l'ordinateur est reliée à la terre.
Par contre, comment déclencher sur le front descendant du bit de start ? Il déclenche sur le premier front descendant qu'il trouve, et du coup les bits se superposent ! Bon, en tous cas, j'ai refait une (mauvaise) photo, base de temps réglée sur 10µs.
Ça suffit pour voir que la largeur d'un bit est d'environ 9 µs et confirmer le débit de 115200 bit/s, ce qui était le but avec cette base de temps. Si tu veux visualiser l'effet de la manipulation des commandes, il faudrait l'augmenter afin de voir une trame d'octets entière.
Je n'ai pas utilisé d'oscilloscope depuis environ 15 ans, donc ma science du déclenchement est complètement rouillée.
Du coup, j'ai refait l'essai avec l'UART. Et là, je retrouve bien le même genre d'impulsions, mais qui ne varient plus de 0 à 3.5V, mais d'environ 3.2 à 3.5V !
Donc il y a un problème qui écroule le niveau bas (actif). Tu es sûr du câblage ? La sortie du récepteur sur l'entrée RX de l'UART et la masse/0V sur la masse ? Tu as enlevé le pont entre TX et RX ?
Il vaut mieux montrer que raconter.
Hors ligne