Détricotage

[bk4nt]

Bonsoir, pour un sujet qui doit avoir sa place dans la rubrique "trucs et astuces",

Dans un autre fil de discussion, certains auront compris que j'ai entrepris de détricoter une "Gleissbox". Pour comprendre comment elle est conçue. On parle de "reverse engineering".

Par le passé, tout était plus simple. On pouvait lire et exploiter les refs des composants (lorsqu'elles n'étaient pas délibérément altérées par les concepteurs). Puis suivre les pistes et en déduire des schémas simples, compréhensibles.

Aujourd'hui et avec les composants CMS, tout est devenu plus compliqué. On a du mal à les identifier. Les valeurs des résistances restent parfois seulement lisibles, celles des condensateurs céramique, non... "Z1" pour piloter le pont en H de la Gleissbox: je n'ai pas la moindre idée de ce que pourraient être ces Z1.

C'est aussi devenu plus compliqué avec les 2 à 8 couches des PCB. Par le passé, avec des montages en l'air ou avec des PCB simple face, c'était facile. Par chance, la "Gleissbox" n'est qu'en double face. Pour autant, on a aucune idée de comment les pistes sont routées sous les CMS. Sous ces Z1, visuellement, on ne peut savoir comment c'est câblé. En tous cas, pas sans dé-souder les Z1, ce qui pourrait être destructif.

Par le passé, les composants étaient simples, des passifs marqués, des diodes, des transistors (ou des lampes)... On pouvait les tester et les identifier, voire les mesurer. On pouvait aussi "sonner" les pistes, pour les suivre; ce sans risquer de fragiliser les composants, les multimètres étaient conçus pour. Je doute que Z1 soit un composant simple; c'est plutôt une porte logique, ou un driver de Mosfet. Je vais donc éviter de "sonner" les pistes autour des Z1, éviter aussi d'utiliser un multimètre en mode "test diodes", ce qui n'apprendrait probablement pas grand chose.

Ceux qui ont suivi ont remarqué que pour la partie alimentation DCC/MFX de la voie, la "Gleissbox" est conçue ainsi:
- la CPU
- suivi d'un CD4555 (dual 1 vers 4 decoder)
- suivi de ces Z1...
- et enfin des Mosfet, 2 canal N évolués (avec protections) et 2 canal P, le pont en H

Ces circuits à Z1 pilotent les Mosfet, le pont en H. En suivant les pistes du PCB, je pense avoir identifié quelques points de tests utiles (ce qui est marqué M pour mosfet). A l'occasion, je vais poser là des sondes d'un oscilloscope. Pour en savoir plus.

Par le passé, tout était plus simple, plus gros voire énorme. Les points ici marqués M ne font pas 1mm. Plus rien n'est si simple.

Un peu plus loin sur cette "Gleissbox", il y a des composants pour le feedback MFX. C'est nettement moins clair: il y a un petit lot de composants dont des céramiques non marqués, et un petit circuit à 6 pattes indéterminé, tout aussi indéterminé que ces Z1. Dans ce lot de composants pour le feedback, je trouve un "K3WI 1", totalement indéterminé. Ce serait moins simple, mais ça doit pouvoir se détricoter aussi.

[bk4nt]

Bonjour,

Du détricotage encore... Par DM, on m'a invité à discuter de cet/ces autres sujets ici.

J'ai donc une Gleisbox, et la passerelle CAN/Wifi/Ethernet m'a évidemment intéressée:
https://www.locoduino.org/spip.php?article361 "Commander sa centrale Marklin® MS2 en WiFi à partir de Rocrail®, JMRI®, iTrain® ou autres gestionnaires."

Comme je n'ai pas trouvé le schéma de cette passerelle, j'ai ouvert le Gerber proposé. Pas de schéma: on suit les pistes, on identifie les composants, on voit comment ils sont utilisés.

J'ai ouvert le Gerber/zip avec ces deux afficheurs online:
https://www.gemaddis.com/gerber-viewer-en-ligne
https://www.pcbway.com/project/OnlineGerberViewer.html

