framboise314.fr

Vu comme ça, les signaux ont l'air propres et les niveaux corrects.
De mémoire, mais j'ai la flemme de rechercher dans tous mes posts, il me semble que je t'avais conseillé de ne traiter, dans un premier temps, que le signal B (celui des tours d'antenne) qui me semblait plus problématique.

Je te le suggères, à nouveau, avec une hypothèse:
Sur l'oscillogramme, on voit nettement que les signaux sont synchrones et changent d'état au même moment (ce qui est logique).
Je ne suis pas certain que le Raspberry (et la libwiringPi) sache traiter ces 2 interruptions en même temps.

A la limite, quand le signal B est présent, le signal A ne te sert à rien et pourrait être ignoré soit logiciellement, soit matériellement avec un XOR.

En approche logicielle, une interruption est armée sur le signal B et met le compteur à 0.
Le signal A est traité dans une boucle (avec les tempos suggérées par Bud dans la Saga) et incrémente ce même compteur qui te donne la position de l'antenne.

Sylvain

Ce qui est étrange, c’est que cela fonctionne avec les signaux de l’arduino et pas avec ceux du radar. Pourtant, même s’ils ne sont pas parfaits ces derniers semblent corrects (au moins à titre expérimental). Coté codage il y a une multitude de façons de faire mais si cela fonctionne avec une source de signal, cela devrait fonctionner tout pareil avec l’autre qui visiblement est identique.

A tu essayé de ne câbler que le signal B ?

spourre a écrit :De mémoire, mais j'ai la flemme de rechercher dans tous mes posts, il me semble que je t'avais conseillé de ne traiter, dans un premier temps, que le signal B (celui des tours d'antenne) qui me semblait plus problématique.

Justement, non : "Dans un premier temps, je vous suggère de ne tester que le signal ,A, en rendant votre programme paramétrable au lancement, avec 2 arguments pour la durée de l'impulsion et pour sa fréquence.."

spourre a écrit :Je ne suis pas certain que le Raspberry (et la libwiringPi) sache traiter ces 2 interruptions en même temps.

Je pense que oui, puisque j'arrive à faire exactement ce que je souhaite avec ces deux signaux en utilisant l'Arduino comme générateur de signal, c'est lorsque je passe sur le radar que ça se gâte... Avec l'Arduino qui génère le signal, j'arrive à compter mes 16 000 et quelques impulsions du signal A, remises à 0 à chaque détection d'une impulsion du signal B. La seule différence entre mes tests avec Arduino et ceux sur le radar est la présence de parasites sur les signaux. Dans chaque cas, j'ai un signal A de fréquence 4 kHz et de période 250 µs, et un signal B consistant en une impulsion de 125 µs toutes les 4 secondes.

spourre a écrit :A la limite, quand le signal B est présent, le signal A ne te sert à rien et pourrait être ignoré soit logiciellement, soit matériellement avec un XOR.

Pourquoi ignorer le signal A ? Il faudrait que je le mette de côté histoire de tester uniquement le B, histoire de voir si c'est le cumul des deux signaux qui est de trop pour le RPi. Je vais faire ça dans la journée !

spourre a écrit :En approche logicielle, une interruption est armée sur le signal B et met le compteur à 0.
Le signal A est traité dans une boucle (avec les tempos suggérées par Bud dans la Saga) et incrémente ce même compteur qui te donne la position de l'antenne.

Ouaip, ça c'est déjà fait ! D'ailleurs, si le code intéresse quelqu'un, je peux le poster.

Je me répète : merci pour votre aide, c'est motivant d'arriver le matin au travail et de voir vos messages qui me donnent matière à réfléchir et à expérimenter dans la journée !

EDIT pour répondre à Bud Spencer :

Bud Spencer a écrit :Ce qui est étrange, c’est que cela fonctionne avec les signaux de l’arduino et pas avec ceux du radar. Pourtant, même s’ils ne sont pas parfaits ces derniers semblent corrects (au moins à titre expérimental). Coté codage il y a une multitude de façons de faire mais si cela fonctionne avec une source de signal, cela devrait fonctionner tout pareil avec l’autre qui visiblement est identique.

Tout à fait, c'est bien ça qui me laisse perplexe.

Bud Spencer a écrit :A tu essayé de ne câbler que le signal B ?

Comme indiqué plus haut dans ce message, je fais ça dans la journée et je vous tiens au courant !

Pinhapple a écrit :...
Justement, non : "Dans un premier temps, je vous suggère de ne tester que le signal ,A, en rendant votre programme paramétrable au lancement, avec 2 arguments pour la durée de l'impulsion et pour sa fréquence.."
...
Je me répète : merci pour votre aide, c'est motivant d'arriver le matin au travail et de voir vos messages qui me donnent matière à réfléchir et à expérimenter dans la journée !
...
Comme indiqué plus haut dans ce message, je fais ça dans la journée et je vous tiens au courant !

Je pensais que le signal A serait le plus problématique à traiter du fait de sa faible durée (cf. remarque de Bud sur la latence) et de sa fréquence.
L'idée était quand même déjà de ne tester que sur un seul signal et, à la limite, en le ralentissant assez, le signal A devient un signal B

( vieux singe, grimace, toutça ...)

Je me répète aussi, pour moi (nous) c'est motivant d'avoir un contributeur qui s'accroche et explore toutes les pistes suggérées sans se décourager.

Sylvain

spourre a écrit :Je pensais que le signal A serait le plus problématique à traiter du fait de sa faible durée (cf. remarque de Bud sur la latence) et de sa fréquence.
L'idée était quand même déjà de ne tester que sur un seul signal et, à la limite, en le ralentissant assez, le signal A devient un signal B

Je taquinais !

spourre a écrit :Je me répète aussi, pour moi (nous) c'est motivant d'avoir un contributeur qui s'accroche et explore toutes les pistes suggérées sans se décourager.

Merci, ça me fait plaisir à lire !

Je reviens du radar, sur lequel je me suis branché pour lire uniquement le signal B. J'ai fait rapidement un soft en C basique : dès qu'il y a un front montant sur la pin 3, on incrémente un compteur initialisé à 0, compteur que l'on affiche en continu en console avec un while (1). Probablement pas ce qui se fait de plus propre, mais suffisant pour les besoins de ce test.

Résultat : même chose que d'habitude. Au lieu de s'incrémenter de 1 à chaque seconde, le compteur s'incrémente d'environ 1 000 à chaque seconde. J'avais d'abord essayé ce soft de test avec l'Arduino qui générait le signal, et ça fonctionnait comme attendu...

Pinhapple a écrit : ....
Je reviens du radar, sur lequel je me suis branché pour lire uniquement le signal B. J'ai fait rapidement un soft en C basique : dès qu'il y a un front montant sur la pin 3, on incrémente un compteur initialisé à 0, compteur que l'on affiche en continu en console avec un while (1). Probablement pas ce qui se fait de plus propre, mais suffisant pour les besoins de ce test.

Résultat : même chose que d'habitude. Au lieu de s'incrémenter de 1 à chaque seconde, le compteur s'incrémente d'environ 1 000 à chaque seconde. J'avais d'abord essayé ce soft de test avec l'Arduino qui générait le signal, et ça fonctionnait comme attendu...

Si on regarde les maillons qui constituent la chaîne de traitement, on trouve:

-) le signal du RADAR
-) le pont diviseur
-) le Raspberry (port GPIO)
-) le logiciel.

