RFID 13.56 Mhz & 125 Khz

[CATPLUS]

RFIDs 125 KHz &/ou 13.56 MHz.

Détection des Locomotives &/ou des Cars.

Depuis un certain temps dans ce domaine, mes expériences sur le RFID m’ont amené à tester ces deux pistes.  J’ai lu beaucoup d’articles et regardé de nombreuses  vidéos. Ma conclusion est somme toute (cela n’engage que moi) qu’il est possible de faire cohabiter ces 2 systèmes.

Un tableau (non exhaustif) vous donne une idée des différences entre ces 2 détecteurs.

Voir les posts précédents :

http://forum.locoduino.org/index.php?topic=163.msg1705#msg1705

http://www.locoduino.org/spip.php?article41

https://www.youtube.com/watch?time_continue=8&v=CM88k0HpyGc

http://forum.locoduino.org/index.php?topic=539.msg5944#msg5944

http://forum.locoduino.org/index.php?topic=539.msg7371#msg7371

Le cahier des charges:

- Suivi des Locomotives => 13.56 MHz (maximum de 255)

- Gestion du parc (cars) => 125 KHz    (tester avec + des 300 cars)

- Affichages
   - Ecran PC/Tablette, etc…
   - LCD ou O’Led

- Transfert des données  (via USB ou CAN) dans une BD (Excel, HTML)

- A l’arrêt du system, garder en EEPROM le N° de la locomotive
   - Possibilité d’effacer la loco de l’’EEPROM
2 possibilités :
=> en automatique  détection dans le canton de la machine &/ou en manuel - un Bouton poussoir.

- Utilisation avec DCC &/ou en Analogique.

- Aucun ajout dans la locomotive (le Tag est fixé sous la machine, pour les cars  idem)

- Compatibilité  avec le CAN

- Faible coût (environ une dizaine €)

Les 2 versions fonctionnent.

Présentation de la version I2c (locomotives)

Au fur et à mesure de l’avancement des travaux, je ferai  une mise à jour de cette page.

Remerciements à mon ami Christophe pour son « aide très précieuse» sur la programmation.

Cordialement
Marcel

[bobyAndCo]

J'ai effectivement pu tester un jeu en 13.56 Mhz que Marcel m'a adressé et c'est très intéressant. Dans le montage que nous avons réalisé il n'y a qu'un seul lecteur qui se contente d'afficher sur le moniteur de l'IDE (en Serial.print donc).

La base de données affiche la loco qui passe sur le lecteur et, couplé à un détecteur de consommation, efface la base de données quand le détecteur de consommation ne signale plus la présence d'une loco dans la zone.

J'ai fait une petite vidéo qui expliquera mieux qu'un long discours et qui est visible sur ce lien :



Le code lui est téléchargeable ci-dessous.

Marcel souhaite pouvoir disposer d'une interface de visualisation de la position de chaque convoi et pouvoir également ajouter des locos, en supprimer ou les modifier. Nous allons donc créer une interface sur PC à base de navigateur web.

La prochaine évolution est de relier tous les capteurs RFID entre eux sur le bus CAN pour être dans la même topologie que les satellites et pour être compatible. La messagerie sera propre pour l'instant puisque (à ma connaissance), le système de messagerie n'a pas encore été déterminé pour la v2 des satellites en ce qui concerne le RFID. Mais il sera simple par la suite d'adopter la messagerie des satellites.

Une passerelle CAN/Ethernet-WiFi assurera la jonction entre le bus CAN et le réseau WiFi pour l'interface sur PC. La même que celle qui a été présenté à Orléans.

La prochaine étape est de connecter le système que vous voyez ici sur le bus CAN et d'afficher à partir d'un Arduino dédié les différents messages reçus des capteurs RFID sur un écran LCD par exemple.

[bobyAndCo]

Ca y est ! Dans le projet de Marcel, les différents lecteurs RFID (RC522 I2C) font remonter leurs informations via le bus CAN à un Arduino qui centralise la base de données.

Nous sommes dans un concept très similaire à celui des satellites et j'espère vraiment que les satellites en v2 permettront de lire des capteurs RFID (ici une info sur 7 octets) et l'envoi sur le bus CAN.

