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