[Little Brosers] Exploring the GATT

This week, I have continued my exploration of the SDK and the softdevice. The reason I was not able to register a custom service last week has been found quite quickly: there was a variable in the config file of the SDK/softdevice which held the maximum number of vendor specific GATT service allowed. Running into this problem has made me correctly set up the debugging through RTT, and saved me a lot of headaches for the next obstacle. Once the variable for the maximum number of vendor specific GATT services was correctly set, the softdevice needed more space in memory. Thanks to the debugging messages, we were able to quickly identify the problem and modify the linker script to give more memory to the soft device. Without the precise debugging messages I wonder how much time I would have spent scratching my head trying to explain the crashes of the board.


The next thing I did was refactoring the monolithic main.c given as a template by the Nordic SDK to coherent small files. While quite simple in appearance, I have actually spent an entire afternoon doing it, figuring out the correct headers to include from the SDK, and having to change the structure in some cases. Since some definition macro from the SDK declared variables as static, but these variables were needed across multiple files. However this was not wasted time, as it made me more comfortable with the SDK.


The remainder of the week has been dedicated to adding characteristics to the GATT service, playing around with read and write rights, and then setting up a timer to transfer the temperature of the CPU automatically through a notify characteristic. This is almost done, and should be finished by tomorrow afternoon.


Next week, I want to focus on helping Antony writing the C implementation of our Merkle tree comparison protocol, and I also want to work on the bluetooth side of the Android app, expanding on Chris’s work. I also have some catch-up to do on the server code from Xavier that I have already started.




[Little Brosers] Getting to know the nordic SDK

C/Android integration

Since we arrived at a satisfying protocol for the Merkle tree part of the project, it was time to start thinking about its implementation. The first thing I have done this week is make sure we are able to integrate some C code into our Android application. That way, we can write the tree comparison implementation in a C library that we import in the app and we will not lose any time. It was quite straightforward, and despite some missing libraries on my fresh arch install I did not run into serious problems. What is done for now is a simple hello world, where one function acts as the interface using the JNI (Java Native Interface) and call a pure C function defined in a different file which returns a “hello world” c string. The JNI interface function gives this string as a Java string which is then displayed in the MainActivity view. Nothing fancy, but enough to be serene about our ability to integrate C code to our application. However I’m not particularly excited to dive into the JNI syntax for more complex interactions given the difficulty to find concise information about it.

Here is a preview of what it looks like:


