Limiter les interférences

Des infos, des conseils sur les bus DSI,CSI, I2C, SPI... du Raspberry Pi

Modérateur : Francois

Répondre
EVOTk

Limiter les interférences

Message par EVOTk » dim. 15 mars 2015 23:06

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 ! :roll:

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 :cry:

Merci

guillaume9344
Raspinaute
Messages : 629
Enregistré le : mar. 6 janv. 2015 19:44
Localisation : finistere

Re: Limiter les interférences

Message par guillaume9344 » lun. 16 mars 2015 07:29

Bonjour,
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

EVOTk

Re: Limiter les interférences

Message par EVOTk » lun. 16 mars 2015 07:44

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.
uploadfromtaptalk1426488121614.jpg
uploadfromtaptalk1426488121614.jpg (1.66 Mio) Vu 7838 fois

Avatar du membre
Manfraid
Modérateur
Messages : 1402
Enregistré le : ven. 3 oct. 2014 14:50
Contact :

Re: Limiter les interférences

Message par Manfraid » lun. 16 mars 2015 08:35

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.

guillaume9344
Raspinaute
Messages : 629
Enregistré le : mar. 6 janv. 2015 19:44
Localisation : finistere

Re: Limiter les interférences

Message par guillaume9344 » lun. 16 mars 2015 20:00

+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 ......
@+
rpi b+ ,osmc, motioneyes
rpi 2 raspbian , server minecraft 24h/24 , utilisation gpio
orange pi pc debian ,utilisation gpio, motion cam

lhebui
Messages : 65
Enregistré le : mer. 2 mars 2016 10:42
Localisation : Eure & Loir

Re: Limiter les interférences

Message par lhebui » mer. 2 mars 2016 11:55

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 ...

Répondre

Retourner vers « Les BUS interfaces »