Day 20: a nice morning

This morning… I slept!

For the first time in a few days, I had some time to rest, which I enjoyed a lot. Since my last post, I have worked a lot on my STM32 for the lab and the communication challenge. We went on until late yesterday (the door closed at 23:30…), but I did it! After exploring non-deterministic bugs, a lot of documentation, and with the help of my best friend Google, I finally reached the final step. There are so many reasons why I could hate myself yesterday (it’s amazing how many stupid mistakes one can make when working under pressure…), but overall it was a very good experience. I am quite proud of what we achieved (basically, audio streaming) and the whole principle of discovering our board features in an ouverture-facile manner was very fun. This challenge was really a platform game! So, thank you, everybody: Alexis and Sam for organizing it, the students for having suffered with me and the alumni for passing by and encouraging us (the cookies were delicious!).

Therefore, I allowed myself to take some rest as a reward. But as soon as the morning was over, I was back in A406! No rest for the brave. This afternoon, Matthieu and I worked again on establishing a first communication between the BLE kit and an Android phone. While he was working on the kit, I managed the Android part. We agreed to develop the apps in Scala (with the scaloid library), which is much more compact and flexible than Java. But first, I had to remember how to program in Scala! So I spent some time reading documentation on Scala, Android, Scaloid, installing Android SDK, Sbt, and so on. I have now a DropScanner app on my Nexus 4… which does nothing yet, except displaying a text and a button. But tomorrow I will try using the BLE API for scanning.

By the way, be careful if you plan on testing BLE apps with a Nexus 4, since before Android 4.4 it couldn’t unbound Bluetooth Smart devices. Of course, I had not upgraded my Android yet…

Day 17: the end is near!

Since yesterday, I worked a lot on my STM32 lab. I have now begun the TCP/IP part, and all the other parts are done! The end is near, I am now more confident in my ability to finish the lab before the communication challenge.

During these two days, I also worked a little on the nRF51822’s BLE stack, by reading parts of the API documentation. I haven’t seen everything yet, but I slowly begin to understand how the stack works. Hopefully, I will understand the whole of it in time to complete our PSSC (programming a scanner app for an advertising drop) before Sunday!

On the board again…

Just can’t wait to get on the board again.

Hello World!

The last two days were dedicated to boards. Yesterday Adele and I played with our nRF51822 dev kit. We managed to flash a little example program using radio to communicate (Benjamin already showed you what it looks like). We also published a little tutorial to help our classmates to make everything work. Then we tried to flash another program using real BLE this time. However it was a little more difficult: we had to write the Makefile because the demo was not shipped with it. In the end, I successfully flashed the software, but it was still not working. Sam explained us today that we had to flash the soft device before. I hope I will have time to investigate more on it very soon!

Today, I kept on my STM32 lab. I tried to make the potentiometer work, but the force was somehow not strong with me today. I will try again tomorrow. In the meanwhile, I managed to make my buzzer work. But as I respect the ears of my classmates, I didn’t try to compose a full 8-bit symphony (yes, this sound really makes me nervous!). Then I started to work on Serial over USB, but it is not yet working. I keep hope alive!!

In addition to that, I have a lot of things to do, especially for associations and internship search. I hope I will manage to finish everything by the end of the week! And also, I’m working on a side-project, but it deals with Web so you might not be very interested in it…

May the force be with you!

Day 14: so much to do, so little time…

I have a loooot of things to tell you tonight. Are you ready? Let’s go!

On Friday, Matthieu, Adèle and I spent a lot of time reading several datasheets to compare different SoCs. In the end, only the nRF51822 and the CSR101x series seemed flawless… until we discovered that the CSR101x was really difficult to get. As a result, we definitely chose the nRF51822. The timing was good, since we received our developement kits on the very same day! We also worked on the choice of other components, in particular the button cells, with Adèle spending a lot of time on Farnell. Having filled up a table of the characteristics of all components, we were able to choose. For the battery, we selected a few of them (CR2032 and CR3032, rechargeable and not rechargeable), but we still needed some information on the support availability and actual prices for big ordering.

Setting up a comfortable environment

I invested my Saturday to ensure a better productivity later: I configured my development environment. More precisely, I set up a .screenrc file which automatically opens windows in the right directory, for all the tasks I do when developing for embedded systems and runs the appropriate commands (openocd, arm-none-eabi-gdb ch.elf, git status, emacs -nw main.c, and so on) at startup, with appropriate key bindings in addition. It was a bit difficult at first to understand how to write this file, but now it is done, and I am very happy of the result! When I start my computer, all I have to do now is to plug my STM32, create (or attach) a screen… and program! It may not seem like such a big change, but I know that I was always spending much time opening, renaming and closing tabs, remembering where my openocd.cfg and .gdbinit files were, opening lots of buffers in emacs… And now I won’t have to anymore. Of course my .screenrc is specific to my directories and my habits, but I can help you setting your own environment if you want!

I also spent an important part of my weekend on my STM32 lab, and I have now working semaphores, threads and events!

Today, I worked with Matthieu and Adèle to complete today’s PSSCs: the choice of components and the BLE architecture for drops.

While Matthieu was crying in front of complex schemes of solar panel connectors and Adèle was losing hope to find a CR3032 support, I was busy searching for rechargeable batteries cheaper than button cells and for application notes about impedance matching in datasheets. However, I found neither of them. I guess that we will keep our first idea of rechargeable button cells!

BLE architecture

