Plume – I’m alive

Hi 🙂

After some problems with the shipment of our receiver boards, we finnaly got its. With the greatfull help of Alexi we welded all the components (except the SWD debug port, beacause, we didn’t able to find it). Then I checked the card and all possible mistakes and I booted it.

And….. our receiver board is alive. 🙂

Now, we will debug all our work. And there is a lot of to do.

See you soon.


PLUME – Emiters & Serial Audio Interface

Hi everybody,

Today I worked on the Serial Audio Interface that we will use to communicate with the Audio Codec. We have to use it as an I2S Bus. However, it is not very simple because the documentation on the Internet about it is very poor. So I made my own configuration, I’m ready to use it. Moreover, this option (SAI) is only available on the STM32f2xx. I’m currently waiting to receive our receiver board to check my code and my configuration.

Moreover, I worked on the emitters and specifically on the emitters coils. We have to made them by ourself, and it’s not a very funny work. I just finished now and we have 3 perfect emitters coils of 700 uH each. 😛 We will use it tomorrow.

I have some pictures for you… 🙂

1001962_508959002544059_856462076003843439_n 1609824_508958922544067_3826350395491944239_n10288805_508958965877396_4772993911968432041_n 10156102_508958945877398_288473813105626500_n

PLUME – For fun…

Whereas I’m working on the software of our receiver, I take few breaks to continue working on the packaging of our transmitter / receivers. I 3D printed our components. Here are some previews of it.

The emitter coils will be hide by the “white part”.

IMG_20140412_172149 IMG_20140415_152039 IMG_20140415_152109

Moreover, we received our receivers. Howerver, PCBPool forgot to weld the Audio Codec on the board. We can’t use the board yet. 🙁




Plume – Communication between the nRF and the STM32

Hi everybody,

As you may know, all the nRF that we will use in our project, will be the N51822QFAAC0. The C0 refers to an old version of Nordic SDK (4.4). However, with our eval kit, we were using SDK 5 because we had N51822QFAAG0. Our goal was to use the same chip, but PCBPool made a mistake. We have to deal with it. Yet, there are a lot of differences between these versions.  Some functionalities are only working using the new SDK.

Moreover, as explains in this post, the nRF has a 6 byte UART-buffer. But with the C0, the buffer is reduced to 1 byte. So, we have to choose an other protocol to communicate between the nRF and the STM32 using a software flow control.

Here is the frame specification I imagined to do that.

Note : This protocol that describes the frame to exchange data between our STM32F4xx and the nRF on the receiver is directly inspire from the API Frame Specification of Digi XBee module. For more information, go on Digi website.


Our communication between the nRF and the STM32 requires that communication be done through a structured interface (data is communicated in frames in a defined order). This paper specifies how data and data responses are sent and received using a UART Data Frame.

UART data frame structure – with escape control characters

Type of message

For our system, we will send and receive only a few kind of message which will correspond to a type of data. As every type of message won’t be sent in both directions we can organize them into three categories.

STM32 > nRF

Data from the receiver coils :

  • Type of message : 0x23

  • Length : 20 bytes

nRF > STM32

Calibration data :

  • Type of message : 0xC

  • Length : 20 bytes

Sampling rate :

  • Type of message :

  • Length : 2 bytes

Both ways


Escape characters

When sending or receiving a UART data frame, specific data values must be escaped so they do not interfere with the UART data frame. To escape an interfering data byte, insert 0x7D and follow it with the byte to be escaped XOR’d with 0x20.

Data bytes that need to be escaped :

  • 0x7E – Frame Delimiter

  • 0x7D – Escape

  • 0x11 – ACK

  • 0x13 – Flush the nRF


When sending a frame from the STM to the nRF, we are not able to send more than 1 byte in a row, due to the buffer in the nRF. So, to deal with this problem, we have to define a software flow control ; when the nRF receive 1 byte, it sends an ACK to the STM.


The protocol is implemented on our board. We managed with Benjamin to test all the communication from the STM32 to the nRF to the computer (using a BLE dongle). It also works in the other way.





PLUME – Software of the Receiver


This week, I’m currently working on the software of the receiver. I finished all the configuration and initialization of our board. Moreover, I finished to work on the communication between our STM and  the nRF and also work on a serial bus to help to debug.

Now, I will work on the communication between the STM and the Audio Codec and study how to configure and use this chip. Hopefully, I’m working with Virgile on that part.

Moreover we received our emitter, with Olivier and Alexis we are welding the component. I hope, we will finish this afternoon and be able to use the emitter.

To be continued…


Plume – Design


Today, I was working on the packaging of the receptor and the emitter.  I think that design and the aspect of our project is very important, so I made some rendering.

Tell me what you think. 🙂

Emetteur_1 Recepteur_3

Plume – Soft of the receiver


As already explains MarcO we finished to work on the PCB of the receiver. Now, we have to continue on the soft of the receiver. So, I’m currently working on the board.h of the card and all the configuration that need ChibiOS to work with our board. This is not a very funny thing, but, I have to do it.

Moreover, we received an evaluation board for the Audio Codec. It will help us to communicate and create a program to configure the mini-DSP of the chip.

So, there are our next step on the receiver :

  • Configure the STM32
  • Configure the Audio Codec and the mini-DSP
  • Configure the nRF and communicate with the STM
  • Receive and analyze the tension from the receiver coil.

To be continued…

Plume – Making some PCB

Hi everyone,

This week, I was working with MarcO on the Schematic and the PCB of the receiver. It is not a easy work because there are so much constraints that we have to respect (signal integrity, symmetry,…) because we have a system which have analogical and digital electronics. However, I like to make PCB because you have to respect all these aspects and think to some physics. Moreover, we want a tiny device (for the moment 40×60 mm) to be able to use it in various situation.

We hope that with our architecture we will be able to do what we want.

To be continued…

PLUME – Work in progress

Hi everebody,

It is been a long time since I wrote something on the website. However, I worked this week. Indeed, the purpose of the week was to choose the components for our project. We decided to focus on the receivers because the architecture of them are more complex. To help us to design the amplification of the signal receive is the coils, we met some experts and teachers of our school. They guided us in our researches.

So, we have two possible architectures for our receivers. One of them is based on the use of a low noise amplifier, a programmable gain amplifier and an ADC. The second is to use a component, an Audio Codec, that includes all these features. However, we didn’t manage to choose one of the possibility. Moreover, we worked on the whole architecture, so we choose our microprocessors, our battery and some other stuff.

Now, we may begin to draw our schematics on Expedition PCB.

To be continued…

Plume – Communication Challenge


After a long time I’m back finally. The last 4 days, I spent a lot of time on my card to prepare the communication challenge. Well, it was not so simple. But the ordeal is over. Now I refocus on the project.

To be continued..