Comme je l'ai déjà précisé, c'est le détecteur de consommation de courant qui, quand il ne détecte plus, permet l'envoi sur le bus de l'information de libération de la zone et l'effacement dans la base de la loco qui y était stockée.

Sur cette image, on voit l'affichage sur le moniteur de l'Arduino qui centralise les remontées d'information et gère la base de données. Il n'y a pas beaucoup de données disponibles car malheureusement je n'ai qu'un lecteur RFID pour le moment.



Le lecteur est à peine plus large que la voie en HO est j'ai vu pas mal de techniques qui permettent de le rendre totalement invisible.



C'est un détecteur du cru "locoduino" qui fait le job pour la consommation de courant.



Marcel souhaitait avoir un écran LCD à proximité de chaque RC522



Prochaine étape, faire remonter l'information du bus CAN au travers d'une passerelle CAN/WiFI pour assurer la gestion de la base de données soit sur un ordinateur ou plus probablement sur un Raspberry avec une interface HTML/Javascript sous Angular.

Mais le projet de Marcel est aussi de pouvoir utiliser ces informations d'identification dans JMRI qui semble être le seul gestionnaire de réseau à lire les informations de capteurs RFID : http://jmri.org/help/fr/html/hardware/rfid/index.shtml

[Jean-Luc]

Nous sommes dans un concept très similaire à celui des satellites et j'espère vraiment que les satellites en v2 permettront de lire des capteurs RFID (ici une info sur 7 octets) et l'envoi sur le bus CAN.

No problemo.

Il y a juste à faire une carte fille en I2C pour connecter deux capteurs. En I2C, l'adresse du capteur étant fixée, on utilise un switch I2C TCA9543A qui permet également de convertir les niveaux 5V vers 3.3V et de multiplexer les INT.

[bobyAndCo]

Merci Jean-Luc.

Et pour la messagerie, qu'elle pourrait être la structure du message dans la mesure où il s'agirait aussi de transmettre 7 octes de données ?

[Jean-Luc]

7 octets de données 

En quoi consistent-ils exactement ces 7 x 10^16 combinaisons ?

[bobyAndCo]

Si l'on veut récupérer tout l'identifiant d'un tag, c'est de cette forme :

0x04 0x72 0x69 0x22 0x66 0x5D 0x80

[Jean-Luc]

Ok

Dans ce cas de trois choses l'une :

• Soit on passe en CAN FD avec des trames de 64 octets mais on ne pourra connecter que des contrôleurs CAN FD (2517 FD et quelques rares micros non Arduino)
• Soit on calcule un résumé, par exemple sur 16 bits et comme la BDD de tags est connue, on peut s'assurer à priori qu'il n'y a pas de collisions
  
• Soit chaque pilote de lecteur RFID embarque une table de correspondance tag RFID -> identifiant de loco et envoie l'identifiant

[bobyAndCo]

• Soit on passe en CAN FD avec des trames de 64 octets mais on ne pourra connecter que des contrôleurs CAN FD (2517 FD et quelques rares micros non Arduino)

Un peu limitatif mais pourquoi pas si on envisage une solution exigeante techniquement et performante et si l'on en a le budget car le 2517 FD n'est sans doute pas au même prix que les cartes NiRen que je viens de commander à 1,37 € l'unité (port inclus !)

2. Soit on calcule un résumé, par exemple sur 16 bits et comme la BDD de tags est connue, on peut s'assurer à priori qu'il n'y a pas de collisions

C'est une éventualité, sur 16 bits ça fait tout de même quelques 32000 locos (et wagons), ça devrait suffire mais ça oblige à faire une "mayonnaise logicielle" en local. Et de charger une table de correspondance. Pas top pour la maintenabilité.

3. Soit chaque pilote de lecteur RFID embarque une table de correspondance tag RFID -> identifiant de loco et envoie l'identifiant

Problématique un peu similaire au point 2.

Je vais tout de même retenir la solution 3 car je suis assez convaincu par l'intérêt de charger les paramètres d'une carte à son démarrage. Si la liste distante est mise à jour, il suffit de redémarrer la carte et il est aussi envisageable de le faire de manière logicielle.

Mais je me laisserai sans doute séduire par la solution 1 quand tu nous auras présenté tes protos !!!

[Dominique]

Étant donné que chaque tag RFID dispose d’un code unique et d’une partie programmable, je pense qu’il sera toujours possible de sélectionner au plus 8 octets dans la réponse du lecteur qui garantit l’indentification d’un très grand nombre de tag.

