Réalisation d'un pont diviseur de tension

Un lieu pour discuter des composants et de leur utilisation. Un passage obligé si vous devez interfacer votre Raspberry Pi avec le monde extérieur. On y trouvera aussi les cartes type commande de moteur pas à pas, continu, servo...

Modérateurs : Francois, smba38

spourre
Raspinaute
Messages : 735
Enregistré le : lun. 22 déc. 2014 16:50
Localisation : 67380 LINGOLSHEIM

Re: Réalisation d'un pont diviseur de tension

Message par spourre » mer. 26 avr. 2017 18:09

Pinhapple a écrit : Tu mentionnes de temps en temps que tu as déjà dit telle ou telle chose : ne va pas croire que je ne lis pas vos messages, j'ai un cahier A4 que je complète chaque jour avec vos suggestions ! :D
Je ne suis pas archi à l'aise avec l'électronique, donc je préfère demander quitte à me répéter malgré moi !
...
Je vois ce que tu veux dire, et je suis d'accord. Ça va fonctionner dans un premier temps sur mon radar, puis je vais passer au suivant avec lequel ça ne fonctionnera pas, donc je rajouterai encore du bricolage, etc.
...
Merci pour ton aide et la régularité de tes réponses !
Je te rassure, quand j'écris que j'ai déjà mentionné une information ou un concept, c'est pour te donner une piste pour retrouver ce passage et, éventuellement, l'approfondir par une recherche personnelle sur Internet ou dans tes cours.
Si j'avais le moindre doute sur ta motivation, je passerai à autre chose :ugeek:

Même si l'électronique n'est pas le cœur de ta formation et de ton futur métier, elle t'imposera tout de même ses contraintes. Ton circuit (et ton logiciel) aura beau être hyper véloce, un circuit imprimé mal conçu en limitera les performances (cf nos échanges entre Bud et moi-même sur la fréquence max du SPI).

Je te mets un lien vers un article (pas trop compliqué) sur les sondes compensées en fréquence, tu verras que les mêmes phénomènes peuvent dégrader tes beaux signaux (les oscilloscopes ont souvent une sortie en signal carré pour ajuster la compensation):
http://www.google.fr/url?sa=t&rct=j&q=& ... LZ5IQViUuw

Tu as bien compris mon message. Ton montage doit fonctionner et être reproductible.

Bon courage.

Sylvain

Pinhapple
Raspinaute
Messages : 125
Enregistré le : jeu. 23 févr. 2017 15:53
Localisation : Rouen

Re: Réalisation d'un pont diviseur de tension

Message par Pinhapple » jeu. 27 avr. 2017 11:48

spourre a écrit :Si j'avais le moindre doute sur ta motivation, je passerai à autre chose :ugeek:
Merci ! :)
spourre a écrit :Je te mets un lien vers un article (pas trop compliqué) sur les sondes compensées en fréquence, tu verras que les mêmes phénomènes peuvent dégrader tes beaux signaux (les oscilloscopes ont souvent une sortie en signal carré pour ajuster la compensation):
Intéressant comme article, j'ai appris quelques trucs ! ;)

De mon côté, j'ai récupéré une petite puce DS26LS32CN pour faire des tests en attendant la réception des shields. C'est du RS-422 et non du 485, mais on m'a dit que ça ne devrait pas être gênant dans mon cas, et ça reste des tests. Je vais reproduire le montage du schéma de câblage : deux résistances pull-up/pull-down de 3,3 kΩ sur chaque signal, et une résistance de 120 Ω entre les deux signaux.

Après lecture de la datasheet du DS26LS32CN, je vois qu'il y a deux broches G ("active-high") et G-avec-une-barre-au-dessus ("active-low"). Quelques petites recherches, et je tombe sur un article qui indique que ces broches doivent être reliées respectivement au 5 V et au GND : pouvez-vous confirmer que j'ai à faire ça aussi dans mon cas ? A quoi servent ces broches ?
  • RPi 3 + LibreELEC / RPi 3 + RetroPie / RPi B+ + Sense HAT ou Framboisedorf ou module caméra
  • Arduino Mega, Uno, Nano
  • Freescale FRDM KL25Z

spourre
Raspinaute
Messages : 735
Enregistré le : lun. 22 déc. 2014 16:50
Localisation : 67380 LINGOLSHEIM

Re: Réalisation d'un pont diviseur de tension

Message par spourre » mar. 2 mai 2017 11:46

