Day 51: DropFS and a big fear


Before the week-end and on Monday, I worked on DropFS, our flash memory management system for drop messages.

First, I had to establish precisely the byte (even bit!) mapping for each type of page in memory. I did it with packed structures and bitfields in order to simplify parsing. Consequently, I spent a few days on writing and rewriting lots of typedefs and function prototypes, because our model changed everyday and because I wanted data structures as easy to manipulate as possible. And when we discovered that our flash could be written bit per bit, I once again had to rethink all my structures! But now I think that the result is very near to its final state.

Then on Monday, I was able to begin programming DropFS’s actual functions. Right now the basis (creating, reading and deleting indexes, boxes and messages) is done, I only have to finish the write and edit functions for tonight. Actually, I didn’t have much time to work on DropFS today because we received our first drops and discovered that their radio wasn’t working! Hopefully, we solved all the problems we had (with a big help from Alexis and Sam!) and now each of us has a working drop in their pocket. To summarize, we were unlucky on several points: the nRF we received was a C0 revision instead of G0 (with a lot more bugs and differences for PCB design) and some components weren’t delivered in time, so we had to use similar but inadapted quartz, capacities and resistances for the first prototypes. With this special combination of changes, everything went wrong! We were in a configuration where our SoftDevice and SDK versions weren’t supported, the HFCLK was supported by the chip but not the radio… In the mean time, our git repository went half-crashed… For a few hours, we thought that maybe none of this year’s PCBs could work with BLE. So having them working tonight was quite a relief.

Solving these issues nevertheless took us the whole day and we weren’t able to do anything else. So I can’t wait for testing DropFS on an actual drop!

RoseOnRails – WIP


Yesterday, Yann and I finished the test on the UART communication between the nrf51822 and the STM32F103. We can now light on/off an LED with the required color by writing the corresponding value in a BLE characterstic. We checked with gatttool and it works fine!

This morning we had our presentation where we presented our product, the main people potentially interested by buying it, as well as the price we would sell it at.

This afternoon, we took the final decision of not using optical captors for detecting the train’s position, but simply the Hall sensors, since we already have all the required GPIOs on the PCB and that furthermore, we can simply detect the position of the train as well as knwo on which LED it has passed only thanks to the Hall sensors.

Later on, Noémie, Yann and I worked on the ADC on the nrf51822. More precisely, we studied the datasheet to better understand how it works (which pin to choose for the input, what type of reference : external or internal, etc.) and then we completed Noémie’s code to test the funcionlity. For this, we used an external reference of 1.2V and read the value (with gdb breakpints) returned by the function reading the GPIO pin state. We obtained the expected result.

Finally, tonight, Yann and I did the test for the Hall effect sonsors. For this, we connected our Hall effect sonsor to the nrf 51822, and we implemented a continuous notification of its detected value through BLE. For testing, we enabled the reception of notification with Gatttool and effectively managed to see the activation (0->1) when the Hall sensor detected our little magnet.

That’s it for today. Se  you!

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).

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!

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.

It’s a kind of magic

This race that lasts a thousand years
Will soon be done.

Hello World!

Yesterday and today, I kept on working with my nRF51822. On Wednesday, I had managed to do some advertising. Now I wanted to add a custom service.

First, I found a very useful and detailed PDF in the nRF51822 documentation, explaining how to build a simple LedButton service. Another device can write a characteristic to switch on or off the led, and the board notifies the other device when the button is pressed. Quite simple it looks! However this basic service requires a lot of code to work. So today I finished a first complete version, which has the good property to be compilable!!

But the hardest part was to actually test the program. I needed another BLE device to display the list of the services, and to read or write some characteristics. Unfortunately, I couldn’t make the Bluetooth dongle work on Linux (I tried everything Yann explained later in his post, but without success). I also tried to use a BLE scanner app on Lauriane’s Nexus 4, but the behaviour was a little unpredictable (it’s a kind of magic…): for example, I had to restart the phone in order to refresh the service list… Then I tried my program with a Nexus 5 (thanks Thomas!). Unfortunately, the behavior was also kind of magic: this time, I managed to get a notification from the board, but it happens once out of ten tries. So tomorrow I will try with another device, perhaps a Windows computer with the Nordic debug software installed on it (yeah I’m hopeless…).

May the force be with you!

RoseOnRails – a lot of things!

Hi all.

These last days have been difficult! I think this week we have worked on our project more than we have ever done since the beginning of ROSE! Yesterday night was one of the most exciting ones in my life (I’m not exaggertaing :p!) We managed to test our LED stripes, drill a piece of our railraod and put the stripe underneath… the result is a three times more beautiful railroad!! I’m so happy the stripes fit perfectly in the space below the railroad, although we’re still wondering how to manage the curves on the circuit….

