Meilleure façon de faire I2C / TWI sur longue distance


9

J'ai un projet qui nécessite de faire I²C / I2C / TWI sur une longue distance (30 à 40 mètres).

J'ai vu certaines personnes suggérer de réduire la fréquence d'horloge à environ 500 Hz, pour atténuer les effets de la capacité d'une si longue ligne, je suppose? Les composants que j'utilise nécessitent au moins la fréquence d'horloge standard de 100 kHz. J'ai fait d'autres recherches et trouvé parmi les réponses à une autre question une suggestion d'utiliser un levier de vitesses P82B96. Dans la fiche technique, ils donnent des exemples de leur utilisation sur des lignes de 100 mètres, même:

I2C_longDistance

j'ai rencontré une autre façon de déplacer les niveaux à travers une carte de dérivation d'adafruit , qui n'est qu'un mosfet (bss138) avec deux résistances de traction (une pour chaque côté / tension). Ils ont eu l'idée deune note d'application de NXP (AN10441) , et deux des canaux dessus pourraient être utilisés comme ceci:

décalage du niveau mosfet

Maintenant, je me demande: quelle solution est la meilleure? Ou y a-t-il quelque chose que j'ai oublié? Et aussi, le 5V est-il suffisant pour assurer une bonne connexion? Y aurait-il un avantage à utiliser une tension encore plus élevée comme 12V?


Tel qu'il est écrit, votre question est probablement trop large pour le format de ce site. Essayez d'affiner votre question et de la rendre très précise.
Joe Hass

J'ai ajouté un résumé, est-il suffisamment étroit et précis?
DaJF

Vous devez également spécifier la longueur de câble maximale pour les capteurs et donner une idée de ce que signifie "faible coût" pour vous. Vous attendez-vous à alimenter les capteurs via le même câble?
Joe Hass

@JoeHass La question est-elle maintenant assez étroite? Sinon, que dois-je faire de plus?
DaJF

Salut, je sais que c'est une vieille question mais qu'est-ce que tu as fini par faire? J'ai exactement la même question que vous, des distances similaires impliquées et une fréquence d'horloge minimale de 100 kHz. Je serais intéressé de savoir ce qui a fonctionné pour vous, merci.
pcdev

Réponses:


1

Je pense que vous êtes sur la bonne voie avec quelque chose comme le NXP P82B96. Si vous regardez la figure 14 et le texte associé, la fiche technique traite de l'utilisation d'une longueur de câble jusqu'à 250 m avec des débits de données supérieurs à 100 kHz.

Il existe de nombreux capteurs de température I2C qui peuvent vous donner une précision de quelques degrés Celsius sans étalonnage et sans circuits analogiques supplémentaires. Comme vous ramenez quand même les données pour traitement, il serait très facile de filtrer le bruit.

Si vous êtes préoccupé par la capacité de câblage, vous pourriez être mieux avec une paire torsadée non blindée plutôt qu'avec un câble blindé.


Le P82B96 pourrait-il être remplacé par l'alternative mosfet? Pour le prix d'un P82B96, je peux littéralement acheter 100 mosfets bss138 (je peux vous donner les liens si vous le souhaitez). En effet, comme vous l'avez dit, j'ai trouvé ce qui ressemble à un capteur de température adapté: le LM75A. En ce qui concerne le choix entre un câble blindé ou non blindé, il semble que ce soit la question du problème que vous souhaitez: interférence possible (non blindée) ou capacité de ligne (blindée), est-ce une hypothèse correcte? L'un est-il plus important que l'autre? Je n'ai aucune idée de comment déterminer cela. Merci btw!
DaJF

Je ne pense pas que vous puissiez remplacer le P82B96 par les MOSFET pour les longues lignes. Il semble que le circuit intégré du répéteur fournisse en fait une certaine amplification, où les MOSFET fournissent principalement un décalage de niveau de tension. J'ai peur de ne pas savoir comment passer l'appel sur le câble ... vous devriez regarder la note d'application NXP AN255. Ils parlent d'utiliser un câblage à paire torsadée mais ne mentionnent pas de bouclier. Pour les signaux numériques, le bruit peut être moins problématique que la capacité.
Joe Hass

2

Vous pouvez probablement vous en sortir avec les capteurs DS18B20 en utilisant un câble blindé CAT5 ou similaire. Ce ne sont que des mesures thermiques, donc si certaines lectures sont corrompues, vous pouvez rendre votre programme suffisamment robuste pour y faire face (c'est une bonne pratique de toute façon).

Pour une utilisation en chaîne, j'ai conçu ce que l'on appelle des contrôles RTU (rooftop unit) qui fonctionnent sur plusieurs capteurs passifs (ils utilisent des thermistances NTC interchangeables , qui ne nécessitent aucun étalonnage pour le chauffage de confort). Il est beaucoup plus facile de filtrer le bruit d'un capteur passif. Un autre ensemble d'installations (un complexe automobile majeur en Amérique du Nord) a utilisé des RTD en platine avec des conditionneurs de signaux - des dispositifs très précis et stables. Vous devez d'abord décider du capteur, puis regarder comment il pourrait être interfacé - l'une de ces options de capteur convient à votre application (bien que les RTD puissent être excessifs).

Dans le cas où ce n'est pas clair, je propose une configuration "en étoile" de capteurs autour de votre processeur.

Si vous voulez vraiment utiliser un "bus" (autre que monofil ou I2C), vous aurez besoin d'intelligence aux extrémités, ce qui signifie un processeur sous une forme ou une autre. Si vous optez pour le porc entier, vous voudrez peut-être envisager d'utiliser des capteurs sans fil qui communiquent via une bande ISM légale dans votre localité. Alternativement, vous pouvez utiliser un capteur par Pi et les faire parler via votre intranet WiFi.


En ce moment, je suis le stade "déterminer quoi acheter", donc le bus ou le capteur peuvent déterminer l'autre. Les seules exigences dont j'ai besoin sont faciles à utiliser et extensibles. La raison du choix d'un bus est que je préfère ne pas faire passer un câble à chaque capteur (c'est ce que vous semblez suggérer, ou ai-je mal interprété "l'étoile"?). I²C est-il un protocole viable à utiliser sur un câble pouvant atteindre 30M / 90FT?
DaJF

Oui, c'est ce qu'une "étoile" est - des fils du contrôleur à chaque capteur. I2C à 30m .. eh bien .. J'ai entendu dire que c'est possible à très basse vitesse, mais je ne compterais pas sur le bon fonctionnement.
Spehro Pefhany
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.