Messages récents

1

Modélisation, Architectures logicielles et matérielles / Re : Re : Protocole MFX : Retour d'information des décodeurs

« Dernier message par bk4nt le Aujourd'hui à 03:24:28 pm »

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.

2

Modélisation, Architectures logicielles et matérielles / Re : Re : Protocole MFX : Retour d'information des décodeurs

« Dernier message par bk4nt le Aujourd'hui à 12:14:09 pm »

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...

3

Modélisation, Architectures logicielles et matérielles / Re : Protocole MFX : Retour d'information des décodeurs

« Dernier message par bobyAndCo le Aujourd'hui à 09:41:48 am »

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

4

Modélisation, Architectures logicielles et matérielles / Re : Protocole MFX : Retour d'information des décodeurs

« Dernier message par bk4nt le Aujourd'hui à 12:54:55 am »

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.

5

Modélisation, Architectures logicielles et matérielles / Re : Re : Protocole MFX : Retour d'information des décodeurs

« Dernier message par bk4nt le décembre 11, 2024, 11:53:10 pm »

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.

Code: [Sélectionner]

#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

6

Modélisation, Architectures logicielles et matérielles / Re : Protocole MFX : Retour d'information des décodeurs

« Dernier message par bk4nt le décembre 11, 2024, 11:06:19 pm »

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.

7

Modélisation, Architectures logicielles et matérielles / Re : Protocole MFX : Retour d'information des décodeurs

« Dernier message par bobyAndCo le décembre 11, 2024, 10:59:29 pm »

Ok, je comprends ! A tester avec et sans.

8

Modélisation, Architectures logicielles et matérielles / Re : Protocole MFX : Retour d'information des décodeurs

« Dernier message par bk4nt le décembre 11, 2024, 10:56:40 pm »

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.

9

Modélisation, Architectures logicielles et matérielles / Re : Protocole MFX : Retour d'information des décodeurs

« Dernier message par bobyAndCo le décembre 11, 2024, 10:49:37 pm »

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 ?

10

Modélisation, Architectures logicielles et matérielles / Re : Protocole MFX : Retour d'information des décodeurs

« Dernier message par bk4nt le décembre 11, 2024, 10:35:08 pm »

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?