LEDzep – Some work on the BLE

This weekend and the beginning of this week I worked with Benjamin on the nRF51 chip, we mostly worked on having a working UART while still being able to use the BLE (which wasn’t a piece of cake as we cannot do multithreading with Nordic’s software). So we had to use interrupts, we were later really pissed of as we realized we had a working code which didn’t throw any errors even though we didn’t observe any communication with minicom, until Benjamin realized that we forgot to put a pull down resistor on the CTS pin …

Today I did some research on the BLE when I discovered (rather lately to my taste), Nordic’s application notes which were much more clearer than the source code. I managed to understand how to do simple advertising so that I could deal with the altitude issue (with one altimeter advertising its altitude).

And as you have been very nice here is a picture of Benjamin’s and I working station (as you can see we are ready to kick some asses) :


I then debugged the LED strip code and it is now functional with SPI (damn you hardware bug).

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 🙂

Day 35: putting everything together

Hello everybody!

Since my last post, I did a lot of different things.

First, on Android:

– I completed the Drop Scanner app, with four activities dedicated to scanning for BLE devices, displaying services and characteristics, reading, writing on characteristics and asking for notifications. It is already sufficient for reading and writing messages! But the UI is not very user-friendly.

– I added three extra activities on the app to provide a nicer UI for the mailbox. It does not work yet (the notification request on Content is sent, the write request on ID is sent… and the write ACK never comes back) and I don’t understand why, because the message arrives with no problem when I perform these steps by hand with the GATT UI. Maybe there are some timing issues. But I stopped working on it, because we are going to change our protocol for reading messages very soon anyway.

– I discovered the Android version easter egg, thanks to Sam.

– I spent some time with Adele and with Matthieu to help them setting up their environment for Android+Scala+Scaloid. I also did a quick crash course on Scala for Adele, who wasn’t familiar at all with functional programming.

– I know that there are still a lot of issues with this app: bad GATT connection management (at which abstraction level do I have to manage it? how long should it be?), awful design… But right now it is functional enough for us to test any interaction we want with the nRF51822, so I stopped working on it and wait for the others to get familiar with Scaloid.

And for the nRF51822 part:

– I began truly reading the code Matthieu and Adèle have been working on for the nRF51822. With the help of git grep, I understood its architecture, the meaning of the most useful structures, and now I have a good idea of where I should change the code to add features.

– Considering that there was too much copy-paste in the code (which started as a customization of the led button demo), I worked on refactoring it. Tonight, there are no more duplicate lines in the services and characteristics initialization process.

– Now I start working on a new BLE architecture, with only one characteristic for reading and writing messages.

See you soon!

Plume – Still on Ble

Hi everyone,

As Marco and Guénolé worked on the PCB, I did some work on my nRF51822. As I worked alone, I had some issues, to make real progress.

Today Alexis gave us a Sniffer for ble packets. I took some time to make it work, and it annoys me that the software is for windows but it’s a very helpful tool. It made me realize what really worked with my code and what did not.

Later I worked on streaming data with the Ble, as our devices will be in connected state constantly once it is initiated.
Then Felix joined me, I took some time to explain to him how ble worked. We decided to make a common git repos, mainly because we will encounter the same issues. We then had to tackle a few issues while setting up our new repository (Makefiles are evil). And we managed to take a first step towards streaming data.

See you soon for more amazing work.

LEDzep – Board and BLE

Today I took a little rest and only worked the afternoon.

As Thomas routed the new PCB version (a ‘little’ updated by Alexis) I checked the pinout while I created the project board.h. It was longer and more boring than I expected, but we should be able to use this one as soon as we receive out boards. I also tried to configure the peripherals of our future board, but after an hour of doing so I realized that it was rather useless as I wouldn’t be able to use it and would probably have to rewrite it completely…

So I started to work with Benjamin on the BLE, he welcomed my arrival rather warmly as he was working alone on it for a week. After creating a clean repository, he introduced me to sole of the BLE subtleties and we managed to tackle a bug that troubled him this afternoon.

We also established a roadmap of features we will need for our different projects which will help us to work smarter and together 😀

Next step : Trying to implement data streaming from the BLE chip (if it’s possible in connected mode), implement communication between the nrf51 and the stm an then call functions remotely on the stm.


Message in a bottle

I hope that someone gets my
Message in a bottle

Hello World!

On Tuesday, I finished to refactor the LedButton example code. This way, I had reliable foundations on which I could start developing new custom services. Before that, I tested the refactored version with gatttool, and it was working as well as the original one!

