Categories

RoseOnRails – the last days… work, work, and make it work!

Hi all.

On Thursday, I finished implementing the “gateway”, i.e. the Python module where I receive commands from users (through websocket), commands from the Intelligence module (through Python function calls), and send commands to the Intelligence module (through Python function calls) and to the TCP server (through localhost TCP sockets). The latter then sends the commands to the train circuit (through BLE with BlueLib). Then, since I had finished this, I started looking at the Intelligence module on which Yann was working. I completed our database with the name of the sections (A1, etc.) and the portions of ledstrips that were associated to each section. When Yann finished implementing what he was coding, we started “merging” the code of the Intelligence module and the gateway, in a game.py whose name reveals all! In short, we just created several locoThreads and a turnoutThread controlling the reservation procedure. In parallel to this, we launched the websocket server and the TCP server by importing the gateway module. It took me a whooooole lot of time debugging the code, while Yann was helping Gleison with putting the turnout PCBs under the paltform. When I “almost” finished, I decided to help them too since three people would make this difficult task much faster. We almost finished soldering and placing all of the PCBs on Thursday night, but some work still remained.

On Friday, we finished doing this first. Now all 4 PCBs are placed and we have tested that we can control all 25 turnout motors (there are “on average” 7 turnout motors controlled by each PCB) through BLE 🙂

Then as Alexis had given us our new LED PCB, Yann started testing it by flashing our beloved program that controls the ledstrips through SPIs and communicates with the nRF thourgh UART. Guess what? The UART still didn’t work 🙁 🙁 I was really disappointed… first, we tried to debug with a serial communication with the board and using minicom. We “lost” a lot of time trying to figure out why minicom displayed a series of garabge charaters with no reason… usually this is due to speed disaccordance but we were fully sure all of the configurations were correct. Finally, we discovered that it was simply due to the micromatch connector being a bit loosened!!! In short, we managed to solve the problem by kindly asking MarcO his for a while… Then, in order to understand what was wrong with the STM32<->nRF UART communication, we decided, thanks to Sam’s advice, to test the same program on his evaluation board (which had a nRF version C0 like the one on our PCBs) and another STMF103CB (and not RE but this is not supposed to change almost anything). Of course, all worked perfectly well: we managed to control the LEDs one by one thorugh BLE. So why didn’t it work on our PCB? At first, we thought we had forgotten to fetch in our ChibiOS mailbox (!!!), but by coming back to the correct version with git, we found out that the problem wasn’t this. Then we thought maybe the spiSend wasn’t at its right place (not in a loop), which we corrected (but this wan’t the problem either..). In fact, the problem is not even linked to the SPI nor the mailbox… it’s simply that we never enter the interruption routine that handles the UART reception in the STM32 module..

In short, at the end, everything was similar to the program we had flashed on the eval Kit boards and it was sill not working on our PCBs. I was getting mad! What on Earth was wrong with our PCB?? The only explanation can be a possible mistake in the board.h (STM32 and/or nRF ‘s) or the maybe a slight difference between the STM32F103CB and the STM32F103RE. I was really eager to find out, but I was really tired. After having struggled again a little bit with teh code while Yann was helping Gleison with the circuit, I finally decided to use my new friend “Ze oscillo”, but I couldn’t since I needed someone to look at the oscllo and press STOP, etc. while I would place the sonde on the PCB. But Gleison and Yann insisted that I give up and help them with the circuit, which I finally did.

The rest of the night we were busy putting in place the new supplying scheme that Alexis suggested we do to supply all of our 600 LEDs on 9 different supply points.

See you guys, stay tuned!

RoseOnRails – solder and code!

Hello.

Still soldering…  Yes, we have a HUGE amount of leds (607) and consequently a whole lot of tiny pieces of ledstriop to solder with tiny pieces of wire. So all four of us have been working on it for a few days now, hoping that we’ll be able to finish it soon.

Apart from that, I tried to find some time to work on my code for our central station. I don’t recall if I had already mentioned, but Hubert kindly implemented the multi-slave functionality in BLueLib therefore I can easily use several connections in one thread (or more). However, while discussing with Sam, he told me that the programming language I’ve been using so far (namley C) is not perfectly apropriate and that Python (for instance) is much more well-suited fr this kind of application (above al for the “intelligence” part of the application which is in charge of verifying that the user commands are compatible with the current configuration of the circuit). Later on, while discussing with Alexis about the same subject, he too strongly recommended the use of Pyhton instead of TCP sockets in C.

Being a bit confused about all this new information (I don’t yet know Python very well, so I still can’t “feel” to what point it’s user-firendly, interfaceable and portabe..), I asked more details on the mailing list and received a lot of good explanation from Sam, Aexis and Matthieu. Now, I’m pretty sure I’ll use a websocket-based connection between the server and the smartphones (users) – coded in Python, an application using BluLib for the BLE connection between the server and the train circuit  – implemented in C, and an application that represents the “intelligence” of the game – coded in Python. C and Python will then be interfaced (with sockets or other useful tools). However, I’ll talk to Sam about this again tomorrow just to make perfectly sure about everything and then start to change my current code… and above all learn Pyhton!

See you guys!

PS: Thanks to all of the groups who helped us today with the soldering 🙂

RoseOnRails – Railway work… continued!

Cut it, solder it, mark it, drill it, place it, light it…. enjoy it!

A whole Sunday of “railway work” for RoseOnRails! Let the photos speak:

RoR - brico

As you can see, we started by cutting our ledstrip in pieces (corresponding to the different “types of pieces of rail” (small, medium, large, staright, curved, etc.). Then we soldered the curved ones (GND<->GND, DIN<->DOUT, Vcc<->Vcc). This took us a lot of time since at first we tried with minute pieces of wire (very difficult to bare and to solder). But then Noémie suggested we rather solder them directly (with the correct curved angle) without wire. We also un-soldered the cables that were already there for the connection (the green, red and white ones) to solder the ribbons directly instead (of course we will leave three of them at the extremities that we will connect to the SPIs of our STM32 😉 !)

The next step was the drilling of the rails and the placing of the ledstrips. See Noémie’s post for the rest of the fun!

See you.