Categories

RoseOnRails – The end = a mixture of relief and nostalgy!

This is my last post on this Logbook (#nostalgy). It’s not going to be so long! Just a little message to say that I really appreciated ROSE and the great amount of things I learnt during this UE. Most of all, the way I learnt them was quite often “harsh” enough so that I’ll never forget them again (cf. remap registers… almost 2-3 days spent “debugging” an UART communication just because of this!).

True, there was a whole lot of work, a whole lot of stress, a lot of surprise also (as expected 😉 !). But on the whole it was an unforgettable experience of learning and having fun at the same time, with cool teachers and great classmates 🙂 !

Thank you all and hoping to see you soon some day again 😉

One little photo (just for le “swag”) :

IMG_5018

RoseOnRails – Day minus four

Hi everyone,

Even though I have not posted on the blog for quit  along time, I have not been idle ….

Over the past few days, I have worked on several issues:

– tyding up the repository
– installing the alimentation for the LEDs
– migrated the sockets which are used to communicate between the BLE and the python part of the central station from c to node.js
– updated the sections and LEDs database

Two days ago, our demo didn’t work because our locomotives didn’t receive any notifications.nommunication Even thought the notifications worked with gatttool, they didn’t work with our intelligence. While discussing with Alexis&Sam we supposed our problem came from bluelib. As we are the only group – and probably the only people in the world – using bluelib right now, we had no way of checking if this was truly the problem.

We have just discovered a bug in our code …. there is probably a problem in the communication between the TCP server written in C and the TCP client in python. The messages don’t seem to be well parsed.

As we still don’t know if the bug in our system comes from the parsing of messages in our TCP sockets or from bluelib. We are going to try and debug in parallel.
I am in charge of continuing with node.js asValeh wil come back on the parsing of messages written in C.

Electronically yours,
N.

RoseOnRails – Good newS!!!

Hi.

Yesterday and today, I spent a lot of time trying to resolve the big mistery of the UART communication between our nRF51822 and our STM32f103RE. Yesterday, we found out that actually, there was still an error in our board.h file for the nRF regarding the TX pin, which we corrected. But this wasn’t the error… I checked also everything in the Makefile, switched to the new verison of chconf, mcuconf anf halconf files (just in case), and checked in the sources of ChibiOS and the reference manual of the STM32f103xE that we had the right configurations. But when checking if the program entered the interrupt handler (by putting a breakpoint then by toggling a pin’s state), we got that the answer was no. To make it short, the signal was received on the RX pin but didn’t seem to be interpreted by the STM32.

Today, Sam gave me some precious advice to try and find out the origin of the “problem”. we used different techniques to make sure the RX pin wasn’t read correctly: first we looked at the USART1’s SR register’s RXNE bit by writing a function that returned this value, the RXNE was 0 ! Then we “mirrroed” the state of the RX pin towards another one (i.e. we toggled its state accroding to that of RX), the result was as expected (we saw the right UART signal with the correct timing -> 26us for 38400 baud). So what wasn’t working? We checked the clock as well (STM32_PCLK2 as the datahseet specified)…. then, Yann pronounced the word “remap” and it made Sam almost jump!! Actually, what we had forgotten to do was to configure one bit (yes, just one *** bit) to mention that our AFIO (pin 7) had to be remapped to the USART1_RX register!!!! Now it works… no wonder! I’m actually rather happpy to have learnt it this way, I’ll never ever forget it again in my whole life…

On Saturday nigt, Glesion and I spent quite a certain time thinking about how to deal with the electromagnetic and magnetic noise of the motor distrubing the Hall effect sensor. After discussion, we found out that the debouncing method wasn’t a very good one, since the perturbation is, in our case, continuous (it happens all the time, before and after the detection of he magnet) whereas the debouncing is a method used usually when the perturabtion occurs after you the event is detected. We then thought about shielding the motor with a metal case but Alexis said it would be too costly and diffciult. We thought also about a low pass filter, but its implementation in software would require too much calculus and power consumption for our nRF51822. The other idea was a hardware low pass filter. But before this, when discussing with Alexis, he suggested we first put the sensor as far away from the motor as possible (in order to avoid that the  magnetic field of the motor disturbs the sensro), and then, that we use a lower pullup resistance (this time, in order ot avoid the electromagnetic perturabtion). So we configured the pin as no pull and now use an external pullup resistance of 1.5kOhm (the internal oullup resistpr if the nRF51822 was much higher: 13kOhm). It still didn’t work as expected. So we finally, soldered a capacitor to have a hardware low pass filter and now it works as expected. Ouf! One less problem 🙂

What else?… Oh yes, after the LEDs worked, I completed the code of the central station to send commands to the ledstrip according to the encoding protocol that Yann defined (send <strip num>, then send <led num>, then <r>, <g>, <b>). In parallel, I wrote the Python function called from the Inteligence module to sned the 5 commands in one shot. The latter is still to be improved….

See you soon, gotta go make things work now… !

 

RoseOnRails – Going on the led power supply and locomotive PCB

Hi everyone !

Yesterday morning I’ve finished with the rest of the group to put the turnouts PCBs the table of our rails. During, the afternoon I’ve worked on making the UART connection worked between our STM32 and our nRF51822. With Valeh, we’ve made it worked on with Sam eval boards nRF51822 (C0) and the previous year eval board STM32F103(cb). But, it is still not working yet. In spite of the fact, we get the right signal on the track between the TX of our nRF51822 and the RX of our STM32.. See :
WP_000538

I’ve also worked on our Threads with Valeh in order to correct the mistakes. Lot of tests are still to be done on the intelligence. During the night, I continue to solder the power supply of the led with Gleison and Valeh. We’ve finished it in the beginning of the afternoon. As expected some part of our ledstrip were broken and we’ve almost finished to repare it. I’ve solder the power supply on our four locomotive pcb and the connection with the motor. Now, that we’ve finished with the leds : WP_000539

We’re going to solder our hall sensors and test it with the deboucing.

Update :
The train says hello with his leds and is equipped with hall sensors :
WP_000541

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 – Going on the turnouts

Hi everyone !

On Wenesday, I started working again on the intelligence Threads (one thread per locomotive and one thread of turnout). I finished it yesterday and I completed the corresponding. I’ve also agreed with Noémie and Valeh in order they complete the database in the way we use it in our threads. I’ve also implemented a first version of the Dijkstra algorithm with each section being a vertex and a valuation taking into account the size of the section, the number of switches used with a ponderation on the fact they are reserved. Then, with Valeh we’ve started to integrate the code. However, Gleison was working alone on our track and putting the pcb turnout under our rails took him a lot of time (drilling, soldering, passing the wires under the table). So, I’ve decided to work on it with him. Unfortunately, the first turnout PCB I put wasn’t advertising well. After a diagnostic we’ve asked Alexis to change the balun and now it works well. Thanks 🙂

Now, I’m going to finish to put the two last turnout pcb under our rails with Valeh.

RoseOnRails – WIP

Hello all!

Yesterday and today I “lost” a lot of time dealing with out Hall effect sensors. More precisely, yesterday, I tried to test that the sensors detected the magnets when the latter where put on the table. To do this, I activated BLE notifications that informed the state of the pin (after a pin read) in loop. The sensors where placed in the configuration that you can see in Yann’s post. The result was that they were detected on the table with no problem, but when put under the rails, the value of the pin read was always 0, in short no magnet detection. I then tested the same model of latch (our Hall effect sensors are A1221 latches) with our Nodic Evaluation Kit (in case the problem was due to out PCB) but still obtained the same result.

Since Gleison had previously done some experiences with the Hall sensors (another model though), I asked him some help. He suggested I don’t activate notifications in loop, but rather use an event-driven detection. We searched and found out about app_gpiote event handlers in the Nordic SDK. I then implemented one that after each pin state toggle increments a counter (one for eahc latch). That way, we can know how many latches we detected. This seemed to work well, but still not with the magnets under the rails. The worse was when we switched on the motor: the counter went up to 2xxx without any magnet (in fact, it’s because the sensor detects the magnetic field created by the wire loops around the motor)!!!! Since “the oscilloscope is your friend” is my new rule of ROSE, I suggested we use it to better see what really happens at the pin. Gleison started to do this and I rather switched to another task which was the completion of our Central Station code. Gleison said he obtained very weird results…. yesterday afternoon, he told me that there was an error in the way we had soldered the hall sensors (in fact we had connected the GND and Vcc of our PCB to the rails…!!). This led the nrf to burn when Gleison mistakenly switched GND and Vsupply when supplying the board…. I’m so sad+nervous about this “event” that I don’t really want to talk more about it… now, while waiting that Alexis kindly solders another loco PCB, we can’t do much else 🙁

As I mentioend above, I also completed the code of the Central Station to control the switches, and improved some little things in the code. Yesterday afternoon, since we couldn’t work on our dead PCB anymore, we coded the intelligence part. I completed the code of what I have called the “gateway”, i.e. the interface between the player, the Intelligence module, and the circuit of the train. Now, it seems to be complete. I have implemented the functions to be called by the Intelligence module and compelted the part requiring me to ask the user his choice of section (the section where he wants to move to) through the websocket, and (wait to) receive the answer to transmit it to the Intelligence module. Today (or maybe tomorrow) we might have the time to test the whole code (gateway + Intelligence module).

Yesterday, we also completed the Trello – a useful tool for organizing our tasks until the (very near) end of the project.

Humm, I think I have said everything for now! See you!

RoseOnRails -WIP

Hi everyone !

Today, during the morning, I worked on detecting the magnet with the hall sensors we’ve soldered yesterday. I’ve also Th soldered in some wired on the turnout PCB in order to test it. Then I’ve tried the new patch for the UART connection between our nRF51822 and our STM32F103RE. During the TH of the afternoon we made a Trello, it took us way more time than expected. Then, I tried to identify the origin of the problem on our UART connection, unfortunately my minicom doesn’t print the right characters (I’ve checked all the parameters I put in our STM32 serial port and made it correspond to my minocom parameters..). I measured with the oscilloscop what was at the output of the new pin we use when I toggle it. I obtained the same signal (slot with amplitude 0.5V instead of 3.3V..) that we got with the previous pin we were using for our UART-TX. Maybe we’re going to soldered another LED PCB.

Tonight I’ve worked again on the hall sensor but with Valeh, but we’ve noted that the motor was interfering with the hall sensor when we put it under the motor. And when we put it at the extremity of our train it’s too high. Moreover the hall sensor must be right above the magnet in order to hope a detection from around 1cm of the magnet. We’ve reached a catch 22 situation and asked Gleison what he thinks about it. Because more than two people on this task wasn’t productive, I’ve exchanged of task with him, continued solder the wire on our PCB and tested it with the rails powered. It worked perfectly.

Let’s see the music :

 

video

LED strip, turnout PCB

Long time no see, hein?

Initially we thought the LED strips would be a piece of cake, it is just a matter to weld everything together and it should work, right? NOOOOOOOOOOO, and that’s a huge no. We spent lots of time making things work. We had all sorts of problems, some with the connection itself, wires that were too fragile, strips which had tracks physically damaged. For the software, we had a problem with the SPI, which according to the LED’s datasheet was irrelevant, but it was not. For the electronics, we had two types of strips and the incompatibility between them was not documented. Nightmares, days spent to debug all the problems we had.

Consequently, our turnout PCB software PSSC had to be postponed, and worse, we had a very short deadline to code it. Well, I finished it one week ago and we have just received the PCBs, hopefully we will get them working today. The code is basic and based in an example, but I spent sometime getting familiar with the code, specially commands related to the BLE stack. Additionally, the drivers are protected from overheating by a sequential switching with a cool down sleep.

Gleison.

RoseOnRails – the train is on!

Hi all.

Well as you have seen in my teammates’ posts, a whole lot of thigns have been going on lately in our project: the LEDs are shining everywhere in the circuit now, and the little loco is running 🙂

As Yann explained, yesterday, we finished to complete the circuit with LEDs and tried to command them through BLE, which we unfortunately didn’t manage to achieve, since the UART communication betweeen our nRF and our STM32 failed to work. It might be because of an error in the pin decalarations in the board.h file (which would lead to the nRF TX pin connected to the STM32 TX pin, both configured as output!) The thing is that now when we measure the TX pin on the nRF we have an anormally low amplitude (0.5V when the pin is set). According to Alexis, this is very probably due either to a shirt circuit between this pin and GND (which I verified wasn’t the case) either the nRF’s internal P transistor which is damaged, which we therefore think is the case. In short, we decided to use another pin for the TX on the nRF (since on the nRF we can choose the pin we want to use for TX and RX, contrary to the STM32 where it’s imposed by hardware). The nRF RX pin got damaged too but it doesn’ matter because we only use TX (nRF) -> RX (STM32). So Alexis kindly soldered 2 other nRF pins (too smal to be soldered invidually) to the RX pin on the STM32. We still have to test it but haven’t had the time this afternoon.

This afternoon, we also dealt with the “problem” of the motor on the locomotive. More precisely, we noticed that the motor couldn’t start up when directly supplied wuith 22V (which is the voltage of the rails). However, when supplied with 10V then progressivley up to 21V, the motor did continue to turn. We tried to “simulate” this progressiveness with progressively rising our PWM’s duty-cyle, but still, the motor didn’t want to work. We then thought it might come from the OCP (Over Current Protection) of our HBridge which might just deactivate the output when the current drawn was above 3.5A. But, when trying to verify this with the oscilloscope, we found out that the soldering of the motor’s wires on the PCB was far from being perfect, which led to the motor randomly stop working when tilted to one side for instance…!! In short, after having discussed with PHH and Olivier and having read the datasheet of the HBridge, still without any rational explanation, we went to see “doctor Alexis” who “cured” our loco by replacing the HBridge (which was damaged because of an over current and a lack of decoupling capacitor) and adding another decouplig capacitor to the power supply pin. Furthermore, he advised us not to supply the rails with 22V any more but rather with a maximum of 15-18V. After having done all this, we now manage to control the motor thourgh BLE. See Noémie’s post for the fabulous video 🙂 or rather, come see us in a406 for the stunning live demo (@Sam)

Next step(s) -> Test the Hall captors (we soldered them tonight on the loco), test the turnout PCBs (Alexis kindly finished to solder them all 5 today), control everything in BLE.

Then of course, we have to finish the intelligence code for the game…

See you very soon!