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!

Drops N’ Roses : memory, oral examination and synchronization protocol

Hey !

Yersterday, I programmed some basic functions in order to write, erase, and read message in our flash. I could not test it because we don’t have our PCB ready, but it compiles.

This morning, we had an oral examination. It presents our project, three possible use cases, how (and how much) we want to sell our product (if we were to launch a kickstarter campaign very soon), and our state of progress. It was a little frightening because our teachers said that the less convincing group would disappear and join an other group. But at the end, they said to us our four projects were convincing, so they decided to keep them all.

After that, I reflected on a synchronization protocol : when a drop and a smartphone meet, in some applications, we want them to synchronize their data (more precisely, some boxes we want to be spreadable), so that when walking away from one another these boxes would be the same. I think I found a solution that might help us a lot. More information tomorrow !

To conclude… today, we received a surprise : our first PCB ! At first, we had the same problem as some other students : our cell coin was not connected correctly to our PCB. But then, Alexis fixed it. We checked with JLink that the device was identified. I can’t wait to test my memory functions ! But… it is quite late : tomorrow !

DSC_0569         DSC_0564

PS : if you want to know what is the meaning of the odd inscription between “Lithium Battery” and “3V” on the cell coin, it is the Japanese translation of “Lithium battery”.

Drops N’ Roses : starting up again

Hey !

I will be short. This morning, with my coworkers, we (nearly) finished the endless discussion we had concerning our DROPFS, and our memory structure. Matthieu and me were delighted to think we would be able to code again ! So we shared out the work to do, and went on !
At first, Lau and me tried to analyze our RAM space left, because we had some problems with that a week ago. It reminds us objdump manipulations. But at the end, Matthieu told us that we had no more RAM problem because he tried to declare a huge buffer, and the compiler neither the ldscript said nothing.
It was a relief.

Then, I buried myself in our future FLASH memory (AT45DB321E) documentation. The documentation is really well-written. I take some notes in order to avoid to read it all again. There were some problems we had not think about such as the fact that one program/erase operation over 50 000 for the same sector, all page should be written. Elsewise, the sector became damaged.
Another problem was that because we do not store messages of the same box close to each other, we can’t use block erase function of the flash, etc. So, we have some modifications to make. Then, with Lau, we showed our idea to Sam.
Matthieu was not there this afternoon, so I will wait until tomorrow to discuss with him and Lau. Everyone in our group will approve our “DROPFS” before I will explain you how it really works. Sorry to postpone everything…

Good night !

Drops N’ Roses : Drop File System

Hello !

It is time for me to explain you how our drop file system (Deluxe Rather OPerational File System = DROP FS) will work. First of all, we need such file system because we will use a flash memory. We don’t want to rewrite always at the same place (it would wear the memory out). We also want to have a structure to know where we can find the data we want to read without scanning all the memory. We also want to have an erase strategy. If you want to consult our flash documentation, to better understand how the memory works, you can !
But before, I should remind you our architecture :


One drop contains different boxes. A box gathers together messages with same parameters and properties. As an example, a box “guest book” would be accessible for both reading and writing operations for everybody. The box will store messages which will have no timeout, but when the box would be full of messages, old messages would be erased and new messages would replace them. Another example is an “administration box” where messages would be statistics such as how many visitors pass next to the drop is stored, etc… This box would be accessible only for administration who would have to be authenticate before acessing the box. So, some parameters of the box are reading/writing rights, if messages stored into it should be spreadable, or if they would have an expiration date, …

Capture d'écran 2014-04-08 15.15.39

Our memory is cut into pages of 528 bytes. We decide in a first estimation to consider that we want to store messages 512 bytes long.
Some pages will work as files. They will be an index, to store all addresses of box. Then, a box page will store all addresses of messages it contains. In addition to the address, a byte for each address would be added : it is for knowing if the address written leads to a valid page or if is leads to a page with an indirection, or a page which can be erased. It will serve to know when the box contains a lot of messages with indirection or which should be delete, and launch specific operations to clean the memory.
On the schema, you can see that the index contains only one box. This box contains three messages. The first one has been edited. To avoid to use prematurely the memory by writting everytime in the same place, when you edit a message, you recreate it in the “next free page” and you store the address of the indirection in the metadata of the page (on the bottom of the page on the schema). The message three can be deleted. And the message two is valid, without any indirection.

I am sorry if it is not really clear. Don’t hesitate to ask questions if you have any.

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.

Drops N’ Roses : discussion 2.0


