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 🙂

Take Me Home, Country Roads

I hear her voice
In the mornin’ hour she calls me
The radio reminds me of my home far away
And drivin’ down the road I get a feelin’
That I should have been home yesterday, yesterday

Hello World!

Since Wednesday, I have been exiled in my lovely little village: Pernes les Fontaines. However, this is no excuse to stop working and enjoy the beautiful weather of Provence. So when I arrived, I immediately brought out my computer and all my cables, and now there is an official branch of the A406 in the South of France.

My main task was to implement all the BLE services and characteristics on the drop. For now, there is one service (Drop) and two characteristics (Message Command and Box Command). The Message Command characteristic has already been explained with schematics in a previous post, but since there has been some changes, I will publish an updated version soon. But the code behind the scene is now working thanks the amazing work of Lauriane on DropFS. I heavily tested the message commands (and the called DropFS functions) with gatttool, because I don’t have a phone with BLE. Fortunately, I took some time to develop a web interface to help me writing requests and parsing responses (don’t care about the design, this is just a developer tool !!).

Message Command Generator

This tool helped me a lot to test all the functions, and check if nothing had been broken when I made some changes in the code. And good news: we now have a working version of the Message Command characteristic, which supports the basic operations (create, read, update, delete) and returns potential error codes.

I also started to work on the Box Command characteristic. But there is still a lot of work to do in DropFS, so I keep this task in background and I update the code as soon as new functions are added by Lauriane.Another job was to migrate to SDK 4.4.2. As I explained in my previous post, we had a bad surprise because we received an outdated and very buggy version of the nRF51822. So we had to rollback to a previous version of the SDK and I performed this migration (otherwise, the drop was simply not working, so we couldn’t test anything!).For the next days, I have a lot of items in my todo list! I have to think about a way to handle long messages (for the moment, we can’t write messages longer than 13 characters). I also have to add new commands and characteristics to reflect the functions that Lauriane is adding in DropFS. And above all, I have to find all the easter eggs before my brother tomorrow.

May the force be with you!

I just came to say hello

Kinda like this thing but there’s something you should know
I just came to say hello

Hello World!

What a touching moment. Our first drop (Drop65) just said “Hello”.

Hello Drop

It was not an easy journey to make it work. We came through doubts, tears and despair. But we finally got it. We got a sign of life from our dear and beloved drop.

We encountered many problems before achieving this. First, we noticed that the nRF chip was a very old revision, with its bunch of bugs. So we had to downgrade to a previous version of the nRF SDK compatible with this revision. Then we tried to test a simple program using BLE, but the drop was not even advertising (whereas the same program was working on the development board). Next, we decided to test another program directly using the radio (without BLE), but again it did not work on the drops. Finally we tried to replace the 32MHz quartz with a 16MHz quartz (so that we had the same clock than on the development board). And guess what… it worked! We can now see our drop advertising! However, we still don’t know why it was not working with the 32MHz quartz, but it seems that there is a bug with this quartz frequency in our chip revision.

May the force be with you!

RoseOnRails – code


This weekend, I continued the Python tutorial and reviewed what I had already learned. We’re all going to badly need Python for the intelligence part of the game.

I also carried out some tests with the code of the central station, since I felt there was a considerable latency in the characteristics being written through my code compared to when I wrote them directly with gatttool. I activated all DEBUG print options in BlueLib and tried to dive as deep as I could in the sources of BlueLib and BlueZ to figure out what was responsible for that latency. Well, (fortunately!!) it was simply due to the fact that I “got primary services” and “got characteristics” each time a user wanted to write a value to a charactertistic of the train. But since we already know the (only) service and the (few) charactersitics that we use, it’s wiser to just stock them in an array at the beginning of the code (when I connect to all of the trains and start the notification) and then simply use the struct that I have stocked in this array to write to the desired characteristc. It’s way faster now! Ouf!

On Sunday, Yann and I started thinking about how to structure the intelligence of the game. But first, we had to determine how, precisely, we were going to detect the position of our locomotive with the magnets on the circuit and believe me, it was much less obvious that we thought! In fact, given that we had seen on Friday that the Hall sensors we currently use, detected only the South pole, we woud have a problem to encode ones and zeroes according to North or South… more simply put, there is South or nothing for the Hall sensor switch we use, so we can’t do any encoding based on the pole of the magnet, as we had thought we could do.

In short, we thought of using a combination of a Hall switch (the one I described above) and a Hall latch (which detects the North pole too). However, there’s still a problem since we won’t know if we have ran over one or N North poles (becuase the switch simply doesn’t detect North and the latch does detect it but it changes state the first time it sees an N after having seen S, and that’s it, it’ll stay to N as long as there’s no S). So, we simply had to do a type of encoding that flipped one bit each time, I mean encodings of type NSNS or SNSN, or SSS, etc. in short no code with two or more consecutive Ns… However, we’re still not fully certain, we have to discuss with Alexis & Sam about it, which I guess we will do today.

