Bonsoir,
J'ai visiblement un probleme d'interférence sur mon projet. J'ai les cables par paires et j'avais fait circuler l'horloge sur la meme paire avec le fil de Data et sa planter souvent !
Maintenant sur un cable j'ai data + Vcc et sur l'autre j'ai Horloge + GND sa marche beaucoup mieux malgres tout sa a replanter une fois et je suis sur que le probleme viens de là.
Y a t'il un moyen de limiter ces interférences ?
Des résistances de pull-up ? Baisser la vitesse du BUS ?
Sinon je vais devoir revoir la conception
Merci
Limiter les interférences
Modérateur : Francois
-
- Raspinaute
- Messages : 629
- Enregistré le : mar. 6 janv. 2015 19:44
- Localisation : finistere
Re: Limiter les interférences
Bonjour,
Il nous faudrait quelques infos suplementaires, nature du bus, des fils,longueur,protocoles.......
tous ce qui pourrai intervenir dqns les perturbations.
@+
Il nous faudrait quelques infos suplementaires, nature du bus, des fils,longueur,protocoles.......
tous ce qui pourrai intervenir dqns les perturbations.
@+
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: Limiter les interférences
Hello guillaume !
Effectivement jai oublier de parler du bus qui est l'i2c
Le probleme est que le projet imite une bombe tnt avec le meme visuel que celui des films.
Visiblement l'i2c n'apprécie pas vraiment les fils torsadé, cela doit créer des interférences je pense.
Si je remplace le fil de donnés et dhorloge par un dupont droit le probleme n'est plus present.
Par contre je nest besoin de remplacer que lee cables avant les convertisseur logique donc ceux en 3,3v, les cables apres le convertisseur donc en 5v ne me cause pas de soucis.
Effectivement jai oublier de parler du bus qui est l'i2c
Le probleme est que le projet imite une bombe tnt avec le meme visuel que celui des films.
Visiblement l'i2c n'apprécie pas vraiment les fils torsadé, cela doit créer des interférences je pense.
Si je remplace le fil de donnés et dhorloge par un dupont droit le probleme n'est plus present.
Par contre je nest besoin de remplacer que lee cables avant les convertisseur logique donc ceux en 3,3v, les cables apres le convertisseur donc en 5v ne me cause pas de soucis.
Re: Limiter les interférences
en fait le gros soucis c'est que l'I2C n'est pas prévue pour avoir un grande longueur de bus, je crois qu'a partir de 10cm c'est possible d'avoir des soucis sur ce bus
NAS : DIY OS Debian: DD250Go + 3x2To + 6To
Raspberry pi : 2B OS : Raspbian
Se tromper est humain, Vraiment foutre la merde nécessite le mot de passe de root.
Raspberry pi : 2B OS : Raspbian
Se tromper est humain, Vraiment foutre la merde nécessite le mot de passe de root.
-
- Raspinaute
- Messages : 629
- Enregistré le : mar. 6 janv. 2015 19:44
- Localisation : finistere
Re: Limiter les interférences
+1 manfred
l ' I2C sert pour connecter essentiellement des circuits d’extensions qui sont généralement situé sur la même carte ou à proximité proches et avec un câblage étudié.
En règles général il est peu recommandé de faire transiter des signaux "brut" par des lignes filaires torsadées , les torsades s' apparentent alors à des selfs couplées créant ainsi des interférences .
Pour des distances plus importantes, et en gardant une architecture bus , il existe le bus CAN ou si il uy a peu de périphériques il y a aussi le rs232 rs485 ......
@+
l ' I2C sert pour connecter essentiellement des circuits d’extensions qui sont généralement situé sur la même carte ou à proximité proches et avec un câblage étudié.
En règles général il est peu recommandé de faire transiter des signaux "brut" par des lignes filaires torsadées , les torsades s' apparentent alors à des selfs couplées créant ainsi des interférences .
Pour des distances plus importantes, et en gardant une architecture bus , il existe le bus CAN ou si il uy a peu de périphériques il y a aussi le rs232 rs485 ......
@+
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: Limiter les interférences
Bonjour,
Je ne suis pas un spécialiste en liaison de communication de données. Je suis allé donc faire un tour sur Wikipedia pour lire la définition de la liaison i2c. Pour moi, ce n'est pas une liaison différentielle. Il y a 2 fils qui transmettent l'horloge et les données mais cela oblige à avoir pour les émetteurs et récepteurs la même référence de masse. Donc, il faut d'une manière ou d'une autre gérer cet équipotentiel. Nous sommes donc ici en communication de mode commun car la clock et les données dépendent de la masse.
Quand on utilise une paire de fils torsadés, c'est pour s'affranchir de perturbations CEM de mode commun car nous avons une liaison de mode différentielle. Donc il est tout à fait normal que des perturbations apparaissent car, d'après ce que j'ai compris, il n'y a que les fils d'horloge et de données qui vont de l'émetteur vers le récepteur :
- La référence de mode commun n'est pas transmise : en gros, il faut aussi transmettre un équipotentiel de masse ; et plus celui-ci va être long, plus il sera perturbé ... Le mieux est d'avoir un câble de type coaxial avec 2 points chauds (la clock & les données) et la masse sur la tresse du câble ... Cela peut commencer à coûter sans compter les pb de pertes, de couplage selfique (entre la clock et les données) et d'adaptation d’impédances (pour éviter les overshoot et undershoot) si le câble commence à être long.
Je pense qu'il serait plus raisonnable de s'orienter vers une liaison filaire de type différentielle. Après, en fonction de la vitesse de transmission et de la longueur, le choix peut s'affiner vers un bus CAN (bus utilisé dans l'automobile voire en avionique qui a l'avantage d'être simple, léger et peu cher car les constructeurs automobiles aiment ça) ou RS422 qui a la réputation de pouvoir supporter des liaisons filaires très longues et ne doit pas coûter très cher car très répandu ...
Je ne suis pas un spécialiste en liaison de communication de données. Je suis allé donc faire un tour sur Wikipedia pour lire la définition de la liaison i2c. Pour moi, ce n'est pas une liaison différentielle. Il y a 2 fils qui transmettent l'horloge et les données mais cela oblige à avoir pour les émetteurs et récepteurs la même référence de masse. Donc, il faut d'une manière ou d'une autre gérer cet équipotentiel. Nous sommes donc ici en communication de mode commun car la clock et les données dépendent de la masse.
Quand on utilise une paire de fils torsadés, c'est pour s'affranchir de perturbations CEM de mode commun car nous avons une liaison de mode différentielle. Donc il est tout à fait normal que des perturbations apparaissent car, d'après ce que j'ai compris, il n'y a que les fils d'horloge et de données qui vont de l'émetteur vers le récepteur :
- La référence de mode commun n'est pas transmise : en gros, il faut aussi transmettre un équipotentiel de masse ; et plus celui-ci va être long, plus il sera perturbé ... Le mieux est d'avoir un câble de type coaxial avec 2 points chauds (la clock & les données) et la masse sur la tresse du câble ... Cela peut commencer à coûter sans compter les pb de pertes, de couplage selfique (entre la clock et les données) et d'adaptation d’impédances (pour éviter les overshoot et undershoot) si le câble commence à être long.
Je pense qu'il serait plus raisonnable de s'orienter vers une liaison filaire de type différentielle. Après, en fonction de la vitesse de transmission et de la longueur, le choix peut s'affiner vers un bus CAN (bus utilisé dans l'automobile voire en avionique qui a l'avantage d'être simple, léger et peu cher car les constructeurs automobiles aiment ça) ou RS422 qui a la réputation de pouvoir supporter des liaisons filaires très longues et ne doit pas coûter très cher car très répandu ...