VLF MD with digital signal processing : Bee-Buzz 1

[Carl-NC]

One thing you should try to avoid is manually controlling timers. STM timers can be set up to create autonomous arbitrary waveforms via DMA. See STM App Note AN4776. Once you have it set up, the timer runs completely autonomously with no further need to intervene in code. It therefore has zero impact on code execution. If you set up your timing properly, you can also use one of the other channels to autonomously trigger the ADC.

[Atul Asthana]

I don't understand #6. Can you provide a timing diagram that shows the relationships? Also, what will the PWM signal look like, and how will you create it?

the pwm output will be genersted by loading corresponding sineeave value into the pwm register on each 384 khz interrupt (the second ticker). the pwm register will then use count down/compare internal function to generate required pulsewidth.

when passed through a lowpass or bandpass filter, in our case a 6 khz bandpass/tuned circuit, it will look like a sinewave, with some distortion (less than 60dB).

[Atul Asthana]

Your "scenario" in your post #58 is a pretty good start.
But Carl is also right; you have to clarify all the details better.
I am also working on my "scenario".
But I'm much slower and I'm always "looking for a hair in the egg"! (local slang saying)
I am too persistent in the details that my wife is sick of me for a long time!
I do not write my "scenario" integrally in one text.
I'm rather breaking down the details of the project on many more levels.
People around me are mostly sick of my hair splitting...
When I said I preferred ESP32 over STM32... know that was "yesterday"!
Today (now it's 4:40 early in the morning, I woke up with the computer again) and today I think completely differently than yesterday.
Instead of just writing my current decision... you'd better look at this document I put together (not for the forum but for my own personal use):

thinking, rethinking and wiping out and rethinking are a part of life, thats how innovations happen.

[ivconic]

Your "scenario" in your post #58 is a pretty good start.
But Carl is also right; you have to clarify all the details better.
I am also working on my "scenario".
But I'm much slower and I'm always "looking for a hair in the egg"! (local slang saying)
I am too persistent in the details that my wife is sick of me for a long time!
I do not write my "scenario" integrally in one text.
I'm rather breaking down the details of the project on many more levels.
People around me are mostly sick of my hair splitting...
When I said I preferred ESP32 over STM32... know that was "yesterday"!
Today (now it's 4:40 early in the morning, I woke up with the computer again) and today I think completely differently than yesterday.
Instead of just writing my current decision... you'd better look at this document I put together (not for the forum but for my own personal use):

[Atul Asthana]

Because without a clear "scenario" this kind of work cannot even be successfully started... let alone finished!With a small difference that I have already decided on ESP32 and not bluepill.
But take this with a grain of salt, it's always on a very long stick with me...long shot as the Americans say.
I started to come up with a scenario. These days I'm very slow to put together a concept. It will be a very long process. Due to certain private difficulties I am prevented from working faster. zz0.5jpso9el75azz

Ivconic,
your explanation and documents are excellent knowledge.

I have a suggestion.
the generic definition and explanation that I am trying to develop for this vlf md, can apply to all kinfs of Hardware.
You could develop your product based on some variation of the explanation I am putting together.

Regards
Atul

[Atul Asthana]

I don't understand #6. Can you provide a timing diagram that shows the relationships? Also, what will the PWM signal look like, and how will you create it?

thanks for rsising doubts

thats the task scheduler for signal processing part :

in each 256 hz cycle, that is 3.9 ms slot,
1. the pwm ticker will run to a complete single cycle of 6 khz by sending 64 points to pwm channel (this implies 384 khz ticks)
2. Synchronised to the pwm ticker, on every 8th ticker, ADC will sample the analog input and put the sampled data in 8 different bins.
3. the action of #2 and #3 here, will be repeated 16 times, adding the corresponding sampled data to the respective bins.
4. at thr end of sampling 16 sine waves, I will have integrated/accumulated the 16 sine waves of 6 khz, improving the resolution by 4 bits.

The above will happen on every tick of 256 hz. implies that in every 3.9 ms slot, I will accumulate 16 sine waves of 6 khz.

hope I've not confused you more.

[Carl-NC]

I don't understand #6. Can you provide a timing diagram that shows the relationships? Also, what will the PWM signal look like, and how will you create it?

[Atul Asthana]

Please pick holes in the design description below to help me refine and improve/add more functionality to the design.

1. currently the ADC is internal, till I understand a suitable audio codec and its interfacing.
2. with current oversampling, integration etc, the theoratical advantage over 12 bits ADC is about 5.5 bits. (with all expected noise, I guess practicslly, not better than 4 bits).
3. I plan to extend the functionality for it to be used as nondestructive subsurface archaeological survey, by adding communication with a remote device like PC.
4. I also plan to find out if the rx front end is saturated and reduce power to usable level.
5. Though I've read about overclocking this procesdor to 94 MHz, but for the sake of safety and longevity, 72 MHz is the limit.
6. There are many proceesrs, similar to stm32 architecture, cheaper with better ADCs, but I sm too unfamiliar with them touse, and their availability in India is doubtful. and will require learning th tool chains.

(not so) Complete description of the VLF MD system,

VLF MD Direct Sampling - Software Design

1. Microcontroller and Development Environment: The target microcontroller is an STM32F103C8T6 clocked at 72 MHz. Development will be performed using STM32CubeIDE.

2. Hardware Pin Assignments:

• ADC (for RX tank): ADC1_IN0, connected to Pin PA0.
• PWM (for TX H-bridge): TIM1 Channel 1 connected to Pin PA8.
• H-bridge control pins: PB0 (IN1), PB1 (IN2), PB2 (IN3), PB3 (IN4).
• HD44780 LCD: RS: PB4, EN: PB5, D4: PB6, D5: PB7, D6: PC0, D7: PC1. Use 4-bit mode.
• Speaker: PA1.
• Switches (9 total): PC2-PC10.
• Power on LED
• Error LED

3. ADC Configuration: The ADC will be configured for 12-bit resolution, single conversion mode, with a sampling time appropriate for the signal frequency.

4. PWM Generation: A 64-point PWM signal at 6 kHz will be generated using Timer 1. This PWM will drive the H-bridge connected to the TX LC tank.

5. Power Control: The transmitted power will be controlled by varying the PWM duty cycle. The nominal power is 100 mW, with a range of 50 mW to 250 mW. A linear approximation between duty cycle and power will be used for simplicity, assuming a constant load resistance. This approximation will be calibrated in practice if absolutely necessary.

6. Sampling and Synchronization: The system operates at a base frequency of 256 Hz. The 6 kHz PWM is synchronized to this 256 Hz rate, meaning that one complete 64-point PWM cycle is generated within each 256Hz cycle. On every 8th PWM point (resulting in 8 samples per PWM cycle), the output of the RX tank will be sampled using the ADC. These 8 samples will be stored in separate bins (8 bins total).

7. Data Acquisition and Integration: Steps 4, 5, and 6 will be repeated 16 times within each 256Hz cycle. After these 16 sub-cycles, the data points in each of the 8 bins will be summed (integrated).

8. Goertzel Algorithm: The 8 integrated data points will be fed into a fixed-point Goertzel algorithm optimized for single-frequency extraction (the 6kHz PWM frequency). The Goertzel algorithm will calculate the amplitude and phase of the received signal. The coefficients for the Goertzel algorithm will be pre-calculated and stored in a lookup table.

9. Circular Buffer and Filtering: The calculated amplitude and phase values will be stored in a 16-element circular buffer. New amplitude/phase pairs are added to the buffer after each set of 16 sub-cycles (i.e., once per 256Hz cycle). This buffer will be fed to two 16-tap IIR low-pass filters:

• Target Response Filter: Cutoff frequency of approximately 16 Hz (corresponding to a time constant of approximately 10 ms). A first-order Butterworth filter will be used.
• Ground/Ambient Response Filter: Cutoff frequency of approximately 0.16 Hz (corresponding to a time constant of approximately 1 s). A first-order Butterworth filter will be used.

10. VDI Calculation and Thresholding: The amplitude output of the target response filter will be compared to the amplitude output of the ground/ambient response filter. If the target response exceeds the ambient response by a defined threshold (e.g., 10% of the ambient response), the phase output of the Goertzel algorithm will be used to calculate the VDI value. The mapping between phase and VDI will be linear: -90 degrees maps to -99 VDI, and +90 degrees maps to +99 VDI.

11. Tone Generation: If the VDI value is not within a "notched out" range (specify the range, e.g., -10 to +10), a tone will be generated using the speaker. The frequency of the tone will be linearly mapped to the VDI value within a defined range (e.g., VDI -30 to +90 maps to 200 Hz to 1 kHz). The tone will be generated using a timer/PWM to create a square wave.

12. Display Update: Every 8th 256Hz cycle, the VDI value and a representation of the target strength (e.g., the amplitude of the target response) will be displayed on the HD44780 LCD.

13. Switch Input and Debouncing: The 9 switches will be sampled within each 256Hz cycle. Software debouncing will be implemented by checking if the same switch state is detected for 16 consecutive 256Hz cycles. If a switch state persists for 16 cycles, the corresponding action will be taken:

• Threshold +/-: Increment/decrement the detection threshold.
• Power +/-: Increment/decrement the PWM duty cycle (and thus the transmitted power).
• Notch +/-: Adjust the notched-out VDI range.

14. Notches / notch filters: Three independent notch filters will be based on VDI, with adjustable start and stop VDI values for each filter.

This provides a concise summary of the VLF MD's core functionality, omitting the details of the serial communication protocol to a remote receiver, which I am working on. This will help in use of this md as a subsurface archaeological survey device.

[ivconic]

ST Cube has everything needed for reading/writing registers in C. Since I've begun using STM processors I've not written a single line of assembly code.

Yes, I know about the ST Cube, even installed it a couple of times in the past. But I didn't do well and gave up.
In fact... a big problem is when a person gets too "spoilt" with some easy software and then switching to something more complicated and serious is usually difficult.
The Arduino IDE really "spoiled" me, but unfortunately; not everything can be done in it.
I think I'll give the ST Cube another go.

[Atul Asthana]

ST Cube has everything needed for reading/writing registers in C. Since I've begun using STM processors I've not written a single line of assembly code.

excellent.
I will also try.

[Carl-NC]

C++ is the most powerful tool. But for timers, direct trimming is the best. So... registry manipulation. So... assembler!

ST Cube has everything needed for reading/writing registers in C. Since I've begun using STM processors I've not written a single line of assembly code.

[Atul Asthana]

Currently I write all my code in C++ because modularizing everything in objects makes it more readable and easier to maintain. You have to be careful not to overuse C++ features because it can rapidly expand memory usage. I also use RTOS because a metal detector is fundamentally a real-time embedded system. With RTOS, you can further modularize tasks; typically I run only two tasks: a UI task and a DSP task. If you write your own task manager, you have to manually juggle everything going on and that gets harder as you add more complexity, like a display, a keypad, audio, wireless, etc. RTOS makes all this much simpler, which is why I brought it up earlier.

.

Great,

Though, I've experience of embedded code development on old 8 bit microprocessors like 6502, 8080/85/Z80, 8086 and 1802 in assembly + C (in later times) for machinery monitoring and control and for business applications in C and Clipper, but that was around 30 years ago. And developing on mil std was way more complex and very tiring.

For the past 30 years, I've been largely on the business side (even in tech companies, mostly strategies, business development and sales that kept me away from technology), though many a times I did advise on trchnology/product development, but have not wetted my toes again in the product development, specially not those involving embedded software.

So, in reality, I will brush up my electronics and embedded to really convert this project into a prototype.

My prefered language will be C and I will try and use existing libraries and functions instead of reinventing the wheel.

[Atul Asthana]

Great.

So to put it straight forward, the signal processing/use of the microcontroller will be something like this :

in a second, do the following 256 times

1. Generate 64 point pwm to drive H bridge at 6 KHz into a tuned LC TX tank. Vary the transmitted power by varying the pulse width, nominal power being 100 mW with rsnge from 50 mW to 250 mW.

2. Synchronised with pwm, on every 8th pwm point, sample the output of RX tank. keep the data for each sample in a separate bin.

3. do the '1' and '2' 16 times, integrating the data points in each of the corresponding bins.

4. feed the integrated data points to fixed point, goertzel algorithm for single cycle to get the amplitude and phase.

5. store the phase and amplitude in a 16 point buffer (a circular array. feed this array (of amplitude values and phase values) to two 16 tap IIR lowpass filters of 10 mlli seconds and 1 second. where 10 millisecond represents target response and 1 second represents ground / ambient response.

6. check if the target amplitude response is above the threshold above the ambient then check the phase angle and convert to vdi. if the vdi is not notched out, send a tone corresponding to the phase angle. every 8th cycle, display the vdi and and probable metal + target strength.

7. Check switches for threshold +/-, power +/-, notch +/- etc into a 16 tap moving average filter. and if any switch reaches 16, then take appropriate action.

please add, if I' ve missed out any thing or have wrongly depicted or have caused any confusion.

[ivconic]

... Expect to write the code twice...

If only I were so lucky!
I often write my code 20-30 times!
Even then, I'm not satisfied!
My disk is full of versions and revisions!
The worst thing is that I give them such names that later I'm not sure which code is the best solution!
I don't have any great knowledge and experience with better processors. I mostly dealt with "obsolete" processors.
RTOS is my old wish but never enough time to sit down and learn it properly.
When it comes to time-critical and precise functions; the best method is to trim the timers and use interrupts FIRST.
Once I get that sorted, all the rest of my CPU time is available for UI and other less time critical tasks.
I mostly write the rest of the "easy" part of the code in Cpp (trimmed C++). I think this only applies to my more modest processor choices.
I remember one time in the past when Carl mentioned in a post that he had 16 timers on some processor! I fell off my chair!
I still squeeze water from a dry beech using only 3 timers! You will hardly hear anything useful from me.
Everything I know is long out of date and primitive.
But in principle I understand the problems with metal detectors and combining it with practical experiences;
I know that the morphology of the DSP project must contain a very good ADC, that is the beginning and everything starts from there.
Carl is right though. Choosing a processor with as many timers as possible will make your job much easier.
Leave the UI for last. Do all time critical functions first.
C++ is the most powerful tool. But for timers, direct trimming is the best. So... registry manipulation. So... assembler!
In the good old days, we called it "machine language".
I still think the STM32 will do a good job. However, my personal choice is the ESP32.
I think that I will switch from Atmega directly to ESP32 in the coming period.

[Atul Asthana]

yes,

I was wondering if there is s better way to process the sampled data, which could reduce computstional load and complexity.

I was thinking of writing the code timed to tx wave form generation using the 64 ticks of the pwm as primary clock where everything is aligned to it at interwals of 4 (for example for sampling) or other processes. I think, that will save a lot of overheads and simplify the softeare development.

But we still need opinions on the processing methodology / strategy and user interaction requirements like power +/-, threshold +/-, filters corner frequencies +/-, notches add / delete, requirement of sending data to a remote etc. how many times a second to update a display and such things.