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

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 !

Drops N’ Roses : Guestbook and crypto

Hello !

So yersterday, I programmed Cairn guestbook v1.0. It gets the ten most recent messages and displays them on the screen as you can see.
So, at first, I wrote in my flash drop 10 messages with “This is a message for Cairn application. This is the %d comment of its guestbook”. Then, I added two short messages thanks to my application Cairn. Messages had to be short, because we have still some problems to write long messages even if we know how to do to send long messages, we do not have programmed it in Scala yet.



I also discovered cryptography based on elliptic curves. It seems to be a really good solution for signing messages. We discussed a lot (as always) about how programming the different functions we need to distinguish an authenticate person, a signed message, etc… for different use cases of our drop.

Then, we dispatched the work, and I was able to code again in C (Yippee!) to manage public, authenticate, and admin rights for the different “opcodes” that someone can send to the drop, in order to read/edit/write/delete a message.

At least, this evening, I tried to found an equivalent library of the one we already for the nRF… but for java ! We want indeed to be able to verify the signature in our Android application. I found a lib called bouncy castle, but I dit not achieve to sign and verify a message with the keys that Matthieu generated on our drop, with the C lib.

I am also a little bit anxious, because we have so many things to do, and… it is nearly the end !
I keep hackin’!

Drops N’ Roses : more Scaloid

Hey !

I am still working on Cairn application. It is a huge work to do on Scaloid. I have an application able to scan and list the specific cairn devices (it is done by filtering some advertising data). This app also notifies its user when a new cairn device is found. Then, it gives the possibility for the user to connect to any device nearby.
The next step is to list automatically the ten most recent posts in the guestbook.

It is still hard to work on Scaloid (because I am not used to it). But I was much more concerned about the guide lines I will have to adopt. I have some problems implementing the different functions and activities because… I don’t really know what is for the best.
It is quite weird to be confronted to such problems. I really feel lost.

But it is in progress… step by step, I create my first app 🙂

Drops N’ Roses : Scaloid programming

Hey !

