Envoi fiable d'I2C via des câbles Cat5

J'envisage d'implémenter un système domotique autour de mon Raspberry Pi, mais j'ai trouvé que le prix et l'espace requis pour insérer un Pi à chaque endroit un certain contrôle est trop nécessaire, mais les câbles Cat5e requis pour cette conception sont déjà installés pendant la rénovation. J'ai des PCF8574, PCF8591 et SSR qui traînent, est-il possible de les piloter avec des câbles Cat5e?

Tous mes câbles Cat5e sont déjà câblés avec un brochage TIA / EIA 568B. Ils font partie de mon câblage structurel et ne sont pas blindés, donc une tension de ligne plus élevée est requise. Je pense à envoyer des lignes d'alimentation et I2C sur le câble, avec ce brochage:

Pin 1 (Pair 1): SCL+
Pin 2 (Pair 1): SCL-
Pin 3 (Pair 2): SDA+
Pin 4 (Pair 3): +12V
Pin 5 (Pair 3): +12V
Pin 6 (Pair 2): SDA-
Pin 7 (Pair 4): GND
Pin 8 (Pair 4): GND

La disposition des broches d'alimentation est identique à celle du câblage PoE 100BASE-TX, de sorte que la puissance nominale sera également la même, et l'utilisation de la signalisation différentielle bidirectionnelle se trouve dans 1000BASE-T qui nécessite Cat5e.

Les lignes I2C SCL et SDA d'origine sont dérivées en deux paires différentielles bidirectionnelles aux niveaux TTL (le drain ouvert n'est pas conservé sur le fil, mais restauré dans le dispositif de terminaison / décalage de niveau que je conçois)

Une suggestion à ce sujet? De plus, quelle puce dois-je utiliser pour convertir les lignes I2C en signalisation différentielle? Veuillez me suggérer des jetons avec option de trou traversant DIP. Je ne sais pas comment gérer les trucs SMT.

ÉDITER

J'ai trouvé cette puce, SN65LBC180, est-ce un bon choix? Comment le câbler dans une unité bidirectionnelle? Comment changer de niveau (il s'agit d'une pièce BiCMOS nécessitant un niveau TTL mais Pi pilote à des niveaux CMOS de 3,3 V) et la rendre compatible avec le drain ouvert?

EDIT 2

Les commentateurs ont suggéré RS-485 qui m'a paru acceptable, mais les deux paires différentielles doivent toujours être bidirectionnelles et seulement deux paires différentielles bidirectionnelles seulement. Je réutilise les câbles Ethernet existants.

EDIT 3

Depuis que quelqu'un l'a soulevé, je ne peux pas utiliser CAN. Il n'y a aucun moyen d'adapter CAN sur RPi sans rien sacrifier (SPI est occupé par un écran tactile, donc pas de convertisseur SPI vers CAN)

Je suis conscient de la limitation de I2C PHY, donc j'essaie essentiellement de lui adapter 1000BASE-T PHY - signalisation différentielle bidirectionnelle pour les signaux SCL et SDA, mais en plus de cela, exécute le protocole I2C.

EDIT 4

Une nouvelle puce m'est venue: NXP P82B96 qui divise I2C en 4 lignes unidirectionnelles, qui à leur tour peuvent être utilisées pour alimenter le SN65LBC180 par opto-isolation (côté Pi uniquement) pour former une signalisation prête à longue distance à 8 broches. Maintenant, j'ai juste besoin de comprendre comment obtenir du courant à travers le fil, ou comment déterminer si le bus envoie et rendre les paires bidirectionnelles.

EDIT 5

D'après les suggestions de réponses, je pense que je dois changer un peu le brochage de l'alimentation:

Pin 1 (Pair 1): SCL+
Pin 2 (Pair 1): SCL-
Pin 3 (Pair 2): SDA+
Pin 4 (Pair 3): +5V
Pin 5 (Pair 3): GND
Pin 6 (Pair 2): SDA-
Pin 7 (Pair 4): GND
Pin 8 (Pair 4): +12V

La tension de signalisation différentielle I2C est TTL. Le + 5V sur la paire 3 provient du Pi, non tamponné mais fusionné. Le + 12V sur la paire 4 peut ne pas être présent est uniquement utilisé pour piloter certains appareils à haute puissance. Si nécessaire, l'appareil peut utiliser sa propre alimentation et laisser les deux rails suspendus non connectés ou fournir sa propre tension plus élevée, mais utiliser le rail 5V.

