LOCODUINO
Parlons Arduino => Modélisation, Architectures logicielles et matérielles => Discussion démarrée par: bobyAndCo le novembre 22, 2024, 12:16:45 pm
-
Bonjour à tous,
J’ai présenté une centrale en MFX qui reprend la base matérielle de LaBox et qui fonctionne de manière très satisfaisante.
https://www.youtube.com/watch?v=kIXx-TSOVpQ&ab_channel=ChristopheBOBILLE
DCC et MFX sont des protocoles qui sont assez similaires pour ce qui est du codage du signal de voie.
Mais le MFX dans son fonctionnement intrinsèque utilise plus les informations de retour des décodeurs que ne le fait le DCC.
Or je suis bloqué sur ce point pour que cette centrale soit vraiment complète.
Je lance un appel à l’aide aux spécialistes de l’électronique intéressés par le retour d’informations des décodeurs. J’ai pu constater au travers d’autres fils que l’activité était bouillonnante pour ce qui concerne Railcom. Peut-être une opportunité pour moi ?
Pour essayer de faire simple, MFX comme DCC, créent dans les trames de voies une fenêtre pendant laquelle les décodeurs envoient leurs informations retour. Ce signal semble correspondre à la technologie RDS.
(https://media.3rails.fr/original/3X/5/4/5410e0b2cb7dbc3ec41e33ccf257e91fd0f77ad3.jpeg)
Voir ici : https://www.skrauss.de/modellbahn/Schienenformat.pdf (https://www.skrauss.de/modellbahn/Schienenformat.pdf) 2.3.1 et suivants :
En principe, le canal de retour est codé comme un signal RDS® (codage binaire et modulation). Il est donc possible d'utiliser une puce de décodage RDS® disponible dans le commerce pour décoder le canal retour dans la centrale. C'est d'ailleurs ce qui est fait.
La fréquence porteuse ne correspond pas exactement à la fréquence porteuse définie pour le RDS®. On utilise une fréquence légèrement inférieure qui, contrairement à la fréquence porteuse RDS®, peut être dérivée d'un quartz avec une valeur de fréquence « paire » (par ex. 4 MHz). La fréquence porteuse est de 52,63 kHz (obtenue en divisant 4 MHz par 76, au lieu de 4,332 MHz divisés par 76 = 57 kHz pour le RDS®).
Comme décrit au point 2.2.6, il existe deux types de messages de retour : un simple message de retour de 1 bit et le message de retour de données. Les deux utilisent certes la puce de décodage RDS®, mais de manière différente. Seul le retour de données proprement dit utilise la technique de transmission du RDS®.
On peut d’ailleurs voir à l’intérieur d’une CS2, la puce PT2579 qui est spécifiquement une puce pour le traitement des signaux RDS.
(https://media.3rails.fr/optimized/3X/0/9/09a362a0499b57ca80d32f1eea2fc78b6afb0f54_2_690x380.jpeg)
La datasheet du composant est ici : https://mobilluk.com.ua/wp-content/uploads/2024/01/PT2579-SN.pdf?srsltid=AfmBOoqq0ymKa5gb6j-dqeNJvNYznXRjoW_3IB-ZcrYzXdUKD85p4YnY (https://mobilluk.com.ua/wp-content/uploads/2024/01/PT2579-SN.pdf?srsltid=AfmBOoqq0ymKa5gb6j-dqeNJvNYznXRjoW_3IB-ZcrYzXdUKD85p4YnY)
Sur une autre source, il semble que l’auteur ait réalisé un montage électronique qui permet de décoder le signal retour. Mais là aussi je ne sais pas analyser cela.
(https://www.persmodelrailroad.com/el/mfx_sense_sch.gif)
Extrait de : https://www.persmodelrailroad.com/mfx_boost.html (https://www.persmodelrailroad.com/mfx_boost.html)
Je lance un appel au forum pour qui serait capable de m’aider dans ce projet.
Christophe
-
Bonjour,
on s'intéresse davantage à Railcom car MFX est plus propriétaire? Il existe de la doc pour MFX?
Ce que vous avez trouvé là, autour d'un LM393, est curieux. Il semblait avoir un booster de type 6017, sans récepteur MFX. Et avoir utilisé le LM393 pour reporter des variations de courant depuis la voie sous booster 6017, et vers la voie où se situe la centrale capable de recevoir du MFX.
La seule chose qui nous intéresserait serait alors le signal à la sortie du LM393. Le 393 étant un comparateur, ce signal à sa sortie devrait être numérique...
Sa solution avec un 393 est aussi discutée ici: https://www.marklin-users.net/forum/posts/t10321-mfx-feedback-with-6017-booster "I have been able to add mfx feedback to a 6017 booster." "I pick up the current draw variations in the boostered section with a signal transformer. Then I amplify the signal and let it cause a corresponding current draw in the section directly fed by the Mobile Station."
Or le PT2579 est un démodulateur, d'un signal analogique (modulé en amplitude, avec suppression de porteuse).
La modulation DBS étant décrite ici, ce qui me semble à priori incompatible avec ce circuit à comparateur 393: https://www.semanticscholar.org/paper/Development-of-Radio-Data-System-Decoder-IC's-Ogawa-Arai/ab5a18be27b2aad7c5538b964c6a079022730640
On serait peut être sur une astuce qui consisterait à n'envoyer qu'une partie du signal modulé AM vers le PT2579, son entrée 4 (l'image où j'ai ajouté des traits en jaune). Potentiellement, un fonctionnement hors specs du PTS2579...
Ca mériterait un test, le 393 alimenté sous 5V, avec une atténuation du signal (simple diviseur avec deux résistances) entre la sortie du 393 et l'entrée du PT2579 (qui prend plutôt du 2,5 à 2V peak peak). Si le PT2579 peut recevoir/démoduler quelque chose dans ces conditions, RDCL (bit clock) et RRDA (data) pourraient être exploités par un arduino.
-
Merci de t’être intéressé au sujet et pour ta réponse. Depuis j’ai avancé et j’ai trouvé ceci qui est beaucoup plus proche du circuit Marklin et fonctionne en RDS.
(https://media.3rails.fr/original/3X/0/9/0942712d0922391339827733c387b3d4a228a636.jpeg)
Voici l’intérieur d’une MS2 où l’on voit distinctement la PT2579, démodulateur RDS.
(https://media.3rails.fr/original/3X/9/1/915037b77a2cd81056eab186f23bdd97e5b31813.jpeg)
J’ai commandé et reçu les composants nécessaires mais étant absent quelques jours, je ne pourrai reprendre cela que la semaine prochaine. Je n’ai pas trouvé de PT2579 mais j’ai cependant réussi à trouver un équivalent, le LC72725KV
Comme tu sembles connaitre le sujet, il m’intéresse d’avoir ton retour sur ces éléments.
Dans l’immédiat, je suis complètement sur le passage de la modulation du signal MFX sur RMT comme cela est le cas pour DCC-Ex. Je vais d’abord terminer ce chantier avant d’entamer celui du RDS.
Christophe
-
C'est curieux.
Sur marklin users (dot) net, les gens répondent à bobyAndCo de voir la doc MFX, à cette adresse: https://www.skrauss.de
Je doutais que les décodeurs de loco intègrent un modulateur AM. Ils n'enverraient que des implusions, comme pour Railcom. Une électronique simple, donc.
Le 393 est donc approprié pour détecter ces signaux feedback MFX. Resterait à tester ou à comprendre mieux comment interfacer un tel montage à 393 avec un PTS2579. Peut être juste un atténuateur à 2 résistances.
bobyAndCo , sur ce second montage que vous avez trouvé, on voit que le signal des locos (des impulsions) est écrêté à 0.7V par D1/D2, et envoyé dans l'entrée MUX d'un démodulateur AM/RDS. De là, les sorties clock et data, exploitables par un processeur.
Du coup, j'ai le sentiment que des démodulateurs RDS AM sont utilisés hors spec, avec de l'AM en mode ON/OFF généré par les locos. Mais si ça fonctionne...
-
Sur marklin users (dot) net, les gens répondent à bobyAndCo de voir la doc MFX, à cette adresse: https://www.skrauss.de
Le lien https://www.skrauss.de/modellbahn/Trackprotocol.pdf (https://www.skrauss.de/modellbahn/Trackprotocol.pdf) c'est un document très complet sur le signal de voie MFX de Marklin. Ce document aborde le retour d'information (§2.2.6 et suivants) mais tous les autres asspect du protocole. C'ets en partie sur ce socument que je me suis appuyé pour produire le code de la centrale MFX.
Tu sembles bien connaître le sujet, penses-tu que tu pourrais m'aider ? Ce qui est bien sûr pour mettre à disposition de tous.
Christophe
-
Désolé bobyAndCo,
je suis déjà occupé par mes propres projets autour de Railcom. Et en tous les cas, je n'ai pas de matériel MFX, je n'irais donc pas bien loin, nul part dans la pratique.
Tu semblais vouloir en savoir plus sur ces feedback MFX. Et il n'y avait pas de réponses. J'ai donc simplement ajouté quelques mots, espérant avancer le sujet.
J'en profite pour corriger ma lecture du second schéma que tu as trouvé:
- on a bien MUX, l'entrée du signal depuis la voie
- RDCL la clock bits
- RDDA, la data, pour du shift in au rythme de RDCL
- le SCOUT/LM311 (un simple comparateur encore), je pense que c'est un signal binaire qui indique une détection de données RDS
Avec Railcom, une tendance pourrait être de le recevoir par canton ou par secteur au moins. Avec autant de composants requis. Et c'est assez facile, on devrait recevoir des mots de 8 bits via UART, directement exploitables.
Du coup, si on voulait un à plusieurs récepteurs MFX sur un réseau, on devine déjà avec quels composants électroniques les construire.
Reste à voir comment traiter les bits RDS reçus. Peut-être avec un simple port SPI pour data et la clock, comme on fait avec des registres à décalages. En ce cas, à chaque message, on recevrait x mots de 8 bits via SPI, ce serait simple.
Si c'est bien aussi simple, il faudrait un SPI en réception:
- clock
- data
- SPI transfer vers un buffer déclenché par la sortie du LM311
Puis ce qu'on fera des données une fois dans le buffer, c'est une autre histoire :)
-
Du coup, j'ai encore regardé un peu le gros PDF sur MFX. Qui nous parle encore d'autres modulations que AM...
Mais le doc expliquant que RDS peut être démodulé avec des composants du commerce, donc un PT2579, un SC6579, ... ce sont alors eux qui s'occupent de la couche basse, AM, ASK ou phase, on a pas à s'en soucier.
Il y a ici manifestement des gens qui savent coder. Et il doit y avoir maintenant assez d'éléments ici pour construire un récepteur avec ce que bobyAndCo a partagé.
Resterait à faire un montage pour tester et "sniffer", pour voir ce qui sort en pratique de broches clock/data(/LM311) d'un de ces composants du commerce.
Plus loin dans la doc, ça semble dire qu'on reçoit de 1 à 4 octets. Voire moins. Il faudra alors probablement faire plus qu'un simple SPI transfer, pour s'adapter aux nombre de bits et octets reçus. A moins que faire un SPI transfer avec un timeout si on ne reçoit pas 4 octets dans un délais donné. D'une façon ou d'une autre, ça doit pouvoir se coder.
-
Last but not least, auquel je viens de penser, il pourrait suivre un problème d'approvisionnement de ces composants spécifiques. En effet, on substitue le DAB/DAB+ à la FM (dont RDS, qui devrait un moment s'éteindre également... et la production ainsi que la vente de ces composants avec).
Le 31 décembre 2024, la SSR ne diffusera plus ses programmes radio en FM. Il faudra donc écouter la radio en DAB+ ou via internet. Quelles solutions pour adapter les appareils à domicile ou en voiture? https://www.rts.ch/info/societe/2024/article/fin-de-la-fm-pour-passer-au-dab-quelles-solutions-28560288.html
Si ces composants / décodeurs RDS ne sont plus produits ni vendus, même Marklin finira par avoir un soucis. Pour ce qui nous concerne, ou pour ceux qui ont investit dans MFX, ils pourraient avoir à acquérir un petit stock de puces RDS si c'est une solution simple pour des récepteurs MFX.
Il y avait eu un précédent avec DCF77, un système imaginé il y a longtemps pour diffuser des signaux, l'heure d'une horloge atomique. Il existe aussi des composants dédiés pour décoder facilement ce signal DCF77. Un moment, les antennes émettant ces signaux ont commencées à être démontées...
https://next.ink/11388/102604-grandes-ondes-france-inter-sarretera-au-1er-janvier-pas-service-dhorloge-atomique/ "France Inter qui est actuellement disponible sur la fréquence des 162 kHz cessera d'émettre à compter du 1er janvier 2017" "depuis 1977, cette fréquence transmet un signal horaire de référence élaboré à partir d’horloges atomiques explique l'Agence nationale des fréquences (ANFR)." "Problème, ce service est largement utilisé dans des secteurs clés de l’industrie afin de synchroniser plus de 200 000 horloges indique l'ANFR. Cette dernière cite quelques exemples : la SNCF, Enedis (anciennement ERDF), Aéroports de Paris ainsi que des collectivités locales." "Afin de maintenir ce service en état de marche malgré l’arrêt de la diffusion de France Inter, l'ANFR explique qu'elle a été « missionnée » par le gouvernement afin de maintenir la diffusion du signal horaire, et ce, dès le 1er janvier 2017. "
-
Le truc qui me plaît le plus, c'est ce montage à LM393, tout en haut. Eco et capable selon son auteur de répercuter des signaux d'une voie vers la centrale.
Les décodeurs de loco envoient peut être des signaux tout simples (impulsions à durées et espacements variables) qu'une CPU rapide pourrait facilement recevoir puis traiter. Ca ferait faire du shift in (synchrone) de la sortie du LM393.
On en saurait plus si on trouvait une trace d'oscilloscope, de ce qu'on a en entrée/sortie du LM393. Ou sur la voie, envoyé par un décodeur MFX. Peut être un encodage tout simple.
https://connect.ed-diamond.com/GNU-Linux-Magazine/glmf-204/radio-data-system-rds-analyse-du-canal-numerique-transmis-par-les-stations-radio-fm-commerciales-introduction-aux-codes-correcteurs-d-erreur
-
Bonjour,
Est-ce qu tu parles de quelque chose comme ceci ?
https://web.archive.org/web/20120729085546/http://www.alice-dsl.net/mue473/mfxrahmen.htm
Christophe
-
Plus de détails sur la forme/timing des signaux seraient utiles, oui. Mais à ce lien là, sur la partie RDS/retour, je remarque:
Fenster für Bestätigungs- Rückmeldun: on voit le DDC/MFX, mais pas d'exemple de signal RDS
READ-Paket wird der Rückmeldeträger mit einer Übertragungsrate von 912µs/Bit RDS-ähnlich phasenmoduliert
modulé en phase de manière similaire à RDS
Unklarheiten...
Rückmeldungen wurden bisher nur teilweise ausgewertet. Details sind daher nur unvollständig bekannt.
Jusqu’à présent, les retours n’ont été que partiellement évalués. Les détails ne sont donc que partiellement connus.
-
J'en ai lu un peu plus dans cet autre fil, où tu échanges avec les Marklin users:
https://www.marklin-users.net/forum/posts/m677703-Marklin-MFX-feedback--using-RDS#post677703
Je constate que tu avais déjà perçu que ces composants RDS sont aujourd'hui difficiles à trouver. Marlin les utilisant encore pour ses nouvelles stations. Pour un industriel, ce n'est pas une difficulté, ils en auront mis assez en stock pour les prochaines années, selon leurs prévisions de ventes et réparations.
Avec un LM393, ce serait pour une approche "software based", que tu évoques là bas. RDS, c'est juste 1000 BAUD. Mais dans des temps/timings courts. Un ESP32 ne suivrait pas. Il faudra à mon avis plutôt penser à un CPU dédié à cette tâche réception/décodage RDS, qui communique ensuite les données reçues à l'ESP.
Dans un premier temps, tu pourrais déjà évaluer avec un composant dédié RDS. Ce serait une bonne base pour ensuite décoder/comparer facilement les signaux.
Puis réfléchir à comment faire un décodeur à partir d'un AVR 20MHz. Peut être en le raccordant avec un LM393, en même temps que le montage à composant RDS, ce qui permettrait des comparaisons de signaux reçus/décodés.
Je ne sais pas s'il existe déjà un software PIC ou AVR qui ferait l'affaire.
-
C'est à cette approche que je pense, avec un AVR rapide, 20 ou 16MHz.
Là, l'article décrit comment RDS est encodé. J'imagine qu'on a un signal équivalant à "e" à la sortie du LM393, et que les décodeurs de loco font en fait un travail d'encodage très simple.
Une approche en synchronisant l'horloge ou les timing "d" avec les transitions up/down de "e", pour faire du shift in de "e" au rythme de "d"....
Ou si l'AVR suit (en étant dédié à la tâche), peut-être avec "e" sur une pin int up/down, et un calcul rapide du délais entre deux interruptions. A nouveau pour "e" dans un buffer.
Une fois les données "e" dans un buffer, il serait facile d'en déduire "b", puis "a", la data.
"d" a une fréquence double comparé à "c". J'essayerais d'échantillonner "e" à la fréquence "d", pas sur les transitions up/dow de "e". On aurait alors deux bits par symbole "e" dans un buffer: 00, 01, 11 ou 10.
C'est du 1200 BAUD et les décodeurs n'envoient pas tout le temps de messages. Entre deux messages, l'AVR pourrait décoder le buffer "e" et transmettre la data à un ESP.
Seule difficulté: la précision et la stabilité des quartz (de l'AVR et de ceux des locos). On pourrait avoir à sur échantillonner les symboles "e" sur 4 bits ou plus au lieu de 2 pour rester assez synchro, sur une "fenêtre", et se resynchroniser sur les transitions up/dow de "e". Ou avoir à utiliser une PLL pour générer "d"; ça pourrait alors être plus simple dans l'AVR. Mais avec une PLL, on pourrait perdre des symboles du début d'un message, le temps qu'elle soit en phase.
Tout peut dépendre de la fréquence "d", si elle serait compatible avec un AVR à 20 ou 16Mhz. Si c'est juste 2375 Hz, ce serait facile. On décode bien le DCC (entre 4 et 8Khz) avec un simple UNO, alors pourquoi pas le RDS si c'est effectivement aussi lent?
2375, une valeur bizarre; pour la radio FM. Marklin a donc utilisé un quartz de 4MHz. Probablement pour une vitesse plus adaptée à des quarts 16 ou 20MHz et pour des diviseurs entiers:
La fréquence porteuse ne correspond pas exactement à la fréquence porteuse définie pour le RDS®. On utilise une fréquence légèrement inférieure qui, contrairement à la fréquence porteuse RDS®, peut être dérivée d'un quartz avec une valeur de fréquence « paire » (par ex. 4 MHz). La fréquence porteuse est de 52,63 kHz (obtenue en divisant 4 MHz par 76, au lieu de 4,332 MHz divisés par 76 = 57 kHz pour le RDS®).
L'extrait/image de source: https://www.electronicdesign.com/home/article/21202018/testing-rds-equipped-fm-radio-receivers
-
A mon avis, cette approche toute simple avec un AVR peut fonctionner. Et ne dépendrait alors plus de composants obsolètes.
Je doute en tous cas que les locos aient une radio FM embarquée. A mon avis, leurs décodeurs envoient un simple signal encodé et directement exploitable, notamment par le biais de ce montage simple à LM393.
Ca m'a fait regarder comment est construit une radio FM. Le "démodulateur" RDS se situe bien après le démodulateur FM. Ces puces RDS seraient donc plutôt des décodeurs avec récupération d'horloge, d'où data et clock en sortie.
Dans cet exemple:
- un TDA7040 démodule la FM
- MPX est splité vers le TDA7021, et vers le décodeur RDS, via T1
- un TDA7021 décode la stéréo
- Le TDA7330 ou "RDS decoder" se contente de restituer la data/clock RDS
Et dans la doc du PT2579, on lit "démodulator", mais ce n'est qu'un décodeur. Donc on peut ignorer tous les aspects modulation/radio FM.
De source: https://www.techdesign.be/projects/021/021.htm
-
Zut. Je me suis planté. Le signal en sortie des décodeurs pourrait bien être modulé, à 57kHz/AM. Alors un tel composant particulier pourrait être requis, pour avoir un signal exploitable (1).
Mais ça n'explique alors pas comment un simple montage à LM393/comparateur présenté plus haut pourrait fonctionner. Ce ne serait pas compatible avec de l'AM.
Et je n'ai pas réussi à trouver un exemple en image d'un signal électrique MFX/RDS émis par un décodeur.
-
Et finalement, j'ai trouvé ceci: https://rainer.mueller-korntal.de/mfxreceiver.htm
Soupirs. Il s'agirait donc bien d'un signal analogique, modulé. Donc une solution simple ne suffira pas.
Il utilise les fonctions d'un PIC: des amplis op, un comparateur et un convertisseur AD. Et il partage un code source.
Une solution partielle, mais un début: "Bisher ist das nur die Ein-Bit-Rückmeldung mit ASK-Wert implementiert, die Auswertung der Phasensprünge fehlt momentan noch."
J'en conclue que la solution à LM393 est imparfaite, ne permet que la détection d'une modulation et sans décodage. Pour un feedback élémentaire.
-
Je te remercie sincèrement une nouvelle fois de m’aider et de chercher des solutions. Je ne suis pas disponible encore jusqu’au WE au moins ce qui ne me permet même pas d’étudier les pistes que tu soumets.
Je pense cependant que le PT2579 (ou équivalent) est la piste à privilégier même si le composant est rare et que cela va s’amplifier. C’est malgré tout celle qui reste la plus simple pour arriver à un résultat selon moi et explorer ensuite de nouvelles directions mais à partir de résultats déjà existants.
Le dernier montage que tu proposes fonctionne avec 1 bits car « Dans le cas de la confirmation simple, il n'y a pas de synchronisation avec l'horloge RDS® comme dans le cas de la confirmation de données ».
Il y a des précisions intéressantes dans le document dont j’ai donné le lien plus haut : https://www.skrauss.de/modellbahn/Trackprotocol.pdf
2.3 Canal de retour
On appelle voie de retour la transmission d'informations du décodeur à la centrale via le rail.
2.3.1 Modulation
En principe, le canal de retour est codé comme un signal RDS® (codage binaire et modulation). Il est donc possible d'utiliser une puce de décodage RDS® disponible dans le commerce pour décoder le canal retour dans la centrale. C'est d'ailleurs ce qui est fait.
La fréquence porteuse ne correspond pas exactement à la fréquence porteuse définie pour le RDS®. On utilise une fréquence légèrement inférieure qui, contrairement à la fréquence porteuse RDS®, peut être dérivée d'un quartz avec une valeur de fréquence « paire » (par ex. 4 MHz). La fréquence porteuse est de 52,63 kHz (obtenue en divisant 4 MHz par 76, au lieu de 4,332 MHz divisés par 76 = 57 kHz pour le RDS®).
Comme décrit au point 2.2.6, il existe deux types de messages de retour : un simple message de retour de 1 bit et le message de retour de données. Les deux utilisent certes la puce de décodage RDS®, mais de manière différente. Seul le retour de données proprement dit utilise la technique de transmission du RDS®.
2.3.2 Codage du retour d'information 1-bit
La réponse simple de 1 bit est codée par le fait qu'il y a ou non une réponse du décodeur. Si le décodeur répond, cela vaut un (« oui »). Si la centrale ne reconnaît pas de réponse, cela signifie zéro (« non »). La particularité : ce type de réponse peut être envoyé simultanément par plusieurs décodeurs, les réponses sont reliées par OU. La réponse est donc reconnue comme existante si au moins un décodeur envoie une réponse.
Le décodeur utilise le signal porteur RDS® comme réponse, c'est-à-dire qu'il génère un signal rectangulaire d'une fréquence de 52,63 kHz.
Techniquement, il s'agit d'un signal ASC (Amplitude Shift Keying). Le signal porteur est donc modulé en amplitude avec le flux de données. Il n'y a que deux états à transmettre : Bit = 0 signifie que l'amplitude du signal porteur est nulle, Bit = 1 signifie que le signal porteur est transmis avec une amplitude complète sans changement de phase.
Dans la centrale, on utilise le fait que la puce du décodeur RDS® signale la présence d'un signal porteur indépendamment des données transmises.
2.3.3 Codage lors de la confirmation des données
Lors de la confirmation des données, un flux de bits de données est envoyé, que la centrale interprète. 1, 2, 4 ou 8 octets de données ainsi qu'un octet de somme de contrôle sont transmis.
Lors des essais, seuls 1, 2 et 4 octets ont pu être transmis. Les informations contenues dans la documentation CAN de la Märklin Central Station 2 et la structure de commande permettent toutefois de conclure que 8 octets sont également possibles.
Le retour d'information ne peut être effectué simultanément que par un décodeur qui y est invité par la commande correspondante.
La modulation biphase définie pour le RDS® est utilisée pour coder l'horloge et les données. A chaque signal d'horloge, la position de phase du signal porteur change de 180°. Une horloge dure 912 μs, elle est donc transmise à 1096,5 baud (= signal porteur divisé par 48). Les bits sont également codés par changement de phase :
Bit = 1 : la position de phase ne change pas à l'intérieur d'une mesure.
Bit = 0 : la phase du signal porteur change de 180° au milieu d'une mesure (donc
456 μs après le changement de phase de l'horloge).
Je ne peux malheureusement pas en ce moment faire de recherches très poussées mais je crois que c’est la piste à suivre qui est me semble t’il la mieux documentée.
J’ai aussi trouvé ce petit article très général mais qui montre la possibilité de lire le « message » RDS avec un ATMega mais qui n’apporte pas beaucoup de détails sur le montage et encore moins sur le code.
https://tekmanoid.com/rds
Christophe
-
Je pense cependant que le PT2579 (ou équivalent) est la piste à privilégier même si le composant est rare et que cela va s’amplifier. C’est malgré tout celle qui reste la plus simple pour arriver à un résultat selon moi et explorer ensuite de nouvelles directions mais à partir de résultats déjà existants.
Tout à fait d'accord. Tandis que selon les sources, certains de ces composants sont encore disponibles pour pas cher.
Ils avaient été spécialisés et améliorés pour une mise en oeuvre toute simple et sans nécessiter de réglages. Si on reconstruisait un vrai démodulateur AM "Double-sideband suppressed-carrier DSB-SC", ce serait très vite une usine à gaz, à la fois encombrante et difficile à reproduire.
J'ai fini par trouver enfin des traces de scope. Dans un article où précisément quelqu'un commençait à construire un démodulateur à transistors. Un autre lui répond: "il va te falloir une boite pleine de transistors." :)
Une modulation avec des délais courts, longs, courts, longs... la donnée PSK, à 1200 Baud. Normalement, un simple LM393 et un AVR peuvent recevoir et décoder cela. Mais il resterait un doute sur la polarité si on procédait de cette façon.
https://www.mikrocontroller.net/topic/319718
-
Juste 1200 Baud mais un sacré casse tête. Des délais courts ou longs... avec un AVR, comment savoir où sont les 1 et les 0?
La doc nous dit qu'il y a aussi changements de phase. Ajoute qu'il y a idle bits, préambule et une checksum.
Le préambule 010 (et les idle bits) devraient pouvoir permettre de se synchroniser... Sinon, il faudra un truc en plus pour détecter aussi les changements de phase.
C'est l'avantage de ces circuits spécialisés: ils s'occupent de tout.
-
certains de ces composants sont encore disponibles pour pas cher.
J'ai trouvé des LC72725KV chez Mouser. A ce jour, ils en ont un peu plus de 2000 en stock à 1,50€ pièce ce qui est très raisonnable. https://www.mouser.fr/ProductDetail/onsemi/LC72725KV-TLM-E?qs=y%252BJdrdj3vZrUHkd4SqtCFg%3D%3D&countryCode=DE¤cyCode=EUR&_gl=1*1q96xd3*_ga*MTAzODU3NzU0NC4xNzMzMzAzMTY5*_ga_15W4STQT4T*MTczMzMwMzE2OS4xLjAuMTczMzMwMzE3OC41MS4wLjA.*_ga_1KQLCYKRX3*dW5kZWZpbmVk (https://www.mouser.fr/ProductDetail/onsemi/LC72725KV-TLM-E?qs=y%252BJdrdj3vZrUHkd4SqtCFg%3D%3D&countryCode=DE¤cyCode=EUR&_gl=1*1q96xd3*_ga*MTAzODU3NzU0NC4xNzMzMzAzMTY5*_ga_15W4STQT4T*MTczMzMwMzE2OS4xLjAuMTczMzMwMzE3OC41MS4wLjA.*_ga_1KQLCYKRX3*dW5kZWZpbmVk)
Juste 1200 Baud mais un sacré casse tête. Des délais courts ou longs... avec un AVR, comment savoir où sont les 1 et les 0?
Je ne pense pas que la partie logicielle posera de gros problèmes. le codage est déjà bien documenté dans le document de Stefan Krauss https://www.skrauss.de/modellbahn/Trackprotocol.pdf (https://www.skrauss.de/modellbahn/Trackprotocol.pdf) à partir de la page 13 § 2.2.6 : Principle of feedback.
A mon retour, je fini le RMT (2 à 3 jours ) et je me mets sur le sujet.
Christophe
-
Bonjour,
J'ai même vu des puces à 0€50. Qui fait partie du casse tête: réaliser quelque chose qui ne ferait pas exploser le budget.
Vu la grosse doc du MFX, ce n'est pas un signal analogique à la sortie des décodeurs, mais bien des séries d'impulsions. De l'AM en mode ON/OFF, mais qui est donc manifestement compatible avec les puces spécialisées RDS. Un simple signal binaire qui doit être exploitable sans difficultés avec un LM393. Ce qui fait déjà deux composants avec un AVR.
Cette histoire de changement de phase à 57kHz m'ennuie plus. Pas sûr que l'AVR puisse facilement les détecter. Ca pourrait nécessiter des composants en plus pour envoyer une impulsion à l'AVR à chaque changement de phase. Peut-être un CD4046, une PLL. Ca ferait 3 composants déjà. On devrait pouvoir se passer d'une PLL si on se fie aux préambules 010 pour se synchroniser sur le flux de données, en ce cas, un LM393 et un AVR devraient suffir.
Ca devrait être facilement réalisable et codable pour le fun et pour approfondir la couche basse, ces signaux MFX/RDS. Puis pour ensuite tenter d'optimiser le nombre de composants.
Sinon, pour une détection d'occupation ou une localisation (sur Ack), comme il est possible de le faire avec Railcom (sans tout recevoir ni décoder), ce devrait être très simple. S'il y a des impulsions à 57kHz (détectable avec un LM393 et un banal circuit RC), il y a un décodeur sur la voie concernée.
-
J'ai trouvé des LC72725KV...
C'est excellent. Je viens de survoler la doc de cette puce, qui confirme qu'on peut se contenter d'un LM393 :)
Dans un récepteur radio FM, le signal RDS est analogique, susceptible d'être bruité. Tout une partie en entrée de ces puces sert à conditionner/filtrer ce signal analogique.... dans cette puce, ce signal analogique est ensuite envoyé vers un très simple comparateur. A la sortie de ce comparateur, du binaire, comme présenté dans la grosse doc MFX. Ou encore du binaire comme à la sortie d'un montage à LM393. Des salves, qui correspondent aux éléments binaires (séparés ou distinguables du fait des changements de phase).
Traiter de l'analogique aurait été beaucoup plus complexe.
Ils utilisent une PLL pour récupérer l'horloge, pour générer RDCL et pour décoder la data en étant synchrone.
C'est "juste" cette partie "décodage data en étant synchrone" qui sera à développer sur un AVR.
A mon retour, je fini le RMT (2 à 3 jours ) et je me mets sur le sujet.
On devrait donc prochainement avoir un résultat :)
Et à quelques unes de mes erreurs ou approximations près, désolé, l'essentiel sur la couche basse devrait être couvert par ce dont on a discuté ici.
-
Bonjour,
but now , I'm back , to let you now that :
1) sourcer ces ICs , c'est 0€39 , et il y en aura encre pour un moment : https://fr.aliexpress.com/w/wholesale-PT2579.html (https://fr.aliexpress.com/w/wholesale-PT2579.html)
2) décoder des signaux tels celui-ci preambule idle.JPG , il faut que je vérifie , j'ai peut-être une idée avec un STM32 : on utilise un module capture (yen a plein dedans) , et on configure son filtre digital de manière à ce qu'il ignore les impulsions courtes : on récupère les changements de phase , avec le temps qui les sépare ...
-
Bonsoir Marc,
Je me réjouis de ton retour.
Merci pour les liens sur les composants chinois. Pour les tests, j’ai préféré rester au large de ces composants pour ne pas ajouter à la complexité de mise au point une éventuelle défaillance des composants
Tu as vu que ce projet me tient particulièrement à cœur et ton aide s’ajoutant à celle de bk4nt serait particulièrement bienvenue.
Je crois que tu as du Marklin, je peux t’envoyer tous les composants au besoin. Idem pour bk4nt mais je crois comprendre qu’il est en DCC.
Je pense (mais je me trompe peut-être) que le traitement logiciel du signal n’est sans doute pas très compliqué. Peut-être faut t’il comme tu le notes un µC un peu puissant et disposant surtout des fonctions nécessaires comme le SMT32, mais c’est du traitement de signal et c’est tout de même connu et documenté.
Un oscilo est sans doute bienvenu (ce que je n’ai pas) pour connaitre précisément les spécificités du signal, ses niveaux, ses timing etc.. Mais encore une fois, ceci me semble bien documenté ici : https://www.skrauss.de/modellbahn/Trackprotocol.pdf à partir de la page 13 § 2.2.6.
Merci encore,
Christophe
-
Un oscilloscope basique devient vite inutile pour ce genre de projets car les signaux fluctuent tout le temps ou sont très éphémères. Tandis qu'un oscillo numérique avec la possibilité de faire des captures est plus cher.
Il y a plus utile pour ce genre de projets: un analyseur logique. On en trouve de bons à 150, à 50 et même à moins de 10 euro. J'ai fait beaucoup avec un OpenLogicSniffer qui m'avait coûté environ 50.
Ici, la présentation d'un "gadget" qu'on trouve pour pas cher (regarder à partir de 12 minutes 30 secondes pour l'utilité):
https://www.youtube.com/watch?v=Sxkm0U0PsQ4&t=750s
La seule difficulté pouvant être le déclenchement de la capture (ce qui est le cas aussi pour synchroniser un oscillo). Une broche d'un processeur/système sous test pouvant être dédiée à cela. Selon ce qu'on code, on ajoute une ligne pour que la broche change d'état au moment choisi: la capture se fait dans la foulée.
Sinon, pour un oscillo cheap, il y a des solutions aussi. Un simple petit dongle audio (carte son USB avec entrée micro) à 2€ fait l'affaire. Comme on travaille souvent sous 3 à 5V, ça peut suffire. La bande passante est alors limitée, à 20kHz (mais avec deux voies si l'entrée est stéreo). Associé à Audacity, on peut en faire des choses très sympa aussi.
Dernier élément qui complète un tel analyseur, un dongle audio ou même un vrai oscillo: un isolateur USB (encore un modèle pas cher). Car dans certains cas, raccorder la masse/0V d'un PC à la masse/0V d'un circuit peut provoquer des choses étranges.
Pour environ 20 euro, on peut ainsi avoir un équipement minimal pour y voir vraiment plus clair.
-
j'ai un oscillo qui m'a coûté 50€ chez Ali , il est USB , donc il faut l'écran du PC , très bien , mais en effet , il reste dans son carton ; il aurait été utile pour faire de la BF ...
par contre , l"analyseur logique à 10€ , je m'en sers systématiquement , parfois pour "programmer à l"analyseur" , cad. triturer le code jusqu'à ce que l"analyseur montre les bons signaux ... ... ou bien ajouter un truc du genre PINB0 = 1 dans la loop , pour vérifier que le programme n'accroche pas anormalement quelque part , car on peut avoir l'impression qu'il marche bien , alors qu'il y a un gros bug ...
pour l'analyseur , prévoir un large ruban de dupont à l'avance , car cette merdre se met à foirer dès qu'on l'a enfichée et défichée l'une ou l'autre fois
concernant mon idée de capture + filtre , ça marcherait , mais c'est pas assez robuste : on risque en effet de louper le point de changement de phase , s'il y a une perturbation juste à ce moment là , et du coup , l'ensemble du message serait peru . En fait , ce qu'il faut détecter , c'est ... le changement de phase , cad. on constate qu'il y a une certaine phase , puis on conste que la phase à changé : l'évaluation n'est pas critique , du temps qui s'est passé entre les 2 changements de phase ; une phase dure 9.5us , donc il faudrait échantillonner environ toutes les 2us , et mettre un peu d'intelligence , pour déterminer ce qui se passe.
Donc pour un AVR , ça va trop vite. Un STM32 , genre G030 à 64MHz , le fera facilement , et un Pi Pico , aussi , mais le cœur serait très chargé avec ceci : si l'autre cœur est accaparé par le CAN , on ne pourra plus lui faire faire grand-chose d'autre.
Quoi qu'il en soit , je vais ressortir un Pico , lui faire générer un tel signal sur une broche , et voir si j'arrive à le décoder sur la broche d'à côté
en fait la seule question , demeure le hardware pour la détection au niveau de la centrale
-
Bonjour,
but now , I'm back , to let you now that :
1) sourcer ces ICs , c'est 0€39 , et il y en aura encre pour un moment : https://fr.aliexpress.com/w/wholesale-PT2579.html (https://fr.aliexpress.com/w/wholesale-PT2579.html)
Concurrencer ces composants dédiés à moins de 0€50, on y arrivera pas. Il s'agit finalement plus d'un POC, Proof of Concept, ou d'un challenge: s'en passer (et au passage, en apprendre beaucoup sur MFX et l'encodage RDS).
Une solution hardware simple consisterait à utiliser deux bascules monostables redéclenchables à la suite du LM393: on aurait des impulsions sur les changements de phase. Ce serait plus espacé que des transitions à 57kHz. Mais ça fait trop de composants (l'espace que ça occupe sur un PCB).
Je ne sais pas ce que peuvent faire les STM32. J'ai regardé la datasheet du atmega328, un classique. Le noise canceler du timer 1 n'est pas souple du tout, il fonctionne à sysclock, c'est trop élevé pour pour filtrer ce signal "RDS".
J'en suis arrivé à me demander si un simple attiny85 pourrait suffire. Il intègre un comparateur analogique, on pourrait alors se passer du LM393. Ce tiny peut fonctionner avec un quartz à 20MHz, pour une horloge assez stable. Ce tiny pourrait être pas loin de pouvoir tout faire, puis de transmettre les données décodées à un ESP32.
-
oui c'est une option à creuser ;
pour ma part , je préfère utiliser des arduino tout faits , avec l'alim , le quartz , la liaison USB pour télécharger et déboguer ; la mise en oeuvre est immédiate
un STM32 a aussi au moins un comparateur ; j'utilise également des arduino équipés de clones d'AVR , (voir minievb) : ça ne coûte rien , ça pédale à 32MHz , il y a 2 comparateurs , dont les sorties sont accessibles , pour vérifier avec l'analyseur que le comparateur fonctionne bien
-
En fait , ce qu'il faut détecter , c'est ... le changement de phase , cad. on constate qu'il y a une certaine phase , puis on conste que la phase à changé : l'évaluation n'est pas critique , du temps qui s'est passé entre les 2 changements de phase ; une phase dure 9.5us , donc il faudrait échantillonner environ toutes les 2us , et mettre un peu d'intelligence , pour déterminer ce qui se passe.
Donc pour un AVR , ça va trop vite. Un STM32 , genre G030 à 64MHz , le fera facilement , et un Pi Pico , aussi , mais le cœur serait très chargé avec ceci : si l'autre cœur est accaparé par le CAN , on ne pourra plus lui faire faire grand-chose d'autre.
D'où l'idée d'un petit processeur dédié, qui ne s'occuperait que de cette tâche. Il n'aurait qu'à envoyer les messages décodés à la CPU "centrale", via un UART.
Échantillonner/évaluer à 2us fait faire beaucoup de travail? Une interruption sur up/down ou toutes les 9.5us pourrait suffire? Il s'écoulerait 19us au changement de phase. Ca ne laisse que peu de cycles d'horloge/instructions entre deux interruptions à 9,5us...
Pour une immunité au bruit, il faudrait comparer les phases à N-3 ou N-4, stockés dans une FIFO. Si un échantillon N est décalé de 19us comparé à N-4, il y a potentiellement eu changement de phase.
Si on a autre chose que 9.5 ou 19us, c'est du bruit...
Ca ferait faire tourner un timer à sysclok. A chaque interruption, lire la valeur du timer. Comparer la valeur lue à la valeur N-4. Pousser la valeur N dans la FIFO.
Si on a détecté 19us pour au moins 3 échantillons (sur 4 dans la FIFO), un changement de phase serait confirmé.
Si c'est exécutable en 9,5us, la taille de la FIFO pourrait même être augmentée, pour plus d'échantillons. Si ça peut fonctionner sur interruptions, c'est synchrone; mais le timer/sysclock va shifter très légèrement par rapport au signal reçu.
Ca pourrait être évalué à une fréquence plus basse que 52k63. Ca pourrait nécessiter un peu d’assembleur pour que ça rentre dans un AVR à 20 ou 16MHz.
Une fois un message reçu, il n'y a plus d'interruptions jusqu'au prochain. Il doit rester du temps libre pour le décoder, ce n'est pas un flux de data continu.
-
le principe de ce que je pense faire est le suivant :
- on ne s'occupe pas de l'impulsion de 19us en B , car celle-ci peut avoir été perturbée ; de même , une perturbation sur une impulsion de 9.5us pourrait nous faire croire qu'on est dans le cas B ; ce n'est donc pas la bonne solution
- ce que je propose , c'est d’échantillonner statistiquement en A , et d'en déterminer la phase ; de continuer (continuellement) l'opération , et de constater en C que la phase a changée ; une évaluation approximative du point de changement de phase suffit à déterminer le nouveau bit
alors à ce stade , je ne sais pas encore comment faire ; j'avais aussi pensé à échantillonner à 9.5us , mais si on se trouve près d'un flanc , et qu'on passe de l'autre côté parce qu'on est un peu moins rapide que l'émetteur , on verra un changement de phase erroné ...
-
La période A est une référence. Le changement de phase, ce n'est pas que B, d'une durée plus longue.
Par rapport à A, ce sont toutes les impulsions en C qui sont décalées de 9,5us, jusqu'au prochain changement de phase.
Et en effet, sur ce genre de projet, on est confronté au problème que pose la précision et la stabilité des quartz (ils ne sont pas pile à 10, 16 ou 20MHz, et leur fréquence fluctue tout le temps). Pour y palier en réception série, après le start, les UART font de l'oversampling.
Il faudrait plutôt un oversampling à 2,375us (9,5/4) ou 1,9us (9,5/5) pour rester à peu près en phase sur une période. Et de temps en temps, se resynchroniser, sur ce signal, il n'y a pas de start.
-
échantillonner statistiquement en A , et d'en déterminer la phase ; de continuer (continuellement) l'opération , et de constater en C que la phase a changée ; une évaluation approximative du point de changement de phase suffit à déterminer le nouveau bit
... mais si on se trouve près d'un flanc ... on verra un changement de phase erroné ...
Je pense qu'il faudra un mix car à cette vitesse, les glissements et instabilités d'horloges vont vite poser problème. De surcroît, si une CPU passe son temps à échantillonner/traiter, elle ne peut plus faire autre chose.
Des périodes avec un potentiel changement de phase, il n'y en a que peu, et il ne s'agit que d'environ 1000 ou 1200 baud:
- sur changement de phase détecté et confirmé, cesser d’échantillonner
- armer un timer, pour ne reprendre l'échantillonnage que peu avant un prochain potentiel changement de phase
- s'il n'y en pas pas, cesser d'échantillonner, réarmer le timer
timer, 10 échantillons, timer, 10 échantillons, etc, avec:
- au début, à la première détection du signal, juste armer un timer, pour ne commencer à échantillonner que plus tard
- à l'expiration du timer, utiliser une interruption (pin state change) pour d'abord se synchroniser sur ce signal, puis de là seulement commencer à échantillonner
Ce serait synchronisé à la fois sur les changements de phase, pour le timer, resynchronisé surtout sur le signal avant chaque courte période d’échantillonnage.
Ca libérerait plein de temps CPU. Et si c'est suffisamment synchrone, un unique échantillon par impulsion du signal pourrait suffire. Pour l'immunité au bruit, il devrait suffire d'échantillonner une dizaine d'impulsions, ou à peine plus.
Ca ferait utiliser un ou deux timers, un timer "phase change", un timer "bit sample", et utiliser des interruptions.
Régulièrement, avec un timer, une période d'échantillonnage du signal, on constate ou non un changement de phase:
-
alors à ce stade , je ne sais pas encore comment faire ;
Je finis par en être là moi aussi :(
Le bruit pouvant être un réel problème. D'autant plus que contrairement à DDC, avec MFX, les locos continuent d'être alimentées, si j'ai bien compris. Je n'ai aucune idée de ce que ce niveau de bruit pourrait être.
Les moteurs arrêtent de tourner pendant ce "moment RDS"? Ou du bruit/signaux de la consommation des locos (moteurs alimentés en PWM) peut-il se superposer au signal "RDS"?
Quoi d'autre pourrait être source de bruits, de courants susceptibles de perturber un récepteur à LM393?
Les puces spécialisées auraient là un gros avantage: elles filtrent, pour ne recevoir quasi que le signal "RDS" à 52.63kHz. Ce qui ne serait pas le cas avec un banal montage à LM393.
Or le montage à LM393 fonctionnerait. Et le montage avec un PIC qui peut détecter un "bit ack" n'a pas de filtres non plus.
Edit: je suis repartit dans la doc MFX... Qu'est-ce qu'ils entendent par "pause"? Tout doit s'arrêter, pour des feedback non perturbés?
Je note au passage qu'il s'agirait d'un changement de phase potentiel toutes les 912us. 48 x 19us. Ou 57k63 / 48, un équivalent 1096 potentiels changements de phase par seconde, c'est peu. 1096 / 16, 68 octet max par seconde? 1 à 4 (ou 8 ) octets par message? Ce sont des "pauses" de 120ms, pour jusqu'à 8 octets? Et pendant ce temps là, les moteurs ne tournent plus?
Faut que je me lance dans des tests. Doit pas y avoir besoin d'une bête de course pour recevoir/décoder cela.
-
Bonjour,
Je me réjouis une nouvelle fois que vous vous intéressiez à ce sujet. Je n’ai pas encore eu la possibilité de lire de façon très attentionnée tout ce que vous avez pu écrire mais j’ai compris (je me trompe peut-être) que vous semblez préoccupés par la stabilité ou la régularité du signal. N’est-pas justement l’intérêt du démodulateur (LC72725KV ou autre) ? N’est-ce pas lui qui doit faire le job et fournir sur ses sorties un « signal propre » qui pourrait facilement être interprété par un µC ?
Je vais avoir du temps à partir de maintenant pour faire le montage électronique et donc procéder à des tests.
Je ne dispose pas malheureusement de moyen d’analyser les signaux. Il faut pour cela que j’achète un analyser logique mais j’ai aussi regardé pour un oscillo numérique qui aurait pu me servir par la suite. Je ne trouver rien qui semble vraiment de qualité en début de gamme à moins de 300€. Un peu logique tout de même.
Mais j’ai vu ceci mais là pour le coup à moins de 150€, je me demande s’il n’y a pas un loup ? : https://fr.aliexpress.com/item/1005007466736772.html?src=google&pdp_npi=4%40dis%21EUR%21261.98%21130.99%21%21%21%21%21%40%2112000040875933031%21ppc%21%21%21&src=google&albch=shopping&acnt=248-630-5778&isdl=y&slnk=&plac=&mtctp=&albbt=Google_7_shopping&aff_platform=google&aff_short_key=UneMJZVf&gclsrc=aw.ds&&albagn=888888&&ds_e_adid=&ds_e_matchtype=&ds_e_device=c&ds_e_network=x&ds_e_product_group_id=&ds_e_product_id=fr1005007466736772&ds_e_product_merchant_id=5341269438&ds_e_product_country=FR&ds_e_product_language=fr&ds_e_product_channel=online&ds_e_product_store_id=&ds_url_v=2&albcp=19000274136&albag=&isSmbAutoCall=false&needSmbHouyi=false&gad_source=1&gclid=Cj0KCQiAgdC6BhCgARIsAPWNWH3rMinKw-Vy-cK4ch386OAOT02PWT5ubOSeM-idWcH087K62YIFAjMaAo1ZEALw_wcB (https://fr.aliexpress.com/item/1005007466736772.html?src=google&pdp_npi=4%40dis%21EUR%21261.98%21130.99%21%21%21%21%21%40%2112000040875933031%21ppc%21%21%21&src=google&albch=shopping&acnt=248-630-5778&isdl=y&slnk=&plac=&mtctp=&albbt=Google_7_shopping&aff_platform=google&aff_short_key=UneMJZVf&gclsrc=aw.ds&&albagn=888888&&ds_e_adid=&ds_e_matchtype=&ds_e_device=c&ds_e_network=x&ds_e_product_group_id=&ds_e_product_id=fr1005007466736772&ds_e_product_merchant_id=5341269438&ds_e_product_country=FR&ds_e_product_language=fr&ds_e_product_channel=online&ds_e_product_store_id=&ds_url_v=2&albcp=19000274136&albag=&isSmbAutoCall=false&needSmbHouyi=false&gad_source=1&gclid=Cj0KCQiAgdC6BhCgARIsAPWNWH3rMinKw-Vy-cK4ch386OAOT02PWT5ubOSeM-idWcH087K62YIFAjMaAo1ZEALw_wcB)
Peut-être avez-vous des pistes ou des conseils à me suggérer ?
Je renouvelle aussi ma proposition de vous fournir tous les composants si toute fois vous souhaitiez réaliser des tests de votre côté.
Merci encore pour vos réponses et pour votre aide.
Christophe
-
Bah alors, tu ne veux pas acheter de composants en Chine, mais t'es prêt à acheter un scope en Chine? :)
La seconde option, à peine plus chère, mais avec les 3 sondes, dont une à 100MHz (pour une bande passante plus élevée, des signaux rapides plus propres)?
Le même scope est aussi proposé/décrit ici,avec une vidéo: https://www.elektor.fr/products/fnirsi-1014d-2-in-1-2-ch-oscilloscope-100-mhz-signal-generator?srsltid=AfmBOor3TfcJSVhSO_4319m9tkQNdDay1CdK6pcfdW7t9r7SkDjOvjTw
Chez Elektor, c'est plus cher. Mais dans ce qui est inclu, il y a "2x Sondes oscilloscope (100 MHz)".
Après quoi, ce n'est plus qu'une question de prix et de délais de livraison. Seul soucis, ça ne fait que deux voies. Il pourrait être complété par un analyseur logique 8 voies à 10€.
Souvent l'ergonomie de ce genre de produits est critiquée. On le voit dans la vidéo de présentation, pour le réglage du générateur de signaux, c'est assez limité. Mais on fini par s'y habituer (et pour un tel prix, être content).
Single/Normal/Auto. Il n'a pas entrée "Synchro ext" sur l'arrière... Les options de synchro pourraient être limitées, genre une voie pour la synchro/déclenchement, une autre pour la capture. Mais Single doit permettre de faire une capture. 1 GSa/s, 240 Kbit de stockage... faut voir comment c'est réparti entre les deux voies et le générateur de fonction. Ca pourrait limiter les possibilités de "zoomer" dans une capture. C'est où un analyseur logique entrée de game pourrait compléter. Avec Export par port USB.
Il est alimenté par un bloc type USB 5V2A ou plus. On aime ou on aime pas. Il devrait être isolé de la terre, ce qui peut être un plus.
Faut voir ce qu'en pensent les gens sur Youtube, il pourrait s'agir d'un scope entrée de game pas cher et exploitable (avec une ou deux sonde à 100MHz pour plus propre lorsqu'il le faut).
https://www.youtube.com/results?search_query=FNIRSI+1014D
Sinon, oui, c'est clair, un LC72725KV ou autre simplifie tout. Ca envoie un signal Quality, la clock et la data au format série, il y a juste à faire du shift in. C'est moins intéressant à étudier :)
Et comme je le disais plus tôt, ces circuits spécialisés ont aussi un filtre en entrée, centré sur 52k63. S'il y a du bruit, une bonne partie sera filtrée et n'impactera pas la réception.
-
Oulala... mais non.
Là, vers la minute 2, on voit comment ce scope peut être limité. Mais ce qui est propre à ce genre d'appareils, à leurs méthodes d'échantillonnage de signaux cycliques: https://www.youtube.com/watch?v=sd_mHf-cwIA
Arrivé à la minute 3, il ajuste la base de temps et le signal affiché est alors normal. Ca pourrait poser un problème si on souhaite mesurer deux signaux aux formes et fréquences très différentes.
Ensuite, vers 3 minutes 30, il fait du zoom in avec son Rigol... et voit de petites fluctuations, je pense que c'est du bruit lié à l'appareil, que ce ne sont pas forcément des variations du signal mesuré.?
Vers la minute 5, il fait des captures avec le Rigol, le FNIRSI ne pourrait pas en faire... Ca compromettrait la capture et la lecture de signaux lents autour d'un Arduino. Ce qu'un analyseur logique à 10€ et en complément du FNIRSI pourra faire.
Mais passé la minute 5, il montre ce qu'on peut obtenir quand même avec un Arduino. Pas mal, la vidéo, qui reste courte et claire.
Vers la minute 9 à 10, les effets du raccordement à la terre ou au secteur d'un scope... Après quoi il change l’adaptateur secteur du FNIRSI.
Vers la minute 13, on comprend que le FNIRSI est un scope à 20MHz, pas 100. Ca limite, pour les signaux rapides.
Ni l'un ni l'autre appareil ne me semblent être mauvais. Ca nécessite simplement de s'adapter, d'adapter les réglages à ce qu'on souhaite mesurer et voir. Ou de s'adapter à ce qu'un appareil peut faire.
Ce Rigol est certainement plus utile. Mais il coûte le double.
-
Lui est encore plus critique, critique aussi envers ceux qui présentent ce scope comme étant une bonne affaire:
https://www.youtube.com/watch?v=yQKuHJELEOs
On y voit encore d'autres choses que ce scope fait mal ou curieusement comparé à ce qu'on peut attendre d'un tel appareil. Ou qu'on ne pourrait pas faire. Pour le même prix, il recommande plutôt de petits appareils portables (qui n'ont pas la même ergonomie du tout). Il n'est ni à 100MHz et vu les Lissajous, il n'est pas à 1Gsps non plus.
Dans la première vidéo, on voit en tous cas bien qu'un tel Rigol serait plus approprié à Arduino, pour facilement faire des captures puis zoomer. Le Rigol proposant plus d'options pour la synchro. S'il s'agissait du besoin, un Rigol (ou équivalent, il en existe) afficherait plus et mieux un signal MFX/feedback RDS.
-
J'ai voulu voir un peu d'une vidéo d'un gars qui l'apprécie. Lui, pour de l'audio, donc de 0 à 20kHz:
https://www.youtube.com/watch?v=1FknB71Nk5o
Ca m'a plus l'air d'un scope pour débutant/scolaire, pour faire des TP simples. Ou pour de l'audio, comme dans cet exemple. Vers la minute 5, on apprend que l'amplitude du générateur est fixe, et ne monterait même pas à 5V. Si on voulait envoyer un signal carré à un Arduino, il faudrait alors bidouiller d'abord...
Vu ces 3 vidéos, on sera très vite limité, voir déçu de ne pouvoir en faire plus.
-
Je ne dispose pas malheureusement de moyen d’analyser les signaux. Il faut pour cela que j’achète un analyser logique mais j’ai aussi regardé pour un oscillo numérique qui aurait pu me servir par la suite. Je ne trouver rien qui semble vraiment de qualité en début de gamme à moins de 300€. Un peu logique tout de même.
C'est pas mes sous... Et il est certain qu'on en fait déjà beaucoup avec un analyseur logique à 10 ou 50€.
Après avoir vu les 3 vidéos plus haut, va voir sur Youtube tout ce qui se dit en bien (et en mal) du DSO2D10 de Hantek, à 260€:
https://www.amazon.fr/Hantek-Num%C3%A9rique-Oscilloscope-Stockage-passante/dp/B08ML9RLFF
Il a plus de fonctionnalités, avec en plus, une entré Sync (ou sortie générateur de signal). Il pourrait être plus adapté, selon ses présentations:
" un oscilloscope économique à 2 canaux avec une bande passante de 100 MHz et un générateur de fonction intégré. Le DSO2D10 offre des options de décodage et de déclenchement comme I2C, SPI, UART/RS232 et CAN ... une fréquence d'échantillonnage de 1 GSa/s et une profondeur de mémoire de 8 Mpts"
Ou le DSO2C10, sans générateur de fonction, je suppose, 239€. En fouillant, on le trouve à 170€... Si le générateur de fonction s'avérait limité (ou inutile), ce modèle ferait aussi l'affaire.
Sa synchro évoluée pouvant à elle seule faire une réelle différence. Faut trouver une présentation pertinente sur Youtube avant de prendre une décision.
Je ne l'ai pas encore vue, je vais regarder cette présentation, longue, le type semble être lui-même être intéressé par les possibilités de décodage et de de synchro:
https://www.youtube.com/watch?v=Mmx7eo9STXE
-
Mais j’ai vu ceci mais là pour le coup à moins de 150€, je me demande s’il n’y a pas un loup ?
Bref, oublie le FNIRSI. Ou trouve en un d'occas et pour vraiment pas cher. Ce n'est pas pour nous car trop limité.
Les DSO2D10 ou la version DSO2C10 (sans AWG) semblent être plus intéressants, dans la même gamme de prix. Curieusement, il y a moins de vidéos pertinentes sur YT pour ces scopes là. Mais ils ont un vrai plus: 2 canaux ET une entrée sync, ainsi que plus d'échantillons, pour zoomer sur une capture.
Ceux là ne sont fournis que avec une sonde. Des sondes ou des Tektronix d'occas, on en trouve pour pas cher.
Il faut vérifier ses possibilités de déclenchement pour une capture, et les gadgets en plus qu'il propose.
https://www.youtube.com/watch?v=1i4MwPjQmrk
Edit: oh purée... FNIRSI 1014D contre OWON SDS1104 contre Hantek DSO2D10, ces scopes cheap. là encore, je ne l'ai pas vue. Je vais la regarder, ça dure une heure:
https://www.youtube.com/watch?v=iqfm1pN2Uac
-
Pour un scope pas cher, avec de la capture et du zoom in, normalement, c'est le DSO2C10 (2 canaux et une entrée Sync).
-
Je vais ajouter quelques lignes encore, pour ne pas vous faire acheter n'importe quoi.
J'ai vu des avis négatifs sur ces Hantek, et peu de revues concrètes sur YT. Quelqu'un aurait souhaité un remboursement et l'a retourné en Chine, du fait d'une anomalie: le scope a échoué bloqué en douane, en Chine... mais c'était il y a 3 ans, depuis, le sofware a pu évoluer.
Ca reste un scope pas cher. Autour d'un Linux; ça ne démarre pas instantanément, peu importe. Dans la longue vidéo, plus haut, le type tourne un bouton, on constate qu'il doit insister car le débounce est imparfait... Le type qui a retourné son scope en Chine constatait qu'il plantait systématiquement en captures à 8msps, il suspectait un problème hardware, de RAM.
Du Rigol ou équivalent serait plus cher. Sans l'AWG (tout le monde n'en a pas besoin), il est à partir de 239€ environ:
https://www.amazon.fr/Hantek-Num%C3%A9rique-Oscilloscope-Stockage-passante/dp/B08MLBBPYX?th=1
On peut le trouver à partir de 170... Mais je l'achèterais plutôt en France, pour la possibilité de le retourner dans les 14j (un mois chez Amazon) s'il ne répond pas aux besoins ou s'il ne fonctionne pas de façon satisfaisante. Au delà, acheté en France, on a une garantie de 2 ans. Il serait plus facile d'obtenir une réparation, un échange ou un retour.
Il n'est fourni que avec une sonde, mais avec un coax à croco aussi. Ca suffit pour tester ce scope. Une seconde et même une 3ième sonde pour la synchro ne coûtera pas très cher. Ce qui est fourni avec suffira amplement à le prendre en main avec un quelconque montage ou sketch Arduino qui fourni des signaux lents et rapides.
Pour faire quelques captures de signaux lents et rapides, à 1, 2, 4, 8MPS, avec des bases de temps différentes. Et faire des essais avec les différents modes de déclenchements/Sync. On attendrait d'un tel scope que ça fonctionne, sans trop de bugs ou de difficultés liées à l'ergonomie, et surtout que ça ne plante pas. On est vite fixé après quelques heures de prise en main et d'utilisation.
L'AWG serait pour moi un gadget. Avec de la PWM et un circuit RC, l'Arduino peut faire un minimum d'analogique, pour des tests du scope.
Vu la vidéo plus haut, la façon dont le décodage est affiché/défile, le décodage UART, I2C, ... pourrait être un gadget aussi. Un analyseur logique à 10€ en complément le fera mieux.
Si les parties scope 2 voies/capture de 1 à 8msps/zoom, la base de temps et la syncro (avec une entrée Ext Trig) fonctionnent normalement, ce genre de modèle économique pourrait convenir.
Dans la même gamme de prix, les autres scopes n'ont que deux voies, pas d'entrée Ext Trig, qui peut être un vrai plus.
PS: ça, je ne le recommande pas, avec ces Hantek, certains vont plus loin. Le software du modèle de base pourrait être upgradé pour activer l'AWG... Le hardware (notamment les faces avant) seraient les mêmes.
-
Perso , j'ai un Hantec , mais il n'a pas d'écran : USB vers le PC , donc moins cher et confort d'utilisation du 17" ... et comme il reste principalement dans son carton ,ben c'est juste un petit carton
-
Et tu en penses quoi pour ce que l'on fait ?
Il se connecte au PC mais existe t'il aussi les soft pour Mac. J'ai on PowerBook M2 ?
Je suis sur le point de me laisser tenter par le RIGOL Digital Oscilloscope DS1054Z : https://rigolshop.eu/product/oscilloscope/ds1000z/ds1054z.html
Tu as un avis ?
-
J'ai trop focalisé sur ces low cost :(
A moins de 300 encore, à 260€, il y aurait cette option DS1102Z-E à 2x100Mhz (plus Ext Trig) 24Msps, et avec aussi des possibilités de décodage:
https://rigolshop.eu/product-oscilloscope-ds1102z-e.html
Celui-ci sera sans AWG. Mais ce devrait un bon scope. Sur Rigol, les options tel que 24Msps ou le décodage sont en principe facturées. A ce lien, le tarif annoncé est avec les options incluses/offertes:
"Analog channel bandwidth: 100 MHz, 2 analog channel, 1 GSa/s, Memory depth up to 24 Mpts, Up to 30,000 wfms/s waveform capture rate, Trigger and Decoding options are permanent free installed, EU Cable. All options were preinstalled."
Ce qui fait finalement 3 options pour des entrés de gamme 2 canaux:
- le FNIRSI, peu cher, mais pas du tout conçu pour nous
- le Hantec, à 239, fourni avec une sonde, qui sera à compléter par deux sondes
- ce Rigol (ou son équivalent d'une autre marque), il faudra ajouter une sonde de plus pour Ext Trig
Mon choix se porterait évidemment sur le Rigol. On le trouve sur Amazon, avec deux sondes 150MHz et 3 ans de garantie:
https://www.amazon.fr/Rigol-Oscilloscope-Num%C3%A9rique-DS1102Z-d%C3%A9clenchement/dp/B089WHC4MK?th=1
Il n'y a pas de décodage/synchro CAN. S'il en faut, le Rigol sera à compléter par un petit analyseur logique.
Sur YT, les présentations de ce Rigol sont principalement en russe ou en espagnol...
Seul reproche que les gens font généralement aux Rigol, leur ventilateur. On l'oublie cependant vite, il n'est pas si bruyant que cela. Après quoi, les tarifs grimpent, notamment pour 4 voies.
Le DS1054Z repéré par Christophe n'étant qu'un 4 x 50MHz. Aussi avec options incluses. Mais qui pourrait suffire pour des signaux tel que UART, I2C, SPI jusquà 1Mbps. Les signaux trop rapides ne seront plus tout à fait carrés à l'écran. Du SPI à 10Mbps devrait être illisible.
Ext Trigger, attention: C'est, en théorie du niveau TTL (5V max). La doc Rigol affiche +/-4V pour les seuils de déclenchements.
Du coup, j'ai un peu pollué le fil, désolé. Mais ça devrait avancer ceux qui cherchent un scope pas cher mais utile.
-
Perso , j'ai un Hantec , mais il n'a pas d'écran : USB vers le PC , donc moins cher et confort d'utilisation du 17" ... et comme il reste principalement dans son carton ,ben c'est juste un petit carton
Pour l'application de Christophe, un scope 2 ou 4 voies pourrait être utile. Un analyseur logique ne traite que des signaux numériques type 3.3V ou 5V.
Seul un scope permettra de voir correctement un signal de retour à l'entrée d'un LC72725KV ou d'un LM393, de l'équivalent analogique à des niveaux faibles. La ou les autres voies du scope permettant de voir la data/clock RDS décodés, une 4ème pouvant capturer ce qui passait coté DCC. Le tout simultanément, sur le même appareil et écran.
Un Hantec ou un Rigol permettent ensuite de "zoomer" sur les captures. Ce que le FNIRSI ne permet pas.
Pour un mix analogique/numérique ou même pour regarder de plus près des signaux bruités, ou occasionnellement bruités, un tel scope sera incontournable.
Après, en effet, il pourrait rester dans son carton jusqu'à ce qu'on lui trouve une nouvelle utilité. Si on bricole assez, dont avec de petits signaux, il restera à portée de main.
-
alors à ce stade , je ne sais pas encore comment faire ;
Je finis par en être là moi aussi :(
Le bruit pouvant être un réel problème. D'autant plus que contrairement à DDC, avec MFX, les locos continuent d'être alimentées, si j'ai bien compris. Je n'ai aucune idée de ce que ce niveau de bruit pourrait être.
c'est aussi ce que j'ai cru comprendre , ça s'ajoute ou se retranche , c'est le changement de phase qui importe ; ce qui m'interroge , c'est que du coup , le signal émis va se courber , en débitant sur tous les récepteurs du secteur ...
Les moteurs arrêtent de tourner pendant ce "moment RDS"? Ou du bruit/signaux de la consommation des locos (moteurs alimentés en PWM) peut-il se superposer au signal "RDS"?j'en ai bien peur
Quoi d'autre pourrait être source de bruits, de courants susceptibles de perturber un récepteur à LM393?
pratiquement pas de liste exhaustive sur un réseau de MF
Les puces spécialisées auraient là un gros avantage: elles filtrent, pour ne recevoir quasi que le signal "RDS" à 52.63kHz. Ce qui ne serait pas le cas avec un banal montage à LM393. le transfo et le condensateur constituent un certain filter ...
Or le montage à LM393 fonctionnerait. Et le montage avec un PIC qui peut détecter un "bit ack" n'a pas de filtres non plus.
Edit: je suis repartit dans la doc MFX... Qu'est-ce qu'ils entendent par "pause"? Tout doit s'arrêter, pour des feedback non perturbés?
Je note au passage qu'il s'agirait d'un changement de phase potentiel toutes les 912us. 48 x 19us. Ou 57k63 / 48, un équivalent 1096 potentiels changements de phase par seconde, c'est peu. 1096 / 16, 68 octet max par seconde? 1 à 4 (ou 8 ) octets par message? Ce sont des "pauses" de 120ms, pour jusqu'à 8 octets? Et pendant ce temps là, les moteurs ne tournent plus?
Faut que je me lance dans des tests. Doit pas y avoir besoin d'une bête de course pour recevoir/décoder cela.
-
Perso , j'ai un Hantec , mais il n'a pas d'écran : USB vers le PC , donc moins cher et confort d'utilisation du 17" ... et comme il reste principalement dans son carton ,ben c'est juste un petit carton
Pour l'application de Christophe, un scope 2 ou 4 voies pourrait être utile. Un analyseur logique ne traite que des signaux numériques type 3.3V ou 5V.
Seul un scope permettra de voir correctement un signal de retour à l'entrée d'un LC72725KV ou d'un LM393, de l'équivalent analogique à des niveaux faibles. La ou les autres voies du scope permettant de voir la data/clock RDS décodés, une 4ème pouvant capturer ce qui passait coté DCC. Le tout simultanément, sur le même appareil et écran.
(...)
il s'agit bien d'un scope , qui me semble-t-il existe aussi en 4 voies .. mais je crains qu'en effet , il ne marche que sur PC W
je suis sur W , car j'ai toujours eu des choses (HW et SW) qui ne marchent que sous W
-
Je pense aussi que le LC72725KV doit grandement simplifier le boulot (filtrage etc...) C'est normalement pour cela qu'il y a un composant dédié.
Par ailleurs tout est bien documenté sur les alternances, les durées... dans ce que je vous ai mis en ligne. Aussi je pense qu'avec un oscillo tout ceci va être beaucoup plus facile à comprendre et à régler.
Comme il faut bien se décider alors je vais prendre le RIGOL DS1054Z sur Amazon même si j'évite en générale. Il y est un peu moins cher qu'en achat direct (va comprendre) et surtout je peux le retourner jusqu'au 31 janvier !!!
Au besoin, on peut acheter par la suite l'upgrade en 100Mhz si besoin un jour mais pour ce que j'ai à faire 50MHz suffiront mais les 4 voies vont surement se révéler les bienvenues pour superposer les différents signaux
https://www.amazon.fr/Oscilloscope-num%C3%A9rique-d%C3%A9clenchement-d%C3%A9codage-gratuits/dp/B01N76DEFX/ref=sr_1_5?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=3TSDEWAACRBHE&dib=eyJ2IjoiMSJ9.0qXc377_unoj9xpItWu7Ey3YyrI_rBXMFkJz0Ro5MuMW_NdOc78V168t2F0tKvD1tFRZC0Rc9ZsFpeSzwR4oxBjX61Nj0z9STTRHkzKgDvCoRvA-qTNeVSUCVyErq8tdycUOmYDQUQIXiOomg9RypAMMIfQNsv47Z0t3qeXkTjN6oWYS_tVK43IJO0T0HBb-kOewOXQieTPCH_ynnICynkD-E4S5UAWoAPFeOV2pDbE9GLooKympV8RXjWmnf-jCH7-ZkSCgkoMKv3XYbDMDPAXlDXHTP3icO-Ds68IuVd4.omlzWuAoEXcSCRiPq2m086pVziMVnLIElxoZGQUjIs0&dib_tag=se&keywords=RIGOL%2BDigital%2BOscilloscope%2BDS1054Z&qid=1733694214&sprefix=rigol%2Bdigital%2Boscilloscope%2Bds1054z%2Caps%2C659&sr=8-5&th=1 (https://www.amazon.fr/Oscilloscope-num%C3%A9rique-d%C3%A9clenchement-d%C3%A9codage-gratuits/dp/B01N76DEFX/ref=sr_1_5?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=3TSDEWAACRBHE&dib=eyJ2IjoiMSJ9.0qXc377_unoj9xpItWu7Ey3YyrI_rBXMFkJz0Ro5MuMW_NdOc78V168t2F0tKvD1tFRZC0Rc9ZsFpeSzwR4oxBjX61Nj0z9STTRHkzKgDvCoRvA-qTNeVSUCVyErq8tdycUOmYDQUQIXiOomg9RypAMMIfQNsv47Z0t3qeXkTjN6oWYS_tVK43IJO0T0HBb-kOewOXQieTPCH_ynnICynkD-E4S5UAWoAPFeOV2pDbE9GLooKympV8RXjWmnf-jCH7-ZkSCgkoMKv3XYbDMDPAXlDXHTP3icO-Ds68IuVd4.omlzWuAoEXcSCRiPq2m086pVziMVnLIElxoZGQUjIs0&dib_tag=se&keywords=RIGOL%2BDigital%2BOscilloscope%2BDS1054Z&qid=1733694214&sprefix=rigol%2Bdigital%2Boscilloscope%2Bds1054z%2Caps%2C659&sr=8-5&th=1)
-
...
Les puces spécialisées auraient là un gros avantage: elles filtrent, pour ne recevoir quasi que le signal "RDS" à 52.63kHz. Ce qui ne serait pas le cas avec un banal montage à LM393. le transfo et le condensateur constituent un certain filter ...
...
Les filtres de ces puces ont été développés dans les années 90. Ils sont sans rapport avec un simple transfo suivi d'une capa. Et reproduire un tel filtre ne serait pas simple... Je n'ai rien trouvé d'équivalent dans le commerce qui soit cheap.
Ce qui contraindrait donc de les utiliser, pour l'immunité au bruit. Vu qu'on en trouve encore facilement, ce n'est donc pas un problème.
The design of an 8th order switched-capacitor bandpass filter centered at 57kHz with 3kHz bandwidth and linear phase characteristics in the passband is reported. Four biquads are cascaded and operated at 4.332 MHz with double-sampling technique. The group delay performance have been analyzed via Monte Carlo simulations: there results an expected mean value of 230 μs with 2.9 μs standard deviation, using a unit capacitor statistic with 0.15% relative standard deviation. The filter is a basic circuit for an RDS integrated decoder and is realized in high performance BiCMOS technology. https://ieeexplore.ieee.org/document/5467751
-
mais les 4 voies vont surement se révéler les bienvenues pour superposer les différents signaux
Je continue à lire. Ton 4 voies et avec un lc72725 va vite s'avérer utile et "bavard".
Tu vas vite voir si ton signal sur MPXIN est au bon niveau (l'amplitude) ou s'il faut que tu modifies le circuit entre le transfo de courant et ton lc72725.
Après quoi tu vas pouvoir nous dire quelle est l'efficacité de ce filtre et s'il est utile: si tu vois ou non du bruit sur MPXIN (mix RDS/PWM des moteurs, etc), et quelle est la différence du signal après le filtre, sur FLOUT. Sur FLOUT, il ne devrait plus y avoir grand chose d'autre que le RDS.
Avec juste deux voies, on pourrait très bien le faire aussi, en avançant étape par étape ou étage. 4 voies seront plus efficaces, sur un tel cas, on voit tout en même temps.
Avec un analyseur logique seulement, on serait limité. On ne pourrait le brancher que à RDDA et RDCL (peut être à FLOUT, mais avec du bricolage...). En l'absence de signal, on ne pourrait pas faire de diagnostics autour d'un tel circuit, pas si facilement. Et si signal, on aurait aucune idée de ceux sur MPXIN et FLOUT (amplitudes et niveaux de bruits).
-
...
Ils sont sans rapport avec un simple transfo suivi d'une capa. Et reproduire un tel filtre ne serait pas simple... Je n'ai rien trouvé d'équivalent dans le commerce qui soit cheap.
Ce qui contraindrait donc de les utiliser, pour l'immunité au bruit. Vu qu'on en trouve encore facilement, ce n'est donc pas un problème.
...
mais il faudra quand-même des condensateurs , et le transfo , et le capot du transfo , et le quartz , etc. ... le BOM ne sera pas des + simples
-
Qu'on ait 10 ou 20 composants n'est pas un problème.
Ces circuits spécialisés ont été conçus pour décoder le RDS depuis MPXIN et sans aucun règlage à faire. Le signal MPXIN devant avoir une certaine amplitude, à déterminer, ça devrait être précisé dans la datasheet de la puce utilisée.
Le transfo sert à l'isolation galvanique, et à amplifier un peu le signal des locos. Entre le transfo et MPXIN, il faudra quelques composants, un montage à déterminer, pour que ça puisse bien fonctionner et sans réglages non plus. Ce sera la partie la moins simple de la solution.
Christophe a trouvé un schémas en page 1 dont il est possible de s'inspirer. En page 1, il a aussi ajouté une photo d'une centrale et de ses composants "RDS". On peut constater qu'il n'y a pas besoin de faire de réglages... ce qui serait l'idéal pour la solution.
Il faudra pour cela assez bien connaître les signaux depuis les locos jusqu'à MPXIN, leurs amplitudes et les tolérances acceptables. Là encore, un scope sera utile, pour vérifier que le montage fonctionne bien comme voulu.
-
On peut en savoir plus, sur cette centrale? Quelqu'un l'a ouverte et étudiée?
Je me demande encore si pendant "pause" les moteurs/PWM sont actifs ou non... Ainsi que comment un montage à simple comparateur LM393 pourrait fonctionner s'il y a plein de bruit pendant la "pause". Je n'ai rien trouvé à lire à ce sujet dans la grosse doc MFX.
En jaune, à droite, c'est un transfo de courant fréquences élevées, pour le 52kHz? Le second truc au milieu, à 3 pattes, probablement deux diodes pour écrêter à +/- 0,7V. Le truc à 6 pattes pourrait être un ampli op ou aussi un simple comparateur. Autour du PT, il ne doit s'agir que des composants recommandés par sa doc (avec peut être une ou deux différences, dont le quartz 4MHz, pour s'adapter à 52kHz au lieu de 57).
L'autre solution trouvés par Christophe me parait clair. Je me demande si D8 à 10 sont vraiment utiles, le montage tout simple à LM393 s'en passe... TR1, 1:100, suivi de R1/R2, un atténuateur. D1/D2 pour que ça ne dépasse jamais 0,7V; R1 limite le courant dans les diodes. C1/R3, un filtre passe haut, ça va atténuer le signal DCC à 4/8kHz, un peu atténuer aussi le 52kHz. Les valeurs R1/R2 et C1/R3 ont pu être choisies pour un signal RDS en sortie de +/-0,5V...
S'il y a du bruit pendant la "pause" lié aux moteurs/PWM dans ce genre de montages, une partie des signaux RDS devrait être "polluée".
-
Je crois que la centrale avec une puce PT présentée en page une est une Mobi v1 de 2004 (20 ans!). On y voit bien la puce RDS et un petit transfo.
Dans la manette V2 (quelqu'un l'ouvre sur YT, démonte tout), on ne voit plus ce composant RDS. Mais la manette Mobi v2 est associée à un petit boîtier noir sur lequel on peut brancher 2 manettes. Ce petit boîtier noir: une sorte de centrale à deux manettes Mobi v2? C'est mal documenté, j'ai eu un mal fou à trouver ce que ce petit boîtier noir pourrait contenir.
Dans ce petit boiter noir (un mini booster 1A?), il pourrait encore s'y trouver une puce RDS (l'énorme truc des années 90 avec un gros quartz à côté). Et encore un SOT23-5 ou 6... un composant qui m'intrigue. Je n'y vois par contre pas de petit transfo, pas sur les photos que je trouve. Je n'y vois même pas de diodes. C'est curieux.
Je viens de commander un set pour l'ouvrir. "motorola / mfx / DCC", je suppose que c'est bien un pack avec un feedback RDS.
-
Le composant RDS est encore bien présente dans les centrales Marklin, cette photo que j'ai déjà publiée est l'intérieur de ma MS2 que j'ai achetée il y a 1 an
(https://media.3rails.fr/optimized/3X/9/1/915037b77a2cd81056eab186f23bdd97e5b31813_2_650x500.jpeg)
-
Le problème de petits CMS tel que ce "3Ft" en 3) est qu'il est compliqué de deviner leur référence... Et il n'y a donc pas de transfo de courant pour le feedback? Dans la MS1, on peut en deviner un...
En 1), le pont en H, des Mosfet en SOIC8, avec de grandes surfaces à droite à gauche pour leur refroidissement. 2, la sonde de courant du pont. 6), le processeur, pour lequel Google me propose ce PDF: https://www.silabs.com/documents/public/data-sheets/C8051F50x-51x.pdf
4) ce CD4555 avec 5) est étrange aussi. On sait quelle est l'utilité de 5)?
-
Pour 3, effectivement il n'est indiqué sur le composant que 3Ft
-
Voici la zone 5 en gros plan. Ce n'est pas lisible ici mais c'est indiqué K46 sur les composants
-
D'après Google, K46 pourrait être des diodes, 3Ft un transistor, j'y crois moins. 3Ft ne sont peut être que des diodes aussi.
Comme on ne connaît pas ces composants, il y aurait à dessiner les schémas de ces parties (en suivant les pistes, etc) pour essayer de cerner mieux ces fonctions et ce que sont réellement ces composants.
Et sur ce cas de la MS2, suivre un peu les pistes pour comprendre comment le feedback RDS arrive au PT. Il doit s'agir d'un circuit imprimé 2 couches seulement et dont on connaît déjà une bonne partie (le pont en H, le PT, le processeur, les alims...), c'est donc encore assez facile à faire.
Une fois qu'on a le schémas ou une ébauche, un scope peut être utile pour en savoir plus.
J'ai vu passer cette info aujourd'hui. Un gars a décortiqué une PlayStation pour l'étudier et dans le but d'en reconstruire une:
https://hackaday.com/2024/12/09/playstation-motherboard-sanded-and-scanned-but-theres-more-to-do/
https://github.com/LawrenceBrode/playstation.uno
Je vais cependant essayer de ne pas casser ce booster/centrale :)
-
Mais pourquoi ce schéma que j'avais déjà publié ne te satisfait-il pas ?
J'ai commandé tous les composants pour le reproduire. Par ailleurs, j'ai commandé aujourd'hui l'oscillo. Avec ce montage et l'oscillo on devrait y voir clair, non ?
-
C'est juste par curiosité, pour comprendre mieux comment ces différentes solutions fonctionnent ou non.
Ou encore pour comparer et voir comment ce simple montage autour d'un LM393 pourrait être approprié ou non. Même si on a conclu qu'un montage à PT le fera plus efficacement, notamment du fait de son filtre intégré 52k.
Ou encore par curiosité, pour voire quelle est la nature des bruits (s'il y en a) durant la période "feedback RDS".
Tu as pris quoi pour le transfo de courant? Les plus classiques pourraient ne pas fonctionner, leur bande passante étant limitée. C'est pourquoi j'ajoutais quelques mots sur le transfo de la MS1, un modèle susceptible d'avoir une bande passante de 20kHz à 1MHz, donc adapté à 52kHz.
Comme il est utile à l'isolation galvanique, et que je n'en ai pas repéré sur les photos MS2, je me demande comment cette dernière est fichue...
Sinon, si le simple montage à LM393 fonctionne, il pourrait servir à réaliser un détecteur de présence pour les cantons très économique (signal oui ou non pendant la période feedback).
-
1:1000 de chez AliEx
-
En tous cas, je n'ai pas l'intention de "concurrencer". Tandis que la détection de présence dans les cantons m'intéresse aussi.
Si ça peut fonctionner, ce ne serait alors qu'un montage tout simple, en mode on/off, pas un décodeur RDS:
-
1:1000 de chez AliEx
J'ai regardé vite fait... On n'en voit pas les spécifications. Ce genre de modèles (leurs ferrite) est normalement optimisée pour fonctionner à 50/60Hz AC. A 52kHz, leur fonctionnement pourrait être aléatoire, selon la source, selon le modèle.
La première image incluse est de chez Farnel, pour "transformateur SMPS 50kHz". Il doit en exister aussi chez Ali. Idéalement, il faudrait choisir un modèle avec une référence, pour pouvoir commander exactement le même.
Ce genre de transfo serait optimisé pour fonctionner à 52kHz et aiderait à garantir la reproductibilité du montage (sans ajustement des valeurs de composants entre le transfo et le PT).
La seconde image est de chez Alibaba. Même chez Farnel, on aurait à bien vérifier la plage de fréquence...
-
Plutôt "à partir de 20kHz", qui inclue 52kHz. Je pense que ce serait plus facilement reproductible, avec une liste de composants et sans aucun ajustement.
Ce n'est pas le même tarif qu'un banal "transformateur de courant". C'est bien ce genre de transfo qu'on voit sur la MS1.
-
En plus je me suis trompé, ce n'est pas 1:1000 dont on a besoin mais 1:100.
Celui-ci semble bien correspondre en effet :
(https://ae01.alicdn.com/kf/S58e2530ede0a4286af17d82db051efc53.jpg)
https://fr.aliexpress.com/item/1005004278061067.html?spm=a2g0o.productlist.main.3.4ff8nftCnftCzf&algo_pvid=ebf5e02f-f182-4d06-b978-17b55922d75b&algo_exp_id=ebf5e02f-f182-4d06-b978-17b55922d75b-1&pdp_npi=4%40dis%21EUR%2112.89%217.09%21%21%2113.29%217.31%21%40211b81b117338616422331175e948d%2112000028604321628%21sea%21FR%212059547165%21X&curPageLogUid=abUQ9p7z4LaG&utparam-url=scene%3Asearch%7Cquery_from%3A (https://fr.aliexpress.com/item/1005004278061067.html?spm=a2g0o.productlist.main.3.4ff8nftCnftCzf&algo_pvid=ebf5e02f-f182-4d06-b978-17b55922d75b&algo_exp_id=ebf5e02f-f182-4d06-b978-17b55922d75b-1&pdp_npi=4%40dis%21EUR%2112.89%217.09%21%21%2113.29%217.31%21%40211b81b117338616422331175e948d%2112000028604321628%21sea%21FR%212059547165%21X&curPageLogUid=abUQ9p7z4LaG&utparam-url=scene%3Asearch%7Cquery_from%3A)
Sans toi je serai bien mal barré !
Christophe
-
Mes cours de techno et de physique/magnétisme/propriétés des matériaux sont très lointains. Et je n'ai pas réussi à trouver quoi que ce soit de limpide à ces sujets sur le net. Ce sont des composants complexes qui moi-même me dépassent.
On peut faire des bobines et même des transfos dans l'air (de l'air). Dans les transfos (ou même dans des bobines, des selfs, des inductances), plutôt que de l'air, on utilise des matériaux pour optimiser leurs performances. Ces matériaux ayant des propriétés magnétiques.
Ces matériaux (du fer, ou des ferrites, ce autour de quoi il y a les enroulements) servent à transférer l'énergie dans un transformateur, d'un enroulement à l'autre. Ou servent à emmagasiner l'énergie et à la restituer pour une inductance. Si ces matériaux sont inappropriés à l'utilisation (la plage de fréquence d'utilisation), ou si la solution est mal dimensionnée (la puissance à transmettre), il y aura des pertes, ou une saturation, magnétique, ça ne fonctionnera pas comme attendu.
D'où cette suggestion d'utiliser un petit transfo optimisé pour des fréquences à 20kHz au moins et plus, une référence qui couvre le besoin: 52kHz. Au final, et avec une liste de composants précise, la solution devrait être fiable et reproductible. La ref repérée supporte 10A (20 max), avec une très faible perte (des mili Ohms), ça semble être approprié aussi.
Avec un transfo banal et quelconque conçu pour 50Hz, on pourrait toujours bidouiller, obtenir quelque chose qui fini par fonctionner à 52kHz quand même. Mais rien ne garantirait que ça fonctionnerait avec un autre modèle/matériaux de transfo 50Hz.
-
Bonjour,
J’ai commandé le transfos 1 :100 ci-dessus. Comme je dispose de tous les autres composants et que je devrais recevoir l’oscillo sous quelques jours, j’espère pouvoir commencer les tests semaine prochaine.
En attendant, j’ai essayé d’imaginer ce que serait la partie logicielle car, sur ce point, je n’ai trouvé aucune publication. Je suis plus ici dans ma "zone de confort"
Si je n’ai pas trop de mal à voir comment exploiter les sorties RDCL, QUAL et RDDA, je ne comprends pas trop le rôle du LM311. A priori, il renvoi un on/off (0 ou 1) quant à la présence d’un signal RDS. Mais le signal d’horloge devrait suffire, bon !
Voici donc un exemple de code qui me semble t’il devrait permettre de lire et exploiter les infos de retour. Vos remarques sont les bienvenues.
#include <Arduino.h>
// Broches GPIO sur l'ESP32 pour les signaux RDS
#define RDDA_PIN 27 // Broche pour les données RDS
#define RDCL_PIN 26 // Broche pour l'horloge RDS
#define QUAL_PIN 25 // Broche pour la qualité du signal RDS
// Variables pour stocker les données RDS
volatile uint8_t rdsData[64]; // Tampon pour 64 bits de données RDS
volatile uint8_t bitIndex = 0; // Index pour les bits reçus
// Interruption sur l'horloge RDS (RDCL)
void IRAM_ATTR onRDSClock() {
// Lire le bit de données sur la broche RDDA
uint8_t bit = digitalRead(RDDA_PIN);
// Stocker le bit dans le tampon
rdsData[bitIndex / 8] <<= 1; // Décaler les bits existants
rdsData[bitIndex / 8] |= bit; // Ajouter le nouveau bit
bitIndex++;
// Réinitialiser l'index si 64 bits sont lus
if (bitIndex >= 64) {
bitIndex = 0;
}
}
// Fonction pour afficher les données RDS
void displayRDSData() {
Serial.print("RDS Data: ");
for (int i = 0; i < 8; i++) { // 64 bits = 8 octets
Serial.printf("%02X ", rdsData[i]);
}
Serial.println();
}
// Setup
void setup() {
Serial.begin(115200);
pinMode(RDDA_PIN, INPUT);
pinMode(RDCL_PIN, INPUT);
pinMode(QUAL_PIN, INPUT);
// Attache l'interruption sur l'horloge
attachInterrupt(digitalPinToInterrupt(RDCL_PIN), onRDSClock, RISING);
Serial.println("RDS Decoder Started");
}
// Loop
void loop() {
// Vérifier si le signal RDS est présent via la broche QUAL
if (digitalRead(QUAL_PIN) == HIGH) {
displayRDSData(); // Afficher les données RDS collectées
} else {
Serial.println("No RDS signal detected");
}
}
-
A mon avis, le LM311 ne sert pas à grand chose puisqu'on a déjà RDCL/DA et QUAL...
Le LM311 informe qu'il existe ou non un signal à 52kHz. En ce cas, s'il n'y a rien en RDCL, on en déduira que le signal RDS n'est pas exploitable, ou qu'il est trop bruité.
Avec un Arduino, tu pourrais injecter du simple 52kHz en entrée du PT, sans changement de phase; le LM311 le détectera, mais comme il ne s'agirait pas de RDS, le PT ne décodera rien (RDCL/DA et QUAL à 0).
Le LM311 pourrait servir à du debug ou pour évaluer le fonctionnement de l'ensemble? Sur un PCB final, si ça ne sert à rien, ces composants pourraient ne pas être soudés, ou soudés de façon optionnelle.
QUAL est peut être inutile aussi, pourrait fonctionner en on/off sur ce genre d'application. Dans une radio, ça peut indiquer un signal dégradé même si on a des signaux RDCL/DA...
S'il y a du bruit après le filtre passe bande 52kHz (dans cette application, un bruit à 52kHz lié aux PWM des moteurs, etc) en plus du signal RDS, QUAL pourrait l'indiquer...
Quelques essais confirmeront si ce LM311 et QUAL sont utiles ou non (potentiellement des entrées ESP économisées, ou cablées/soudées de façon optionnelle).
On a encore un autre indicateur: la checksum des data RDS reçues, elle sera valide ou non en cas d'erreur de transmission (du bruit dans le message).
Et je pense qu'il serait possible de se passer du quartz 4MHz, c'est ce que suggère la datasheet du SC6579. La datasheet du PT que j'ai à ce sujet est trop sommaire. L'ESP pourrait alors générer une PWM/clock à 4MHz pour Clock in. Ca se fait sur certaines applications, pour moins de composants, s'il y a des broches CPU libres, et s'il est simple de générer une clock. Ca pourrait aussi être prévu de façon optionnelle sur un PBC final, avec au choix un quartz ou un signal 4MHz généré par l'ESP.
-
Je suis assez d'accord avec toi sur le rôle du LM311. Je verrai cela de toutes façons au cours des tests.
Pour le quartz, tu as raison de dire qu'un signal envoyé par le µC peut jouer le même rôle. C'est ce que j'ai fait avec le Raspberry PI Pico et son tranceiver CAN sur les conseils de Jean-Luc et ça fonctionne bien.
Bon, il n'y a plus qu'à... quand je vais avoir tous les composants.
Christophe
-
J'en conclue que tu pars donc sur ce genre de montage.
A mon avis, les 4 diodes à l'entrée sont inutiles, n'introduisent qu'une chute de tension (le seuil des diodes).
En entrée de TR1, on aura du DCC/PWM ou du RDS, le feedback, pendant la pause DCC.
Ce signal RDS, ce seront des impulsions positives ou négatives, selon l'orientation des locos/décodeurs. En quelque sorte, un signal RDS (52kHz avec changement de phase) avec une composante continue positive ou négative.
C1 (et C3 aussi) va éliminer la composante continue. Seul le signal RDS va passer après C3. Qu'il y ait ces 4 diodes ou non.
L'impédance au primaire de TR1 sera quasi nulle, et sans ces diodes, la chute de tension introduite sera donc nulle également.
-
J'en conclue que tu pars donc sur ce genre de montage.
Oui
A mon avis, les 4 diodes à l'entrée sont inutiles, n'introduisent qu'une chute de tension (le seuil des diodes).
Si je ne m'abuse, ces diodes forment un pont redresseur, non ? Et elles n'ont qu'une faible chute de tension puisqu ce sont des Schottky.
-
Si je ne m'abuse, ces diodes forment un pont redresseur, non ? Et elles n'ont qu'une faible chute de tension puisqu ce sont des Schottky.
Oui, mais à quoi il sert? :)
-
B'hein je ne te comprends pas bien. A minima, elles évitent les courts-circuits entre les rails.
-
Euh... qu'on soit d'accord, c'est pas du tout fait pour être branché sur "les rails" ...
J'imagine que c'est pensé pour être branché sur le fil d'un rail, pour en capter le courant, le courant qui circule quand le décodeur envoie son feedback.
Je dis qu'on peut se passer de ces diodes:
- Centrale, fil A, rail A
- Centrale, fil B, TR1 a, TR1 b, rail B
Où serait le risque de court-circuit? Et l'utilité d'un pont de diodes?
-
Ok tu dis que l'un seulement des fils de la central passe dans la primaire de la bobine. Centrale, fil A, rail A. C'est assez logique en effet. Par contre je ne comprends pas ce que tu veux dire par Centrale, fil B, TR1 a, TR1 b, rail B
Pour moi TR1 c'est le secondaire, comment pourrait il être relié au rail B ?
-
Ok tu dis que l'un seulement des fils de la central passe dans la primaire de la bobine. Centrale, fil A, rail A. C'est assez logique en effet. Par contre je ne comprends pas ce que tu veux dire par Centrale, fil B, TR1 a, TR1 b, rail B
Pour moi TR1 c'est le secondaire, comment pourrait il être relié au rail B ?
Juste comme ça, sans diodes. La loco génère un courant, le transfo le capte, et puis c'est tout. En se passant de ces diodes. Qui sont pour moi inutiles.
-
Ok, je comprends ! A tester avec et sans.
-
Ok, je comprends ! A tester avec et sans.
Sans ces diodes, pour moi, ça suffit. Le PT ou ces décodeurs RDS ne sont pas sensibles à une polarité. Ce qu'ils captent, c'est:
52kHz <changement de phase> 52kHz <changement de phase> 52kHz <changement de phase>
La polarité (selon l'orientation des locos sur les rails, ou selon comment c'est câblé, sur rail A ou rail B), le PT ou ces décodeurs, je pense qu'ils y sont indifférents.
-
Voici donc un exemple de code qui me semble t’il devrait permettre de lire et exploiter les infos de retour. Vos remarques sont les bienvenues.
#include <Arduino.h>
Quant à cette idée, très simple, 64 bits in, je pense que ça ne va pas fonctionner. Parce que le nombre de bits et d'octets qui vont entrer seront aléatoires.
Pour commencer, il faudra peut être faire du shit in/affichage bit à bits. C'est possible: le RDS, c'est à 1000-1200 Baud et le serial doit pouvoir fonctionner à 115200 Baud.
Pour constater d'abord comment les messages sont "enveloppés". Puis pour adapter ensuite le code. Qui ne tiendra pas dans une routine d'interruption, une routine qui figerait tout l'ESP pendant son exécution (lente).
The data stream of the return channel transmits one bits in the idle state. The data frame is structured as follows:
. . . 11111 010 Byte1 (Byte2 ... Byte8) Checksum 111...
Au début, on a des "idle states", des 1. Ensuite, un préambule, 010. Ce n'est que après qu'on commence à avoir des data, de 1 à 8 octets.
010: le préambule, ça va commencer... Sur erreur de transmission, on aura un faux préambule, ou on le rate.
Problème majeur: on n'a pas d'info de longueur, du nombre d'octets qu'on va recevoir. On va devoir "deviner" que la transmission est terminée, sur réception d'un checksum (suivi de bits à 1).
J'aurais préféré une trame plus simple, qui facilitait tout:
. . . 11111 010 Length Byte1 (Byte2 ... Byte8) Checksum 111...
Comme on a pas "Length", il va falloir "deviner" à quel moment c'est terminé. En sachant qu'un "ByteX" pourrait très bien imiter une checksum et faire penser à tort que c'est fini...
Et s'il y a erreur de transmission, la checksum ne sera pas valide... on pourrait finir sur un timeout ou bloqué là, à l'attendre...
Recevoir et valider/rejeter ce genre de flux de données sera plus compliqué qu'un simple shift in.
De deux choses l'une:
- soit on a pas trop de bruit, tout baigne, avec juste un timeout ou des erreurs occasionnelles
- soit ce genre de message est très susceptible d'être perturbé et leur réception/correction sera compliquée
-
111...1 <010> <message> <checksum> 1111
Les "flags", ce sont les 111 (nombre indéterminés par la doc)... <010>, le début, suit le <message>, la <checksum> à la fin. Suivent encore des "flags"...
Il va falloir une routine pour détecter "l'enveloppe", et si la checksum est valide, en extraire le message.
Ca m'a fait revoir ce qu'est HDLC. Qui prévoit qu'une data imite un délimiteur ou "flag". Si rien n'est prévu lorsqu'une data imite une "checksum/flag", il va falloir se casser un peu la tête pour recevoir et valider/invalider le message. Sans y rester bloqué en cas d'erreur de transmission.
-
Bonjour,
Je comprends et je suis d’accord avec tout ce que tu dis.
Il faut ajouter à cela que la centrale sait combien d’octets elle attend en retour de la demande qu’elle a fait. La construction même de la fenêtre de retour de données créée par la centrale détermine le nombre de nombre d’octets attendus en retour. §2.2.8
C’est une piste pour avoir le nombre d’octets en retour.
Et/ou, il faut raisonner en effet en « enveloppe de message » pour pouvoir extraire les data « utiles » et oui aussi à un timeout dans le cas où rien de cohérent ne vient « conclure » l’enregistrement du message.
A ce stade, je ne pense pas que l’on puisse faire bien autrement que de surveiller à l’oscillo puis analyser les messages échangés entre la centrale et les décodeurs et adapter selon les résultats obtenus.
Par ailleurs, tu soulèves à juste titre la question de de blocage ou de lenteur dans une routine d’interruption. Mais je n’étais qu’au state premier de l’expérience. Il y a des moyens simples de contourner mais cela viendra selon moi en parallèle. Sur un ESP, on peut tout à fait imaginer une routine d’interruption qui envoie les data brutes dans une queue pour traitement parallèle. Je me demande aussi, comme tu l’as je crois déjà évoqué, si l’on ne peut pas confier cela à un ATTiny qui là aussi enverrait les data au µC.
Christophe
-
Il faut ajouter à cela que la centrale sait combien d’octets elle attend en retour de la demande qu’elle a fait. La construction même de la fenêtre de retour de données créée par la centrale détermine le nombre de nombre d’octets attendus en retour. §2.2.8
Bonjour,
Les centrales attendent des réponses précises? Hier soir, je me demandais s'il serait possible de planter ou de faire rebooter une Marklin en lui envoyant n'importe quoi. Ce serait rigolo, lors d'une expo, si on branchait un petit truc sur une voie :)
Sur ce genre de projet, il ne faudra pas s'attendre à quelque chose de précis en retour. Surtout avec Labox, je pense, destinée à du DIY et à des développements divers.
Si la solution fini assez robuste, elle pourrait faciliter ensuite le développement d'un décodeur avec feedback, sans perturber la centrale.
Je me demande aussi, comme tu l’as je crois déjà évoqué, si l’on ne peut pas confier cela à un ATTiny qui là aussi enverrait les data au µC.
Eventuellement un tiny qui reçoit proprement, avec la centrale qui elle même valide ou non, selon le nombre d'octets attendus/reçus...
-
Il faut ajouter à cela que la centrale sait combien d’octets elle attend en retour de la demande qu’elle a fait. La construction même de la fenêtre de retour de données créée par la centrale détermine le nombre de nombre d’octets attendus en retour. §2.2.8
Sur ce point, j'ai pu faire fausse route. Si la centrale sait combien d'octets sont attendus, et que les locos s'y tiennent, c'est plus facile. Il suffit alors de recevoir ce nombre d'octets, la checksum, puis de la vérifier. Avec un timeout simple, pour ne pas rester bloqué en cas d'erreurs de transmissions.
-
Bonjour,
J'ai reçu le pack MS2. Avec un transfo de 2A. Dans le booster, c'est tout petit, tout est petit...
Je n'ai pas trouvé de transfo pour le feedback; il aurait pu être soudé à l'arrière du PCB. Autour du pont en H, on voit deux sondes de courant. Celle de droite, c'est manifestement comme sur Labox (motor shields, etc), une sonde de courant; une piste va vers la CPU qui a un ADC.
Le feedback MFX semble être récupéré par la sonde de gauche, en haut du pont en H. Près du PT, on voit 3 points de tests, ils seraient parfaits pour un scope; 3 signaux, le 0V est à récupérer ailleurs. Pas question de poser une sonde sur les composants, on ferait vite un court-circuit; ou il faut être prudent. On voit aussi quelques "vias" qui pourraient servir de points de mesure. On pourrait même souder quelques pattes de résistance sur certains de ces points pour faciliter les mesures (pour qu'une sonde y reste bien accrochée).
Il y a là un risque. On pourrait être tenté de prendre des mesures sur cette MS2 et en même temps sur un petit montage à transfo/PT. Pour comparer les signaux. Il faudrait alors s'assurer d'abord que les alims de ce ce booster et du circuit à transo ont bien la même référence 0V. Que le montage est Ok, sans risques de court-circuits. Avec un fil soudé entre le 0V de ce booster et le 0V du circuit à transfo/PT.
A l'arrière de cette carte, on voit une piste qui va de cette sonde de gauche vers le PT, vers la CPU aussi. Sur cette longue piste, on devrait pouvoir voir le signal RDS modulé à 52kHz. Ils ont donc réussi à se passer d'un transfo d'isolement, en intégrant une sonde à cet endroit, dans le pont. Ca a pu leurs permettre d'optimiser les coûts de production.
Le circuit à transfo garde tout ses intérêts. Il isole électriquement et reste simple, sans réglages. Ce transfo faciliterait aussi les mesures simultanés sur le booter MS2. Et ce circuit à transfo/PT peut être inséré n'importe où sur le réseau, à la sortie d'un booster dépourvu de récepteur MFX aussi.
Je n'ai pas une idée claire du fonctionnement des 4 circuits qui sont en bas à gauche sur ce booster/centrale. Vu le PCB, leurs sorties vont vers le pont en en H. C'est manifestement ce qui pilote les Mosfets du pont. vns3nv04dp... des Mosfets évolués, pas de simples transistors: https://www.st.com/resource/en/datasheet/vns3nv04dp-e.pdf
Près des prises pour les manettes, il doit s'agir un transciever CAN. Pas un bus, mais un montage en étoile... Si le bus est assez lent et comme les câbles des manettes sont courts, ça ne doit pas poser de problème.
On peut aussi remarquer quelques ferrites (dont de grosses près de l'alim et près des sorties DCC/MFX). Les industriels ont des contraintes, ce genre de circuits rayonnent, produisent du bruit susceptibles de perturber d'autres équipements. Ils sont obligés d'en ajouter pour être conformes aux normes. Au dos de cette centrale MS2, sur l'étiquette CE, je lis: "The device complies... The device may not cause harmfull interferences... The device must accept any interferrence... included intereferrences that may cause undesired operatins." On aurait juste des contraintes si on souhaitait vendre de tels produits en Europe. Ou si quelque chose qu'on a développé perturbe régulièrement la Wifi du voisin :)
S'il y a des difficultés pour comprendre comment ça fonctionne, pas mal de choses devraient pouvoir être faites avec une MS2. L'essentiel semble être documenté. https://www.maerklin.de/fileadmin/media/produkte/CS2_can-protokoll_1-0.pdf
-
Christophe,
Je regardais quoi encore et comment faire avec cette MS2... Je constate que avec un scope 4 voies, tu n'auras aucune difficulté pour voir comment le tout fonctionne :)
https://forum.3rails.fr/t/railuino-la-bibliotheque-pour-commander-son-reseau-en-diy-avec-le-protocole-can-de-marklin/27168/3
-
Je continue d'ausculter la Gleisbox MS2. Qui m'intrigue.
Côté "CAN", on remarque un transceiver RS485/RS422, un MAX3085. Les boites noires sur la droite sont des ferrites. A côté du MAX, une résistance de 120 Ohm. Deux ports, pour un branchement vers deux manettes. Sur un bus CAN on a normalement une 120 Ohm aux extrémités seulement.
En entrée du PT, j'ai un "K3WI 1". Aucune idée de ce que c'est. Juste des diodes ou autre chose. Des deux côtés, deux pattes sont en court-circuit. Soit ce sont des diodes, soit c'est plus évolué. A ce format, il existe des portes logiques programmables, des microprocesseurs aussi.
Pour le pont en H, d'un côté, un mosfet évolué (avec des protections), de l'autre, un banal IRF736 (dual P Mosfet). Et ce circuit pour le feedback RDS... Je suis curieux d'apprendre comment ce circuit feedback fonctionne.
Le pont en H est piloté par un CD4555 (avec les 4 groupes de composants). Un décodeur binaire 1 vers 4. Je me demande aussi comment ça peut fonctionner.
-
Je renouvelle aussi ma proposition de vous fournir tous les composants si toute fois vous souhaitiez réaliser des tests de votre côté.
D'après ESU, la MS2/Gleisbox doit être dans une version minimale pour que tout fonctionne... mon kit semble être Ok. J'attends deux ESU multi protocoles, dont M4, qui serait MFX. Ou c'est juste une version minimale pour la détection de nouvelles locos:
https://www.esu.eu/en/support/faq/digital-systems/m4-data-protocol/ "The software version of the command station is not older than V3.0.1."
C'est assez obscur dans ces docs, et je n'ai pas tout lu... La MS2/Gleisbox fait aussi du DCC seulement, sais tu si elle a un cutout Railcom dans ce mode (elle n'a pas un tel récepteur)?
As tu prévu de faire un mini PCB façon breakout pour périphérique Arduino, avec le transfo, le PT et quelques points pour raccorder les différents câbles et signaux? Un mini PCB avec quelques points de tests pourrait tout faciliter.
J'ai trouvé cette non solution qui pourrait aider. Non solution car avec les taxes et les frais, c'est à plus de 50€....
-
Bonjour à tous,
Depuis deux semaines je n’ai que très succinctement survolé le forum et ce fil car je me suis totalement investi dans l’introduction de la technologie RMT de Espressif dans ma centrale MFX sur base de laBox
C’est maintenant terminé et je suis très satisfait du résultat la génération du signal de voie est plus précise et plus stable sur l’ESP32 qu’au travers des timers. Je rappelle que c’est ce procédé qu’utilise également DCC-Ex pour son soft (mais uniquement pour l’ESP32)
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/peripherals/rmt.html
Ces captures à l’oscillo montrent bien les trames parfaites pour les bits 0 à 100µs et pour les bits 1 à deux alternances de 50µs.
(https://media.3rails.fr/original/3X/b/2/b2954b5be5ec74e21cc0b723e915ecbcabd246d6.png)
(https://media.3rails.fr/original/3X/0/f/0ff932c973b620d0333603bd0bbfd7f92f5e764b.png)
Le programme est sur mon Github : https://github.com/BOBILLEChristophe/directMFX_ESP32
(https://github.com/BOBILLEChristophe/directMFX_ESP32)
Réaliser cela sans oscillo aurait été très compliqué et probablement que j’aurais abandonné avant la fin. Merci à bk4nt pour ton aide et tes précieux conseils.
Merci également à Dominique, Thierry et... Michel car je réutilise le hard de laBox sans avoir eu besoin d'y apporter la moindre modification. Je challenge sera peut-être un jour de réaliser uneBox DCC et MFX (M4) comme le font beaucoup de centrales.
Je vais maintenant pouvoir me consacrer à l’implantation du retour d’information dans cette centrale.
Christophe
-
Bon, maintenant que la centrale MFX est terminée je m'étais lancé au décodage des signaux de retour des décodeurs vers la centrale. Mais OH malheur, le composant LC72725 est plus petit que petit !!! Même mes fils les plus fins paraissent de gigantesques câbles au regard des pattes microscopiques.
Du coup, je me suis résolu à commander des composants chinois en DIP. Le principal problème est que je ne serai livré au mieux qu'entre la fin janvier et la mi février.
J'en ai profité pour m'intéresser plus en détail au fonctionnement et je pense avoir compris l'essentiel. Y a plus qu'à attendre.
Christophe
-
Quand c'est trop petit, un composant peut être monté quand même. C'est l'astuce du dead bug:
https://www.youtube.com/watch?v=q53uPn1mKc0
Sur cette vidéo, vu ce composant, il utilise à mon avis des fils beaucoup trop gros. En plus, il les plie très courts...
Les QFN sont fragiles. Si on insiste trop au fer sur une broche, ou si on exerce trop de contraintes mécaniques avec un fil trop gros/rigide, on fini par arracher une broche; tout est alors à recommencer.
J'ai fini par trouver une technique assez simple et rapide (mais ça prend du temps):
- pour l’immobiliser, coller le composant sur un bout de plaque à proto, étamer rapidement ses broches
- trouver un bout de fil multi brins, en utiliser des brins de 0.2 à 0.3 mm... les étamer un peu à une extrémité (doser la quantité de soudure)
- chauffer le fil, seulement le fil; sur de petits QFN, la chaleur du fer transmise via ce fil de cuivre suffit à le coller/souder sur la broche du QFN (c'est plus précis et facile que de chauffer à la fois la broche et le fil; on ne risque pas de faire chauffer les broches d'à côté, ni de faire baver)
- puis souder l'autre extrémité du fil sur une pastille de la plaque à proto (en conservant une longueur, pour de la souplesse, pour exercer moins de contraintes mécaniques sur la puce après montage)
Pour certains composants, il n'existe que des versions QFN ou plus petits, ce qui ne laisse pas le choix. Des modèles type SOIC ou TSSOP ont les broches moins fragiles. On peut alors tenter des fils un peu plus gros que 0,3mm pour transmettre plus facilement la chaleur via le fil qui est à souder.
On peut être audacieux avec cette technique. On peut ajouter une capa de découplage au format CMS à même la puce, avec deux bouts de fils. On pourrait même ajouter un quartz au format CMS à ce LC72725. Ou encore faire un petit montage en l'air avec des CMS autour de la puce. Mais ça prend du temps.
Pour des SOIC ou des TSSOP, ça peut sinon être tout simple, avec un breakout. Une version courte, avec un gros fer, sans se poser de questions:
https://www.youtube.com/shorts/thCHK7kKb0E
Il y a là aussi une astuce. En procédant ainsi, il reste souvent des excédents de soudure, des courts-circuits entre les pattes (on en voit sur cette version courte). Si on insiste au fer seul, les excédents disparaissent d'un côté mais réapparaissent de l'autre... L'astuce consiste à répartir et à éliminer les excédents de soudure à la tresse à dé-souder. En une minute ou deux, la puce est soudée proprement.
Des exemples, du net. On peut tout faire, mais c'est plus ou moins long selon la taille des CMS:
-
Mais OH malheur, le composant LC72725 est plus petit que petit !!! Même mes fils les plus fins paraissent de gigantesques câbles au regard des pattes microscopiques.
A ta prochaine commande, n'oublies pas:
- des breakouts, faciles à souder,
- des quartz au format CMS, il seront installables à proximité immédiate de la puce,
- une bonne loupe pour vérifier les soudures :)
Ca prend son temps (avec les plus petits CMS qui tendent à rester collés au fer), mais si j'ai pu le faire, c'est réalisable par tous :)
La grosse puce a été soudée comme expliqué plus haut, fini à la tresse à dé-souder, c'est assez propre.
Le quartz, c'était presque simple. Les capas sont au format 0201. Puis j'ai coupé les pistes inutiles sur le breakout.
Monter l'alim et ses 4-5 composants sur un DIP 8 m'avait pris plusieurs heures... Une première tentative avait foiré: j'avais exercé trop de contraintes sur le uDFN 6, une broche avait finie arrachée. J'ai donc rallongé les fils pour plus de souplesse/élasticité, pour moins de contraintes mécaniques. Pour ce genre de montage "en l'air": d'abord souder le fil sur la plaque à proto, ensuite plier le fil pour qu'il soit au plus près de la broche, puis souder le fil à la broche (en chauffant juste le fil préétamé, du cuivre, qui va répartir la chaleur).
En tous cas, ça doit pouvoir donner des idées pour exploiter des composants "trop petits".
Au début, on imagine que c'est irréalisable. Mais non, finalement.
-
le composant LC72725 est plus petit que petit !!!
Ce composant a un pitch de 0,65mm... ce qui est encore gros. Je dois avoir des breakouts quelque part mais je ne retrouve plus ma tresse à déssouder pour t'en envoyer un bout.
Les vidéos à ce sujet sont rares, ce ne sont pas des techniques dites "professionnelles". Ces derniers utilisent du flux et des pannes appropriées, ce dont on peut se passer.
Ici, ils suggèrent de souder simplement à la tresse; ce qui pourrait faire chauffer inutilement la puce et le PCB. Je fais autrement, je soude grossièrement, puis j'élimine les excédents à la tresse:
https://www.youtube.com/watch?v=9PRKJXJrnvo
https://www.youtube.com/watch?v=wMKXZ252TZ4
Cette technique est préférable et simple. Il applique un gros excès de soudure, je suppose que c'est pour la vidéo, pour la démo. En pratique, on a pas à en appliquer autant. Puis hop, on retire les excès à la tresse à déssouder:
https://www.youtube.com/watch?v=8yyUlABj29o
Il te manquerait 3 choses pour utiliser tes puces:
- un breakout au bon pitch/dimension
- de la tresse à déssouder
- une loupe pour vérifier la qualité des soudures
-
Merci à nouveau pour toutes ces infos,
La loupe, j'ai
La tresse à dessouder, j'ai aussi
La panne appropriée, j'ai encore
Mais pas de breakout à 20 broches !
Pour ce genre de choses, j'utilise de la soudure liquide.
Christophe
-
bk4nt,
J'ai commencé les tests à l'intérieur de "la boite"
Je confirme que le rapport cyclique de l'horloge est parfaitement de 50% (écran 23) avec une fréquence de 52,9kHz. On devrait plutôt lire 52,63kHz. C'est le quartz 4Mhz / 76
L'image 24 est la superposition de la sortie pin 15 (T57) et de la broche QUAL
Je vais chercher sur la carte des points de tests pus pratiques car ici je me plug directement sur le composant ce qui est fort peu pratique et un nid à courts-circuits
-
l'horloge est parfaitement de 50% (écran 23) avec une fréquence de 52,9kHz. On devrait plutôt lire 52,63kHz. C'est le quartz 4Mhz / 76
C'est plutôt l'imprécision du scope, dont à quelques pixels près. Il faut changer la base de temps pour qu'un cycle clock occupe toute la largeur d'écran (ou plus, avec le zoom, et en utilisant les marqueurs temporels), ça pourrait être plus juste. Sinon, il faut un fréquence mètre (dont on peut se passer pour ce projet).
Le quartz à 4Mhz et celui du scope ne sont pas si précis, ils ne sont chacun qu'à quelques ppm près. Donc une imprécision est normale.
50%, ca permettrait donc bien de recombiner clock et data, pour créer des symboles, qui pourraient être compatibles avec Rx RMT de l'esp32. On ne doit pas avoir tant de data feedback que ça. De temps en temps seulement quelques 2 à 4 octets à 1200 Baud. Une fois les symboles dans le buffer RMT, l'esp pourrait les décoder à son rythme.
Avec une particularité. Pour un certain type de feedback, un décodeur n'envoie qu'une porteuse à 52.63kHz, pas de data. Mais là encore, ça devrait générer un flux de symboles (clock combiné avec la data qui reste à "0").
Avec la recombinaison pour des symboles, RMT devrait pouvoir rester synchro même quand la data est stable à 0 ou à 1. Reste à vérifier que RMT peut bien traiter du Manchester en Rx; pendant ce temps, l'esp serait libre pour d'autres tâches.
Image de source https://electronics.stackexchange.com/questions/246987/nrz-level-encoding-problems
J'en étais plus sûr; en IR, on utilise du Manchester aussi: https://civade.com/post/2021/05/02/IR-remote-1/4-%3A-Comprendre-et-analyser-les-signaux-d-une-t%C3%A9l%C3%A9commande-infrarouge "La transition d'un zéro à un un représente un 1 zéro logique, tandis que la transition d'un 1 à un zéro représente un 1 logique." Un symbole 00 ou 11 serait une violation du code Manchester, une erreur de transmission.
-
La solution serait donc toute simple. Après le démodulateur RDS, réencoder en Manchester.
Manifestement, on ne pourra pas se passer d'un démodulateur RDS, qui est un signal bi phase à 52kHz. Un signal qu'il faut filtrer pour éliminer le bruit, ce dont les puces spécialisées RDS s'occupent.
Les émetteurs IR fonctionnent autrement, envoient juste des bursts pour économiser les piles, ce n'est pas du bi phase (sauf fonctionnalité non documentée, l'esp ne devrait pas pouvoir filtrer/démoduler du biphase). Le filtre de l'esp sera aussi inutile; on ne devrait jamais en avoir à la sortie du démodulateur RDS.
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/peripherals/rmt.html "Note that, carrier modulation and demodulation are not supported on all ESP chips, please refer to [TRM] before configuring the carrier, or you might encounter a ESP_ERR_NOT_SUPPORTED error." Pas un soucis, puisque ça ne nous intéresse pas pour cette application.
-
La solution serait donc toute simple. Après le démodulateur RDS, réencoder en Manchester.
Manifestement, on ne pourra pas se passer d'un démodulateur RDS, qui est un signal bi phase à 52kHz. Un signal qu'il faut filtrer pour éliminer le bruit, ce dont les puces spécialisées RDS s'occupent.
Chercher à se dispenser du composant RDS qui fait parfaitement le job serait assez idiot en effet !
Tu sembles confirmer ce que je présentais. Le RMT est probablement aussi la solution pour le retour d'information quand il s'agit d'octets. Ne pas oublier toute fois que l'on a à la fin de chaque message un CRC sur 8 bits qu'il faudra contrôler pour accepter ou rejeter le message.
Les retours de messages sur 1 ou plusieurs octets sont envoyés par series de 2 toutes les 500mS environ.
Il s'agit entre autres de la fameuse reconnaissance MFX si prisée des Marklinistes qui renvoie l'adresse UID (absolument unique pour chaque décodeur)
Christophe
-
Je ne trouve pas d'exemple de code RMT Rx Manchester...
C'est peut-être enfui dans des librairies RMT RC5: https://www.st.com/resource/en/application_note/an4834-implementation-of-transmitters-and-receivers-for-infrared-remote-control-protocols-with-stm32cube-stmicroelectronics.pdf
Chez Expressif, le sujet Manchester Rx/Tx ne surprend pas: https://github.com/espressif/esp-idf/issues/5350 "The rmt is used to implement a bidirectional manchester encoded communication."
J'en déduis que c'est une solution "simple" à évaluer.
-
Et là ? sans certitude cependant :
https://esp32.com/viewtopic.php?t=9234&utm_source=chatgpt.com
https://esp32.com/viewtopic.php?t=35178&utm_source=chatgpt.com
https://github.com/espressif/arduino-esp32/blob/master/libraries/ESP32/examples/RMT/RMTLoopback/RMTLoopback.ino?utm_source=chatgpt.com
-
Tu sembles confirmer ce que je présentais. Le RMT est probablement aussi la solution pour le retour d'information quand il s'agit d'octets.
Avec un réencodage Manchester, RMT devrait être performant pour recevoir le feedback MFX. L'esp et ses API ayant du être conçus pour, pour un traitement matériel et software optimal.
On pourrait quand même avoir envie de comparer la performance/temps CPU entre un shift in des bits avec interruptions via clock vs RMT avec des symboles puis le traitements bit à bits nécessaires ensuite...
Railcom Rx serait à mon avis plus efficacement traité par un UART de l'esp. Pour ne pas avoir à traiter/tester les bits start et stop par RMT puis par software, ce qui comparé à un UART, du matériel, fait perdre du temps CPU. Un UART mettant directement les octets reçus en RAM.
A vérifier, RMT ne doit avoir que "un fil" en entrée. S'il y a une entrée clock, ça pourrait aussi faire du shift in. Sinon, pour du shift in, il y aurait également à réencoder vers Manchester ou autres... puis à décoder dans la foulée, pour acquérir les bits. Ca pourrait consommer plus de temps CPU qu'un shift in plus classique...
Un shif in ou out plus classique avec un périphérique SPI devrait rester nettement plus performant que avec RMT qui a tout à traiter bit à bit.
-
Et là ? sans certitude cependant :
https://esp32.com/viewtopic.php?t=9234&utm_source=chatgpt.com
https://esp32.com/viewtopic.php?t=35178&utm_source=chatgpt.com
https://github.com/espressif/arduino-esp32/blob/master/libraries/ESP32/examples/RMT/RMTLoopback/RMTLoopback.ino?utm_source=chatgpt.com
Au premier lien, ça chute sur "Can you please share the you libraries or the references from where you got."
Au second, il y a du code... Au troisième, un loopback RMT, on a pas la moindre idée du temps CPU (nombre d'instructions) que prend ceci:
// Start an async data read
size_t rx_num_symbols = RMT_NUM_EXCHANGED_DATA;
rmtReadAsync(RMT_RX_PIN, my_data, &rx_num_symbols);
// Write blocking the data to the loopback
rmtWrite(RMT_TX_PIN, data, RMT_NUM_EXCHANGED_DATA, RMT_WAIT_FOR_EVER);
// Wait until data is read
while (!rmtReceiveCompleted(RMT_RX_PIN));
Ca s'arrête sur un wait/while. Sauf avec un RTOS, à partir de là, la CPU ne fait plus que boucler et attendre :)
Du shift in/out par SPI étant instantané, géré par le hardware.
Mais avec MFX, vu le peu de feedback qu'on attend, quelques octets par seconde, le temps CPU avec un esp n'est peut-être pas si important que cela.
-
Ca pourrait n'être que peu performant. RMT traitant la couche basse/physique. Le reste est à faire par software...
Dans cet exemple RMT RC5, je n'ai pas pris le temps de tout lire, le traitement des données reçues (peu d'octets, un code, d'une télécommande) semble être fastidieux:
typedef struct {
uint16_t header_high;
uint16_t header_low;
uint16_t one_high;
uint16_t one_low;
uint16_t zero_high;
uint16_t zero_low;
uint16_t footer_high;
uint8_t footer_low;
uint16_t frequency;
const char* name;
} ir_protocol_t;
uint32_t rc5_check(rmt_symbol_word_t *item, size_t &len){
if(len < 13 || len > 30 ){
return 0;
}
const uint16_t RC5_High = proto[RC5].one_high + proto[RC5].one_low;
uint32_t code = 0; bool c = false;
for(uint8_t i = 0; i < len; i++){
uint32_t d0 = item.duration0;
uint32_t d1 = item.duration1;
if (rc5_bit(d0, proto[RC5].one_low)) {
code = (code << 1) | c;
c = rc5_bit(d1, RC5_High) ? !c : c;
} else if (rc5_bit(d0, RC5_High)) {
code = (code << 2) | (item.level0 << 1) | !item.level0;
c = rc5_bit(d1, proto[RC5].one_low) ? !c : c;
}else{
//Serial.printf("BitError i:%d\n",i);
return 0;
}
}
return code;
}
https://github.com/junkfix/esp32-rmt-ir/blob/main/esp32-rmt-ir.cpp
-
Un récepteur Manchester avec un nombre d'octets précis attendus par la centrale devrait être plus simple que ces récepteurs de télécommande. Ceux là traitent et testent bit à bit pour les valider, détecter les violations, et en extraire des codes, à peu de bits...
Si on attend 1, 2, 4 ou 8 octets, plus une checksum, on sait combien de bits RMT doit recevoir, avec le start bit.
Sauf timeout, dès que RMT a reçu tous les bits attendus, qu'ils sont en RAM,
on ignore le start bit, un bit à 1, inutile de le tester?
on décode les symboles bits, on écrit les octets puis la checksum dans une structure,
éventuellement, on teste au passage les violation Manchester, mais il ne devrait jamais en exister, ce serait du temps CPU perdu
on vérifie la checksum, si elle est invalide, on droppe le paquet...
Edit... ces 3 lignes sont encore trop courtes. Avant la data et le start bit, il y a un préambule. Il faudra donc aussi:
recevoir bits à bits le préambule (par symboles)
tester tous les bits de ce préambule, jusqu'à détection du start bit
ensuite seulement on commence à recevoir la data...
On est donc très éloigné de ce que peuvent faire des UART, périphériques SPI et CAN, en Rx, avec de gros flux de données, sans solliciter la CPU. Avec RMT Rx, la CPU doit tout traiter symboles par symboles, bit à bits, etc.
Si on disposait d'un périphérique hardware dédié à la Rx MFX, ou d'un Tiny dédié, on aurait:
- une interruption pour signifier qu'on a détecté rien qu'une porteuse 52k, jamais de start bit
- une interruption pour signaler que X octets valides sont en RAM (le hardware en aurait validé la checksum)
- une interruption pour signaler qu'il y a eu erreur de transmission (checksum invalide ou timeout, etc)
Reste l'intérêt de RMT Rx pour des messages courts et à bas débit, non susceptibles de trop charger la CPU. Avec du code plus ou moins compliqué, on doit pouvoir recevoir n'importe quel type de données encodées, reçues via un fil/GPIO Rx.
C'est ce qui semble avoir été fait pour la réception de codes IR, de télécommandes. RMT Rx passe les symboles à la CPU, la CPU décode les messages, qui restent courts et occasionnels.
Même dans la doc, je lis que ce n'est pas fait pour des choses trop évoluées ni trop rapides... En mode Tx/Rx, on ne pourrait faire que du half duplex; on aurait à faire du Tx sur un canal, du Rx sur un autre canal. Quand au buffer, il est limité aussi.
The RMT module contains eight channels. Each channel has both a transmitter and a receiver, but only one of them can be active in every channel. The eight channels share a 512x32-bit RAM block which can be read and written by the processor cores over the APB buss, read by the transmitters, and written by the receiver. https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf
The RMT RAM can be accessed via the APB bus. La doc ne semble pas parler de DMA pour de gros volumes à échanger.
Au départ, donc, une solution pour télécommandes IR (plus télécommandes ou messages courts via RF433MHz). Avec une souplesse, pour permettre toutes sortes d'encodages, à gérer par la CPU. Soit une souplesse pour étendre les capacités I/O de l'esp lorsque les performances vs charge CPU restent en adéquation.
-
Ce qui m'a fait aller voir comment le RP2040 pourrait traiter le problème du Manchester ou de la réception du feedback MFX.
Sur esp32, RMT transmet donc des symboles Rx à la CPU. Puis cette dernière doit ensuite les valider et les convertir en bits: un travail pour la CPU. Ensuite seulement, la CPU commencera à traiter les bits... A de petits débits et avec des messages courts, ça doit être un travail raisonnable pour la CPU de l'esp32.
Le RP2040 a une sorte d'assembleur et jusqu'à 8 machines à états sur les IO, qui déchargent la CPU. Le RP2350 a jusqu'à 12 machines à états. C'est spécifique à ces CPU Raspberry.
Ce code pour RP2040 semble partir du principe qu'il n'existe que deux symboles possibles, 10 ou 01. Ca exclue les erreurs de symboles, les erreurs de transmission... Au lieu de pousser des symboles dans une FIFO, le code pousse les bits décodés dans la FIFO. Ce qui soulage alors la CPU, elle n'a plus qu'à traiter ensuite les données reçues:
https://github.com/raspberrypi/pico-examples/blob/master/pio/manchester_encoding/manchester_encoding.pio
.program manchester_rx
; Assumes line is idle low, first bit is 0
; One bit is 12 cycles
; a '0' is encoded as 10
; a '1' is encoded as 01
;
; Both the IN base and the JMP pin mapping must be pointed at the GPIO used for RX.
; Autopush must be enabled.
; Before enabling the SM, it should be placed in a 'wait 1, pin` state, so that
; it will not start sampling until the initial line idle state ends.
start_of_0: ; We are 0.25 bits into a 0 - signal is high
wait 0 pin 0 ; Wait for the 1->0 transition - at this point we are 0.5 into the bit
in y, 1 [8] ; Emit a 0, sleep 3/4 of a bit
jmp pin start_of_0 ; If signal is 1 again, it's another 0 bit, otherwise it's a 1
.wrap_target
start_of_1: ; We are 0.25 bits into a 1 - signal is 1
wait 1 pin 0 ; Wait for the 0->1 transition - at this point we are 0.5 into the bit
in x, 1 [8] ; Emit a 1, sleep 3/4 of a bit
jmp pin start_of_0 ; If signal is 0 again, it's another 1 bit otherwise it's a 0
.wrap
% c-sdk {
static inline void manchester_rx_program_init(PIO pio, uint sm, uint offset, uint pin, float div) {
pio_sm_set_consecutive_pindirs(pio, sm, pin, 1, false);
pio_gpio_init(pio, pin);
pio_sm_config c = manchester_rx_program_get_default_config(offset);
sm_config_set_in_pins(&c, pin); // for WAIT
sm_config_set_jmp_pin(&c, pin); // for JMP
sm_config_set_in_shift(&c, true, true, 32);
sm_config_set_fifo_join(&c, PIO_FIFO_JOIN_RX);
sm_config_set_clkdiv(&c, div);
pio_sm_init(pio, sm, offset, &c);
// X and Y are set to 0 and 1, to conveniently emit these to ISR/FIFO.
pio_sm_exec(pio, sm, pio_encode_set(pio_x, 1));
pio_sm_exec(pio, sm, pio_encode_set(pio_y, 0));
// Assume line is idle low, and first transmitted bit is 0. Put SM in a
// wait state before enabling. RX will begin once the first 0 symbol is
// detected.
pio_sm_exec(pio, sm, pio_encode_wait_pin(1, 0) | pio_encode_delay(2));
pio_sm_set_enabled(pio, sm, true);
}
%}
Vu comment fonctionnent ces PIO du RP2040 on pourrait même imaginer plus simple que avec Manchester, avec juste clock et data RDS:
- détecter la clock, une première transition, la présence d'une porteuse
- ou détecter un premier bit à zéro
- le préambule MFX, ce sont des bits à zéro
- attendre le start bit, un bit à 1, s'il en suit un
- après un start bit, ne faire le shift in que de la data et de la checksum
Après réception, la CPU d'un RP2040 n'aurait alors plus qu'à vérifier la checksum de la data reçue. Pour très peu de travail à réaliser par cette CPU.
Cerise sur le gâteau, pour des transferts plus volumineux, ou par gros bursts, alors que la FIFO PIO du 2040 a une taille limitée de 32 bits, il doit être possible de transférer son contenu via la DMA. J'en retiendrais simplement que RMT vs PIO/DMA, ce ne seront pas les mêmes applications.
https://github.com/raspberrypi/pico-examples/blob/master/pio/logic_analyser/logic_analyser.c
Entre l'esp, mfx, le 2040 et tout le reste, ça fini par devenir un océan sans fond. JMP, on en apprend plus dans la datasheet du 2040. X et Y dans ces instructions, c'est quoi? :-\
https://files.seeedstudio.com/wiki/XIAO-RP2040/res/rp2040_datasheet.pdf
-
Christophe,
Je vais t'envoyer de quoi monter ton décodeur RDS, sur un breakout.
Et aussi un bout de câble avec un connecteur mini din. La moitié d'un câble. A la base, c'est un câble mini din vers mini din, 10 pin, un câble audio/vidéo cheap, avec les 10 pins et l'écran câblés. Un câble que j'ai acheté au pif, sans savoir comment il était fichu ou conçu. Je t'en envoie la moitié, facile à dénuder et à souder.
Je viens de vérifier, sur ce connecteur MS2 on peut récupérer:
- CAN +
- CAN -
- GND/Masse (la référence 0V utile pour CAN+ / CAN -)
- une alimentation de 15V ou plus pour la gateway
Soit 3 à 4 fils, pas juste deux...
Depuis Versorgung+ (l'alim secteur de la MS2) il faudra prévoir un régulateur de 5V ou 3.3V pour alimenter l'esp.
Je glisse un truc dans l'enveloppe. Je suis pas sûr de ce que c'est, je pense que c'est un convertisseur DC vers 5V (3A max). Et un chimique à ajouter près de l'entrée/in de ce convertisseur.
-
Merci. Je vais m'y remettre maintenant que les fêtes sont passées et que les risques de crise de foie s'éloignent !
-
Bonjour à tous,
J'avais commandé des composants en DIP pour le RDS car je ne voyais pas comment m'en sortir (soudure) avec les composants CMS qui sont microscopiques. Finalement, ces composants en DIP sont vraisemblablement défectueux. J'avais un signal même sans liaison au rails et à la centrale, juste le VCC des composants. Ca a corroboré mes craintes car il est fréquents que, pour des composants que l'on ne trouve plus sur le marché (ou qui sont en rupture longue), des escrocs refilent des composants défectueux, probablement éjectés au cours des contrôles de fabrications. Nous avons connu cela avec les MAX471 quand ceux-ci ont cessé d'être fabriqué.
Finalement, bk4nt m'a gentiment envoyé des adaptateurs vers le format 2,54 (et d'autres petites choses) et je l'en remercie.
Je redoutais la soudure et finalement, cela c'est très bien passé. J'ai utilisé de la soudure liquide et le résultat que vous voyez ci-dessous me semble très correct. Pour m'assurer qu'il ne restait pas de soudure entre les pattes, j'ai nétoyé le surplus de soudure avec un pinceau à fibres de verre. D'où les traces que l'on observe en surface, un peu comme des coups de balais !
Je n'ai pas eu le temps de tester aujourd'hui mais je le ferai certainement demain. Je vous tiens au courant.
(https://www.locoduino.org/local/cache-vignettes/L700xH502/_dsc1661-48319.jpg?1736195370)
Christophe