La résistance de 120 ohms sert à fermer la ligne de transmission sur son impédance nominale en vue de limiter les problèmes de réflexion en bout de ligne.
Dans la data sheet, elle est mentionnée mais non obligatoire avec ce circuit intégré . Elle permet donc d'obtenir un débit maximum et la mettre en place ne peut pas nuire. Si tu ne l'as pas sous la main, tu prends une valeur approchée à +- 10 %.

Les résistances de rappel ne sont pas indispensables non plus.
Comme pour tout circuit numérique, il est recommandé de mettre au plus près des broches d’alimentation une capacité de découplage (100 nF, polyester). Une capa électrochimique (ou tantale) de plus forte valeur (100 micro F ) est recommandée sur le bus d'alimentation, à l'entrée de la carte.

Les broches G et non G (ou G barre) contrôlent le comportement en sortie (front montant, descendant ou tri-state). Une seule est nécessaire mais il n'est pas recommandé de laisser une broche en l'air. Ceci est très clairement illustré dans la data sheet.

Sylvain

Pinhapple
Raspinaute
Messages : 125
Enregistré le : jeu. 23 févr. 2017 15:53
Localisation : Rouen

Re: Réalisation d'un pont diviseur de tension

Message par Pinhapple » mer. 3 mai 2017 09:00

spourre a écrit :La résistance de 120 ohms sert à fermer la ligne de transmission sur son impédance nominale en vue de limiter les problèmes de réflexion en bout de ligne.
Dans la data sheet, elle est mentionnée mais non obligatoire avec ce circuit intégré . Elle permet donc d'obtenir un débit maximum et la mettre en place ne peut pas nuire. Si tu ne l'as pas sous la main, tu prends une valeur approchée à +- 10 %.
Faute de 120 Ω, j'ai tenté avec une 100 Ω, mais mon signal s'affaissait en sortie. J'en ai discuté avec quelques collègues qui m'ont dit de mettre une 470 Ω, qui ne devrait pas poser de problème sur une si petite distance (j'ai 2 mètres de câble). Quel est votre avis à ce propos ?
spourre a écrit :Les résistances de rappel ne sont pas indispensables non plus.
Comme pour tout circuit numérique, il est recommandé de mettre au plus près des broches d’alimentation une capacité de découplage (100 nF, polyester). Une capa électrochimique (ou tantale) de plus forte valeur (100 micro F ) est recommandée sur le bus d'alimentation, à l'entrée de la carte.
J'ai essayé de reproduire au mieux ce qui se passe dans le radar, sans trop prendre la liberté d'ajouter ou d'enlever des éléments. Je vais voir ce que ça donne avec ces modifications ! ;)
spourre a écrit :Les broches G et non G (ou G barre) contrôlent le comportement en sortie (front montant, descendant ou tri-state). Une seule est nécessaire mais il n'est pas recommandé de laisser une broche en l'air. Ceci est très clairement illustré dans la data sheet.
J'ai la G reliée au 5 V et la G barre reliée au GND, ça va ? Et par curiosité, si je ne dois pas laisser une broche en l'air, qu'en fais-je ?

Du coup dans mon montage actuel, j'ai trois résistances par signal : une pull-up (3,3 kΩ), une pull-down (3,3 kΩ), une résistance de terminaison (470 Ω), et c'est tout. Le signal traité obtenu est très net, il n'y a plus ou sinon très très peu de bruit (vu à l'oscilloscope), donc les affaires reprennent !
  • RPi 3 + LibreELEC / RPi 3 + RetroPie / RPi B+ + Sense HAT ou Framboisedorf ou module caméra
  • Arduino Mega, Uno, Nano
  • Freescale FRDM KL25Z

spourre
Raspinaute
Messages : 735
Enregistré le : lun. 22 déc. 2014 16:50
Localisation : 67380 LINGOLSHEIM

Re: Réalisation d'un pont diviseur de tension

Message par spourre » ven. 19 mai 2017 23:19

Pinhapple a écrit : ...
Du coup dans mon montage actuel, j'ai trois résistances par signal : une pull-up (3,3 kΩ), une pull-down (3,3 kΩ), une résistance de terminaison (470 Ω), et c'est tout. Le signal traité obtenu est très net, il n'y a plus ou sinon très très peu de bruit (vu à l'oscilloscope), donc les affaires reprennent !
Bonsoir,

Des nouvelles ? tu avances ?

Sylvain

Pinhapple
Raspinaute
Messages : 125
Enregistré le : jeu. 23 févr. 2017 15:53
Localisation : Rouen