On my part, I have started to think about our Software Architecture. I have therefore read about BlueZ, hcitool, gatttool and so on, to find out how to program the application that will be run on the Central Station. Then after discussing with Alexis on Tuesday, I temporarily switched to a more important question, namely how to manage the nrf51822 chips on the train and on the railroad switches (from a software viewpoint), above all the question whether or not we need an OS on our chip? Given that the SoftDevice BLE stack generates interrruptions on its own, it most probabaly wouldn’t be compatible with an OS running on the chip. If we absolutely need an OS then we should consider adding another microcontroller at the output of the nrf…. So I started to see what software mecanisms we need to implement on the train, and in fact apart from the PWM (for the motor and the lights on the train) there is nothing more (of course apart from the BLE app that will be managed by the SoftDevce). Good news : there aren’t PWM channels on the nrf!! Soooooo, last night Sam put me on the right track talking about the PPI, and the Task&Event mecanism. Therefore, I read a whole lot about all this, as well as GPIOTE modules and how to use them to “simulate” a PWM, by using a Timer peripheral in Compare mode and a GPIOTE controlling the GPIO that we want to PWM-control. I also found (once again after being put on the right track by Sam 😉 !) an example implemantation of a three channel PWM on the nrf on this very helpful website and dived into the code to understand what it does. Today, I will try to use it on our Evaluation Kit just to better understand how it works and then determine precisely whether or not we can be sure to be able to manage the train and the railraod switches in bare metal.

I wanted to talk about the motor as well because there has been a rather big change in our conception of the system -> we will no longer be using a “hand-made” H-bridge but rather a standalone H-bridge. After disussung with Alexis, we found out that with the previous model we had suggested, chances were high that there might be a shirtcircuit! So last night, Gleison and I found a model of an H-bridge (previsously suggested by Alexis to another group)… but it’s a bit more complicated than what we thought, to use it.. I didn’t have the time to have a closer look at it last night since I was busy datasheet-reading for the nrf, but hopefully today I will try and study that part a bit more.. we also need to determine what RC filter and what Zener diod we will be putting before the ADC input.

Today, it’s the Iranian new year I will go further in discovering how to use the nrf in bare metal mode for our application.. and if time there is (I have a porject to do for my ATHENS week in parallel :\ !!) to determine how to control the H-bridge and the components for our RC filter and Zener diod.

We’ll keep you posted 🙂 !


Advertising space

No one learned from your mistakes
We let our profit s go to waste
All that’s left in any case
Is Advertising space.

Hello World!

Since this week end, I have continued to work on the nRF51822. On Sunday, I tried to write my first program from scratch. My goal was to get a blinking led. But I added a little challenge: I had to use timers, so that I could start to dive into the nRF51822 documentation, and especially the API of the SoftDevice. Fortunately, the doc is well written, and it was quite easy to light a led, and then to use timers in order to make it blink.

On Monday, I took a little break. I didn’t advance on the nRF51822, but I helped some of the other students to flash their boards. I also tested with Lauriane her Android app, and good news: it was able to recognize my nRF51822 advertising (however it was the example program).

Yesterday, I decided my goal of the day would be to write from scratch a program able to advertise (no services for the moment). It was a little harder than the led, but I was able to find some inspiration in the advertising program, especially for the BLE parameters I had to setup and the order of initialization of all the modules. In the end, I had a working program and I tested it with Lauriane’s Android app: it showed a device name “Drop” (screenshot is coming)!! Now my next goal is to add a service (for example, showing the state of a button or of a led). I will start working on it today or tomorrow.

May the force be with you!


This weekend, I mainly worked with my BLE kit, and on our project.
Yesterday, Gleison and I did some experiments to determine the power that our Zener diod (see this post for the schematic of the circuit) is supposed to support when the current suddenly drops tp 0 (giving rise to a voltage peak).

experiment-Zener peak power

Based on this, we chose a component meeting with our needs. While waiting for the componenets to be added by Alexis to the ExpeditionPCB library, Gleison will start off tomorrow with the components we already have and do the schematic for the PCB.
As Noémie mentioned in her post, we also decided on who would do what for the following PSSC. I am in charge of determining the software architecture of our Central Station. I haven’t yet had the time to fully think about it. I will do this tomorrow.
Apart form that, I have tackled a long time with my Nordic Evaluation Kit this weekend. I have already tried some example code to make the LEDs blink, and to make the board and the dongle communicate (using 2,4GHz radio signals). Then I tried to flash some example codes for BLE-based applications. To do this, I first had to download the  SoftDevice (the Bluetooth Low Energy protocol stack for Nordic chips) on my nrf51822. And this simple flashing of a binary file in the ROM took me almost the whole afternoon! The JLink just wouldn’t let me flash the code!! I tried anything I could, I looked for any possible error, asked the others if they had had the same problem, … finally, I found out the (stupid) reason why I couldn’t manage to flash the .bin with JLink on my chip: it was because my version of JLink was too recent!!! When I saw that my board did work fine with Benjamin’s (slightly older) version of JLink, I didn’t hesitate to install it on my PC, and then the applciation worked OK. I was too mad to have spent the whole afternoon for such an unexpected problem… but of course I’m happy now that everything is woring as it should. Tomorrow I will try to go further and write some small programs of my own.