J’opte pour le choix 2 mais sans transcodage, seulement un choix d’octets.

Cela évitera d’enregistrer toute la table des locos dans tous les lecteurs 

Il restera à faire un petit outil de programmation des tags en liaison avec la bdd. Mais ce ne sera même pas nécessaire dans les petits/moyens réseau, avec le code unique existant dans les tags.

Pour rendre le lecteur I2C invisible, il faut juste creuser le support sous la voie. Sur ta photo, on voit une bosse qui, en N en tout cas, est une source de mauvais contact. Une petite feuille de papier, après tu peux balaster.

Jolie réalisation 

[bobyAndCo]

Je n'ai pas approfondi sur la technologie même des tags, mais si tu me confirmes qu'ils sont programmables, alors effectivement, on peut n'utiliser que les 2 ou 4 premiers octets ce qui sera largement suffisant même pour les plus grands réseaux !!!

La bosse sur la photo, c'est parce que j'ai implanté rapidement le lecteur que Marcel m'a envoyé pour les tests. J'ai en effet vu sur la toile des réseaux où les lecteurs étaient complètement "enfouis", c'est bluffant.

[Dominique]

Je n'ai pas approfondi sur la technologie même des tags, mais si tu me confirmes qu'ils sont programmables, alors effectivement, on peut n'utiliser que les 2 ou 4 premiers octets ce qui sera largement suffisant même pour les plus grands réseaux !!!

La bosse sur la photo, c'est parce que j'ai implanté rapidement le lecteur que Marcel m'a envoyé pour les tests. J'ai en effet vu sur la toile des réseaux où les lecteurs étaient complètement "enfouis", c'est bluffant.

Je vais regarder le codage des tags en rentrant mais c’est sur que c’est facile à gérer.

Pour l’encastrement, j’ai fait cela pour les moteurs d’aiguille : en les retournant ils affleurent le plan du réseau. Une petite fraiseuse à main est nécessaire.



Là c’est vite fait mais la voie reste bien plate !

[Jean-Luc]

Si les tags sont programmables, une paire d'octets suffira largement.

Sinon, pour le point 2, il ne s'agissait pas d'embarquer une table mais une valeur 32 bits servant de multiplieur pour une fonction de hachage. C'est tout.

Je suis pas trop pour le 1 car si on passe en CAN FD, on ne peut plus brancher que du FD. Le 3 était là pour occuper l'espace

[Dominique]

Si les tags sont programmables, une paire d'octets suffira largement.

Je pense qu’il ne faut pas imposer de programmer les tags, car ils ont déjà une signature unique. C’est peut être utile s’il y a des centaines, voire des milliers de tags, ce qui est loin du cas général.

Je verrai bien un cas général où on transporte la signature sans traitement sur 8 octets maxi, et, optionnellement une zone programmée pour les cas très spécifiques.

Laissez moi regarder ce que ces tags permettent de faire, je compléterai ma réponse plus tard.

[Dominique]

On parle de la Puce NTAG213 : Ces Puces ont une mémoire disponible toujours assez faible, mais plus que suffisante pour un lien ou un texte court. Le NTAG213 dispose de 144 bytes.



Les 8 premiers octets de la mémoire contiennent l'UID + un code fabricant (Nxp = 04) :
The unique 7-byte serial number (UID) and its two check bytes are programmed into the first 9 bytes of memory covering page addresses 00h, 01h and the first byte of page 02h. Une page = 4 octets.
The second byte of page address 02h is reserved for internal data. These bytes are programmed and write protected in the production test.

Pages 04h to 27h for NTAG213 are the user memory read/write area.

Quand on achète un rouleau de 100 tags, tous les UID sont différents.
Souvent une série de ces UID ont une partie identique et quelques octets différents seulement. Après analyse des UID d'un lot de tags, il est facile de décider combien d'octets restent à transmettre en Can (moins de 7 donc) : A mon avis, ça ne vaut pas le coup de les transcoder et le gestionnaire du réseau doit en déduire le numéro de train facilement. L'apprentissage du gestionnaire est facile à faire.

Pour plus d'infos : https://www.nxp.com/docs/en/data-sheet/NTAG213_215_216.pdf