Si le test avec le signal issu de l'Arduino c'est fait dans les mêmes conditions (même pont diviseur, même GPIO et même logiciel) qu'avec le signal du RADAR, on peut mettre en doute le seul point qui diffère entre ces 2 tests: Le signal B du RADAR.

Dans quelles conditions les oscillogrammes qui montrent un signal "propre" ont-il été relevés ? Sur quel type d'oscilloscope, avec quelles caractéristiques (c'est un point que j'avais déjà évoqué).
Il est possible que certains "spikes" ne soient pas visibles mais parasitent le signal. Il faudrait essayer avec un filtrage (logiciel ou matériel avec un trigger de Schmitt).

Nota: As-tu vu le compteur d'accès à nos discussions ? Il y a du monde à la fenêtre.

Sylvain

Pinhapple a écrit :
Résultat : même chose que d'habitude. Au lieu de s'incrémenter de 1 à chaque seconde, le compteur s'incrémente d'environ 1 000 à chaque seconde. J'avais d'abord essayé ce soft de test avec l'Arduino qui générait le signal, et ça fonctionnait comme attendu...

Il va peut être falloir exploiter la liaison différentielle en fin de compte pour supprimer les parasites .

spourre a écrit :Si le test avec le signal issu de l'Arduino c'est fait dans les mêmes conditions (même pont diviseur, même GPIO et même logiciel) qu'avec le signal du RADAR, on peut mettre en doute le seul point qui diffère entre ces 2 tests: Le signal B du RADAR.

