Starting with STM32 (NUCLEO-L412KB)

[gf]

... so one could think about implementing two mixers in order to upgrade the R meter to a RCL meter.

That's basically how Picuino's previous project (AVR-based millivoltmeter) was working. The excitation signal was generated by the µC, too, (square wave + analog filtering, since no DAC available), and it was phase-synchronized to the quadrature NCO. Frequency and sample rate was of course lower, due to the limited power of the AVR.

[Picuino]

Here's an optimized and corrected version: https://godbolt.org/z/G34oKdv4r

Process time = 24% of CPU time (almost twice as fast)

[Picuino]

... so one could think about implementing two mixers in order to upgrade the R meter to a RCL meter.

That's basically how Picuino's previous project (AVR-based millivoltmeter) was working. The excitation signal was generated by the µC, too, (square wave + analog filtering, since no DAC available), and it was phase-synchronized to the quadrature NCO. Frequency and sample rate was of course lower, due to the limited power of the AVR.

This time I want to make a Lock-In amplifier to amplify the signal coming from a D2 led diode.
Another led D1 should emit about 30kHz towards a crystal and the signal received by D2 should show the vibrations of the crystal at lower audio frequencies.
The original project showed how it could be used to “listen” to what is spoken near a window. It could also be used to analyze the vibrations of an inaccessible machine.

https://www.holographyforum.org/data/pdf/aa-Collection_a_k/aa-Laser/aa-lockin/Homebrew_lockin_amplifier.html


I do not need to calculate the components in phase and the components rotated 90º.

[Picuino]

In my case I will use normal infrared LEDs (I will try to have the emitter somewhat collimated with two holes in line) and the project itself is an excuse to learn about the STM32, instrumentation amplifiers and synchronous amplifiers.

In the other project I did, a simple Atmega328 could measure R, L and C with precision of about 50000 counts (every second) simply with its 10 bit ADC at 10kHz.

In this case I want to measure at higher frequencies, without calculating phase shift and without as much precision to get an audio output.

[gf]

Synchronous demodulation is certainly useful for this use case. But don't expect wonders. Keep in mind that a lockin amplifier's ability to dig a small signal deep out of the noise floor relies on a very narrow bandwidth. A wide bandwidth (say 10kHz in your case) defeats this ability, i.e. the signal you feed into the demodulator should already have a sufficient a priori SNR.

[dietert1]

We have a Polytec HLV 1000 for laser based audio measurements. As far as i know it uses interference, i.e. mixing at optical frequency to detect motion as a Doppler signal. It works with red light in order to facilitate pointing the laser head at the target.
As it measures velocity one needs a differentiator in order to use it as a microphone.

Regards, Dieter

[gf]

Something like this?
https://en.wikipedia.org/wiki/Laser_Doppler_vibrometer

[dietert1]

Yes. At the time Polytec called it HLV = Hearing Laser Vibrometer. It works well when used with a reflective target. I remember ordering special self-adhesive reflector sheets they offered and some powder made of glas particles.
With a system measuring displacement (position), one needs two differentiators to make a microphone. This may cause a noise problem.

Regards, Dieter

[Picuino]

That device is beyond my intentions. But it is very interesting. I didn't know there were such detectors.

Now we are in exam season and I will have to reduce the time dedicated to this project. I hope to be able to devote much more time to it in July. For now I will continue in my spare time little by little.


Compiling the previous example, a warning has appeared about the variables that catches my attention.

../Core/Src/filter.c:20:20: warning: initialization discards 'volatile' qualifier from pointer target type [-Wdiscarded-qualifiers]

In the following line of code:

Code: [Select]

    uint16_t *p1 = &adc1_buff[init];
adc1_buff is volatile. Perhaps the compiler is asking for the pointer to a volatile to be volatile as well?
I hope this does not cause problems. On other occasions compiler optimizations have led to not updating the buffer by not declaring it volatile.

[gf]

Yes. At the time Polytec called it HLV = Hearing Laser Vibrometer. It works well when used with a reflective target. I remember ordering special self-adhesive reflector sheets they offered and some powder made of glas particles.
With a system measuring displacement (position), one needs two differentiators to make a microphone. This may cause a noise problem.

