Partie interactive du site pédagogique ELECINF344/ELECINF381 de Télécom ParisTech (occurrence 2011).


TSV Safe Express: remote controlling is possible!

We have yesterday worked on the control of our circuit from a remote server, and we finally could remotely control all lights on the circuit. We could also run our train in both directions, corresponding to the remote program commands.

As we send information about the car position (sensor information), the remote program controls our circuit continuously.

After that, we were facing the problem that the railroad switches weren’t decoding our DCC commands. So we have reprogrammed them. After that some of the railroad switches. Unless the railroad switches aren’t included in our work specification, we try to control them all in order to make a free circulation of our train. Vaibhav and Theodor are concentrating on this part while I am doing the presentation for tomorrow.

TSV Safe Express: Demystifying Conundrums

During the last two days, we have faced a lot of problems with the sensors of the track. We had two types of interrupts that were causing us problems:-
1. Debouncing Interrupts
2. Fake Interrupts

Problem: We have configured STM32 GPIO ports to Internal Pull-Up. All our sensors cards are powered by the Central Station Card through the CAN bus. We observed that there is some kind of parasitic signal that comes from the booster towards our Central Station which produces a glitch in the power towards the Nodes (Sensors card in this case). Due to this glitch in power, the GPIO ports which were pulled high become low and thus Fake Interrupts are produced. Thanks to Alexis who stayed till 5 in the morning to help us debug the problem.

The first one was solved by making sure that the any interrupts (that is not fake) from the sensors is processed only if there is atleast a gap of 100ms since the last time it was called. For the second one, which is more tricky, we use a simple method (a FreeRTOS task) which checks for glitches. This method was proposed by Samuel and we thank him for assisting with our software.

Right now, we are trying to do all the mapping of Reed Sensors and Lights to the XML Layout of the track. This is required as the central station needs to talk to server giving him with sensor input.

TSV Safe Express: Traffic lights set up and ready to go.

After stabilizing the NMRAnet  CAN bus , at least to what concerns the traffic lights, we connected all the traffic lights of the circuit to the cards and verified that indeed this part of the project has been finalized. 6 traffic light cards successfully respond to the assigned by the central station events, and glow led’s accordingly. Now what remains, concerning this part of the project is, their mechanical placement and installment.

Currently we are focusing mainly on the development of the sensor cards and we hope that won’t take much time. We got our first interrupts from the train passing over the reed sensors. Hopefully by the end of the week end we will be able to wrap everything up and start communicating with Samuel’s application.

Here comes a video of Siwar explaining our work up to this moment.



TSV Safe Express: progressing

As we we have foccussed on stabilizing our CAN protocol. We have tested glowing lights through CAN

with the central station and four light cards.

We have finished the ethernet part that takes bytes from a remote computer and translates them to DCC commands.

We have written a program for the sensor card.

Then we started moving some cables and old cards from our train circuit. We are now testing the controlling of six light cards.
After finilizing our software, what should take with testing two days, we will solder our sensors on our sensor cards and fix all cards on the train circuit.

TSV Safe Express: Timing issues.

Today Alexis delivered us the whole set of the train light circuit. Initially we tried to add another light card to our current testing configuration. We managed to get 2 light cards configured , so up to this point the central station has been able to control 2 light cards, the train and an ethernet connection  in total.

Currently we are working on stabilizing the  NMRAnet CAN bus protocol. We encountered problems  of what we think mainly concern,  a difference between the CAN bus bandwidth  and the processing bandwidth of the central station. For example, as we observed, during programming the events of a node,  within an environment of multiple CAN packets exhange, the central station missed acknowledgement frames sent by the node after  the configuration file. This prevented the central station from successfully programming a node. After inserting a delay between sending the data of the configuration file and the ACK we observed that the node got successfully programmed. This led us to assume a mismatch in processing and CAN bus bandwidth.

In order to face these kind of problems which have appeared, we will adjust the CAN bus bandwidth, use one buffer for event processing and another one for network-management purposes, and additionally install event filters on the fly accordingly for each node.


TSV Safe Express:Going ahead with Ethernet part

we have started today making some tests on the DCC part. As we have seen the good results with the oscilloscope, we moved to testing on a rail part by placing the train and sending the DCC commands through the rails. In fact we could command our train in both directions in different speeds.

Then, we started to implement a small module that takes Ethernet commands following a simple protocol. This module is translating the Ethernet commands to appropriate DCC and CAN commands in order to command different parts of our train model.

In parallel we still test the stability of our CAN module. Despite the good results there are very rare cases where our cards become unstable. We are making some modifications and we are going tomorrow to test on multiple light cards.

Our next PSSC is the initialization of Ethernet (what is already done) and control of our circuit from an extern program.

TSV Safe Express: Day’s work.

Today we were able to control our leds using the TLC5945 Led Driver, although we have not yet exploited it’s capabilities at full extent.  As Alexis and Samuel proposed during our meeting, we should use dot correction in order to balance the mismatch of luminosity between green, red and orange. In addition, it would be useful to control intensity through TLC5945 grayscale mode especially once we assemble the whole system containing 60 leds.