I am sorry, I have no amazing photographs or videos to show you. However, I have not been inactive.
Thanks to the work of my coworkers (and my own), we are now able to write/read/edit/delete messages in our flash thanks to our application DropScanner. For example, I modified some functions of DropScanner to match the format that we defined for our BLE message characteristic. I also continued working on Android for creating our Cairn application. I have to automatize the connection to Cairn drops, to get directly important messages, etc…
I am not used to Scaloid yet, even if it is better than a few days ago. But I would like to work on something different because I don’t feel comfortable with Scaloid programming. I am really slow because of design part, and because I am a bit lost : I don’t really know where I should write my functions (API, local activities, or in another file). I am wondering how I will be able to finish the project (and really go on) if I am so slow (because a huge part of the things left to do are linked with Scaloid programming.

That is why I also try to debug our drops with Matthieu and Lau, to clean our repository, etc…
I checked that our drop is robust, by letting it advertise all night long without any crash (that is quite reassuring).
I also reflected on how we will modify advertising fields to add our own data, and I think we will use the “field data”.

I also thought of how we will make the CPU and our memory sleep, but I have to wait until Tuesday to actually make some measurements (we will have some material to do so we don’t have yet).


Drops N’ Roses : Stressful day 1000

Hey !

As Matthieu and Lau said, yersterday was a stressful day. I spend the day trying to make our PCB send something in BLE… to prove that our antenna and balun were functional. I checked everything : the fact our components were well-welded, the fact we had only the high frequency quartz, the fact that the softdevice 6.0.0 was not working on our chip (we have a N51822QFAAC0). With Alexis and Sam, I even check with an oscilloscope the behaviour of an eval kit with a N51822QFAA which was functional, to compare it with our drop, which was not functional… And it was quite weird, because the behaviour was quite the same for each pin. I also checked our PCB plan, because I was thinking that I made a mistake.
At least, we noticed that the quartz on the eval kit was 16 MHz and not 32Mhz as we thought. Matthieu, who was reading all bugs for SDK4 that we had to use (we have a N51822QFAAC0) told us that one bug was that the microcontroller could not work with 32MHz…
So Alexis welded a 16Mhz quartz instead, and it works ! We were really eased.

This morning, I spend some time correcting some part of my code for programing the memory, or refactoring it. I also wanted to add the hardware protection by controlling the WP pin. I thought I programmed it correctly, but I made some tests, and it does not work… I still don’t know why, because I really do it as the documentation recommends it.It is quite mysterious… so maybe we’ll have no hardware protection on our external flash.

Then, I read all our Scaloid code… again and again, to understand it. It is quite complicate to understand for me, because I am not used with Java anymore, and I have never programmed anything in Scala nor Android.
I began to make some minor changes. I need some information from Matthieu to continue, because it concerns BLE characteristics to exchange data, and we have to agree about what I have to send him.

As he sends me an email when I was writing this post, I think I can go back to work !

Drops N’ Roses : AT45DB321E test

Hey !

This week-end (and yersterday) I made some tests to check if the behaviour of our drop was correct.At the beginning, I created a new file in order to work with a clean repository (because I could not stand to work in the SDK file anymore). Then, I created our own drop_board.h, change the Makefile, and make a really simple test : a blinking led (yes, we have one !). So that is how our dead drop came alive.

After this primary test, I tried to write and read some pages of the flash memory. Write a page, erase one, and read one were succesful tests. But writing a byte was giving strange results. So, I factorize my code to make it easier to read… and I corrected a stupid mistake (a & instead of a | ) for writing the byte address in the same 3 bytes already used for page address. And this time, the function to write a byte was working. Afterwards, I check if it was possible to write a whole page and rewrite some of the bytes of the same page without erasing the page.
To give an example, what I would like to test was :
– I write a whole page with some bytes at 0xFF.
– Am I able to rewrite those bytes at 0xFF ?
The answer is yes. And it is even better ! I can rewrite a bit : if I have 0xFF (1111 1111), I can put 0xFE (1111 1110) and then 0xBE (1011 1110). Then, if I write 0xF9, I will obtain (1011 1000).
This is because the write operation for this memory is just puting “0” instead of “1”. And because we can’t erase a smaller area of the memory than a page (meaning to put every bits of the page at 1), we can only lower the value of a byte when we write the flash. That was a relief (even if we have to change our memory architecture, because we were not sure to have this bit writing possible, and so we plan to use a complete byte for some information that we can now store in one bit.

Then, I would like to test the BLE. But… this time, we had a really bad surprise. I was wondering what version of the SDK I could use with my drop, so I read our nRF number : N51822QFAAC0. The C0 corresponds with an old version of Nordic SDK (4.4).
With our eval kit, we were using SDK 5 because we had N51822QFAAG0. And there are a lot of differences between these versions. That is a bad surprise for everybody, because some functionalities are only working using the new SDK.

After this bad new, I decide to do another thing : merge our branches. And it was quite complicate because we were not working in same branches, nor at the same level (because Lau and Matthieu still worked on the SDK file, whereas I created a new one), but some changes were made in “same” .c or .h.
Sam helped us a lot. We had to rewrite history, to pretend that we had always worked on the “new file” I created, and then merge some files, etc… It was not so easy.
But now, it is done. And I added the SDK 4 in our repository as well.

Yersterday evening, Matthieu was trying to make the BLE working. I hope he succeeds.

Drops N’ Roses : synchronization protocol

Hey !

Be prepared for the longest post ever…
Today, I would like to explain to you our synchronization protocol. As I said yersterday, for some applications such as KTA (speleology application), we would like to be able to both :
– keep some messages in a specific drop, for example for direction indications.
– spread some messages in our drop-network. It would allow anyone to access these messages everywhere. It would not have been possible without spreadable messages, unless the user goes to that specific drop.

But for having such spreadable messages, we need a synchronization protocol.

When we will have it, we would be able to synchronize a smartphone and a drop, and then, if the smartphone meets another drop or another smartphone, they would synchronize themselves, and so… one by one, every network drops would have the same messages.


  • Use Case

In order to explain how we will proceed, I am going to take an example and develop it during all my speech.One of the aims of KTA application is to avoid people to get lost in caves, and to make research easier if someone really get lost.
To do that, we want to store (and spread step by step in all our drop-network) for each user a message, which contains his pseudonym and a list of his last locations (the id of the last drops he met) and a timestamp for each location. Knowing that the size of a message is limited, we would be able to store around 50-60 locations for each user.

  • Problems

This use case raises some problems :
– to be able to spread a message, it needs a unique id in all our network.
– if we want to edit a message, for example to add a pair (position and timestamp), we will have to distinguish different versions of the same message and identify the newest one.
– to avoid that a user A erases user B ‘s messages, or even worst, changes the content of the message with pair of location and timestamp, and replace them with others, we need to protect these informations. the only user that could edit his message should be himself, but other users should be able to spread his messages as well.
– because our memory is quite limited (32Mb is quite big, but… ), we want to forbid someone to flood the memory. We want to allow only one message for the box “location” per person.
– we want also to manage the term date of a message, and to stop its spreading when it is too old. (We want to save some battery !)

  • Our tools

What we are going to use are :
– a web server, with a data base which will contains a limited number N of users. It will also store their public key (RSA), and their pseudonym. This server would be accessible thanks to our mobile-application, out of the caves. Before to go in catacombs, people would have to register on this server if they want to use our system which stores their last locations.
– on our drop, we create different boxes. For this use case, there are two boxes (n°1 and n°2) whose size is N messages, and another box (n°0). Box n°2 contains location messages for each user, certified by each user (with their private key (RSA), corresponding to the public key they have on the server). Box n°1 contains  a set of messages. Each message is certified by the server. Each message contains a server version number, the pseudonym of one user, his rights (I will explain what it is for later) and his public key. These keys will serve to check the certificate of messages in box n°2. Box n°0 contains the public key of the server, to check the certificate of the keys in box n°1.
The advantage of using certified messages is that nobody (except the owner of the message) can change its content, but everybody can store the message, and spread it.

– a very simple synchronization protocol : one for the keys synchronization and another for location messages synchronization.
But before I can explain these protocols, let me explain how the server and its data base works.

  • Server and data base

Each line of this table represents data for a user in the data base : the first item is the server version, the second is the user’s pseudonym, the third his rights, and the last his public key. All this data are certified by the server.

Server data base

1 – User A – Rights – public key

2 – User B – Rights – public key

3 – User C – Rights – public key

50 – User D – Rights – public key

So, imagine N = 50. You can store only 50 users in your data base. And now, it is full. If another user wants to use our system, he can’t. Except if for exemple, user A don’t want to be in the database anymore. He is deleted, and so, another user can register.

Server data base

51 – User E – Rights – public key

2 – User B – Rights – public key

3 – User C – Rights – public key

50 – User D – Rights – public key

The version number is incremented, so it is now 51.

  • Keys synchronization

We want this database to be stored into our box n°1.
Please, consider that each drop has already the public key of the server stored into the box n°0.
Consider that someone (user C) downloads KTA application, and registers as “user C” in our website, and that he is the third person to subscribe. Consider that the drop he would meet has only the first line (corresponding to user A) of the data base stored as a message in its box n°1. The drop will advertise “KTA” and “1”. Thanks to this advertising, the smartphone of user C would know that the drop is not up-to-date. So the smartphone would connect and exchange step by step the (version + pseudonym + rights + user’s public key), all certified by the server. It means that, if the smartphone tries to send something that is not certified by the server, the drop would refuse to store it. In our case, if the smartphone send at first (3 – User C – Rights – public key) certified by the server, the drop would also refuse to store it, because the drop wants the second version, and not the third.

That is because we want to simplify the behaviour of the drop, and make it a bit stupid in order to avoid calculations and save energy. This behaviour is also good, because even if a smartphone has to send 40 versions and get disconnected before it has transmitted all 40 versions, the drop would be on a steady state, and would advertise the last version it has stored. So if another smartphone came, it can get the versions it has not yet without any calcutation required.

But what if now, we take the example of a 51th version again. And the drop is synchronized with the 50th version. If a smartphone with the 51th version meets the drop, it would synchronize : the drop would delete the first version, and replace it with the 51th version.

What if it was not the first version which was replace but the third, because user C want to give up KTA. If someone (user F) registers, the database would change the first version (1 – User A – Rights – public key) into fifty first version (51 – User A -Rights – public key). Same for the second version. And then, for the third, it would create (53 – User F – Rights – public key).
Proceeding like this assures us that we would keep a steady database and synchronization behaviour with the drop.

  • Location messages synchronization

As I explained ahead, the drop would advertise the server version number, so keys would be synchronized.
So now, we would like to synchronize messages which contains the last (locations + timestamps) of this user. These messages are certified, to assure the fact that it is its owner who posts it.

On connection, the drop will send a list of pair with : user ID (for our example, it would be between 1 and 50) and the last timestamp of this user. The last timestamp would be known because it would be the first data of each user message.

The smartphone compares what it receives with the messages it has. It determines which messages it should give to the drop and would message it should ask from the drop.

After these exchanges, the two devices are synchronized !

  • Conclusion

This is the principle of our synchronization protocol.
All smartphones would use this principle to synchronize themselves with drops and other smartphones.
And with this way of doing, we also can send (when someone goes out the caves) these data to the server. Thanks to that, without moving, an administrater could monitor people movements and if someone disappear, he can directly go to the last location where this person has been seen.

Next time, I will complete this protocol with the management of expired messages (too old to be spread in the network).I hope I have been clear. It was quite complicate to explain !
And… congrat’s if you read all this post !

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 !