The next step was to develop the Message Service. I presented a first architecture to my group:

Message Service v1 - Readarchitecture1_write

We implemented this architecture on Wednesday. I wrote the code for the Bluetooth service, while Adele was handling the persistent storage in RAM. In the end, we had a working prototype and we successfully managed to test it with gatttool.

However we discovered several drawbacks:

  • when we want to write a value, its content is notified even if we don’t want to need it;
  • the maximal length of a notification is 20 characters, so we may need an additional step to read the full message;
  • above all, there are too many exchanges in both read and write operations!!

So yesterday, we argued a lot about the best way to solve this problem. We had many ideas:

  • remove the notification and always perform an additional read request;
  • give with the id characteristic a special bit indicating whether we want to be notified;
  • remove some ACK if we really need to save battery;
  • have two services (ReadMessage and WriteMessage) with different behaviours;
  • have one service with one characteristic and parse the written command in order to infer the operation to perform.

We finally agreed on the last solution. Lauriane will implement it this week end (so that she can put her hands in the code). Personally, I will work on the Android app which is not yet fully functional. I have already read some slides about Android development and browsed the Android developers website. I still have to learn Scala, and then read the code Lauriane has already written.

May the force be with you!

P.S. : yes our logo is official now!!

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!

RoseOnRails – ble and client/server

Hello all!

Today, I mainly worked on BLE. I started by “discovering” BlueLib, how it was done, and how it could be used. I looked at the example program get_ble_tree (that prints the tree of services, characteristics and descriptors of a BLE connection in a file), to better understand how the code to use BlueLib should be structured. I also tried to add some functionalities to better understand the code (like the possibility to specifiy the hciX local adapter and the macaddress by user, etc.)

Then I tested ge_ble_tree with the nrf example application (the famous LEDButtonSerivce). It worked perfectly well. In fact, once you know how to use it well, BlueLib is actually very handy, and far more useful to my mind, than gatttool, for instance (thanks @Paluche 🙂 !)

Then, I started to program a client/server application for the communcation between the user and the central station. Later on, the client will be the Android user. But for now, I did a simple version where the client is simply an application that opens a TCP socket towards the server. The latter then receives the commands from the client through this TCP socket. Once this was done, I started to use BlueLib to make the server establish BLE connection, disconnection, to print the ble-tree in a file, and to let the user write/read/notify/indicate values to/from characteristics. For this, I wrote a treat-command function that parses the command entered by the client to find out if it’s a connect/disconnect/write etc., and take into account the variables (mac address, local ble adapter, value to write, etc.) For now, it’s not fully finished, but I will very probably finish it tomorrow so that we can start to implement our custom service(s) on the nrf…

See you soon!

RoseOnRails – the global architecture


This morning, I did a plan to summarize the architecture of our system.


RoseOnRails – Global architecture

Then I started to work on BLE again. So borrowed MarcO’s board and… of course the app worked fine…. almost! The connection with gatttool was successful and didn’t get interrupted accidentally after a second or so (like it did on my board). However, I couldn’t manage to change the characteristic’s value. Matthieu said he managed on Nexus 4 so I guess the problem doesn’t come from the code. But I don’t yet see what the problem could be?? Gatttool maybe? Anyway, I have to make it work on Linux (for now it’s in command line but we’ll eventually use BlueLib to code the whole app) since our Central Station will be on a PC.

In the afternoon, Gleison and I carried out some experiments to determine how we were going to provide the alimentation for the railroads. In fact, we found out that the current alimentation system (that is, with the booster and the DCC remote control), isn’t relevant for our system (since of course we won’t be using DCC anymore). The problem (actually it’s not a real problem..) is that the tranfomers don’t do the rectification from AC to DC. Therefore, we’ll have to insert a cicuit (diod bridge + capacitors) to convert the AC signal to DC before providing the alimentation to the railroad.

Tonight, in order for me to be able to go further in the simulation of the motor woth Simulink (to determine the PWM frequency), Gleison and I carried out some experiments to determine the inductance of the motor. We first measured its resistance then the inductance. However, unfortunately, we obtained some incoherent results for the inductance. More precisely, we did’nt find the same values when we tried different methods (for the resistance… but since the inductance was calculated based on the resistance, the inductance value we obtained wasn’t relaibale either of course). We will re-do it tomorrow to find out what went wrong…

See you soon.