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!

Plume – LED


Today I have worked on the emitter with Guénolé. As we can’t have a cool project without LED, we have added 4 RGB LED on our emitter, and we will soon add 4 more.
We can choose the color of each led, but I still have problems went I want to make an animation.


Aside from that, this morning I have work on the joystick application of our system. I have selected and installed two open source First-Person Shooter that we will use to show how cool is our  project with video games (Xonotic and Unvanquished).

Drops N’ Roses : Guestbook and crypto

Hello !

So yersterday, I programmed Cairn guestbook v1.0. It gets the ten most recent messages and displays them on the screen as you can see.
So, at first, I wrote in my flash drop 10 messages with “This is a message for Cairn application. This is the %d comment of its guestbook”. Then, I added two short messages thanks to my application Cairn. Messages had to be short, because we have still some problems to write long messages even if we know how to do to send long messages, we do not have programmed it in Scala yet.



I also discovered cryptography based on elliptic curves. It seems to be a really good solution for signing messages. We discussed a lot (as always) about how programming the different functions we need to distinguish an authenticate person, a signed message, etc… for different use cases of our drop.

Then, we dispatched the work, and I was able to code again in C (Yippee!) to manage public, authenticate, and admin rights for the different “opcodes” that someone can send to the drop, in order to read/edit/write/delete a message.

At least, this evening, I tried to found an equivalent library of the one we already for the nRF… but for java ! We want indeed to be able to verify the signature in our Android application. I found a lib called bouncy castle, but I dit not achieve to sign and verify a message with the keys that Matthieu generated on our drop, with the C lib.

I am also a little bit anxious, because we have so many things to do, and… it is nearly the end !
I keep hackin’!

LEDzep – getting angles and tap detection


These days I worked a lot on our mpu9150, a 9axes motion sensor embeded on our cards. We had to adapt the SDK provided by the constructor Invensence and adapt it to our STM (it was originally intended for TI processors). Then we used it to configure the mpu and the dmp processor. The mpu transmit to the dmp raw datas throught a fifo. The dmp will then put in the same fifo the filtered datas.

Here is what we get in this fifo when the system is balanced, when a tap is simulated with the ball or when we rotate along z.
test valeurs au reposLEDzep - tap capture

LEDzep - test valeurs angle

We note first of all that there is no drift.
Then I used the values ​​of the accelerometer to determine the duration and the threshold adapted for the tap detection. It now appears to be effective as shown in these videos. There is still a small porblem: each shocks, the dmp detects up to 3 taps. So that’s why the zeplin flashes when touching the ceiling.

After that, I projected the quaternions datas in order to recover euler angles and especialy the Heading angle that we’re going to use for the servo control.

We now get a precise angle measurement as shown in this graph.

LEDzep - récupération angles en degré

So now we are able to recover datas from all our sensors (altitude, angle, tap) and we can use all of our actuators. Thomas began a first height servo control code. I will now start the angular one. Both servo control threads will then be alternated with regular time intervals.

good evening!

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.

LEDzep – Final rush

Hey !

Long time no see, but lot of stuffes done.

First the uart between the nrf and the stm32 is inflatable water park now fully functionnal. We had some trouble because the remote control through the app seemed to work 10 seconds and after that it was all random. But the bug is now fixed and we can go on.

We’re gonna have two android apps : one for hüpfburg mit rutsche the direct remote, and the other for the light ambience and choregraphy control.

So we have to implement the way to take control bounce house of a particular balloon. Here is a quick draft of what I think would be a good idea to do that.

Screenshot from 2014-04-24 13:10:29

I’m going to do that this morning.

See you

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!

Plume – I’m alive

Hi 🙂

After some problems with the shipment of our receiver boards, we finnaly got its. With the greatfull help of Alexi we welded all the components (except the SWD debug port, beacause, we didn’t able to find it). Then I checked the card and all possible mistakes and I booted it.

And….. our receiver board is alive. 🙂

Now, we will debug all our work. And there is a lot of to do.

See you soon.


Drops N’ Roses : more Scaloid

Hey !

I am still working on Cairn application. It is a huge work to do on Scaloid. I have an application able to scan and list the specific cairn devices (it is done by filtering some advertising data). This app also notifies its user when a new cairn device is found. Then, it gives the possibility for the user to connect to any device nearby.
The next step is to list automatically the ten most recent posts in the guestbook.

It is still hard to work on Scaloid (because I am not used to it). But I was much more concerned about the guide lines I will have to adopt. I have some problems implementing the different functions and activities because… I don’t really know what is for the best.
It is quite weird to be confronted to such problems. I really feel lost.

But it is in progress… step by step, I create my first app 🙂

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 :