GRATTEZ QUE

Le brochage est toujours mon design d'origine, qui est compatible 802.1af.

Essayer de faire avec IIC est une mauvaise idée. IIC est vraiment destiné à la communication entre puces sur une seule carte. Étant donné que le courant maximum requis pour tirer une ligne basse est limité, les lignes ont une impédance relativement élevée (quelques kΩ). Cela signifie qu'ils peuvent capter facilement le bruit, ce qui est un problème grave lors de l'utilisation de câbles non blindés dans les murs, peut-être juste à côté des fils d'alimentation CA.

J'utiliserais CAN pour cela. CAN utilise une seule paire torsadée réunie avec seulement 60 Ω en un seul point, et le signal est différentiel. Cela signifie que la plupart du bruit inévitable en mode commun qui sera capté en raison du couplage capacitif peut être annulé par les récepteurs. Le CAN fonctionnant à 500 kbits / s peut couvrir quelque chose de la taille d'une maison ordinaire.

De nombreux microcontrôleurs sont disponibles aujourd'hui avec CAN intégré. Vous avez généralement besoin d'une puce de transceiver physique distincte (comme le MCP2551 commun), mais les couches les plus basses du protocole sont implémentées en silicium dans le périphérique CAN. Le firmware interagit avec le bus CAN au niveau de l'envoi et de la réception de paquets complets. La détection et la nouvelle tentative de collision, la génération de la somme de contrôle, les détails de la signalisation des paquets de bus, la validation de la somme de contrôle reçue et l'ajustement de la dérive d'horloge sont tous gérés pour vous.

Ne tombez pas pour RS-485. C'est une relique d'une époque révolue. Il utilise également un seul signal différentiel comme le CAN, donc a également une bonne immunité au bruit. Cependant, les gens préfèrent généralement le RS-485 car il semble "plus simple". C'est seulement parce qu'ils ne regardent pas l'ensemble du système. Tout d'abord, ce n'est pas vraiment moins complexe électriquement. Vous aurez toujours besoin d'une sorte d'émetteur-récepteur pour piloter et recevoir le signal différentiel. Que vous ayez un émetteur-récepteur RS-485 connecté à l'UART du microcontrôleur ou un MCP2551 connecté au périphérique CAN est à peu près sans importance en termes de coût et de complexité matérielle. La grande différence est que RS-485 vous laisse au niveau des octets bruts (via l'UART). Cela signifie que pour mettre en œuvre tout système significatif et robuste, vous devez inventer votre propre protocole pour gérer la détection de collision, Décidez comment gérer les tentatives, la mise en paquets, la génération et la vérification des sommes de contrôle, le contrôle de flux, etc. Avec CAN, il vous suffit d'envoyer et de recevoir des paquets, et le matériel s'occupe des détails.

I2C n'est pas la voie à suivre. CAN trancievers coûte un dollar chacun, et vous pouvez les utiliser comme uart trancieves et écrire votre propre protocole afin que vous n'ayez pas besoin d'un micro compatible can de vous ne voulez pas utiliser la pile de canettes complète.

Je me sens toujours un peu mal à l'aise quand je vois des conducteurs cat5 fonctionner en parallèle pour plus de courant. Cela me dérange parce que si un conducteur casse, l'autre transportera le courant complet du système. Les notes actuelles de cat5 sont très conservatrices, donc les chances d'un incendie sont assez faibles, mais je n'aime tout simplement pas la possibilité.

La manière la plus sûre de le faire est d'avoir un polyfusible sur les deux rails d'alimentation et de relier les masses à l'alimentation, et de connecter chaque appareil à un et un seul ensemble d'alimentation / masse. De cette façon, si un fil tombe en panne, les appareils utilisant cette ligne perdent de l'énergie au lieu qu'une ligne soit forcée de transporter la puissance de deux.

Beaucoup de gens aiment mettre l'alimentation et la terre dans les deux paires torsadées pour des raisons EMI au lieu d'avoir une paire d'alimentation et une paire de terre. Si vous avez deux paires alimentation / terre, la ligne électrique sera plus proche de la terre et les champs s'annuleront, réduisant ainsi les ondes radio transmises ou reçues des lignes électriques. Inutile, mais agréable s'il y a beaucoup de bruit électrique qui bourdonne.

À mon avis, le 12V est trop faible pour la distribution d'énergie alors que le 24v est encore raisonnablement sûr et beaucoup plus efficace.

Si l'automatisation allume et éteint simplement les choses dans la maison, je simplifierais cela en:

• Garder tous les "cerveaux" en un seul endroit. Utilisez des extenseurs d'E / S I2C si nécessaire, mais conservez-les tous avec le raspberry pi. Vous aurez également besoin d'un matériel approprié pour vous assurer que vous n'essayez pas d'obtenir trop de courant à partir des broches GPIO du pi.
• Utilisez les câbles Ethernet pour piloter simplement les relais. Vous pouvez construire votre propre carte ou obtenir des relais statiques 120 / 240V montables sur panneau qui se monteront dans une boîte électrique. Les fils des câbles Ethernet Cat5 peuvent gérer jusqu'à 50 V à 320 mA chacun, ce qui est plus que suffisant pour piloter un relais. En fait, vous pouvez piloter 7 relais à partir d'un seul câble (plus un fil de terre). Ou laissez un fil pour une sortie 12V de commutation, afin que vous puissiez également installer un interrupteur manuel. S'ils sont vraiment longs, vous devrez peut-être tenir compte de la chute de tension, mais vous pouvez obtenir des relais qui commutent à 3-32V. 12V devrait être plus que suffisant, même en cas de chute de tension.
• Vous voudrez également consulter les codes du bâtiment locaux pour obtenir des conseils sur le mélange des câbles haute et basse tension dans le même boîtier.
• Des commutateurs simples peuvent également être effectués via les câbles Ethernet, encore une fois jusqu'à 7 par câble, et simplement câblés aux entrées du pi. La chute de tension peut être un problème pour les très longs câbles.
• Vous pouvez également utiliser des optoisolateurs pour protéger le pi contre les dommages.
• Pour les quelques appareils qui ont besoin de plus d'un relais (comme un panneau de commande), utilisez les câbles Ethernet comme Ethernet réel. Cela ne devrait pas être une dépense énorme s'il n'y a pas beaucoup de ces appareils. Ils peuvent être soit un autre pi, soit un microcontrôleur avec Ethernet.

^{simuler ce circuit - Schéma créé à l'aide de CircuitLab}

EUREKA! Deviner! (non testé, le testera ce week-end)

Les puces d'interface sont des tampons / séparateurs N2P P82B96 I2C et 2 puces d'interface de bus CAN SN65HVD251P TI. Essentiellement, j'utilise I2C sur CAN PHY.

P82B96 comprend le protocole I2C et gère l'arbitrage de bus pour moi, et me donne des broches Tx et Rx séparées qui peuvent être liées ensemble. Je les alimente dans l'émetteur-récepteur CAN SN65HVD251P et cela me donne la paire différentielle bidirectionnelle pour envoyer par câble.

Les broches d'alimentation viennent directement, sans tampon du rail 5V de mon Pi. (Je n'utiliserai pas la tension et l'alimentation de signalisation 12V pendant un certain temps)

Indépendamment des mérites d'IIC au niveau de la puce, la mise en œuvre que vous proposez sera très difficile. Le problème est l'arbitrage des bus. Bien que plusieurs unités puissent être mises en parallèle en utilisant, par exemple, RS485, la grande question sera:

Comment une unité sait-elle si elle peut prendre le contrôle du bus pour envoyer des données?

Dans IIC, avec des lignes de signal de drain ouvertes, le transfert bidirectionnel est facile - mais avec les bus à trois états, vous avez besoin d'un moyen pour vous assurer qu'une seule unité tente de conduire le bus à la fois. Ce sera difficile. Vous pouvez le faire, en particulier si vous établissez un seul maître et exigez que tous les esclaves aient des contraintes de temps rigides sur l'envoi de données, et qu'ils n'envoient des données que si le maître le demande, mais cela nécessitera un effort considérable de votre part dans la conception du cartes d'interface pour le maître et les esclaves.

En ce qui concerne les pilotes / récepteurs physiques, RS485 fera l'affaire, et il y a beaucoup de puces d'interface disponibles. Juste Google.

Je ne sais pas si vous êtes intéressé par une solution premade par opposition à la construction de votre propre circuit, mais j'ai pensé que je ferais remarquer que Pololu vend ces cartes d' extension différentielle longue distance I²C fabriquées par SJTbits, qui semblent faire à peu près exactement Qu'est-ce que vous cherchez. (Divulgation complète: je travaille pour Pololu.)

Même si vous ne voulez pas l'utiliser directement, peut-être que regarder le circuit qu'il utilise pourrait vous donner quelques idées. Vous pouvez voir le schéma dans la fiche technique; il utilise un tampon NXP PCA9600D, un pilote de ligne différentielle TI AM26LS31CDR et un récepteur de ligne différentielle TI AM26LS32ACDR.

Je sais que c'est un peu ancien et une solution semble avoir été trouvée quelque part parmi les réponses, mais j'avais cette suggestion à proposer. Il y a des appareils comme le PCA9614 / 5/6 de NXP que je considère en ce moment comme une solution pour un bus I2C longue distance plus robuste (PCA9614 2 canaux multipoint Fast-mode Plus tampon différentiel I2C-bus) . Essentiellement, il est vrai que cela devient autre chose que le vrai I2C, mais aux extrémités du bus, il est invisible pour les appareils. Cette famille particulière traduit les signaux en 2 paires différentielles bidirectionnelles, et il existe également des dispositifs similaires, comme cela a déjà été mentionné dans les commentaires, qui se traduisent par 4 paires différentielles unidirectionnelles. La traduction en seulement 2 paires vous permet d'utiliser un câble CAT tout en ayant 2 paires pour l'alimentation / la masse.

Pouces vers le haut! J'essaie actuellement de résoudre à peu près le même problème. J'essaie également d'utiliser I2C sur cat5 pour la domotique avec mon brochage personnalisé. La raison en est le coût, je veux que ce soit très rentable et les composants I2C toujours au moins 5 fois moins chers que même attiny13 uC (AFAIU uC est requis pour CAN et RS485).

1) Actuellement, je suis juste en cours d'essai pour la première partie d'un système et maintenant je réussis avec un câble de 15m de long avec 5V et une connexion SCL & SDA correcte! J'utilise PCF8574 et 2 relais pour déclencher l'éclairage de ma pièce. Le brochage est

1
2 INT
3 +5V
4 SCL
5 SDA
6 GND
7
8

2) Je comprends bien qu'il ne pourra pas se permettre quelques relais de plus ou 10 mètres supplémentaires ... Une chute de tension est importante (de 5,5 à 4,7). Donc, pour le problème de chute de tension, je vais mettre 12V sur une ligne à la place et ajouter des régulateurs de tension 5V sur les cartes pour garder une tension fine partout, quelle que soit la chute de ligne. Je mettrai quand même des alimentations supplémentaires sur les futures lignes.

