This post sums up all the work we have done in the last three weeks. It is an indirect reply to the other post

We have tested each of the parameters on the transmission line between the tweeters and our receiver.

Here is a review of the tests we conducted :

Radio transmission :

System : the master sends a synchro messages to the tweeters and orders them to beep at the same time.
Signal observed : signal entering the tweeter
Result : a maximum of 200µs shift is observed
Conclusion : this is a negligeable parameter on the transmission line

Bip detection (here comes the hard part)

This is the main source of uncertainties.


The filtered we have design thanks to Alexis Polti is resistant to type I and type II errors (false positive and false negative errors).
First we apply a pass band filter : to remove the noise from other frequencies.

  • band pass [20800Hz; 21200Hz]
  • stop band (40dB attenuation at least out of [20000Hz, 22000Hz]

We square each samples to get the power of our filtered signal and then we apply a low pass filter in order to get the enclosure of the power.

  • band pass [0Hz, 1600Hz]
  • cut-off 1800Hz


The trigger is designed as follow :
If a point is above a given threshold it is a possible bip.
We consider it as a valid bip if for the bip_length 90% of the enclosure is above threshold level.
If the point is valid a debouncer to avoid echoes is then activated.

In the following example you can see the signal (light red), the power at 21kHz (dark red) and the enclosure (black).
Regular beeps are send every 1s. Beep lenght is 10ms.
Abscissa is time in seconds, ordinate is the amplitude of the signal


This is a zoom on the second beep of the same recording.


Conclusion : we observe that the signal we get is not “clean” and as many echoes.
We also observe that the tweeter takes a some time to enter resonance which results in a possible 3ms shift.

This is a major concern. One possible improvement is calculate several position and apply a low pass-filter to get the position is several measures are alike.

Further development

Fo now we record a sample before analysing it.
We shall implement a “continuous” mode that enables doing all the computing part while recording the audio file.

D-21 : XBEE communication protocol

Here is a post concerning the XBEE communication protocol (hence the title) that we will use to synchronize the different slave tweeters.

We named the different messages to be able to be able to identify them quickly if you have any questions concerning them.

Protocol :

The master broadcasts alternatively two kinds of messages:

  • synchronisation messages “SYNCHRO”
  • configuration messages “CONFIG” detailing :
    • the frequency of the internal timer
    • the length of a cycle
    • ID with beeping configuration of each tweeter


When turning ON the master:

  • It waits a cycle length to get the actual configuration of the active tweeters
    • If all the configurations are the same
      -> it recovers this configuration and re-activate the synchronisation signal
    • If configurations are different or no configuration are received
      -> it sends a new configuration and re-activates the synchronisation signal


The slaves do the following things:

  • when receiving a synchronisation message “SYNCHRO” -> reset of the timer
  • when they receive a new configuration, they apply the changes concerning the general timer configuration (frequency and cycle length)
    • If their ID is present in the configuration
      -> apply the changes concerning the beeping times
    • If their ID is not present in the configuration
      -> send its ID to the master (to be included in the new configuration)
      in a message called “LOG”
  • during their “beeping interval” they send their ID and the actual beeping configuration according to them to the master in a “OK” message



When the master shuts down, the actual configuration is still applied and used for a given time.

When the master turns on: it tries to recover the configuration of each tweeters and if it is consistent (equal for each tweeter) he save it and re-synchronize the tweeters.

When a tweeter shuts down, the master will adjust the configuration accordingly. The master knows a tweeter is shut down because he won’t receive the OK message.

When a tweeter turns on, it waits for a configuration message containing its ID followed by a synchronisation message to start beeping.

If no configuration messages are send, the master is most likely dead and the tweeter cannot resynchronize.
If the configuration message does not contain its ID the tweeter sends a “LOG” message and it will be included in the next configuration file.


Choice and implementation of the localisation algorithm :

Finding the solution of a localisation problem thanks to tdoa (time difference of arrival) of the beeps and knowing the position of each tweeter.

Technically the problem consists in solving 3 equations of the second degree with 3 parameters (the coordinates if the position of the device).

One major advantage of an algorithm is to be able to use the fact it has redundant information if extra twitters are used.

The uncertainties in the reality come from two elements :

  • detecting the exact time of arrival of a beep (this maybe difficult because of the noise and air flux)
  • knowing the speed of ultrasound (which varies a lot in function of temperature, humidity, pression …)

Simulations shows that the main source of uncertainty is the speed of the ultrasound.

The algorithms we chose to implement takes all the information from the emitters and apply a least square algorithms to find a good position. The solution obtained is re-injected into the equation system to deduce an error parameter. This process is repeated to minimise the error in function of the speed of the ultrasound.

We are eager to test it in real life to see how good is the precision obtained.


I am aware I spend a great deal of time on this problem.

I am now switching to the embedded part concerning the synchronisation of the emitters.

Please feel free to leave any comments.

WAMI: Where AM I


The aim of the project is to implement an indoor localisation system using ultrasounds.

The localisation system shall be able to locate a given cell phone in a 3D space of approximatively 50m * 50m * 20m (lets say the Amphitheatre Thevenin for instance).

The system  is composed of :

  • emitters who send ultrasound beeps
  • a receiver who computes his position thanks to the time difference of arrival of the beeps

Our receiver will be a cell phone implementing an android application. This choice has been made so that the project is easily portable and does not require any additionnal equipment.



We design our own PCB to be rather generic.

They have :

  • LEDs and buttons for control
  • a H-bridge to connect the tweeter and have an increase power of emission (x4 as compared to a normal connection)
  • a XBEE module for radio communication
  • USB and a micromatch concerning the interfaces

We also have a codec connected in case we need to record the ambient noise / beeps coming from the other emitters.

Communication protocol

In order for the system to work we need to synchronised our emitters.

This is the purpose of the presence of xbee modules.

One of the devices we made will be considered as the master and send synchronisation information to the other emitters. By considering that the time of flight of the radio waves to the different emitters is much smaller than the precision we need for beeping (which is true in reality), all the “slave twitters” are therefore synchronized.



The device we use for reception is a regular cell phone able to run an android application.
Regular micros on modern cell phone sample the sound at 44kHz which is enough to regognize ultrasounds (from 20kHz to 22kHz).

Detecting a pulse

We are curently working on several methods to detect the time of arrival of a pulse. To do that we need to get the energy associated to the 20kHz frequency.
We thought of implementing :

  • FFT
  • the Fourier coefficient associated to 20kHz frequency
  • a goertzel filter

We shall meet a signal teacher tomorow whose advice will be precious.


Finding position

To compute its position from the measures of the time difference of arrival, the receiver needs to associate each beep to a tweeter and to know the position of all of them.
The main incertainties in the algorithm is that we don’t know the speed of the ultrasounds (it varies a lot with respect to temerature, humidity, altitude). For instance a 5°C shift results in 3m/s diffenrence in the ultrasound speed.
We are currently using a least square algorithm with some adjustements to be able to find the proper position.


It has been a while since my last post.

During this week I started creating a whole environement to compare the different algorithms in python.
Since I was not familiar with this langage I took 2 days to quickly learn the basis and started my project.

Concerning the personnal work I finaly ended my PCB practical.


My two last days were dedicated to looking for a proper triangulation algorithm.

Also the web ives many results for “triangulation” or “localisation” combined with “ultrasonics”, “equations”, “time of flight” and many other key words, I didn’t find the equations we were looking for. Lots of article deals with recovering a position from angle measure but not from time of flights or distance measure.

The best solution I found, is writing the equation myself using Maple software to solve them.

Good point is that Maple is able to solve those equations, bad news is that the result for each coordinate is about 5 pages long and has an imaginary part.
I hope that I will be able to decipher the result and implement the algorithm for a simulation soon.

We, the WAMI group, decided we should make a proper simulation toolkit in order to test our algorithms on a system as close to the reality as possible.

Tonight Issam and I worked on implementing the algorithm chosen to check wether or not it is working. Our first tests ran perfectly well.

For a given point we calculate the flying time of the ultrasound. When we transmit those arguments to our algorithm it manages to work out what the original point was with a very high precision. Thanks to this toolkit we will be able to study more precisely how the different parameters affect our results. For instance we hope to see how much deviation we get, if the speed of the ultrasound changes (it is very sensitive to the temperature and humidity).


Concerning the algorithm itself, we chose to have a very specific position of our transmitters (they are at the tips a a standard orthonormal basis) + one is at the origin of the basis.

This method seems very accurate. According to me the only drawback is that we need to have a very specific position of our transmitters ( we cannot randomly put them where we want). We are looking for a silution in order to improve this.



It has been a week since my last post on the logbook.

Concerning the ‘non-project part’, it took me a while to get expedition PCB running properly on my computer but I eventually succeded. Thanks to this wonderful software I made the schemas that where asked for in the practicals. I haven’t compiled them yet, so I am planning a wide debug session soon. I still have to do the ‘place and route part’.


Although I spent an incredible amount of time installing windows and expedition pcb on my laptop (on a virtual machine), we did some work with my group.

As we met on sunday, we took some time to discuss the project. We all agree we should find the most simple and smooth solution to achieve our goals. We tried to express the datas we needed to make a good localisation on our mobile device and thought of how to them as simply as possible.


Since tuesday, I spent my time wandering in configuration files of all kind.
I discovered new syntaxes that allowed me to edit a proper .zshrc file. I also took time to make my own vimrc file that you can find on my github account “”.

After I managed to configure my printer, I printed several cheat sheets for vim and gdb and I have tried to familiarize with those new tools.

I moved on slowly on the stm32 practicals because of all I did above but I think I will have it finished by wednesday.