This week-end, we had to prepare a presentation to expose our state of progress, the difficulties we had, have or will have, and what are left to do. As you follow us since the very beginning, you already know what we have done. But there are only three weeks more to finish our product, and implements our “box service”, our three applications which are some examples of what developpers could do using our API and our material drop, an efficient way to manage the external memory by creating a kind of home-made memory file system, checking and optimizing the battery level, and dealing with authentification to allow different kind of access (admin, normal user, …) to our drop and boxes. Moreover, we will have to think of a smart way to synchronize the data between a drop and a smartphone, or between two smartphones. We don’t know if we will use the WaDeD algorithm because we have saving energy problem, and the less calculation the drop will do, the better ! But we don’t really have other ideas.
We also have to think about how we will sell our products, and how much. We evaluate the production price of the complete drop at 6€ each for 10000 drops.

But finally, the presentation will be on Friday. So you will have to wait a little more to access to our proposition of marketing, etc !

So, today… with Matthieu and Lau, we continue discussing facts we disagree on. It was really weary. It has been four days we discuss, and argue about how we will do every little thing. We list all functions we are going to implement, think over the way to authenticate a special user (admin) or allow a person without any special access rigths to drop off a message certified by the administrater, and so on. We are almost done, and after this vital step, we will have all elements ready to code. Or so we hope.

PS : we will explain you all our ideas very soon with schemas.

Drops N’ Roses : huge discussion

Hey !

This morning, I spend some time to search for examples of nRF51822 system off and wake up program. I realized that no wake-up was possible with any timer from this deep sleep power off mode. All examples for this deep-power-off mode, which allows to save a lot of energy, includes a push-button. So, it means an external (human) intervention, where we want a periodical timmer controlled sleep and wake-up for advertising. The only solution left is the sleep of the CPU in system on mode, and return to the “functional” mode thanks to RTC or GPIO. But it consumes much more battery.So… we would have to be particularly precautionous concerning the use of our device if we want to save some battery. I am a bit anxious, because our device had to be use almost one year with a little button cell.

I have also other concerns… With Matthieu and Lau, we did argue a lot today. because we had not the same outlooks and prospects for our project. So, we spend some time to discuss many subjects this morning and afternoon, such as the products we would “sell”, if we need to have every exchange in char so it would be readable for humans, etc… And we are not done yet.
But we will agree. We are responsible persons.

Keep following ! On Monday, you would be able to access a new presentation concerning our state of progress, and all the matters we are discussing !

Drops N’ Roses : State of progress

Hello World !

This week, I was concerned about Drops N’ Roses’ future. We have indeed RAM problem… even with the use of external memory. That is because nRF51822 RAM is only 16kB, and the BLE stack use an important part of it. Moreover, I need a buffer for exchanging data with the external memory, and Lau also use another buffer for the BLE.
So, we had to remove one of them, and to clean whatever we can to have more free space ! We don’t want stack overflow… or other memory disaster.

We also did a focus group, talking about how we will organize our FLASH memory.
I was wondering how we would be able to keep some important data such as the drop id, etc… because, our drops will sleep the major part of the time. Iwas wondering how we would do without RAM retention to keep those data, or access them thanks to the SPI and the external memory without consumming all our batery very fast. But then, I remember we could use the NRF51822 flash for some important information.

We tought also about scenario for our diverse application Android. Here, you can see what the trasure hunting app would look like.

I also spend some time helping Lau or Sam debugging our Android application.

But I am not very proud of myself… I am not really efficient !
I will rest, and come back with more ideas, and things done (I hope)… because there are not so much time left !

Back to ROSE

We only said goodbye with words
I died a hundred times
You go back to her
And I go back to…..
I go back to us

Hello World!

Yes, I’m back. Sith Lords are not as powerful as they used to be, so kicking them out of the galaxy has been easier than expected.

Last week end and on Monday, I worked a lot on the Drop Scanner app. I had to learn many things (Scala, Android, Scaloid) and to dive in the code Lauriane had written. When I began to understand how the code was working, I changed a little bit the interface. No breakthrough, but this helped me to put my hands in the code. There are still a lot of things to improve about the UI and the UX. Also, some bugs remain and have to be fixed as soon as possible!

Yesterday, I also started to think about the memory organization. We will have a Flash memory, which means that we have to spread the write requests across the pages not to wear them too fast. So I began to search for existing Flash file systems, in order to take some good ideas. Especially, I found UBIFS and JFFS2 which are popular Linux flash file systems. In the end, I designed a brand new flash file system, called DropFS (stands for Deluxe Rather OPerational File System). We still have to think about a few issues, but the global architecture looks solid. I will explain the whole design in a few days with gorgeous schematics. Stay tuned!

Finally, we decided to think again about our use cases, and clarify them in order to know what we really need to implement in our drops. I was assigned to think about the Cairn use case (the one for hikers). I wrote a little text explaining how the user would use the app, but above all I made an interactive mockup of the app, showing the different screens and interactions. Check it out!

May the force be with you!