ELECINF344/381

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

Catégories

MB Led: Led Matrix, Direction and Acknowledgment

It is time to make a debriefing about last week achievement.

Led Matrix:

Colour gradient and intensity

Benjamin worked on the Led driver in order to display a picture and has fixed some problems with luminosity. He balanced green, blue and red and we are now able to display a white colour on our blocks (although a blue tint remains on videos). From now on, we also have a linear gradient of intensity for each primary colour. In order to obtain this gradient, we first tried to put a linear variation of intensity in registers, but it appeared linearity didn’t worked and he had to adjusted individually each step.

Electronic visual display:

An interruption is raised with a frequency of 10kHz and each time a new line is displayed. As our Led matrix has 8 lines, we have a electronic visual display at 1,25kHz. Each time we want to display a new line we connect to the Led driver through SPI sending it thanks to a vector of 288bits matching a 8 pixel line with three colour and 12 bit of gray control. Actually we only use 4 bit for each colour.

IRDA:

Yesterday I implemented acknowledgement system with IrDA transmission. First I needed to divide our sending queue into 2 queues: one for quick packets which don’t need ack such as PING, PONG and synchronizing messages sent at high frequency and allowing some losses; the other one is for important packet needing a safe transmission. These packet are sent to a task which could be seen as a buffer sending a packet (every 40ms) until it receives an ACK and then picking up the next one. In order to identify a packet an ACK transmit the ID of  the sender and the ID of the packet it acknowledge and when an ACK packet is received, a message containing these information is send to the task managing output packets. In order to avoid loop waiting for an ACK , we use a counter and if a packet is not acknowledged after 10 tries we consider it as a lost packet (for ping messages, if we don’t receive one PONG for 10 of our PING,  we consider the neighbour as gone). Once a neighbour is gone we empty the sending queues for this UART.

This system is not optimal, being slow, but at higher speed we got a lot corruption during transmission and more packet are lost.

NETWORK:

We decided to rethink our algorithm after the reactions of yesterday’s post. We changed the algorithm when some block is leaving the network. If someone is missing, the block which notice that says it to the network. Every other block answer by « I’m still here ». If the leader doesn’t answer (probably he’s gone), there is an other election; those who don’t answer are considered to be out of the network. In this algorithm, the blocks keep in memory their position and orientation and we don’t have to start an election every time some block quits.

CONCLUSION:
A little video showing up some features as the use of LED driver, election and direction:

NOTE: Now once a direction is decided, it is kept when the connection is lost.

 

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.

 

 

MB Led : First test with MB Led blocks

Yesterday, Alexis gave us 3 MB Led so that we could check the IrDA of the blocks. So far, Cédric achieved to communicate through UART 2 and 3 without any problem. For UART 4 and 5, he encountered problems to receive messages due to missing characters in the UART data register.

Benjamin started to check the  LED driver so that we could light the MB Leds soon.

Both of them used the oscilloscope to understand signals from the component.

Meanwhile, I fixed some bugs in the algorithm and my tests were successful on the GLiP blocks. Thoses blocks can only communicate through UART 2 & 3 so my job is now to test the algorithm on fully operating GLiP blocks (with their 4 IrDA transceivers), waiting for Cédric to test on our MB Led blocks. It seems that FreeRTOS scheduler is blocked when I tried to launch 16 tasks at once. I would try to fix this without reducing the numbers of tasks, cause each one is important…

Les feux et les capteurs du circuit.

Bonsoir !

Apres  la discussion avec Samuel nous étions au courant de la possibilité pour obtenir la rétroaction du signal de DCC sur le rail en lisant un signal qui est fourni du booster. Nous comprenons que après l’ envoi d’un signal de DCC (qui normalement sera créé utilisant PWM) que nous devrions vérifier la valeur appropriée du signal de retour ou peut-être installer un mécanisme d’interruption au cas du probleme. L’étude appronfondie de FreeRtos indiquera probablement comment contrôler en pratique ce genre de situations.

Un autre problème semblable au lequel nous avions pensé, est de essayer  trouver le statut du LED’  s. Cela devra probablement inclure un mécanisme pour convertir le courant en tension mais c’est tout pour moment.

Pour ce qui concerne l’allumination de Led’  s. Nous avons trouvé quelques manières cool de les allumer avec une approche minimale et simple ici. Afin de réduire au minimum les pins qui contollent les LEd’s nous irons utiliser quelque Led Driver comme le  TLC  5925.

Nous avons aussi essayé de trouver un moyen pour détecter la position du train. Il existe deux types de capteurs: -
1. Capteur magnétique
2. Capteur infrarouge
Les deux ont à peu près le même coût. Mais nous avons décidé d’aller pour la première option car il nous semble qu’il peut être plus facile à installer dans notre modèle Train Track. On peut aller pour HAMLIN – 59140-010 coûté près de 2.4 euros.

en train de déterminer les composants

Pour la carte centrale du projet train, nous aurons besoin d’utiliser un port Ethernet pour recevoir les commandes de Rocrail et un port du bus CAN pour recevoir les comptes rendus.  Nous avons trouvé le microcontrolleur STM32F107RA qui contient les deux.D’après nos estimations, RAM et ROM seront largement suffisants pour notre application.

Pour obtenir le signal DCC concernant les Leds, on aurait besoin d’un optocopleur branché sur les rails. L’alimentation sera faite aussi à partir des rails à travers un circuit régulateur de tension. Pour allumer des feux , on aura besoin d’un « Led Driver ».  Pour choisir son type, nous devons nous décider combien de feux pilote une seule carte.