Java_com_littlebrosers_drops_littlebrosers_MainActivity_helloWorld(JNIEnv *env, jobject this) {
  char *str = hello();
  return (*env)->NewStringUTF(env, str);

Not really sexy. Once that was done, we also had to build a new docker image for our CI since the rose one did not have the NDK (Native Development Kit) installed and it is necessary for compiling C code for Android. Fortunately that was done pretty quickly despite none of us being familiar with docker.

Playing around with the nRF-devkit

After that, I got to play around with the devkit and start to understand the Nordic SDK. Despite being a bit lost at first, I am starting to get the hang of it. Everything bluetooth related is hidden behind Nordic proprietary software called a softdevice, which we can only interact with through an API. That was a bit frustrating at first, but the Nordic tutorials are quite well made, and by going through the examples and learning to read their documentation, I am starting to understand how we are supposed to use the SDK. This is however still a work in progress. I understood how to modify the advertising data, but I am still struggling to add a custom service to the GATT, since the tutorials are made with an older version of the SDK than the one we use. I am currently trying to adapt the nordic services code given in examples to create a custom service, but this is taking time since I do not want to blindly copy anything. This time investment is worth it though, as I will be able to help the other members of the group when they will start to look into it.

That’s what my week has been about. I hope that either tonight or early next week I will be able to register a custom service for the GATT, so that I can continue by adding characteristics to it. Once the BLE technical part is done, we will be able to focus on implementing the Merkle tree comparison protocol in C and interface it with Android on one side, and the Nordic SDK on the other.



[ZeROSEro7] Running demo and Fibonacci on the STM32F4xx Dev Kit

I didn’t post last week because I participated in the ATHENS program. I wasn’t in France and I was pretty busy.
Nevertheless, this week, I continued the ZeROSEro7 project and I’m writing about my advancement in the project.

nRF52 dev kit (BLE) to SX1276 dev kit (LoRa)

After finishing the nRF52_DK environment and successfully close the issue “nrf52 dev kit Fibonacci”, I let Enguerrand to continue BLE development on this dev kit.

In addition, I started to manage about the new SX1276 dev kit received last Wednesday. I read the datasheet, schematic, etc. about SX1276 (LoRa). I got back useful documents from the Internet and from Enguerrand’s works to push into a git repository. I obviously spoke with Enguerrand about his works on the previous LoRa dev kit to save all useful information about his works.

I also connected the SX1276 dev kit to the STM32 dev kit (Olimex) with breadboard jumper cables in SPI communication:

Tab 1 : Connexion Olimex – SX1276
VCC UEXT – 1 J3 – 4
GND UEXT – 2 J2 – 7
NSS J3 – 6 (SX1276) J2 – 3
MOSI UEXT – 8 J2 – 4
MISO UEXT – 7 J2 – 5
SCK UEXT – 9 J2 – 6



I have to verify the right connexion between olimex and sx1276 with example program to flash in the STM32.

Fibonacci on the STM32F4xx Dev Kit

like with nRF52 dev kit (Nordic), I made an environment for the STM32 dev kit (Olimex).
I added ChibiOS in our git repository and to the usb_dev_kit directory, there is the environment to develop on the STM32 dev kit.
With the Makefile, it’s possible to format the code, compile and debug with gdb.
I updated CI tests to use adapted docker image to compile with the last version of arm-none-eabi-gdb.
All CI tests pass, I merged with dev branch and I closed the issue Fibonacci runs on STM32 dev kit.

Schematics and PCB

I’m improving on the mentor software to draw schematic and I have to start a schematic about one device before next week.

Next week

So for the next week, I will continue about SX1276 (LoRa) with Enguerrand’s help and I will start schematic of one device.

[ZeROSEro7] Running demo and Fibonacci on the nRF52 Dev Kit

This week was consecrated to development boards. We received all of it and we started to create environments to develop, compile and debug programs on it.

I continued my work on the nRF52 Development Kit and I finally finished the environment for this board. I made a Makefile which compiles the main.c file with the SDK directory, sdk_config.h and the linker script. It’s possible to  load the program in flash with make flash which used a Nordic command line tool called nrfjprog. Finally I can debug codes with make startgdbserver which open a JLinkGDBServer and make debug which called arm-none-eabi-gdb function.


I wrote 2 functions in C Language to compute the Fibonacci sequence. The first function is a linear algorithm and the second is a recursive algorithm. I loaded these functions in the nRF52 Dev Kit to valid an Issue and we added some tests in the gitlab-ci.yml file to test every push with GitLab if the code is correct.

Install software

Finally, I installed on my computer Clang-format to be able to format my code according the coding style, I installed stlink to use the LoRa Development Kit and I installed XpeditionPCB to design schematic and PCB.

Next week is the Athens program I participate it. So, I won’t be able to work on Development Kit and I will try to begin the schematic of the spy talk.

[ZeROSEro7] Nordic nRF52 getting started

This week, we have continued to research component for our devices. We analyzed more precisely features and made the decision to keep the following items:

Tab 1 : Components
 µC  STM32F215RG
 BLE  nRF52832-QFAA
 LoRa  SX1276IMLTR

For each component, we chose a microprocessor development board to begin the software part of each device. We ordered all microprocessor development board Friday and we will receive them on Monday. We ordered the following items:

Tab 2 : microprocessor development board
 µC  OLIMEX STM32-E407
 BLE  Nordic nRF52 DK
 Wifi  Texas Instrument CC3220SF-LAUNCHXL

Nordic nRF52

I got the BLE development Kit from Nordic last Friday and I began to use it. I read a lot of information about this board on Nordic website.

I read, more specifically, information about the nRF52_DK PCA10040 v1.1.1 which contain a nRF52832 component. I got back useful files like datasheets, SDK, examples, etc.

I started to set up the environment to this development board. I got back a linker script and wrote a gdbinit to load and debug a program on the nRF52_DV. I’m editing a Makefile able to compile, load and debug a program.

Next week I will finish the environment and start to reorder useful file to push in our git repository. I would like also to discover the PCB software Xpedition PCB to start to design schematics.