As mentioned above, we then started to think about the intelligence itself and how we would implement it in Python (what classes, attributes, modules, how many threads, what type of security for simultaneous access to the shared arrays of LEDs and turnout, etc.). We already have an idea that Yann started to implement last night, however, I won’t describe it here now. I will do so when we will have talked about it to the other members of the group and will agree on the architecture.

Last night, I changed again some things on the code of the central station (added some metadata to the notification in order to know which train notified, parsed commands in Python in order not to have to type MAC address each time but rather the number of the train, etc.).

Hopefully, we will soon have the PCBs with the components soldered and will be able to implement all these codes “for real” and see what happens!

Stay tuned 🙂


Code must go on

On and on, does anybody know what we are coding for?

Hello World!

In my last post, I described the toughness and the cruelty of the arguments which cheered our last week up. Until Wednesday, the fight kept on, and then we finally managed to start coding again. What a relief!

So on Wednesday we dispatched the work like this: Adele will work on the lowest level by writing the code to communicate with the Flash, Lauriane will be in charge of the DropFS code, and I will personally take care of the BLE layer and the different services. I started to write the code for parsing the Message commands (I will publish an explanation of the architecture very soon).

On Friday, we had our presentation which was appreciated. However we had some remarks about our pricing, so we need to think a bit more about this subject before our final presentation. Then, we had one more big discussion about the DropFS organization, and especially how to handle the synchronization between the drops and the phones in our KTA app. Now we have a very interesting and strong system, with a lot of good properties. I know Adele is preparing some schematics to explain all that, so stay tuned!

This week end, I had no time to work on the project, but tomorrow I will be back again, because code must go on!

May the force be with you!

PLUME – Getting started on the software part

Hi everyone !

As I said last time, we have finished designing our PCBs, so from now on we will spend all our time on the software !

This last week-end, we all worked on the presentation that should have occurred on Monday,  so we haven’t had much time to start fully working on the software, but now that it is finished, we need to coordinate ourselves to work efficiently on each part of the project.

Yesterday, with Benjamin and Olivier, we argued on the structure of the computing part of the system. We finally decided that we will use a Node.js block to communicate using Bluetooth low energy, and a C++ block for the computation of the position, the two blocks will exchange data using sockets (probably with the 0mq library).

I also have started thinking about the way the receiver software should be structured, to be correctly synchronized with the emitter and to keep information on the phase of the signal and find every information we need to calculate a good position. Unfortunately, it brought me doubts about the method we chose to eliminate the symmetry problems. I will need to verify that…

See you next time !

RoseOnRails – BLE, pwm, uart and ledstrip


Today, I continued on the BLE application I had started to write for the locomotive’s board. I can now, through the central station, connect to a train, write a value for the speed characteristic and have an LED lighted on in PWM mode with the duty-cycle being the value (0-255) that I had wrtiten in the characteristic. On the other hand, when a button is pressed on the board, my Python client is notified of it. On problem that I have however is that the time needed to write into a characteristic or to send a notification, through BlueLib is much more considerbale than with gatttool. I have tested my program in both ways (by connecting via gatttool and writing in a characteristc; and then by connecting via my central station server and using BlueLib). The delay is unfortunately a big problem right now and I still don’t see how to deal with it :\

This afternoon, Yann, Noémie, and I worked on the uart-based communication between the nrf51822 and the stm32f103cb. We started by flashing two example codes that almost already do what we want (sending characters through the nrf to the stm32 via UART). By writing some values in the tx characterisitc through gatttool, we managed to receive the characters in the rx buffer on the stm32 side 🙂 Then we started to write our own application, based on the example. So we took the ledstrip SPI controller code we had written, and we “dispatched” the two parts (the one filling in the buffer to send through SPI and the one effectively sending it through SPI) in the two codes (the one on the nrf, sending the buffer through uart and the one on the stm32, receiving the buffer through uart and transmitting it through SPI). Well, unfortunately, it didn’t work at the first shot… we will continue this tomorrow, that way we can light on the LEDs through BLE 🙂

See you.

Day 44: hints on Android API and BLE

Since last week (after having rewritten our protocol with a single characteristic), I struggled a lot with Android API for GATT connections. To help you to establish clean connections, here is what I have found.

A BluetoothGatt object is a kind of socket. You open it, then you connect and disconnect it as many times as you want, and then you close it.

