Decodeur wagon ou fausse motrice ou tender pour feux rouge/blanc de Rudy

[msport]

Bonjour,
j'ouvre un nouveau fil pour ce projet de décodeur pour feux rouge/blanc Rudy (projet que j'ai depuis que le DCC m'intéresse) :
Ayant numérisé une loco ICE d'une rame de 3 wagons, je me suis retrouvé avec la fausse motrice dont les deux ampoules (rouge/blanche) éclairait en permanence.
D'où l'idée d'y placer un décodeur de fonctions (pas d'accessoires) répondant à la même adresse que la locomotive.
Après quelques balades en rond sur internet, le projet de Rudy correspond exactement au besoin.
Je l'ai réalisé sur un Nano (pas encore déversé sur un ATtiny, ce que j'ai déjà fait via un UNO, mais je compte si possible le mettre sur un ATtiny85 d'une mini carte avec USB (où il y a un régulateur 5V))
ça fonctionne pour commander une Led via le F4 classique et d'autres. Et c'est déjà beaucoup. Mais le programme documente la possibilité de piloter deux LED inversées par la direction de la loco.
C'est là où j'ai un problème :
Je ne suis un spécialiste de la trame DCC ni du C++ et je n'ai pas décortiqué à fond le programme mais la ligne 51 :
    byte instructionType = instrByte1>>5;