Afterwards, we considered our BLE architecture. I read the SoftDevice specification and Android API documentation for BLE. Then the three of us discussed about architecture questions: what is the best granularity level, from a consumption point of view? How to ensure atomicity for read and write operations? We designed four architectures :

  • A single service, very generic, with characteristics “OperationID”, “Input”, “Output”. The current operation (read, write, edit, list boxes…) is selected by the “OperationID” characteristics and the semantics of the other characteristics depends on the operation.
  • A single service Message (characteristics “id” and “content”, when the client changes one value, the server updates the other one accordingly) and a service Box to select the appropriate box for current operations.
  • One service per operation, and appropriate characteristics for each one of them. For instance, service Read would have characteristics BoxId (write only), MsgId (write only), MsgContent (read only). In this architecture, there can be a service Authentification, used before any other operation, typically for the treasure hunt.
  • One service per operation and per box. It increases a lot the number of services, but reduces the number of characteristics by 1 per service.

The first architecture is conceptually the easiest, but probably the hardest to implement. The second one may create concurrence issues when several devices are connected. For the fourth one, the risk is to have too much services and exchange a lot of messages just to give the list of services. But in the third case, the problem is the same, except that it is moved to the level of sending the list of boxes.

There is still a problem of atomicity. With the second architecture for instance, when the client reads the message 136 and then writes the message 137, it first writes id=136 (the server updates content=foo), then reads content=foo, then writes id=137 and content=bar, but in which order? The server must wait for both characteristics to be updated or the box will be corrupted. Possible solutions are to add an extra boolean characteristics that could act as a mutex, or to require a short delay (how much?) after each update before processing.

Right now, we don’t understand BLE well enough to decide what the best architecture is. We need to start developing an Android app with BLE API to know what is easy or not to implement and how much messages it represents.

Another idea: maybe we could use characteristic descriptors (for instance the MsgId as a descriptor for MsgContent), but we are not sure yet of what changes between attributes and descriptors, concerning notifications, updates and number of messages. Are descriptors really the same as attributes, but only at a different level, with different semantics?


PHEW! That was already a lot of work for a few days. I will now spend the rest of the day working on ADC and reading documentation for Android development. Then I will rest a little, because next week will be very dense: we must finish our STM32 lab, design the PCBs, learn how to use the nRF51822 and how to develop Android apps… and develop our first app!

Flash a-ah // Savior of the Universe

Flash a-ah // He’ll save everyone one of us

Hello World!

Our #1 objective for this week is to find the components we will use in our project. Basically, we have to find: a micro controller, a BLE chip (possibly integrated in the MCU), some memory and battery. For the micro controller, we already have a favourite (nRF51822), however we need to look for outsiders. I listed some possible competitors yesterday, and now I have to compare them. About the battery, Adele made some good research, I’m sure she will tell you everything soon.

Concerning memory, we discussed a lot about this subject with the teachers on Wednesday. They had advised us to use a FRAM, which is designed to consume a little energy. However, when I looked for FRAM modules, I found out that this technology was extremely expensive (about $15 for 2Mb). So the teachers told us to investigate the Flash technology (now you have understood the title of this post). And a Flash module we found was not so energy intensive, and above all extremely cheap (about $3 for 64Mb). However it was not available anymore, so I looked for other products of the same family and I found the same chip with a 32Mb storage capacity (AT45DB321E). Eventually, we have a champion!

And last but not the least, I kept on my STM32 lab and now all the semaphores, interrupts and events work all together! Two lessons to be learned: conditional variables must be used with mutexes (and never alone! It doesn’t work! One can spend hours on that problem figuring out why the hell nothing works! I know this! It happened to me!) and semaphores are not that bad. In the end, I can switch on and off my led with a button (yes, I know, three days to light a led…). Next item on my to-do list: change its intensity with a potentiometer.

May the force be with you!

Authentication, nRF51822 and more Git

Hello World!

I’ve done some work on Wednesday, but it has mostly already been told by my fellow coworkers (tests of BLE range, boxes architecture, Git presentation).

Yesterday, Benjamin and I finished our presentation about Git. Actually it is a bit more than a presentation : the slides are intended to be used as a reference by the other students during the project. That’s why there are a lot of slides (but don’t worry, we won’t show all of them!). In the end, the biggest challenge was to pick the topics we are going to explain in details, so that everything fits in less than 20 minutes.

Another thing I’ve been working on is authentication. This is a critical part of our project because we need to have a special user (called owner) able to change the configuration of the drop. However we also would like to prevent other users from impersonating the owner. In order to do so, Lauriane et I defined a simple authenticating system:

  1. The very first time the drop is switched on, it looks for another Bluetooth device (running the Drop Admin app). The first device found will be the owner, and the app and the drop will exchange a shared secret key which will be used to authenticate the owner later.
  2. If the owner wants to give its rights to another device, he tells so to the drop and the next device connected, say within one minute, will be the new owner (the former shared key is revoked and a new one is generated). We also need a way to recover a key (for example, if the authenticated device is lost and the owner wants to register the key in his new phone).
  3. We also wanted to grant special rights to some users (called administrators) in some boxes (configured by the owner). In this case, the owner must tell the drop that the next device connected will be added as administrator in box n. Then the administrator device connects to the drop and they exchange a shared secret key. However this method requires to owner and the administrator to be together at the same time, so perhaps we will have to find a better solution (even if we don’t really want owners to use administrators, this is just a feature which can be used in  very specific cases).

Last thing I’ve done: I began to investigate the nRF51822 (which was quoted in the course about RT OS). This SoC embeds a BLE chip and provides a full software stack to use it. A development kit has been ordered and should arrive soon. Then I’ll be able to start reading the documentation and hack a few things to see if it will fits to our needs. Next week, I will also begin to look for other SoC we could use.

May the force be with you!