Plume – Measures


Our receiver almost works. We are able to receive the tension of our 3 coils :

Our measures

Our measures

But we still have a problem, our function that compute the maximum of 3 values doesn’t want to work …

Stay tuned.

Plume – Green and blue stuffs


I have one graph to show you. The audio codec is alive, and we will harness its power , just wait for it !


In blue, our raw signal

In blue, our raw signal


In blue we can see our raw signal. It no longer have discontinuities =)


On a side note, Noble seems a good option for Ble as 3 out of 4 group of us are using it. I’m glad it helped. I just hope it won’t burn.

Plume – LED


Today I have worked on the emitter with Guénolé. As we can’t have a cool project without LED, we have added 4 RGB LED on our emitter, and we will soon add 4 more.
We can choose the color of each led, but I still have problems went I want to make an animation.


Aside from that, this morning I have work on the joystick application of our system. I have selected and installed two open source First-Person Shooter that we will use to show how cool is our  project with video games (Xonotic and Unvanquished).

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 – Working on the control part of the receiver software

Hi readers !

This last week, I worked on the core of the receiver software : the control part. I had to answer these questions :

How will the data be processed on the mini-DSP of the codec we choose?

We chose to multiply our signal by a cosine on one hand and by a sine on the other, each at the frequency of the signal (19kHz) and send the results, after a lowpass filtering, on the left and right output channels of our codec. That way, we bring our signal back in baseband and thanks to the 90° phase shift, we will be able to compute the amplitude of our signal and follow the evolution of its phase.

How will we synchronize with the emitter on start-up?

Let me remind you that our emitter has a four steps periodic operation : it emits on one coil, then on another, then on the last one, and then stops for a time. All of these steps have the same duration.

So to find the correct synchronization, what we have to do is simple in theory, we wait for the signal we measure to be small enough to consider we have no emission, then we wait to sense something to consider the first coil has started emitting.

How will we keep this synchronization through the time?

Though quartz oscillators are rather precise, but at a 192kHz audio sampling rate, the synchronization might shift of one audio sample every 0.4 s if we don’t fix it on a regular basis. But as we compute the phase of our signal at each measure, we can use it very easily to fix this synchronization.

For example, let’s suppose the clock of our emitter is a little faster than the one of our receiver, instead of sensing a 19000Hz signal, we will have a 19000.001Hz signal, therefore instead of having constant values on the left and right output channels of our codec, we will have a cosine and a sine at 0.001Hz. by measuring the phase of this output, we will be able to compute on each measure cycle the corresponding phase shift to fix it, by skipping an audio sample for example.

How should I organize and trigger the different steps I have to do on each emission cycle?

For each emitting coil, we have three steps:

  • at the beginning, we need to set the amplification at the lowest
  • after some time, we make one low-accuracy measure to compute the perfect amplification setting and send this setting
  • at the end, we process our samples to get our measures

We will receive the values from our codecs through I2S and use a DMA controller to record them on two buffers synced on an emission period, so that one address will always correspond to the same time of an emission, that way it will be really easy to access the samples we need.

To trigger our different steps, we will use a PWM and callbacks.

How will we transmit all of our values?

The problem with bluetooth low energy is that it can only transmit 20 bytes packets. Considering the rate at which we will transmit, we might not be able to transmit more than one packet for each measure, therefore we need to compress the 9 values on 32bits we had to a smaller size.To do this, I decided to send the 9 values with a 16 bits precision, and one single bit-shift indicator to use on everyone of them. As the 9 values should always be on the same order of magnitude, we shouldn’t be losing in precision doing that.


I already have written the code to execute all of that, but as Guénolé told in a previous message, we haven’t received our PCB yet, so I may not test all of this before Tuesday. I am really looking forward to testing the software on the real board, but I am afraid of the time it will take to debug everything ! We’ll see that soon !


See you !


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 – Calculator

Hi all,

After one week of work, I have finally succeded in making our first  simple version of the application work.
It display, thanks to blender, the position of a receiver in 3D space. If you are interested, watch this video :

We send the 9 simulated tensions through the zeroMQ socket and plot the position.
If we look at our architechure, The demonstration proves that the red blocks start to work.


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 – Magnetic generator


I have good news today.
First, we figure out, with the help of Samuel, why our USB port was broken. We had a 6 Mhz clock wherease I though it was a 8 Mhz, as our schematic says.

Secoudly, our H Bridge works as expected.

The alternative intensity that is going through the coil have a magnitude of 1.1A.
And we have 20 periods to make our measures, a little more than expected.
Concerning my concerns for the heat, we are border line. We can’t increase the intensity.

Aside from that, today I have finished to code the interface, using ZeroMQ, between NodeJS that handle the BLE and the calculator.