Author Topic: Starting with STM32 (NUCLEO-L412KB)  (Read 12537 times)

0 Members and 1 Guest are viewing this topic.

Online gf

  • Super Contributor
  • ***
  • Posts: 1302
  • Country: de
Re: Starting with STM32 (NUCLEO-L412KB)
« Reply #200 on: June 01, 2024, 05:01:13 pm »
... 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.
« Last Edit: June 01, 2024, 05:10:35 pm by gf »
 

Offline PicuinoTopic starter

  • Super Contributor
  • ***
  • Posts: 1019
  • Country: es
    • Picuino web
Re: Starting with STM32 (NUCLEO-L412KB)
« Reply #201 on: June 01, 2024, 05:56:40 pm »
Here's an optimized and corrected version: https://godbolt.org/z/G34oKdv4r

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

Offline PicuinoTopic starter

  • Super Contributor
  • ***
  • Posts: 1019
  • Country: es
    • Picuino web
Re: Starting with STM32 (NUCLEO-L412KB)
« Reply #202 on: June 01, 2024, 06:04:08 pm »
... 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º.
 

Offline PicuinoTopic starter

  • Super Contributor
  • ***
  • Posts: 1019
  • Country: es
    • Picuino web
Re: Starting with STM32 (NUCLEO-L412KB)
« Reply #203 on: June 01, 2024, 06:13:28 pm »
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.
 

Online gf

  • Super Contributor
  • ***
  • Posts: 1302
  • Country: de
Re: Starting with STM32 (NUCLEO-L412KB)
« Reply #204 on: June 01, 2024, 07:03:32 pm »
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.
« Last Edit: June 01, 2024, 07:13:56 pm by gf »
 

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 2235
  • Country: br
    • CADT Homepage
Re: Starting with STM32 (NUCLEO-L412KB)
« Reply #205 on: June 01, 2024, 08:39:08 pm »
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
 

Online gf

  • Super Contributor
  • ***
  • Posts: 1302
  • Country: de
Re: Starting with STM32 (NUCLEO-L412KB)
« Reply #206 on: June 01, 2024, 09:53:27 pm »
 

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 2235
  • Country: br
    • CADT Homepage
Re: Starting with STM32 (NUCLEO-L412KB)
« Reply #207 on: June 02, 2024, 06:21:56 am »
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
 

Offline PicuinoTopic starter

  • Super Contributor
  • ***
  • Posts: 1019
  • Country: es
    • Picuino web
Re: Starting with STM32 (NUCLEO-L412KB)
« Reply #208 on: June 02, 2024, 08:22:18 am »
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.
 

Online gf

  • Super Contributor
  • ***
  • Posts: 1302
  • Country: de
Re: Starting with STM32 (NUCLEO-L412KB)
« Reply #209 on: June 02, 2024, 08:49:36 am »
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?


 

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 2235
  • Country: br
    • CADT Homepage
Re: Starting with STM32 (NUCLEO-L412KB)
« Reply #210 on: June 02, 2024, 09:39:00 am »
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
« Last Edit: June 02, 2024, 10:26:27 am by dietert1 »
 
The following users thanked this post: gf

Online gf

  • Super Contributor
  • ***
  • Posts: 1302
  • Country: de
Re: Starting with STM32 (NUCLEO-L412KB)
« Reply #211 on: June 02, 2024, 11:58:21 am »
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.

Quote
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.
 

Offline PicuinoTopic starter

  • Super Contributor
  • ***
  • Posts: 1019
  • Country: es
    • Picuino web
Re: Starting with STM32 (NUCLEO-L412KB)
« Reply #212 on: June 02, 2024, 04:48:29 pm »
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.

 

Online gf

  • Super Contributor
  • ***
  • Posts: 1302
  • Country: de
Re: Starting with STM32 (NUCLEO-L412KB)
« Reply #213 on: June 02, 2024, 06:17:02 pm »
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;
    }
    ...
}
 

Offline PicuinoTopic starter

  • Super Contributor
  • ***
  • Posts: 1019
  • Country: es
    • Picuino web
Re: Starting with STM32 (NUCLEO-L412KB)
« Reply #214 on: June 02, 2024, 07:10:01 pm »
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf