Bonjour à tous,
Je suis nouveau dans l'usage de ce forum, j'espère être dans la bonne section.
J'utilise un nano ble 33 rev2 placé dans un boîtier "CPU". Dans un second boîtier "IHM", j'ai un gps qui communique en 9600bd sur liaison série, plus un écran oled 128x128 type MC01506 avec driver SH1107. L'écran utilise une interface I2C.
Lorsque je connecté les deux boitiers en liaison courte (en utilisant juste les connecteurs placés sur les 2 boitiers), tout fonctionne parfaitement.
Lorsque les deux boitiers sont reliés par un câble de 80cm environ, cela fonctionne quelques dizaines de secondes puis l'arduino se bloque (l'écran se fige). Le câble entre les deux est un câble ethernet 4 paires torsadées.
Je soupçonne donc un problème avec le câble (effet de capacitance ou autre) peut être lié à la vitesse du bus i2c car la liaison série à 9600bd du gps ne devrait pas être un problème. Sauriez vous comment résoudre cela ou quel type de câble conviendrait mieux ?
L'ensemble devant être monté dans un véhicule, je ne peux éviter cette longueur de câble.
Merci pour vos réponses.
En effet pour les paires j'ai fait comme ceci (peut être un pb là): 7 fils utilisés sur 8 disponibles :
5v seul
masse et SDA sur une paire
RX du gps et le bouton poussoir associé au screen: ce BP est branché en interruption et permet de changer le type d'affichage : vitesse, position, etc...)
TX du gps avec SCL
Il y aurait une meilleure association ? J'avoue ne pas avoir considéré ce point
Je peux essayer en effet de mettre des résistances de pullup sur les deux entrées SDA et SCL.
Mélanger TX du GPS et SCL sur une même paire n'est pas idéal. TX étant un signal asynchrone et SCL étant un signal d'horloge synchrone, ils risquent de générer des interférences l’un sur l’autre.
De même lors de l’appui sur le bouton, des parasites ou des variations de potentiel peuvent perturber le signal RX.
Dans une paire torsadée on associe souvent chaque signal différentiel avec sa masse dans une même paire torsadée. Par exemple : (5V + GND), (SDA + GND), (SCL + GND),... pour éviter les interférences croisées
➜ vous n'auriez pas assez de paires pour vos besoins ...
@J-M-L merci ça me fait progresser ce genre de conseil. Je vais d'abord essayer les résistances, et si ça ne suffit pas je me creuserai la tête pour trouver une autre combinaison des paires.
Je devrais faire ça demain, je vous dirai comment ça progresse.
Associer un fil signal avec SON fil de masse augmente la capacité parasite, dans l'absolu c'est pas ce que l'on fait de mieux, dans la réalité cela présente plus d'avantages que d'inconvénient.
Au moins c'est parfaitement stable et cela évite de faire un montage qui tombe en marche par le plus grand des hasards et qui assurément tombera en panne un jour ou l'autre.
La capacité parasite forme un circuit RC avec la résistance de charge (la R qui s'appelle pull-up).
Un circuit a un temps de charge lent et un temps de décharge court.
Plus il y a de capacité, plus la partie exploitable du bit retrécie jusqu'à ne plus fonctionner.
Le problème se réduit à une question de temps disponible pour les 1 et les 0.
Deux solutions :
diminuer la résistance de pull-up ce qui augmente le courant : il faut s'assurer que les transistors le supportent. L'information se trouve dans les datasheets sérieuses (chinoiserie aléatoire).
"On peut s'autoriser à penser dans les milieux autorisés" qu'un courant entre 5 et 10 mA est sans danger.
Attention, quand il y a plusieurs modules et que chaque module a ses résistances de pull-up, toutes les résistances de SDA et toutes celles de SCL se retrouvent en parallèle.
La résistance à prendre en compte pour le calcul du courant est la résistance équivalente à toutes les différentes résistances en parallèle.
Solution 2
On peut travailler dans l'autre sens : plutôt que de diminuer le temps de charge avec pour conséquence l'augmentation du courant , on peut augmenter le temps des bits en baissant la fréquence SCL. Cela aura pour conséquence d'augmenter le temps de communication I2C.
Pour un afficher cela ne devrait pas être perturbant.
La bibliothèque Wire le permet même si ce n'est pas bien documenté. Je ne connais pas la nano 33 BLE, je ne connais pas ses possibilités.
Un câble ethernet a une impédance caractéristique de 100 ohms.
Sur de grandes longueurs, il est préférable de l'adapter sinon il se produit des réflexions.
J'ai déjà réalisé des liaisons de 50 m en câble ethernet en adaptant coté entrée de câble avec une résistance série et coté utilisation avec un dipole placé entre signal et masse.
Résistance de 100 ohms plus capa série de 100 nF.
La capa sert à éviter la formation d'un pont diviseur "continu" entre le rdson du transistor de sortie et la charge de 100 ohms.
Coté émission c'est moins critique.
On montre dans les livres et revues spécialisés que jusqu'à 500/600 MHz, pour un signal numérique, on peut se passer d'une adaptation en entrée de câble.
Au-delà de ces fréquences, la parasitologie est trop importante et on travaille généralement sur 50 ou 100 ohms à chaque extrémité.
Le Rdson des transistors des sorties des micro fait autour de 30 ohms.
Si on veut adapter en entrée de câble, il faut en tenir compte et ajouter en série une résistance de (Zc- Rdson) soit 70 ohms avec l'éthernet.
En fait il est toujours préférable de travailler en entrée et en extrémité de câble avec une résistance inférieure au Zc du câble.
Surtout en extrémité : plus la résistance est faible, plus l'influence des capa et inductances parasites sera masquée.
Si je devais adapter un câble ethernet, je me contenterais de 50 ohms série pour l'entrée du câble ce qui ferait environ 80 ohms au total. et 80 ohms pour l'extrémité sortie du câble.
Ce principe fonctionne bien avec le SPI qui est unidirectionnel, mais pas avec l'I2C qui bidirectionnel et avec des résistances un peu partout dans l'araignée du réseau I2C.
On ne sait pas où il serait possible d'adapter.
En SPI l'impédance de sortie du micro est approximativement 30 ohms.
En I2C l'impédance de sortie du micro est celle d'un montage source commune (émeteur commun) , c'est-a-dire égale à la résistance de drain -> notre fameuse pull-up.
L'impédance dépend du nombre de modules connectés sur le bus.
Merci beaucoup pour vos conseils. Ayant sous la main des résistances 2k j'ai placé une résistance sur SDA et une sur SCL. Résultat immédiat: 1er test: bloquage au bout de 2h (ça bloquait avant au bout de 10 à 30s). 2e essai sur 1h30: pas de bloquage.
Donc les résistances ont un effet très significatif. Je vais changer aussi les connections sur le câble:
(câble blindé extérieur, mais pas de blindage individuel par paire)
En passant 1 masse de plus je peux faire:
SCL /masse
SDA / masse
RX / 5v (je fais essentiellement de la réception sur le gps)
Tx / bouton poussoir qui est relié à une entrée numérique, son autre fil étant a la masse
Pensez vous que se serait mieux ou une autre combinaison serait plus appropriée (sachant que j'ai déjà un gain énorme avec votre expertise) ?
Je pense que si vous pouvez associer sa masse à chaque fil de signal c’est mieux .
5V et GND sur une paire
SCL et GND
SDA et GND
Tx GPS et GND
Tenir compte des commentaires de @68tjs pour les résistances aussi
Pour le bouton passez sur une paire de fil sséparés
Ensuite je me demande quand même pourquoi vous avez besoin de deux arduino à moins de 80cm d’écart. Ne pouvez-vous pas tout mettre sur une seul arduino qui a avoir quelques fils allant vers des périphériques comme le GPS ?
Oui en effet je vais faire des tests complémentaires sur la base de vos conseils.
D'abord essayer avec des 1.5k comme conseillé, puis associer différemment les signaux. Baisser la fréquence de l'I2c est une idée que j'avais mais je n'ai pas investigué la possibilité de la faire.
Sinon je n'ai pas été très bavard dans la description: j'ai un seul Arduino 33 Ble v2 logé dans un boîtier CPU.ce boîtier gere 2 capteurs de température (température intérieure et température extérieure). Le capteur de température intérieur est fixé sur ce boîtier "CPU". L'arduino possède un gyroscope interne qui me permet d'avoir les inclinaisons du véhicule.
Dand un second boîtier "IHM" déporté de 80cm, j'ai: l'écran, un gps, et un bouton poussoir qui permet d'afficher différentes pages sur l'écran: inclinaisons, températures, vitesse, position.
Le tout est dans un vieux 4x4 que j'utilise en montagne sur des chemins difficiles.
Je vous dirai ce qui a été le mieux en terme de solution.
Je parle en résistance totale équivalente, tu peux descendre a 1 k qui donnera 5 mA.
Par contre l’arduino est en Vcc 5V, la ble elle est en 5V ou en 3,3 V ?
Le BLE 33 est en 3.3v partout. Donc entrées digitales en 3.3v max. Par contre mes capteurs (DHT22, gps, screen) sont alimentés directement en 5v, ils sont compatibles. Et la datasheet du DHT22 préconise 5v au delà de 1m de câble sinon les mesures sont fausses, ce que j'ai pu constater. En effet le DHT22 qui prend la temp extérieure est branché sur un câble de presque 2m.
Je vais abaisser mes valeurs de résistance: 1k ça fait 3mA en effet ça passe, le max est 10mA par entrée. Ca permet j'imagine d'avoir des niveaux haut et bas plus francs c'est ça ?
Sans rien enlever aux contributions existantes, il y a qq aspects qui m'interpellent dans ce montage:
pourquoi placer le récepteur GPS (recevant des signaux très faibles, même s'ils sont très résistants au brouillage) à côté de l'affichage (puissant générateur de parasites...). Si les récepteurs GPS communiquent en série à 9600bds, c'est justement pour qu'on puisse les déporter facilement,
Indépendamment de la question de l'alimentation (3.3V ou 5V, pas de mélange sur l'I2C) déjà posée, avez vous prévu les découplages au plus près de l'écran, du GPS, de l'Arduino et des autres capteurs ? Pour mémoire, le découplage "classique" c'est un condensateur chimique de qq centaines de µF (tension <30V) et en parallèle un condensateur de 100nF (100V). Le tout doit être soudé avec des fils aussi courts que possible, idéalement, sur le GPS, l'affichage, l'Arduino et les autres capteurs...
Dans le même registre, quid de l'alimentation ? Stable ? Suffisante en intensité ?
Pour tout vous dire, j'ai déjà déporté de l'I2C sur qq mètres sans problème sur du fil ethernet ou même PTT et cela ne m'a jamais posé de problème...
Côté logiciel:
pas de String pour mettre la zone au bout d'un temps imprévisible ?
dès qu'il y a des transmissions, des erreurs sont inévitables et parfaitement normales. Votre logiciel sait les détecter et les récupérer ?
Le gps est dans le boîtier IHM lui même posé sur le tableau de bord. Je me suis bien posé la question de le mettre dans le boîtier CPU avec l'arduino, mais comme ce boîtier est sous la planche de bord, je crains une mauvaise réception gps.
@MicroQuettas Pouvez-vous préciser comment vous faites le découplage avec les condensateurs ? Les 2 en parallèle sur l’alimentation (pardon si c'est une question de néophyte) ?
L'alimentation est bonne (enfin je ne sais pas): Pour les tests sur table, mon montage est alimenté sur Vin via un adaptateur USB de téléphone, le câble d'alimentation étant modifié pour cela. C'est un adaptateur 2A mais on ne sait jamais la qualité de ces dispositifs.
Qur la voiture j'ai un convertisseur 12v DC / 5v DC stable qui peut fournir 5A. J'ai préféré ne pas alimenter en 12v qui sur une voiture n'est pas hyper stable.
Pour le GPS, vous verrez à l'usage... Mettez le sur le haut, antenne aussi dégagée que possible.
Pour les condensateurs de découplage, en parallèle, fils le plus court possible. Si vous avez accès aux schémas de votre affichage et autres, il est probable qu'il y ait déjà des découplages de faible valeur. En quel cas, le chimique de qq centaines de µF (typiquement 220 à 470µF) peut suffire.
Votre alim a l'air OK. Très bien le convertisseur 12 -> 5V.
Ce qui me chiffonne c'est que j'ai cru comprendre que vous mélangez des circuits 5V et 3V3 sur le même bus I2C ? Ca, j'ai essayé une fois... résultat instable... j'ai vite compris qu'il fallait mettre des changeurs de niveau (par ex. à MOSFET)... et depuis ça marche pile-poil !