Hmm. Isn't Doppler frequency offset approimately proportional to velocity, and position the integral of velocity? Wouldn't this rather suggest FM demodulation + integrator in order to measure position?

[dietert1]

With analog audio the voltage represents acceleration (proportional to force of air pressure).
To go from the velocity measurement of a Doppler system to audio one needs one differentiator.
To convert a position measurement to analog audio one needs two differentiators to first derive speed and then acceleration. At high frequencies a position measurement doesn't work well.
But is has been done, for example in the famous active speakers of Backes & Müller. They built kind of a capacitor microphone into the tweeter to get the dome position. Capacitance was small and the first derivative happened by measuring capacitive displacement currents.

Regards, Dieter

[gf]

Compiling the previous example, a warning has appeared about the variables that catches my attention.

../Core/Src/filter.c:20:20: warning: initialization discards 'volatile' qualifier from pointer target type [-Wdiscarded-qualifiers]

In the following line of code:

Code: [Select]

    uint16_t *p1 = &adc1_buff[init];
adc1_buff is volatile. Perhaps the compiler is asking for the pointer to a volatile to be volatile as well?

Yes, if adc1_buff[] is volatile, then it expects a pointer to a volatile destination, otherwise the volatile qualifier is lost and and the accesses of the function to adc1_buff[] are not volatile. Therefore the warning.

Unfortunately, gcc emits more instructions if the pointer destination is volatile

But I do not see a stringent need for declaring adc1_buff[] volatile. I can hardly imagine a situation where the generated code would not reload the buffer contents from memory each time the function is executed. To be on the safe side when the function happens to be inlined in another function multiple times in a row or in a loop, you can add a compiler barrier to the very beginning of the function.

On other occasions compiler optimizations have led to not updating the buffer by not declaring it volatile.

I think when you encountered this problem, you had declared the buffer as a local variable inside the function.

[Picuino]

The other time I had a problem was with the output DAC buffer. First the buffer was defined as global, but not volatile. A loop is in charge of updating the buffer contents to generate a sine wave, but the compiler detects that the program does nothing with the buffer contents and the first position was not written:

https://www.eevblog.com/forum/microcontrollers/starting-with-stm32-(nucleo-l412kb)/msg5516341/#msg5516341

After defining the buffer as volatile, the problem disappeared.

I will look into adding a compiler barrier.

[gf]

The other time I had a problem was with the output DAC buffer. First the buffer was defined as global, but not volatile. A loop is in charge of updating the buffer contents to generate a sine wave, but the compiler detects that the program does nothing with the buffer contents and the first position was not written:

https://www.eevblog.com/forum/microcontrollers/starting-with-stm32-(nucleo-l412kb)/msg5516341/#msg5516341

After defining the buffer as volatile, the problem disappeared.

See https://godbolt.org/z/MdqTYMqoP
I cannot see a problem in the emitted assembly code, IMO it does what it should do.
Unfortunately you did not provide enough context, but only the 3 lines of the loop. So I can't see what you have really done.

A couple of posts earlier (https://www.eevblog.com/forum/microcontrollers/starting-with-stm32-(nucleo-l412kb)/msg5515009/#msg5515009) you definitively did define dac1_buff[] as local variable inside main(), and not global.

Code: [Select]

int main(void) {
    ...
    uint16_t dac1_buff[1000];
    for (int i = 0; i < 1000; i++) {
        dac1_buff[i] = i * 4;
    }
    ...
}


[Picuino]

Yes, in that case the variable was declared as local. Now it is declared as global in the dac.c file. I don't remember when I changed it, I think it was before I had that problem, but I don't know.

The best way to check if there is a problem with this is to run the program and see its output. If it is as expected, then I guess all is well.

Anyway I have re-declared the variables as volatile and with the code enhancement it is still very fast.

As soon as I get the second filter with decimation up and running, I'll post the code.

For now I post the provisional code as it is at the moment.