J'ai mis de côté le traitement avec le RPi le temps de faire un test avec une Arduino Nano, histoire de voir si j'ai le même souci de lecture du signal B.

spourre a écrit :Dans quelles conditions les oscillogrammes qui montrent un signal "propre" ont-il été relevés ? Sur quel type d'oscilloscope, avec quelles caractéristiques (c'est un point que j'avais déjà évoqué).
Il est possible que certains "spikes" ne soient pas visibles mais parasitent le signal. Il faudrait essayer avec un filtrage (logiciel ou matériel avec un trigger de Schmitt).

Tout ce qui est "propre" a été fait en mesurant le signal de l'Arduino. Je ne saurais pas du tout dire quel type d'oscillo j'ai utilisé par contre !
Je vais commencer à voir comment utiliser le trigger de Schmitt dans mon circuit, je pense que je ne vais pas trop avoir le choix donc autant s'y mettre !

spourre a écrit :Nota: As-tu vu le compteur d'accès à nos discussions ? Il y a du monde à la fenêtre.

En effet, ça en fait des lectures !

guillaume9344 a écrit :Il va peut être falloir exploiter la liaison différentielle en fin de compte pour supprimer les parasites .

C'est une autre option que je peux exploiter, en effet. Ça me rebute un peu plus que d'utiliser un trigger, je vais mettre ça de côté au cas où.

Pinhapple a écrit :

spourre a écrit :...
Tout ce qui est "propre" a été fait en mesurant le signal de l'Arduino. Je ne saurais pas du tout dire quel type d'oscillo j'ai utilisé par contre !
Je vais commencer à voir comment utiliser le trigger de Schmitt dans mon circuit, je pense que je ne vais pas trop avoir le choix donc autant s'y mettre !
...

guillaume9344 a écrit :Il va peut être falloir exploiter la liaison différentielle en fin de compte pour supprimer les parasites .

C'est une autre option que je peux exploiter, en effet. Ça me rebute un peu plus que d'utiliser un trigger, je vais mettre ça de côté au cas où.

Ça change tout, Il faut absolument lever le doute sur le signal qui vient du RADAR .
Le trigger n'est qu'un palliatif au fait de ne pas vouloir (pouvoir) utiliser la liaison différentielle.
Si le signal est très perturbé, il faut s'orienter vers l'exploitation de la liaison différentielle qui n'a pas du être choisie "au pif" par le constructeur.
Je t'avais donné un lien vers un petit module chinois à base de Maxim, Dès que tu as confirmation de la pollution du signal, même si, en attendant, tu bricoles avec un trigger de Schmitt à titre pédagogique et que cela fonctionne, je te recommande fortement de commander un de ces modules (ou alors, tu construit toi-même le récepteur différentiel à base d'ampli OP).
Si tu dois présenter oralement ton projet, tu pourras facilement justifier ce choix.

Sylvain

Je reviens du radar où j'ai fait mon test de lecture avec l'Arduino Nano, c'est de mieux en mieux : je ne détecte rien de bien sur aucun des signaux !
Si j'essaie de lire les signaux A et B en même temps, mes compteurs restent à 0 ; si je débranche le fil A, le compteur B s'incrémente à une vitesse folle ; si je débranche le fil B, le compteur A s'incrémente à une vitesse folle.
Ajoutons à cela un écran tactile qui n'en fait qu'à sa tête et une carte microSD en fin de vie, on obtient le combo parfait pour la crise de nerfs !

spourre a écrit :Je t'avais donné un lien vers un petit module chinois à base de Maxim, Dès que tu as confirmation de la pollution du signal, même si, en attendant, tu bricoles avec un trigger de Schmitt à titre pédagogique et que cela fonctionne, je te recommande fortement de commander un de ces modules (ou alors, tu construit toi-même le récepteur différentiel à base d'ampli OP).

Je vais déjà mettre au propre tout ce que je sais, tous mes tests et mes pistes, histoire d'y voir plus clair. Ensuite j'étudierai cette solution, et j'aurai probablement besoin d'aide à un moment ou à un autre !

J'ai l'air de râler, mais en vrai j'aime bien bricoler avec tout ça...