Réalisation d'un pont diviseur de tension
Modérateurs : Francois, smba38
-
- Raspinaute
- Messages : 735
- Enregistré le : lun. 22 déc. 2014 16:50
- Localisation : 67380 LINGOLSHEIM
Re: Réalisation d'un pont diviseur de tension
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
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
-
- Raspinaute
- Messages : 1089
- Enregistré le : lun. 15 août 2016 21:38
Re: Réalisation d'un pont diviseur de tension
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 ?
A tu essayé de ne câbler que le signal B ?
Le premier ennemi de la connaissance n’est pas l’ignorance, c’est l’illusion de la connaissance (S. Hawking).
Re: Réalisation d'un pont diviseur de tension
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 :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 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 :Je ne suis pas certain que le Raspberry (et la libwiringPi) sache traiter ces 2 interruptions en même temps.
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 :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.
Ouaip, ça c'est déjà fait ! D'ailleurs, si le code intéresse quelqu'un, je peux le poster.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.
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 :
Tout à fait, c'est bien ça qui me laisse perplexe.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.
Comme indiqué plus haut dans ce message, je fais ça dans la journée et je vous tiens au courant !Bud Spencer a écrit :A tu essayé de ne câbler que le signal B ?
- RPi 3 + LibreELEC / RPi 3 + RetroPie / RPi B+ + Sense HAT ou Framboisedorf ou module caméra
- Arduino Mega, Uno, Nano
- Freescale FRDM KL25Z
-
- Raspinaute
- Messages : 735
- Enregistré le : lun. 22 déc. 2014 16:50
- Localisation : 67380 LINGOLSHEIM
Re: Réalisation d'un pont diviseur de tension
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.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 !
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
Re: Réalisation d'un pont diviseur de tension
Je taquinais !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
Merci, ça me fait plaisir à lire !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.
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...
- RPi 3 + LibreELEC / RPi 3 + RetroPie / RPi B+ + Sense HAT ou Framboisedorf ou module caméra
- Arduino Mega, Uno, Nano
- Freescale FRDM KL25Z
-
- Raspinaute
- Messages : 735
- Enregistré le : lun. 22 déc. 2014 16:50
- Localisation : 67380 LINGOLSHEIM
Re: Réalisation d'un pont diviseur de tension
Si on regarde les maillons qui constituent la chaîne de traitement, on trouve: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...
-) 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
-
- Raspinaute
- Messages : 629
- Enregistré le : mar. 6 janv. 2015 19:44
- Localisation : finistere
Re: Réalisation d'un pont diviseur de tension
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 .
rpi b+ ,osmc, motioneyes
rpi 2 raspbian , server minecraft 24h/24 , utilisation gpio
orange pi pc debian ,utilisation gpio, motion cam
rpi 2 raspbian , server minecraft 24h/24 , utilisation gpio
orange pi pc debian ,utilisation gpio, motion cam
Re: Réalisation d'un pont diviseur de tension
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 :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.
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 !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).
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 !
En effet, ça en fait des lectures !spourre a écrit :Nota: As-tu vu le compteur d'accès à nos discussions ? Il y a du monde à la fenêtre.
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ù.guillaume9344 a écrit :Il va peut être falloir exploiter la liaison différentielle en fin de compte pour supprimer les parasites .
- RPi 3 + LibreELEC / RPi 3 + RetroPie / RPi B+ + Sense HAT ou Framboisedorf ou module caméra
- Arduino Mega, Uno, Nano
- Freescale FRDM KL25Z
-
- Raspinaute
- Messages : 735
- Enregistré le : lun. 22 déc. 2014 16:50
- Localisation : 67380 LINGOLSHEIM
Re: Réalisation d'un pont diviseur de tension
Ça change tout, Il faut absolument lever le doute sur le signal qui vient du RADAR .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 !
...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ù.guillaume9344 a écrit :Il va peut être falloir exploiter la liaison différentielle en fin de compte pour supprimer les parasites .
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
Re: Réalisation d'un pont diviseur de tension
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 !
J'ai l'air de râler, mais en vrai j'aime bien bricoler avec tout ça...
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 !
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 !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).
J'ai l'air de râler, mais en vrai j'aime bien bricoler avec tout ça...
- RPi 3 + LibreELEC / RPi 3 + RetroPie / RPi B+ + Sense HAT ou Framboisedorf ou module caméra
- Arduino Mega, Uno, Nano
- Freescale FRDM KL25Z