Re: Réalisation d'un pont diviseur de tension

Message par Pinhapple » mar. 23 mai 2017 10:47

spourre a écrit :Des nouvelles ? tu avances ?
Bonjour !

J'ai regardé cette page chaque jour depuis mon dernier message, et ce n'est qu'aujourd'hui que Firefox se décide à actualiser la page... :roll: (Véridique ! Je crois qu'il n'actualise pas mes onglets automatiquement quand je les reprends d'une session à l'autre, je dois faire ça manuellement...)

Du coup oui, ça a bien avancé côté électronique ! Mon montage avec le DS26LS32CN fonctionne correctement, de même que le pont diviseur de tension qui fait le lien entre lui et le RPi. Ma crainte était que le pont diviseur n'écrase trop le signal et que la détection des fronts soit impactée, mais finalement ça va. :)

Côté RPi, celui-ci a un peu de mal à calculer les durées souhaitées : durées de chaque impulsion (du front montant au front descendant) et durée entre deux impulsions (de front montant à front montant). Les mesures se font, mais je doute de la précision des valeurs ; par exemple, en test local avec mon Arduino qui me génère le signal, j'obtiens entre 137 et 146 µs de largeur d'impulsion pour le signal des tops nords, là où je m'attends à avoir du 125 µs. Je dois maintenant faire des tests sur le radar afin d'établir si les écarts mesurés sont dus au RPi ou à de la gigue.

Le fait que Raspbian ne soit pas un OS temps réel me fait craindre que le problème vienne du RPi, mais après ce sera à voir avec mon maître de stage pour les écarts tolérés, même si j'aimerais obtenir une précision à la microseconde près.

Deux cas de figure : 1) le RPi mesure tout correctement, les écarts sont dus à de la gigue -> validation de l'outil et autre mission confiée, ou 2) le RPi n'arrive pas à suivre -> j'aurais prouvé que ce n'est pas possible avec ces outils, et autre mission confiée. Dans chaque cas, j'aurais appris pas mal de choses en électronique, et j'aurais surtout gagné en confiance au niveau des manipulations !

J'irai sur le radar cet après-midi pour faire un test en conditions réelles, je vous tiendrai au courant de ce que ça donne ! ;)
  • RPi 3 + LibreELEC / RPi 3 + RetroPie / RPi B+ + Sense HAT ou Framboisedorf ou module caméra
  • Arduino Mega, Uno, Nano
  • Freescale FRDM KL25Z

spourre
Raspinaute
Messages : 735
Enregistré le : lun. 22 déc. 2014 16:50
Localisation : 67380 LINGOLSHEIM

Re: Réalisation d'un pont diviseur de tension

Message par spourre » mar. 23 mai 2017 12:15

Pinhapple a écrit : Bonjour !
...
J'ai regardé cette page chaque jour depuis mon dernier message, et ce n'est qu'aujourd'hui que Firefox se décide à actualiser la page... :roll: (Véridique ! Je crois qu'il n'actualise pas mes onglets automatiquement quand je les reprends d'une session à l'autre, je dois faire ça manuellement...)
....
bonjour,
J'ai le même problème avec Seamonkey (issu de Mozilla). Il y a des périodes où je ne vois aucun message nouveau.
C'est au point que je passe systématiquement en revue mes messages pour voir s'il y a une réponse.
Pinhapple a écrit : ...
Du coup oui, ça a bien avancé côté électronique ! Mon montage avec le DS26LS32CN fonctionne correctement, de même que le pont diviseur de tension qui fait le lien entre lui et le RPi. Ma crainte était que le pont diviseur n'écrase trop le signal et que la détection des fronts soit impactée, mais finalement ça va. :)
Voila donc une très bonne nouvelle et de quoi alimenter ton mémoire. :ugeek:
Pinhapple a écrit : ...
Côté RPi, celui-ci a un peu de mal à calculer les durées souhaitées : durées de chaque impulsion (du front montant au front descendant) et durée entre deux impulsions (de front montant à front montant). Les mesures se font, mais je doute de la précision des valeurs ; par exemple, en test local avec mon Arduino qui me génère le signal, j'obtiens entre 137 et 146 µs de largeur d'impulsion pour le signal des tops nords, là où je m'attends à avoir du 125 µs. Je dois maintenant faire des tests sur le radar afin d'établir si les écarts mesurés sont dus au RPi ou à de la gigue.

