VLF MD with digital signal processing : Bee-Buzz 1

[ivconic]

I get this feeling that an stm32f103c8t6 @ 72 MHz is not sufficient. A more powerful processor with fpu/dsp should be used !

and of course with a very low noise amp and atleast a 16 bit adcat 100ksps or above.

To logically follow up on Carl's post; no reason to switch platforms, STM32 will do a fair job.
But with the addition of a good external ADC circuit you will get much more.
The whole point of my scribomania is only in the proposal to add a good ADC in front of the processor.

[Atul Asthana]

To logically follow up on Carl's post; no reason to switch platforms, STM32 will do a fair job.
But with the addition of a good external ADC circuit you will get much more.
The whole point of my scribomania is only in the proposal to add a good ADC in front of the processor.

noted.
I need to rework on the amp and adc.

I am wondering if my signal processing and power control approach needs adjustments or rehashing?

[Atul Asthana]

In the past I've advocated that folks define the goal of a project before selecting the chips to use. In this case, you've pretty clearly stated this is an exploration project. As such, I don't know why the 32F103 won't work; it's plenty fast, probably has enough flash and RAM, and certainly enough timers for direct sampling. And does single-cycle mult/div. Where do you think it falls short?

I think that the computational load, specially the signal processing part, is too heavy for the processor to leave much resources for administrative and user interaction management.

[Atul Asthana]

I am also looking for review and suggestions on improving the signal procesding part, since the md is all software, I am pretty sure thst there must be easier / more rational / better ways to process the signal or to manage the admin tasks so thst initial softeare development errors can be reduced.

[Carl-NC]

I am also looking for review and suggestions on improving the signal procesding part, since the md is all software, I am pretty sure thst there must be easier / more rational / better ways to process the signal or to manage the admin tasks so thst initial softeare development errors can be reduced.

A first design is always difficult, after that it gets easier. When I developed the security walk-through detector for FTP, I wrote the code (both DSP and a massive menu-driven user interface) a particular way. Eventually, as I tried to add new features, I decided I had made bad choices so I started completely over. Now what I have is "robust and feature rich" and much easier to manage. Expect to write the code twice. The first time, do it the way you think it should be done. The second time, do it right.

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.

I suggest you define everything you want the software to do. Split it in to DSP and UI functions. Ferinstance, how will you read the ADC and what will you do with the data, and how often? What signals will you need and how will you create them? How much RAM will be needed? On the UI side, will you have pots and/or a keypad? Display? How often do you want to update the audio, and how will it be generated? All this & more.

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

[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]

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.

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

[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]

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.

[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]

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.

[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]

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.