Là, j'ai remarqué ce qui devrait être une anomalie. Par DM, on m'a assuré qu'un bon nombre de telles passerelles ont été réalisées et qu'elles fonctionnes très bien.

Sur ce circuit, selon ce Gerber, je remarque cependant que VIO du MCP2562 n'est pas raccordé à 3.3V, la tension IO de l'ESP. Or d'après la doc du MCP, il y a un Power On Reset / Under Voltage Lock Out sur cette broche 3.3V.

Je ne connais pas les détails de CAN et des protocoles utilisés ici. Il pourrait exister un préambule, ou des retransmissions, cela expliquerait que ce Gerber peut être utilisé. La broche Tx (et une diode de protection sur cette entrée) pouvant alimenter VIO, où il y a un condensateur 100nF. Mais normalement, le tout début des transmissions devrait échouer (erreur bits/CRC) car VIO reste alors encore nul ou trop faible. Une fois des transmissions en cours de façon soutenue ou répétés, la broche Tx et ce 100nF peuvent maintenir VIO à une valeur acceptable. Mais à mon avis, ce circuit fonctionnerait ainsi hors spécifications.

Sur Labox, on m'a fait relire ce schéma, cette broche VIO est bien raccordée au 3.3V:
https://www.locoduino.org/IMG/png/schema_global_png.png

Détricoter avec un schéma, c'est toujours plus simple 

Si un problème était perceptible avec la passerelle CAN, la correction resterait très simple: il faudra ajouter un fil entre le 3.3V de l'ESP et VIO du MCP, via le condensateur près de VIO. Ce sont des pastilles suffisamment grandes qui vont faciliter les soudures.


Sinon, j'ai remarqué que ces interfaces CAN pourraient être utilisées hors spécifications également. Dans la présentation de cette passerelle, je constate que seuls CAN+ et CAN- sont câblés vers la Gleisbox. Il manque le fil 0V, pour interconnecter les OV de la passerelle et de la Gleisbox, CAN+ et CAN- étant chacun référencés au 0V. Là c'est aussi facile à corriger: un fil en plus, pour d'une part, référencer les signaux, d'une autre, drainer les courants qui pourraient circuler entre les 0V des alims utilisées.

Le même genre de problème pourrait se poser avec Labox. Ca ferait aussi ajouter un fil, pour les 0V. Sur un réseau, j'aurais tendance à interconnecter tous les 0V de mes sources DC, pour qu'elles ne soient pas flottantes. Sans un tel raccordement des 0V, les alims finissent référencées par les câbles des signaux; or les circuits d'interface comme ce MCP ne sont pas conçus pour fonctionner ainsi.

Le 0V fait en tous cas bien partie des fils à fils à câbler pour des interfaces de type RS485/422, V35 ou encore pour les ODB/CAN des automobiles.


Toujours à propos du CAN... je lis et je détricote beaucoup... Selon un autre fil de discussion, le breakout CJMCU230 ne serait pas recommandé pour CAN. C'est une interface CAN 3.3V, à base de sn65hvd230. D'après Texas Instrument, ce genre de composant devrait très bien fonctionner également:
https://www.ti.com/lit/an/slla337/slla337.pdf?ts=1734500020454&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FSN65HVD234-Q1

Ce type de composants pourrait être plus sensibles à l'absence d'un fil reliant les 0V, leurs signaux CAN+/- n'ont pas les mêmes niveaux que ceux des circuits CAN 5V.

[bk4nt]

On pourrait penser que pour CAN, le 0V n'est pas utile. Sur les breakout CAN pour Arduino, on ne voit toujours que deux bornes. Et on trouve très vite des montages à 2 fils seulement...

On pourrait aussi penser qu'il existe une forme d'isolation, d'isolation des 0V ou des alimentations avec CAN. Pour une isolation galvanique, il faut des composants spécifiques, avec lesquels on disposera encore des trois fils, CAN+/- et GND ou parfois marqué "shield".

Analog Device propose ce genre d'isolateurs. On en trouve un sur l'interface Canable 2.0 pro / open source, qui intègre aussi un petit convertisseur DC/DC d'isolement:
https://makerbase3d.com/product/makerbase-canable-v2/

