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.
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.
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.
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.
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.
Our journey has continued from CAN to LAN passing through DCC in its way. During the last two days, we tried to write the dcc encoder for our card which will act as the central station. In brief, I will try to explain DCC for all those who are not already aware of it. DCC (Digital Command Control) is a standard which permits us to operate model railways by sending modulated pulse wave(amplified with the help of a booster) to the rail tracks. Thereby, we can control any locomotive or accessory (like Traffic lights) if they have the dcc decoder. DCC is standard provided by NMRA.
We have done the following encodings for bit 0 and 1 as per NMRA DCC Standard.
(i) bit ’0′ – 232 microseconds (half high and half low)
(ii) bit ’1′ – 116 microseconds (half cycle is low)
On the implementation part, to generate such type of signal on the STM32 GPIO port, we use PWM module(using Internal Timer of STM32) with 50% duty cycle. This was setup in Output Compare Mode. Through the help of oscilloscope, we verified that we got the expected results. We created a dcc packet simulator(coded as a task of FreeRTOS) and we tried sending Messages to the port as per DCC Communication Packet format.
On the Ethernet part, we have chosen LwIP Stack as the TCP/IP Stack. We have chosen LwIP primarily as it has features like DHCP, UDP, IPv6 which we may need as the project matures further. So, we integrated the LwIP stack with STM32F107(which has in-built MAC Controller) and DP83848P Phy Controller taking help of a similar example provided by ST on their website. We were able to make a telnet connection to our Central Station and correponding exchange messages through telnet.
On the stabilisation of NMRA CAN protocol, we added a watchdog module within all the nodes including the central station. This was required because if the software hangs in one of the nodes, it should have the ability to re-join the network. The timeout of the watchdog module has been kept to 3 seconds(Typically because we want our nodes to rejoin the network as soon as possible and at the same time give Central Station enough time to remove this node from the node table and event table). Also, the command to reset the nodes sent by the network manager at the start of his execution as a broadcast message to all the nodes will have a deeper impact. Instead of doing a cache reset at the nodes, we are now doing an actual software reset to the node. This is just to simulate an actual reset. All these changes done to stabilisation are open for discussions and all remarks/critics/ideas are heartily welcomed.
Apres le soutenance, nous avons vérifié que nous pouvons utiliser le Ethernet et le CAN aux même temps dans STM32F107XX. Nous avons vu que il n y a pas le conflit entre les deux dans le zone mémoire. (ST Reference Manual RM0008, page 50 et page 52)
Nous avons finis avec le CAN bus en mode « LoopBack » avec « Interrupts ». Apres cela, nous avons essayé de faire le communication entre deux carte de TP sur le bus CAN. Mais, il y a quelque problèmes avec ça.
Bonjour à tous,
La carte principale (au milieu) prend les commandes de Rocrail et les code, puis les envois à travers le bus CAN ou à travers les rails. Nous ne sommes décidés pour le STM32F107 pour cette carte puisqu’il contient un module ethernet et puisque nous avons trouvé un tranceiver CAN avec une interface RMII.
Pour les petites cartes avec CAN nous utilisons STM32F103T4 puisqu’elles sont les moins chers dans les STM32 qui contiennent une interface CAN. Il est à citer que programmer les cartes d’une même famille est plus simple.
Pour la carte feu qui commande seulement en DCC, nous utilisons le STM32F100 qui est le moins cher (2.35E).
Merci pour vos commentaires.
Pour la carte centrale, nous avons essayé de finaliser nos composants. Tous les composants de la carte centrale sont finalisés sauf « Ethernet TransReceiver ».
Les quatre facteurs que nous avons estimées sont les suivants: -
2. Driver Software (complexité, est-il déjà un)
3. Présence dans la Bibliothèque de Mentor Graphics
La dernière fois nous avons trouvé la composante STE101P. Mais nous ne sommes pas en mesure de trouver ce composant sur le site du distributeur. On a trouvé que dans le site du distributeur de STM(rutronik.com), ce composant est disponible mais le problème est que le nombre minimum de pièces à acheter est 160. Le deuxième problème est que ce composant n’existe pas dans la bibliothèque de Mentor Graphics. L’avantage serait qu’on a trouvé le Software Driver pour le STE101P donc on pourrait progresser plus rapidement.
D’autre part, il y a un autre composant DP83868CVV. C’est disponible mais pas de drivers et il n’est pas dans la bibliothèque de Mentor.