3) Le signal lui-même peut être amélioré en utilisant P82B96 ou P82B715 bon marché sans se diviser en lignes différentielles. Un NXP lui-même utilise Cat5 dans certaines présentations mais je ne trouve pas leur brochage. Une partie importante ici est qu'ils utilisent clairement des lignes de signaux dans différentes paires ... par exemple une paire est GND + SDA l'autre est VCC + SCL.

4) Un autre point intéressant - ces tampons peuvent simplement augmenter une amplitude jusqu'à 12 V pour augmenter la résistance au bruit. Donc, j'essaierai probablement de mettre 12V sur les lignes de signal aussi et cela devrait permettre de mettre un pullups directement à partir du fil 12V ... Mais cela me forcera à mettre quelque chose comme P82B96 sur chaque appareil.

Comme vous l'avez peut-être remarqué, j'utilise également une ligne d'interruption séparée ... Master est actuellement sur une carte Arduino connectée à un PC. Le logiciel principal principal sera de toute façon sur un PC 24x7, donc arduino traduit simplement le signal et gère les interruptions. Je peux envoyer une configuration spécifique pour la gestion des interruptions à bord, par exemple pour gérer l'interrupteur à bascule commode via l'interruption ... Cela me permet d'oublier les retards lors du basculement de la lumière manuellement. La gestion des interruptions est un avantage supplémentaire d'i2c.

Donc, mon idée est que I2C est assez simple pour être applicable au câblage d'appartement en ville <= 100m. Au lieu d'aller au signal différentiel, j'espère que je pourrai plutôt réduire la fréquence supplémentaire.

J'aime votre idée de mettre à la fois 5V et 12V car cela réduit le besoin de régulateurs et réduit les coûts ... l'idée de bus multi-fils pour réduire le coût des points de terminaison, je vais également considérer cela pour un nouveau brochage :)