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 – Getting started on the software part

Hi everyone !

As I said last time, we have finished designing our PCBs, so from now on we will spend all our time on the software !

This last week-end, we all worked on the presentation that should have occurred on Monday,  so we haven’t had much time to start fully working on the software, but now that it is finished, we need to coordinate ourselves to work efficiently on each part of the project.

Yesterday, with Benjamin and Olivier, we argued on the structure of the computing part of the system. We finally decided that we will use a Node.js block to communicate using Bluetooth low energy, and a C++ block for the computation of the position, the two blocks will exchange data using sockets (probably with the 0mq library).

I also have started thinking about the way the receiver software should be structured, to be correctly synchronized with the emitter and to keep information on the phase of the signal and find every information we need to calculate a good position. Unfortunately, it brought me doubts about the method we chose to eliminate the symmetry problems. I will need to verify that…

See you next time !

Plume – The receiver PCB is about to be printed !

Finally !

After placing, routing, finding errors, fixing them, finding other ones, fixing them as well, and other last minute changes…, we finally finished designing our PCB. With Guénolé, we spent the whole week working on it so we are happy to have finished it ! You can admire the layout in the pictures below 😉

PCB layout, top traces are in blue, bottom ones in red

PCB layout, top traces are in blue, bottom ones in red

Top layer components

Top layer components

Bottom layer components

Bottom layer components

Aside from that, I also worked on the software architecture to update it and make it work with the new hardware architecture we chose.

After talking with the teachers, we have decided to eliminate the various symmetry problems we had by studying the phase of the signals we sense. By doing this, we can measure the three magnetic fields exactly instead of having 8 possibilities on each measure (±Bx,±By,±Bz). And there is only one symmetry left that we won’t be able to suppress : the three magnetic fields have a central symmetry so they are exactly the same in (x, y, z) and in (-x, -y, -z). Therefore, with this new method, I need to change the software architecture to have a good phase detection, and I think I found a good way of doing it !

And by the way, if you have nothing to do tonight at 9:30, you can come to my improvisation show : !

See you next time !

Plume – Project Architecture

I too haven’t posted here in a long time, though the week has been filled with work ! Things are getting more concrete, and this is really exciting. On Saturday the 15th, I spent much time working on the software architecture of our project. Putting the ideas on paper really helped me figure out how to implement our software and how to make everything work, and I think that the resulting architecture definition will really be helpful to work efficiently.

During the remaining of the week, we worked on choosing the various components we will need on our different systems. That means reading datasheets to find the various data we need to properly design our system. The sensitive part of it was designing the analogical amplification chain to be able to detect the very small signal variation of the magnetic field necessary to compute precisely the position and orientation of our system, even at a 5m distance from the emitter. With Virgile, we evaluated the amplification we needed, depending on the range of distance and the precision needed, thanks to an Octave program. The value we got were useful to fix the gain and the ADC we needed.

But that was before we found the magical component : the audio codec, which comprises all the elements we needed to amplify and measure our signal in a single chip. Therefore, during the last days I have worked to see how it worked and how to use it to check if there aren’t any flaw that would make useless for our application.

Thus we also had to redefine our hardware architecture to include this chip in it. I will also have to change some stuff in the software architecture to make it match with the hardware, but there shouldn’t be much changes, so that is alright !

See you soon !

Plume – A long and diversified week !

Good evening readers !

It has been a long time since I last posted on this logbook, so I have many things to tell you ! Here is my day to day work of this week !

On Monday, I took a little too much time to write the description of our project on (come check it out here), so on the afternoon I mainly worked on the lab work we have on the STM32 board.

On Tuesday, I have worked a lot on the mathematical model of our problem. I really think that thanks to that it will be easier for us to compute a precise location using our magnetic fields. The use of matrices to calculate the three different magnetic fields from the voltage measured in our coils, will enable us to use a precise calibration system taking into account not only the capacity of the individual coils to generate or sense the magnetic fields but also the mutual effects neighboring coils can have on each others. I have put all of these notations and calculation methods in a latex document so that anyone in the Plume team can see how the calculation will work.

On Wednesday, I haven’t really had time to work on the project because I was performing in an Improvisation show and thus I had to leave early. (By the way, if you want to see me on stage, I’d be glad to see you in the audience, so here is the fb page of my company :

On Thursday and Friday, I tried to find a software way to suppress the noise we could have on the magnetic fields we will measure. Indeed, if we can have a perfect measure of the three magnetic fields our orthogonal coils emit, we will have no trouble computing the position and orientation of our sensing device, but as we will need to sense very weak magnetic fields, we might have a very low Signal-to-Noise Ratio. But we might reduce that noise considering that our 3×3 measured values should follow equations depending on only 3 variables, so if we were able to find the nearest point to our 3×3 matrix in this 3-dimensional variety, we would be able to get rid of a lot of the noise. It kind of looks like the way error-correcting codes work. Unfortunately, I haven’t found an efficient way of finding this nearest matrix, even with the help of a mathematician friend of mine, but I will keep this possibility in mind if the noise happens to be a too big handicap.

Finally, on Sunday I have worked with Olivier to conceive a good low noise amplifier for our lab tests. We have tested a few different amplifying circuit, with different resistor and capacitor values, and we finally found a great one, combining a resonant part with a low-pass filtering part. It works well, but we will still have to work on the coils and their power supply to have the range of use we wanted.

That’s it for this week ! It had the opportunity to work on very different subjects and it was really great !

See you soon !


PLUME & ARM “Silver” member

I might repeat what the other previously said, but the time has finally come ! We have revealed the name we kept secret for such a long time! PLUME stands for Positioning and Localization Using Magnetic Emitters.

During a long meeting with the rest of the team we started to plan the roadmap of this project. We also talked about some technical points of the project and shared some implementations ideas. Last but not least, we spent some time finding a name for our project getting ready to disclose the secret name of our project.

Apart from this, I have studied the various debugging methods for ARM architectures, to prepare the presentation I will make on Friday with Gleison. To have more information on the CMSIS-DAP solution, I needed to register on ARM website, hence I am now an ARM Silver member! (That just means that I have access to the documentation, but still, that is quite a fancy name ;-)) Anyway, thanks to this I have been able to discover this debugging technology, I will dive deeper into the documentation tomorrow to give you a great overview of it and of how to use it on Friday.

More information next time !

PLUME – Putting things into equations

Yesterday I started putting things into equations. I haven’t studied Electromagnetism for a long time, but the formulas came back in mind quite easily (with the help of internet of course! ).

To put the problem into equations I had to use some approximations that may be corrected in the future, but after filling two pages of formulas and various sketches, I found the equations to use to calculate the position of a system being able to sense the magnetic field produced by a fixed emitter composed of three orthogonal coils.

I also read several documents about this type of localization technology, they confirmed some of the approximations I chose to make.

Today, I will try to find a way to calculate the orientation using this mathematical model. And continue to put everything I have written on my draft to a Latex file.

We may quickly need to test these formulas in a real situation to check if the approximations are correct or not.