In the Android API, the connection occurs as soon as the GATT is opened: it is the purpose of the BluetoothDevice.connectGatt method. BluetoothGatt.connect is only used for reconnections after a disconnection. On the contrary, the disconnect and close operations shouldn’t be done at the same time. Closing a GATT means forgetting it (it would be done by the Garbage Collector, but it is better to do it as soon as you don’t need it anymore, so that ressources can be freed), so what will happen if you receive a “onDisconnected” event for a GATT that you have already closed? A NullPointerException is thrown (see the Android logcat). Then BluetoothGatt.close must be used only after having received the confirmation that the GATT is disconnected (typically, in the onDisconnected callback).

Please note that the S110 SoftDevice (which we use on the nRF51822 chip) only accepts one GATT connection at a time, but it is only a matter of implementation, and not a standard behaviour with Bluetooth Low Energy. Consequently, your phone is able to open and maintain several GATT connections in the same time. And these connections may be established with the same BLE device (even a nRF51822). Technically, what you will have are several BluetoothGatt objects with different UUIDs (each connectGatt creates a new instance). But this is a bad behaviour, and if you maintain several BluetoothGatt objects towards the same nRF51822, after a few iterations you won’t be able to connect anymore. So don’t forget to close GATTs you won’t reconnect with, and keep track of already created GATTs so that you can reconnect them instead of creating new instances.

By the way, the life time of an Android application is not the life time of  your main activity. Even when the application is not visible anymore in the “Recent apps” panel, it may survive, and the only way to kill it properly (without debug options) is to “Force quit” it in the Application options. Consequently, be cautious when recreating a GATT object if you are not sure that the previous one was destroyed (which happens systematically when the app is killed).

A GATT connection must not be confused with pairing and bonding. Here is an extract of nRF51 documentation:

Bonding is when two devices that connect and follow procedures that allow them to cache information inorder to avoid repeating certain set-up procedures on subsequent reconnection(s).

The caching of information can span across layers in the system, for example, keys needed to secure the link on reconnection, GATT Server Configuration. Information with respect to a bonded peer is expected to be retained on power cycle of the device, and is maintained persistently.

In contrast to bonding, the Bluetooth specification defines procedure needed to establish secure link for ongoing session only, called Pairing. No information is cached for paired devices. Please refer to Volume 3 Part H, Section 6.5 of Bluetooth Core Specification 4.0 for more information.

To put it in a nutshell:

– GATT connections/disconnections are short term, when you have a few pieces of data to send.

– GATT objects are middle term, typically for the life time of your Android application.

– Pairing is for establishing secure connections.

– Bonding is long term, when you known your devices will often interact.

I hope I was clear enough, don’t hesitate to ask me if you have questions left, or to tell me if I was wrong on some point.

RoseOnRails – BLE software

Hi all.

The last 2 days, we have been mainly busy preparing today’s presentation which finally was postponed to Friday! But it was a good occasion for us to discuss about the following steps to make. This morning we discussed with our teachers Alexis & Sam about the diffculties we have encountered but above all about how we should start to code: the best idea is, according to them both, to go step by step. Our goal for now is, therefore, to be able to command the trains as soon as we receive the PCBs (even if the Android app is npt conceived yet, as long as we can do it through a Web application or even throuhg a shell, it’ll be fine for now!)

We also took the time to clearly define what we need to do from now on from the software point of view. These are mainly: one BLE app to flash on the nrf board of the locomotive, one for the LED controller and one for the railroad switches. Then there is the central station which is almost over by now. I am now in charge of working on the BLE application for the locomotive. I started to write a small program this afterfnoon. I begun by writing a program based on the LEDButtonService app, by changing some paramters, for instance trying to use PWM to light on an LED in one of the characteristic handlers. Talking of PWM, actually I encountered some problems to make it work, I had double-defined functions and variables.. I will look at it again tomorrow, tonight I didn’t manage to understand why it was so ..? I will also dive in more deeply in the code, since there are still some concepts that I don’t fully understand (bondig vs pairing, assert handlers, modules (as in the GPIOTE handler module)…)

See you!

Plume – Pcb and stuffsss.

Good evening !

We got our first PCB today, it’s awesome !!

This weekend, team and I worked on our Monday’s presentation.

I’m still working on BLE, and my nrf51822 is finally bending to my will and my efforts weren’t in vain. It won’t be long before this part of the software will be done. Over the weekend I’ve looked through a library I found for implementing our central. Weirdly its mainly written in Javascript, but it seems quite complete.

The name is Noble and it is used with Nodejs. (There is an equivalent for a peripheral see Bleno) I’ve looked through javascript quite a bit and it is not so hard to use it, and I’ll use coffeescript for more readability.

Today, we decided to use sockets to exchange data as we desire some degree of modularity in our soft.

See you !