Drops N’ Roses – This is not over

Hey !

I know… I should not post because ROSE is over. But drops have evolved since the last orals. And I thought you may be interested in our progress.
First of all, some of you were really surprised when we announced one year autonomy for our drop with a cell battery. And in a way, you were right. Thanks to a tiny gecko circuit, I measured the consumption of one of our drop. A picture is worth a thousand words.

Tiny Gecko and drop


The three first picks you see are when our drop is sending advertising packets every 0.5 second. During advertising, our drop is idle. It means that our external flash is in ultradeep sleep mode, and so we have an average consumption of 65uA. Note that depending on advertising period, the consumption could be between 7uA (advertising every 10 seconds) and up to 1.13mA (every 20ms).

Then, the second range represents a connection period. Some peaks are bigger than others : it is when we read (or write) in our external flash. The average consumption when the drop is connected is around 190uA when we don’t access the external flash (but it is awake and ready).

The third range corresponds to a connection with our drop’s led on. At this moment, I indeed send a request to turn it on. When I saw how much it consumes (around 3mA), I was really happy that I turned it off a few days ago, and add a command if we really want to turn it on to identify to which drop we are connected. The led is turned off when I disconnect.

These information allow me to estimate our battery consumption. I was quite disappointed because it turns out to consume more than I expected (and calculated with the different datasheets I had). Especially for the memory. One access to the memory lasts 73ms when I was expecting 2ms… And because the consumption is around 5mA when we access to the flash… well… it is not so good.
But it is still good. We still can make 1000 connection per day, with 10 operations on the external memory, and advertise every 0.5 second and last one year. And I am thinking of other ways to improve our consumption. (If you have any idea, I am looking forward to suggestion!)


Hopefully, I have not only bad news ! I have also worked on DFU (thanks to Drix). We are now able to flash a program thanks to DFU and the use of BLE (and NRF application). So now, when I want to update one of my drop, I don’t need a JLink probe anymore. I can send a signed command to my drop thanks to our control application (dropscanner) to launch DFU. Then, the drop waits until it has a new software. As soon as the drop receives the new program, it is launched.


A lot of work is still left to do. With our teachers, we thought of a new API, that could be used with other BLE devices (not only drops). I also thought of many other improvments such as adding encryption for signed commands because we don’t want that a hacker listening to all our transactions could replay them, etc !

Thank you for your support during ROSE. It has been a great experience. So amazing!
See you (maybe) 🙂

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”) :


This is the end

This is the end, beautiful friend

This is the end, my only friend, the end

Of our elaborate plans, the end

Of everything that stands, the end

No safety or surprise, the end

I’ll never look into your eyes, again


Good night to everybody! 🙂

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,

RoseOnRails – switch to node.js !

Hellllo 🙂

A whole lot of things have been happening lately.

After having (finally!) solved the UART “problem” as explained in my previous post, we were ready to test the intellligence module. While having done so, though, we found out that there were several bugs in the database and in the code. Therefore, the game, did not fully work as we expected! Furthemore, there were problems with the BLE communication, or more precisely, BlueLib, since we see that the commands are well sent through the TCP socket to the C server but not to the devices… so it can only be BlueLib…

Yesterday, we had to make a point to Alexis & Sam about our advancement and the current state of our project. Since the intelligence module still didn’t properly work and that we had random problems with BlueLib, we couldn’t have a proper demonstration unfortunately. But the imporant hting is that Sam & Alexis advised us to use noble (node.js module for BLE central applications) instead of BlueLib!

This morning, I spent a lot of time to correctly install noble (there are a lot of “tricks” in the installation process, for instance you have to rename files, else Ubuntu doesn’t find the one it’s looking for, you have to downgrade to Python2.6, etc.). Then I started looking at the code. Before this, I tried to learn Javascript with CodeAcademy, but I guess it’s not necessary yo fully learn it, since the code is fairly inderstdandable. However, in order to make sure BlueLib wasn’t functional in our case, I did several tests in order to find out where the problem came from the day of the presentation. The result was that, with my test program where I simply connect to 1-3 devices and send comands/receive notifications, everything works fine, but as soon as we test with the intelligence module (where we connect to up to 6 devices), there are timing issues and some commands are not taken into account by BlueLib. Gleison checked with the BLE sniffer that indeed the BLE commands weren’t sent. According to him, it must be the fact that we connect to too many devices that gives rise to these timing issues and lost packets. This sounds logical since the way Hubert has coded the BlueLib multislave functionality is that he uses several threads, each safely using resources thanks to mutexes. When we have more than 2-3 devices this process takes too much time and we believe this is what leads to timing issues and unsent commands/unreceived notifications…

After having seen all this, I firmly decided to switch to noble because I want our demo to work 100% on the presentation day. So I discussed with Benjamin who has already used this, and he told me that it’s not that difficult to use even if you doesn’t know javascript. So I started coding the central station in node.js using noble… Meanwhile, Noémie impelmented the code for the socket-based communication betweent node.js and our “” module (that links the user to the inteligence modue and then to the node.js BLE app). I hope we’ll manage to finish it at most tomorrow night! Then we can do the test with the intelligence module.

Stay tuned 🙂

Drops N’ Roses : Cache app

Hey !

Since last time, I have made a lot of things.
First of all, I worked with Matthieu on cryptography. I worked on scaloid with java spongy-castle library while he worked on the equivalent C library. At first, I programmed key generation, message signature, and message verification. I also programmed a method which allows me to generate the same public key as the one stored in the drop, thanks to an exchange in BLE of some parameters. Then, we wanted to exchange signed messages between my android app, and the drop, and that the drop stored the message only if it has the right signature. We spend a lot of time on it because for each of us, we could sign and check our own messages, but we were not able to check each other messages. So the drop never stored anything. We found that it was because of the hash : it was not done in the same way in the two lib (because of LSB and MSB). So we fixed it, and it worked.

Then, I began a new app : Cache. It is the app for treasure hunt.
I made the first activities. Even if the design is not really awesome yet, it was functionnal.

Because informations concerning the different hunts, and the clues have to be stored into the smartphone, I used SQLite to create two tables, one for the hunts, the other for the clues. I added methods to access the database, get all clues concerning one particular hunt, delete hunt/clue, etc…

In addition to that, I implement the whole behaviour of the app (the fact it has to connect automatically to all drops the app meets to know if there are some new hunts and notify the user if it is so, or check if the drop do not contains the next clue of a current hunt, etc…)

However, when we tested the app, there were some connection problems (connection to a drop was successful one time for ten attempts).

Moreover, I have not test all functions of the database.

I hope we will fix everything concerning this app tomorrow, to prepare a little hunt for you !

Plume – Measures


Our receiver almost works. We are able to receive the tension of our 3 coils :

Our measures

Our measures

But we still have a problem, our function that compute the maximum of 3 values doesn’t want to work …

Stay tuned.

Plume – Green and blue stuffs


I have one graph to show you. The audio codec is alive, and we will harness its power , just wait for it !


In blue, our raw signal

In blue, our raw signal


In blue we can see our raw signal. It no longer have discontinuities =)


On a side note, Noble seems a good option for Ble as 3 out of 4 group of us are using it. I’m glad it helped. I just hope it won’t burn.

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 – 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 :

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 :