Maxim aussi propose des solutions. Il doit en exister d'autres.

[bk4nt]

J'ai voulu aller lire la spec CAN, c'est 216CHF pour le PDF. Je vais m'abstenir 

Selon Texas encore, ces transceivers CAN ont une protection minimale. Mais on lit bien qu'une différence de potentiel entre les 0V des noeuds CAN peut poser problème. C'est au paragraphe 5.1.3:
https://www.ti.com/lit/an/sloa101b/sloa101b.pdf?ts=1734527778888

Dans cette autre doc sur la couche physique, en 4.4, Texas recommande simplement d'éviter les boucles de masse; en 4.6, on ne lit pas que le 0V est optionnel:
https://www.ti.com/lit/an/slla270/slla270.pdf?ts=1734503777597

En pratique, si certains constatent parfois des problèmes, ça peut être résolu très simplement: en interconnectant les OV des alims DC (après avoir vérifié que ça ne provoquerait pas de courts-circuits pour d'autres raisons).

On pourrait aussi réfléchir à interconnecter ces 0V DC pour éviter tout problème éventuel.

[bk4nt]

Je suis tombé sur ce doc de Analog Device, qui curieusement dit l'inverse:
https://www.analog.com/media/en/technical-documentation/app-notes/an-1123.pdf

At the physical layer, differential data transmission is supported by the CAN protocol, providing advantages such as... Wide common-mode range allowing differences in ground potential between nodes

Je vais fouiller encore.

Mais je préfère la version de Texas, je pense que c'est elle qui est appliquée dans l'industrie. Dans le monde des télécoms, les transmissions par deux fils et sans la masse sont isolées par des transformateurs (T1/E1, ISDN, xDSL... ou encore ethernet); les autres standards sans isolement dont RS485, c'est avec le GND câblé.

Pour RS485, c'est pareil, on trouve très vite des breakout Arduino "2 fils". Ca peut fonctionner sur un coin de bureau. En pratique, sans câbler le GND/0V et avec plus d'une alim DC, on finira par avoir des problèmes, des erreurs de transmission ou des choses inattendues.


D'après cette autre doc, il s'agirait plutôt d'une feature, que tous les transceiver CAN/RS485 n'auront pas:
https://www.renesas.com/en/document/apn/an1980-ground-potential-differences-origin-and-remedies?srsltid=AfmBOooc-ygsk5-WqUqxQT2lT-mIXBnYuikiJACJoYJsaTKukP8TbM-v

Industrial RS-485 networks often span long distances. A single bus segment, which is the direct link between remote bus nodes without a repeat function in between, can reach up to 1200m (4000ft) in length. ... Earth potential differences of the mains are projected onto the RS-485 data link via the bus node power supplies. Transceivers with extended common-mode range can operate over ground potential differences of up to ±25V. Higher GPDs require isolated transceivers, electrically separating the data link from the mains.

Analog Device a peut-être des composants CAN particuliers à son catalogue. Qui expliquerait leur note AN 1123.

CAN étant encore particulier comparé à RS485, on l'utilise à 1Mbps; c'est plus susceptible d'être perturbé. RS485 était couramment utilisé à 1200 Baud, donc un tel bus pouvait être très long; de temps en temps, il fallait aller chercher où sur le bus une soudure sur un connecteur était à refaire 


Avec cette autre note, sur RS485, AD peut sembler se contredire:
https://www.analog.com/media/en/technical-documentation/app-notes/an-960.pdf

Dans cette autre note, AD propose une solution à 2 fils uniquement pour RS485, mais c'est avec une isolation galvanique.


J'ai plus lu de la note AD AN-1123 sur CAN: "Galvanic isolation is the recommended solution if there is no guarantee that the potential at the earth grounds at different nodes in the system are within the common-mode range of the transceiver. Galvanic isolation allows information flow but prevents current flow (see Figure 9)."

Après quoi, la note AD propose des références de transceivers CAN avec isolation... ce que nous n'utilisons pas sur nos réseaux.