Categories

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 !

 

3 comments to Plume – Working on the control part of the receiver software

  • Awesome post, thanks for these details!

    I’m curious about your single bit-shift compression trick, would you explain it a tiny bit?

    Would it be interesting to send for example a 4 byte reference sample and then 1 byte deltas only? (A bit like in ADPCM)

    Finally, you might want to fix this little typo: “…to access *our* the samples we need.”

    Keep up the great hacks!
    ;p

  • MarcO

    Typo fixed !
    I am sorry, it wasn’t clear for the bit-shift indicator. It is not on one bit, but on four. But the 9 values are all shifted by the same amount of bits. I hope this is more clear 😉

  • Yep, thanks again for the details 😉