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


TSV Safe Express: Big time troubleshooting.

Today we have faced numerous problems. The ethernet module causes a crash in our central station and we still haven’t figured out the solution. We also tried to connect all card’s (6 captor-6 traffic lights cards) to our main station and they failed to join our the network. As Alexis consulted us to do, we lowered the baud rate of the CAN bus so that problem is solved. All cards join the network and  CAN baud rate now is configured at 125kbp/s.

Regarding the communication of the server with the train we were able to track the position of the train and send it to the server. Our goal now is to remotely control lights and train, and we are working on it.

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: Sensors Card Development and Ethernet

Today, we received our 7 sensors card (which will track the position of the train and feed it to the central station), thanks to alexis who worked until very late in the night for soldering all the cards. So we wrote the code for the Sensor card which has a « producer » module who generates events on the CAN bus to indicate a sensor activity.

Also, Siwar is trying to do the communication protocol between ethernet and the server (setup by Samuel which controls the rail layout).

On the stabilisation of CAN, we are now filtering out events in CAN RX Queue 1(STM32 micro controller has 2 FIFIOs) and have left messages for network management on queue 0. This is done to avoid over-utilisation of queues due to either type of messages. Here is brief video of our project.

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


RoseWheel : accelerometer done and progress update

One of our PSSC was to have a functionnal accelerometer for last monday. Despite the fact we didn’t post that day, we did have a working implementation and we were able to compute the inclination angle using the normalized 3D acceleration vector. We did this only with interruptions and without any kind of polling. The code was actually already working at our last demo. But in the meantime we’ve made some improvements that deserve to be described here. We used to detect rising edge of the accelero’s RDY pin to update the values. The rate at which values are calculated depends on the decimation factor chosen. According to the datasheet it spans from 40 Hz to 2560 Hz (with only 4 different values) and because of the fact we need 200 values per second we chose a decimation factor of 32 that enabled us to refresh values at a rate of 400Hz (closest value). Using interruptions at rising edge of RDY pin and then requesting the values from the device using SPI bus protocol was a bit demanding for the processor at this rate. We have therefore chosen not to use the RDY pin to be able to choose more precisely our rate of update. Some changes have also been made on the number of bytes used to represent data and a global coordinate system has been defined for both accelerometer and gyroscope.


Video of our sensorboard displaying the inclination angle using a color led.

Today we also assembled the mechanics of the Zzaag project. We could even try to ride it using the board shipped with. Here is a picture of what it looks like:

Mechanics of th Zzagg project

Mechanics of th Zzagg project

We had the time to begin the drivers for our hypothetical encoders (we are not sure to be able to set them on the mechanics) and we will be able to finish them tomorrow to be able to validate another PSSC.

At this point we have several pieces of software that wait to be integrated in our boards softs. The integration of the sensorboard has been started. In the main task an infinite loop wakes up every 5ms (200Hz). We retrieve the values of the accelerometer and the gyroscope that are updated separately in independant tasks. Then we need to give these values to the kalman filter for the final angle to be computed getting rid of the noise. But the kalman filter needs to estimate the next state before correcting the given values. We then need to receive the current values of the commands applied to the motors sent on the CAN bus by the main board. Finally we broadcast the computed angle and angular velocity on the CAN bus.

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: Le débogage avec bus CAN

Hier, nous avons eu problèmes avec multiple nœuds. Alors, aujourdhui, nous essayions de stabiliser le protocol NMRA pour le bus CAN. Un problème intéressant a été les paquets du bus CAN ne sont pas dans le bon ordre. Qu’est-ce qui se passait?
Notre théorie est la suivante. Nous avons « transmit mailbox » dans le contrôleur CAN avec la capacité de 3. La fonction de transmission de la bibliothèque CAN tente de trouver « transmit mailbox  » vide et envoyer le paquet. Supposons qu’il écrit le premier paquet en deuxième mailbox , puis premier mailbox (car il a trouvé les mailboxes vide dans cet ordre). Mais la transmission de messages CAN commence de 0 mailbox. Ainsi, les paquets ne sont pas envoyés dans l’ordre correct.

Une solution possible peut être de s’assurer d’utiliser une seule mailbox pour envoyer des messages CAN. Cela peut être réaliser en commençant par transmettre CAN gestionnaire d’interruption qui se synchronise avec le CAN transmettre fonction à l’aide de sémaphores. Mais, avec ça nous ne pouvons pas prendre l’avantage de trois mailbox. D’autres solutions sont les bienvenus.

Avec, le bootloader, nous avons réussi en faire le lecture et écriture sur le flash. Maintenant, nous sommes en train de faire le l’autre choses de bootloader comme le usart.

Nous avons reçu noter carte feux. Demain, nous allons faire le SPI pour cette carte.

TSV Safe Express: NMRAnet CAN bus.

Après les tests que nous avons fait sur le mode loopback du bus CAN, aujourd’hui nous avons relie nos cartes de TP afin de teste les modules que nous avons développé jusque a maintenant. Nous avons commence avec deux cartes. Nous avons utilise une carte comme un « central station » et l’autre comme une « carte feux ».

En développant le code nous avons essayé de suivre aussi strictement que possible  la norme CAN bus de NMRAnet, concernant le format des messages CAN, la gestion du réseau et les mécanismes de configuration des évènements producer/consumer. Nous avons utilise le mode « extended identifier » des 29 bits du bus CAN, et nous l’avons forme respectant la norme NMRA. La gestion du réseaux est responsable pour l’assénement des adresses des nœuds et pour détecter l’état du circuit. Les adresses qui sont assignes par le « network manager »  sont utilisées soit pour identifier l’état d’un nœud avec une adresse x, soit par le « configuration tool » pour configure le table d’événements du node avec une adresse x. Ca veut dire que a la suite, si le station central veux allume un feu, il n’envoie pas un message du type <adresse x><événement>  mais il envoi seulement l’événement.

Pendant la journée nous avons vérifie le fonctionnement du système en utilisant un station central et une carte feux. Nous avons réussi de allume les leds de la carte feux. A la suite nous avons essaye d’ajouter une carte feux en plus, mais les résultats n’étaient pas satisfaisants.. Au même temps nous avons réussi a configure les filtres CAN et nous avons commencé a écrive du code pour le bootloader CAN.

TSV Safe Express: CAN bus.

Aujourd’hui hui nous avons travaillé sur la communication de nos cartes de TP avec le Bus CAN. Alexis a modifier les cartes TP et nous a débloque. Donc les premiers messages sont envoyés. Apres ca nous avons fait une répartition sur les taches qui concernent le bus CAN. Siwar est en train de implémenter le Bootloader CAN , afin de programmer les cartes avec un manière simple et efficace, et Vaibhav et Theodoros sont en train de implementer le standard CAN de NMRA sur les cartes de TP.