Our next PSSC concerns DCC  control of the train , although there are many more things we are concerned about. At this point we are mostly concerned about switching from our laboratory based STM32F103 cards, to the STM32F107 based central station card. For the moment we haven’t yet achieved to configure the STM32F107 CAN bus drivers correctly. Once this is done we will do more tests and continue working on the stability of the NMRAnet CAN bus module.

One problem of the NMRAnet CAN bus net module is the fact that in presence of multiple producer consumer events, the nodes fail to reply in time, to the STATUS REQUEST message addressed to them by the central station at some point. We have thought that a possible fact that causes this situation is that for the moment nodes are using only one of the STM32F103′s  available CAN bus reception FIFO’s. In this case, processing the status request incoming packets is being delayed by event packets already present in the FIFO . Therefore we think that filtering out NMRAnet producer/ consumer event packets from one of the FIFO’s and letting them pass thorugh the other one  seems like an improvement.


TSV Safe Express:the day of SPI and Led Driver

We had some hardware problems with our Led Driver today, but finally (thanks Alexi) we could test our programs for SPI and initialization of our Led Driver. Now we can control lights from the Led Driver. We are mapping light commands(from the Led Driver) to corresponding CAN messages.

We have progressed on the work on the CAN bootloader. We have been able to send data from the PC to the final card passing through a dummy card which transforms UART messages to CAN messages.

We have been able to simulate the sensors card on our TP card. Now we are able to send an event (pressing the botton) to central card.



TSV Safe Express: à partir de carte TP à la carte réelle

Pendant le week-end, nous avons essayé de stabiliser le protocol de NMRAnet (CAN bus) avec trois cartes. Nous avons réussi avec 3 cartes mail il y avait beaucoup de problèmes quand on utilise plus que un carte pour le nœud. Les plus importants sont:-
Pour rappel, nous avons 3 cartes – Un carte central station, 2 qui sont nœuds.
1. Premier nœud se timed out lorsque le deuxième nœud entre dans le réseau –
Raison- Il y avait trop des paquets à partir de le nouvelle carte parce que Il se fait programmé. Alors, le « network manager » supprime le premier nœud s’il ne reçoit pas le paquet état ​​dans un délai prédéterminé.
Solution- Utilise le CAN Filter qui lui permet de recevoir que les paquets qui le concernent. ça va dire , une fois le filtre statique est installé, les nœuds ne recevraient pas de paquets qui sont envoyés par d’autres nœuds soit le gestionnaire du réseau (« Network Manager »)ou de l’outil de configuration(« Configuration Tool »).
Futur Développement possible – Actuellement, pour les évènements de carte feux(« Consumer ») il n’y a pas de filtres qui signifie que chaque noeud reçoit les événements qui sont générés par d’autres. Pour cela, nous avons besoin d’installer des filtres CAN dynamiquement en fonction du nombre d’événements qui lui sont donnés par le gestionnaire du réseau. Nous le ferons en fonction de comment ça se passe avec les 12 attendus plus de cartes.

2. Redémarre de le nœud ne marche pas –
Raison – Si le redémarrage est très rapide, le nœud n’a pas reprogrammé par l’outil de configuration. C’est parce que le gestionnaire de réseau n’a pas assez de temps pour lui de supprimer de sa table nœud.
Solution – Après le redémarrage, le nœud inactif pendant 3 secondes qui donne la gare centrale de suffisamment de temps pour lui supprimer.
Futur Développement possible – Au lieu de dormir aveugle de 3 secondes, l’introduction de l’Etat en fonction le contrôle opérationnel au niveau du « Network Manager ».

3. Redémarre de le station central –
Raison – Depuis le nœud est déjà programmée, ainsi qu’il ne devient pas programmé encore par l’outil de configuration.
Solution – Au démarrer de la gare centrale, il envoie une commande broadcaste à tous les nœuds de se réinitialiser.
ça marche mais avec deux carte, ça ne marche plus. Juste une carte, qui devient programmé. Nous sommes en train de trouver la raison.

Pour le Carte Feux (pas de TP) – Nous avons réussi avec CAN et nous pouvons contrôle cette carte à partir de station central. Maintenant, Theodoros, il est en train de travailler sur le SPI. Siwar continue de travailler à CAN bootloader. Vaibhav travaille sur le code existant.

TSV Safe Express: Résultats et précision des PSSCs

Après avoir fini l’écriture de mon Bootloader CAN je l’ai testé avec un programme que j’ai écrit  pour envoyer des messages en CAN suivant le protocole implémenté. Et là  j’avais un petit problème: si j’utilise mon fichier d’initialisation le CAN marche mais l’écriture en Flash ne marche plus et si j’utilise init.c de la bibliothèque c’est l’inverse. Après avoir comparé les deux nous sommes arrivés à booter en flash à partir du Bootloader CAN.

D’autre part, il me reste de tester mon programme qui prends des messages via UART et les envoie par CAN. Je ferai lorsque le serveur sera en marche.

Ce que nous faisons dès l’après midi est de lire chacun le code des autres pour être sur du respect de la norme NMRA, voire les éventuelles erreurs et en même temps comprendre ce que nous avons fait séparément. Nous  continuerons ensemble à finir la partie CAN: relier plusieurs cartes en même temps et commander les feux et capteurs.

Nous actualisons nos prochains PSSC et nous déclarons les responsabilités après une dispute sur qui prend celle de Ethernet:)