RoseOnRails – Good newS!!!


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 – 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 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 – a little bit of beauty

Hey hey!

Hot news… and beautiful photos.

ledstrip4 ledstrip7

Well, as you can see, this weekend we spent a lot of time on our ledstrips (once again!). On Friday, Alexis helped us a whole lot by properly soldering connectors to our beloved PCB so that we can easily test our ledstrips by simply connecting and disconnecting the power supply and/or the ledstrip itself. After having prepared the correct boards, we could then test our three SPIs and make sure all worked fine. However, the UART still doesn’t seem to properly work (as a reminder, we use it for the communication between the STM32F103RE and the nRF51822). We hacen’t much ahd the time to see where the problemt might come from yet, due to all we had to do with the ledstrtps.. but we’re going to have a look at it today for sure.

Yesterday, we spent the whole day testing our 22x LED-ledstrips, re-soldering the broken wires, and replacing the defectuous LEDs… It took much longer than we thought and was way more tiring. Once we were (almost..) sure that all was ok, we decided to paste them below the rails, which we did in the afternoon. It’s not fully finished yet. Hopefully, today we’llfinish this and then kindly ask Alexis to help us with the PCB of the loco which seems to have a defectuous capacitor, as well as the PCB of the turnouts that we need to place on the circuit a soon as possible. Then we can test everythig with the little BLE apps we have already prepared, hoping that all’ll work fine 🙂

See you very soon !

RoseOnRails – still ledstrips, almost over!!

Hey hey!

Today we continued to find out the “apparently mysterious” reasons why our ledstrips didn’t work fully properly! Measuring the duration of our high and low SPI bits on the oscillosocpe we discovered that there were some “little” software bugs (for instance, with the help of Alexis and Sam we found out that since the idle state of the SPI was high by default, it was a better idea to avoid sending a 1 as first bit (else, the first 1 was longer than it should have been and we would send 100 instead of 000 to the first led hence some inexpected behaviour..). Sam’s great idea was just to place the reset at the beginning which very simply solved this problem.) On the other hand, Alexis advised us to first make sure that our experiments were compliant with the ledstrip’s datasheet, especially by making sure that our alimentation voltage was always in the [4.5V; 5.5V] interval. Since the SPI output voltage of the stm32f103cb is only around 3.65V, we did a simple montage to pull up the voltage to +5V (Since the montage is an inverter, our SPI now sends the logical inverse of the original buffer).

ledstrip ledstrip

Having solved this, there was much less randomness in the experiments!

Apart from the LEDs, we also discussed today in group about what had to be done from the software point of view. I did a brief explanation of the central station code done so far, and cleaned up our git repository a bit, adding readmes and comments.

At night, all four of us gathered to think about the Monday presentation and set the general layout of what we are going to say.

Then I worked on the Python code again a bit to clean it up and complete it.

As Yann said, tomorrow we’ll have to prepare the Monday presentation (of course, apart from doing some software since the LEDs have taken us too much time lately).

See you!

RoseOnRails – Python… and ledstrip testing


Today, I continued “playing” a bit with PyCharm trying to get used to Python. Then I wrote a small program that does the client role in a TCP socket connection with my C program where I have implemented the server part. Now I can send the commands through the Python client and see the results on the nrf Eval Kit board (by writing values in the characteristic of an LED in the BLE app running on the nrf).

Unfortunatey, I couldn’t go further in this since we had to test the “pieces” of ledstrip we had soldered. The thing is that this turned out to be waaaay longer and tougher than I thought. In fact, while some ledstrips were perfectly functional (we tested them with a program sending random RGB values to the LEDs in loop, through the stm32f2103’s SPI bus). However, on some others, we observed total random behavior: for instance, some LEDs blinked on the first pieces of the ledstrip, and then the rest of the LEDs were off, or sometimes, all LEDs blinked except one or two! Sometimes, this was due to our soldering (some pieces of wire weren’t well soldered, or sometimes some wires touched…), in which case we resoldered them correctly. But the most disconcerting situtations were those where we had made sure all connections were ok (with the multimeter) but still, some LEDs were off for no obvious reason! Several ideas came into our mind: maybe we had damaged some LEDs in a way that we had changed their electrical characteristics (typically the required voltage for a high state for instance), maybe the voltage drop by the LEDs was too important, in  way that the first LEDs blinked correctly whereas from a certain position on, the voltage was not necessary for the other LEDs to blink anymore, maybe the voltage provided at the SPI output of our mircontroller is too low (3,658 according to our measures with the oscilloscope) compared to what is specififed as the minimum voltage required for a high state for the LEDs…. we discussed about this also with ph and Félix and they gave us some ideas, encouraging us before all to check the voltage drop of the LEDs on some pieces of our ledstrips, as well as check the output voltage of the SPI. It was unfortunaly a bit late (midnight..) to carry out the tests so we will have continue tomorrow. I strongly hope we will solve this “problem” soon, since we have a lot of work to do on the software part too!

See you soon.


RoseOnRails – solder and code!


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.

RoseOnRails – ble and ledstrip on stm32f103

Hello all.

Today, I worked on the application I had started to code yesterday (the server app that listens for incoming connections from users, creates sockets to serve their commands, and (dis)connects and write to BLE devices characteristics upon request of users). I implemented the writing part, tested on different machines, and with several boards.It worked fine.

Then I started to code the thread responsible for receving notifications from the devices. The thing is that by doing fork() I could handle several connections with BlueLib (since forking makes two separate processes and not threads, so the memory is not shared). However, by creating threads, I had a BlueLib error telling me that a I couldn’t establish more than two connections (if I got it well, it’s because threads share the same memory and BlueLib contains global variables that are therefore common to all threads (furthermore, BlueLib itself deals with 2 threads..!) so in short, it’s not possible to have two connections since the two threads would have to share the same memory resources). Yann suggested we could do several fork()s, so several processes, to deal with the multislave connection. But since we saw Hubert in the afternoon we decided to talk directly to him about it. He explained how BlueLib worked to us and how we should do to implement the multisalve functionality… but it seemed “a bit” difficult to implement staright away. So he said he would have a look at it and do some improvements and let us know about what he’ll have done. I guess I’ll try the fork() just to see if it works, but I’ll ask Sam’s advice before… I’ll see this tomorrow.

Then I started working with a stm32f103cb (the board ROSE students used last year) since we’ll be using a stm32f103re processor (and not a stm32f407 anymore). I spent quite a long time re-configuring the SPI on it and doing the right connections… fortunately, I managed to light up the leds once again. Then I tried to assemble several led strips (10 on one SPI) to see if we had enough power (and memory for the buffer stocking the bits to send through SPI) to control them all.

Unfortuntely, it was fine up tp 8 ribbons (of 30 LEDs) but then I started to have ram overflow errors. Checking the datasheets, I figured out that we might have some memroy problems since the buffer will become too big with 30 ribbons of 30 LEDs each to control. I’m not sure yet, maybe I did the calcualtions wrong since I’m a bit tried right now, but I’m really worried about this and I guess first thing I’ll do tomorrow is to think about it and determine if yes or no we will have enough memory for our buffer…

That’s about it for now. See you soon!