qui devrait extraire le bit direction que je pense être le troisième à partir de la gauche, renvoie systématiquement 1, et ne voit pas le changement de direction.
(je comprends le 2 ou 3 puisqu'il reste les deux bits 01 à gauche de celui de direction après le décalage qui introduit cinq 0 à gauche)
Merci pour toute piste.
Michel

Pour mémoire, (http://forum.locoduino.org/index.php?topic=256.0;topicseen) le lien via :
Sur la page, https://rudysmodelrailway.wordpress.com/software/
en suivant le lien :
Arduino DCC, S88, and more Download link :
https://www.dropbox.com/s/qkhrc147m38llb9/Arduino_DCC_S88.zip?dl=0
on récupère un zip qui contient les sketches pour les ATtiny, dont le décodeur de fonction.
Pour éviter le jeu de piste le sketch est ci-dessous, mais vous aurez besoin de la library pour :
#include <DCC_Decoder.h>
#define kDCC_INTERRUPT 0
Il vous faudra au moins modifier l'adresse de la loco ligne 15 et valider les sorties lignes 16 et 17

[Dominique]

Bonjour Msport,

Ton projet est bien intéressant à plus d'un titre.
J'ai moi-même équipé la 2ème voiture d'un autorail avec un décodeur de loco dont la sortie moteur était HS, mais qui permet de mémoriser la même adresse que la loco et de commander les feux en fonction de la direction.

Mais les beaux articles de Christian sur les ATtiny ouvrent des opportunités notamment les ATtiny85 assez petits pour être logés dans du N et costauds pour la mémoire.

C'est bien le décodage des commandes de loco qui est concerné et je vais tenter de t'aider mais pas avant la semaine prochaine, d'autant que je viens de flasher mon premier ATtiny85 

Amicalement
Dominique

[CATPLUS]

Bonjour

J'aime l'Attiny85 et je l'utilise  dans beaucoup d'applications.
Dans ma dernière demande, j'avais soulevé un problème,  impossible de faire fonctionner l'ATtiny

http://forum.locoduino.org/index.php?topic=256.75
Réponse #84 le: mai 01, 2017, 06:06:38 pm

Peut-être que vous avez la solution. J'attends avec impatience vos résultats et le fichier modifié.
Amicalement
Marcel

[msport]

Merci Dominique pour ta réponse, j'ai donc le temps de mettre au propre ... (dans mon message, les 2 ou 3 sont les switches du case pour fwd et rev où je ne récupère que 1)
Pour Marcel, je ne me suis pas encore intéressé aux accessoires (je viens juste d'acheter un aiguillage ROCO Geoline avec décodeur incorporé pour tester - et dont je vais chercher à programmer l'adresse bientôt sans mouse, là aussi, suggestions bienvenues car je n'ai pas trouvé de documentation, alors que Viessmann en est plus prodigue)
pour ton sujet, Rudy indique : sur la page, https://rudysmodelrailway.wordpress.com/software/
RB_DCC_Decoder_Accessory
Arduino sketch for DCC control of accessories. More info is available here. Configuration per output:
accessory[0].address = 1; // DCC address etc.

Est ce que, tout simplement, il ne faut pas modifier cette adresse = 1 dans la valeur souhaitée (comme les 3 autres, 2, 3, 4) avec encore une histoire de décalage depuis 0 ou 1 ...

A tester tel quel avec une Base station et le serial monitor avec : <a 1 0 1> (et variantes)
a accessory,
1 primary address
0 sub address
1 activate

[savignyexpress]

Bonjour msport,

L'instruction que tu mentionnes fonctionnera bien pour autant qu'il n'y ait pas d'autres bits à 1 à gauche de celui que tu souhaites extraire.

Code: [Sélectionner]

byte instructionType = instrByte1>>5;
Si instrByte1 contient la valeur binaire 0b01000000, le décalage à droite de 5 bits produira 0b010. Si tu utilises cette valeur dans une instruction if, la valeur 0 est considérée comme fausse, toute valeur différente de 0 est considérée comme vraie. Ainsi 0b010 est vu comme vrai alors que le 3ème bit en partant de la gauche (ou le 5ème en partant de la droite) vaut 0.

Pour éviter ce problème, il faut encore appliquer un masque, soit avant ou après le décalage. Attention, le masquage bit-à-bit s'effectue à l'aide des opérateurs & et |. Ne pas confondre avec les opérateurs && et || qui sont utilisés pour les conditions dans les tests if, while.

Avant:

Code: [Sélectionner]

byte instructionType = (instrByte1 & 0b00100000) >>5;Après:

Code: [Sélectionner]

byte instructionType = (instrByte1>>5) & 0b1;
Le préfixe 0b indique que la constante est exprimée en binaire. En Arduino, il semble qu'il soit aussi possible d'écrire  B00100000.

Je ne sais pas si c'est le problème que tu rencontres, mais c'est à prendre en compte.

Bien cordialement.

Marc-Henri

[msport]

Merci Marc-Henri pour cet éclairage, mais dans le sketch que j'ai mis en pièce jointe les instructions sont les suivantes :

if (!bitRead(dccPacket[0],7)) { //bit7=0 -> Loc Decoder Short Address
    Address = dccPacket[0];
    instrByte1 = dccPacket[1];
  }
  else if (bitRead(dccPacket[0],6)) { //bit7=1 AND bit6=1 -> Loc Decoder Long Address
    Address = 256 * (dccPacket[0] & B00000111) + dccPacket[1];
    instrByte1 = dccPacket[2];
  }
  if (Address==decoderAddress) {
    byte instructionType = instrByte1>>5;
    switch (instructionType) {
      case 2: // Reverse speed
        forw_rev=0;
        break;

Si instrByte1 contenait bien le (byte) paquet DCC avec la direction, celle-ci est codée sur le 3e bit en partant de la gauche. Les deux premiers étant 0 et 1 (soit commençant par 01D, D pour direction). Le décalage de 5 positions va donner 0000001D, ce qui donne 2 ou 3 pour la direction. Le problème est donc en amont, dans le contenu de instrByte1. Dominique maitrise manifestement la question des adresses courtes et longues qui est peut-être à l'origine du souci.

J'aurais du aussi préciser que les commandes sont envoyées par la manette DIY "Throttle" décrite par ailleurs dans ce forum (via une BaseStation DCCpp-VV), mais comme les commandes F0 à F4 sont bien interprétées par le décodeur et les locomotives et que la direction est OK pour les locomotives, je n'ai pas encore cherché plus loin.

[Dominique]

Bonjour,

à la place de :

Code: [Sélectionner]

if (Address==decoderAddress) {
    byte instructionType = instrByte1>>5;
    switch (instructionType) {
      case 2: // Reverse speed
        forw_rev=0;
        break;
tu pourrais écrire :

Code: [Sélectionner]

if (Address==decoderAddress) {
  if (bitRead(instrByte1),5) {
    // Forward Operation 011DDDDD
    } else {
    // Reverse Operation 010DDDDD
  }
}

ça doit même s'exécuter plus rapidement !

Cordialement

[msport]

Merci Dominique, mais le problème ne vient pas de l’extraction de ce bit mais de sa valeur qui se trouvait toujours à 1.

Après avoir truffé le programme de serial.print, je trouve le bit direction en première position de dccPacket[2] -et non [1] et je l'obtiens avec un bitRead( (dccPacket[2]) ,7 )
Pas terrible comme méthode de programmation, mais on fait comme on peut. Il sera toujours temps de comprendre.

Est-ce un problème de ma manette (pourtant tous les décodeurs que j'ai (LENZ, LAISDCC, TAMS) l'accepte sans broncher).

Ci-joint la version qui fonctionne sur Nano en attendant de tester le passage sur ATtiny.

Merci de m'expliquer pourquoi ça marche. (j'espère pour vous aussi)

[Pierre59]

Bonjour

Si je ne me trompe pas il doit y avoir 4 cas différents pour l'emplacement du bit de direction dans les trames DCC, selon que :

- l'adresse est courte ou longue
- les crans de vitesse sont courts (14 ou 28 crans) ou longs (128 crans)

Cela donne 4 trames DCC possibles avec 4 emplacements pour le bit de direction (si cela vous intéresse je dois pouvoir retrouver les formats de ces trames dans mes archives).

Quand j'ai fabriqué ma centrale DCC j'ai du prévoir ces 4 possibilités.

Pierre

[msport]

Bonjour,
merci pour ces précisions, au moins je comprends l'origine de mes problèmes. Comme je ne maitrise pas vraiment l'extraction des paquets DCC, je ne pense pas que j'irai beaucoup plus loin.
Par contre de savoir dans quel cas je suis (bit 1 du dccPacket[2]) me permettrait de savoir ce qu'il faut éviter. J'imagine que la réponse est sur internet aussi.
Apparemment, Rudy a choisi les adresses longues pour son exemple (adresse 1830) et je n'utilise (ma "throttle") que des adresses courtes et 128 crans.

[Pierre59]

Bonjour

Voici la forme des trames DCC (concernant l'adresse, la vitesse et la direction) pour les décodeurs multifonctions.

Il y a deux possibilités d'adresses (courte et longue) : 

0AAAAAAA 7 bits d'adresse

11AAAAAA AAAAAAAA 14 bits d'adresse

Et deux possibilités de vitesse (crans) et direction (sens) :

01DcCCCC 4 ou 5 bits (14 ou 28 crans) suivant l'utilisation de "c"

00111111 DCCCCCCC 7 bits (128 crans)

le bit "D" est la direction


Ce qui donne les 4 trames possibles :   

0AAAAAAA 01DcCCCC XXXXXXXX adresse courte 14/28 crans

0AAAAAAA 00111111 DCCCCCCC XXXXXXXX adresse courte 128 crans

11AAAAAA AAAAAAAA 01DcCCCC XXXXXXXX adresse longue 14/28 crans

11AAAAAA AAAAAAAA 00111111 DCCCCCCC XXXXXXXX adresse longue 128 crans

le dernier octet contient une "checksum" (ou-exclusif des octets précédents)

on voit bien les 4 emplacements possibles pour le bit de direction (en gras)

Pierre

[msport]

Vous donnez les bases à ceux qui voudront adapter le sketch aux autres cas. Merci.
Je l'ai donc adapté pour le cas 128 crans, adresse courte.
Rudy a écrit son programme pour 14/28 crans, adresse longue. J'ai juste mis en commentaire la ligne concernée (68).
Programme mis à jour : toutes les sorties en positif et commentaire.

[CATPLUS]

Bonjour
Merci pour le programme. J'ai installé dans un Nano fonctionnement bizarre avec le Zimo (mais cela marche)
Fonctions F4 sortie D3, F3 sortie TX, F5 sortie RX,
Ci-joint un  petit tableau

Par contre impossible de le faire FONCTIONNER avec un ATtiny 85
Cordialement
Marcel

[msport]

j'ai aussi une table de vérité un peu folklorique :
F0 : ?
F1 TX = D1
F2 D3 (inversé)
F3 RX = D0
F4 D4/D5 réversibles suivant forward / reverse
le programme de la station est celui de Dominique DCCpp_VV
la manette est la "Throttle"
mon F4 allume les feux AV/AR réversible sur mes locos. Et en général mon F0 allume les feux rouges en fixe.

[msport]

Bonjour,
après avoir carbonisé quelques neurones (reste à utiliser ceux qui restent) voila le programme qui marche sur un ATtiny 85.
(Oublions l'ATtiny 13 pour cette application, le code refuse de compiler)
Donc avec le processus classique décrit dans ces colonnes (encore merci Christian Bézanger), pour mémoire :
via le programme des exemples ArduinoISP sur un UNO.
Dans préférences https://raw.githubusercontent.com/damellis/attiny/ide-1.6.x-boards-manager/package_damellis_attiny_index.json
Type de carte : ATtiny25/45/85; Processeur : ATtiny85;  Clock : Internal 8 MHz. Programmateur : Arduino as ISP.
Gravure de la séquence d’initialisation puis télédeversement.
Connexion de l'interface DCC sur le booster DCCpp_VV bien connu, manette Throttle, F4 sur cette manette, changement de direction,
les LED sont sur PB3 et PB4 (pins 2 et 3) et le signal DCC via l'optocoupleur sur PB2 (pin 7)
Ci-joint le code tel que compilé, adresse loco 9, donc courte, et 128 crans de vitesse.
IDE 1.8.2 sous W10.

PS: j'aurais du mal à fournir plus d'explications, le programme est le résultat d'approximations successives.
Nota : pas encore testé en parallèle avec la loco #9, embarqué dans la fausse motrice, mais il n'y a pas de raison que ça ne marche pas !