Le fait que Raspbian ne soit pas un OS temps réel me fait craindre que le problème vienne du RPi, mais après ce sera à voir avec mon maître de stage pour les écarts tolérés, même si j'aimerais obtenir une précision à la microseconde près.

Deux cas de figure : 1) le RPi mesure tout correctement, les écarts sont dus à de la gigue -> validation de l'outil et autre mission confiée, ou 2) le RPi n'arrive pas à suivre -> j'aurais prouvé que ce n'est pas possible avec ces outils, et autre mission confiée. Dans chaque cas, j'aurais appris pas mal de choses en électronique, et j'aurais surtout gagné en confiance au niveau des manipulations !

J'irai sur le radar cet après-midi pour faire un test en conditions réelles, je vous tiendrai au courant de ce que ça donne ! ;)
Bon ça, on s'en doutait (Bud et moi) dès le début d'où notre conseil de passer au compilé.
Je ne sais pas quelle définition tu as du temps réel ( http://connect.ed-diamond.com/GNU-Linux ... temps-reel ) mais effectivement Linux n'a jamais été conçu pour l'être. En général, on utilise une machine surdimensionnée en espérant que cela permettra de répondre à l'attente et souvent, cela fonctionne.
Le problème du Raspberry est qu'il est trop rachitique pour cette approche. La wiringPi s'appuie elle-même sur la bcm. et tout cela se déroule en "user land" et est donc soumis aux aléa de la charge du CPU et des décisions du scheduler.
Selon les exigences et les contraintes temporelles,, il y a plusieurs approches possibles:
-) Développer un module pour le kernel (je ne sais pas faire). Suite à ma remarque sur un autre fil, un posteur a lancé une demande d'aide mais n'a pas encore reçu de réponse.
-) Passer aux extensions RT
-) Se passer de Linux et développer directement une appli qui tourne sur le matériel (Baree metal)

L''approche "bare metal" est certainement la voie royale pour faire du vrai temps réel et exploiter au mieux les ressources du SOC. Il y a pleins d'applications qui ne nécessitent ni OS lourd, ni serveur X et interface graphique.
Dans le dernier LMF, page 48, il y a une introduction à la programmation "bare-metal". Les exemples fonctionnent (j'ai testé) et le programme de raytracing est livré avec un support du framebuffer qui exploite la sortie hdmi du raspberry. Cela devrait suffire pour des automates.
C'est un environnement de cross-compilation qui peut tourner dans un docker. Il y a un shell pour préparer la carte SD pour être bootable et démarrer soit sur un programme, soit sur un serveur gdb.
Il n'y a qu'une seule limitation, le debug bare-metal livré (à base de gdb), ne permet pas le debugg en multi-threads (étonnant quand on connaît la position de Denis sur ce point).

Si ton CDI est abonné, ça vaut le coup de lire cet article, voire d'acheter le magazine.

En fonction de la décision de ton maître de stage, ceci pourrait constituer la conclusion de ton travail et fournir des pistes aux prochains stagiaires.

Nota: Nous n'avons évoqué que les pistes logicielles mais tu devrais aussi regarder du côté de la stabilité de l'oscillateur du Raspberry.

Sylvain

Pinhapple
Raspinaute
Messages : 125
Enregistré le : jeu. 23 févr. 2017 15:53
Localisation : Rouen

Re: Réalisation d'un pont diviseur de tension

Message par Pinhapple » mer. 24 mai 2017 11:26

spourre a écrit :Bon ça, on s'en doutait (Bud et moi) dès le début d'où notre conseil de passer au compilé.
Mon soft est en C et utilise WiringPi, c'est autre chose que le Python en matière de rapidité ! ;)
spourre a écrit :Je ne sais pas quelle définition tu as du temps réel ( http://connect.ed-diamond.com/GNU-Linux ... temps-reel ) mais effectivement Linux n'a jamais été conçu pour l'être. En général, on utilise une machine surdimensionnée en espérant que cela permettra de répondre à l'attente et souvent, cela fonctionne.
Article très touffu et intéressant, je n'ai pas fini de le lire mais il m'a l'air d'être très complet !
Il faudra que je fasse un détour par mon école pour voir si le CDI est abonné au Linux Mag, mais j'en doute un peu... :?

Après en avoir discuté avec mon maître de stage, je laisse tomber cet outil pour l'instant, et me concentre sur mon rapport afin d'expliquer pourquoi ce n'est pas possible à l'heure actuelle avec le matériel à ma disposition, ce qui devrait étoffer mon mémoire et justifier pourquoi je n'ai pas pu créer cet outil.

Afin de ne pas en rester là, j'avais aussi envisagé d'utiliser à la place du RPi une Arduino Due (processeur ARM et horloge 84 MHz) pour faire le traitement et l'affichage, ou bien rester sur une Uno et enregistrer les données mesurées sur une carte SD via un shield. Dans chacun des cas, il faut que je sois sûr que les cartes pourront faire ce que je souhaite dans le temps imparti, mais ça c'est une autre histoire qui aurait plus sa place sur un forum Arduino ! :D
  • RPi 3 + LibreELEC / RPi 3 + RetroPie / RPi B+ + Sense HAT ou Framboisedorf ou module caméra
  • Arduino Mega, Uno, Nano
  • Freescale FRDM KL25Z

spourre
Raspinaute
Messages : 735
Enregistré le : lun. 22 déc. 2014 16:50
Localisation : 67380 LINGOLSHEIM

Re: Réalisation d'un pont diviseur de tension

Message par spourre » ven. 26 mai 2017 11:06

Pinhapple a écrit :
Après en avoir discuté avec mon maître de stage, je laisse tomber cet outil pour l'instant, et me concentre sur mon rapport afin d'expliquer pourquoi ce n'est pas possible à l'heure actuelle avec le matériel à ma disposition, ce qui devrait étoffer mon mémoire et justifier pourquoi je n'ai pas pu créer cet outil.
Quand dois-tu rendre ton mémoire ? Dois-tu le "soutenir" devant un jury ?
En tout cas, je pense que tu as de la matière, y compris dans ces nombreuses pages et les autres fils connexes.
De mémoire, le site est en «Creative Commons», il faudra juste, par courtoisie, le citer dans la bibliographie.
"Y A PLU KA" structurer et rédiger :ugeek:

En tout cas, je ne sais pas si c'était l'objectif pédagogique, mais tu auras pu constater que définir la solution matérielle et logicielle avant d'avoir étudié et défini le problème, relève de la logique des Schadocks (1) et peut conduire à un gaspillage des ressources humaines, matérielles et financières. :twisted:

Ça serait sympa de nous faire un retour .

Sylvain
(1) En logique Shadock, s'il n'y a pas de solution, c'est qu'il n'y a pas de problème :D .

Pinhapple
Raspinaute
Messages : 125
Enregistré le : jeu. 23 févr. 2017 15:53
Localisation : Rouen

Re: Réalisation d'un pont diviseur de tension

Message par Pinhapple » lun. 29 mai 2017 09:41

spourre a écrit :Quand dois-tu rendre ton mémoire ? Dois-tu le "soutenir" devant un jury ?
Rendu du document le 28 juillet, soutenance le 5 septembre !
spourre a écrit :En tout cas, je pense que tu as de la matière, y compris dans ces nombreuses pages et les autres fils connexes.
De mémoire, le site est en «Creative Commons», il faudra juste, par courtoisie, le citer dans la bibliographie.
"Y A PLU KA" structurer et rédiger :ugeek:
Oui, c'est déjà en cours ! J'avance au fil du stage, ça m'évite d'avoir tout à faire la veille... ;)
spourre a écrit :En tout cas, je ne sais pas si c'était l'objectif pédagogique, mais tu auras pu constater que définir la solution matérielle et logicielle avant d'avoir étudié et défini le problème, relève de la logique des Schadocks (1) et peut conduire à un gaspillage des ressources humaines, matérielles et financières. :twisted:
C'est en essayant de le faire que je me suis rendu compte qu'il n'y avait pas moyen de faire, en tout cas pas avec le matériel à ma disposition. J'aurais préféré aboutir à la même conclusion avec une analyse détaillée et pertinente, ce qui m'aurait fait gagner du temps, comme ça aurait pu être le cas avec mon autre problème (souvenons-nous de mon souhait d'obtenir 4 000 lectures par seconde avec un Sense HAT en utilisant du Python !), mais au moins là j'en ai la preuve concrète : c'est plus facile de montrer que "ça marche pas" plutôt que de le dire, même en justifiant. :D
spourre a écrit :Ça serait sympa de nous faire un retour .
C'est prévu ! Ne serait-ce que pour clore le sujet, et par politesse ! :)
  • RPi 3 + LibreELEC / RPi 3 + RetroPie / RPi B+ + Sense HAT ou Framboisedorf ou module caméra
  • Arduino Mega, Uno, Nano
  • Freescale FRDM KL25Z

Répondre

Retourner vers « L'électronique et le Raspberry Pi »