VLF MD with digital signal processing : Bee-Buzz 1

[Aziz]

I have forgotton to mention, that we have even more parameters for detection.

Observing additional the magnitude of the TX voltage reference.
On dual frequeny mode: 2 addtional parameters.

On narrow band chirp mode: 6 additional parameters.

A lot of info for good discrimination and ground balancing. Even on hottest mineralized soils. Not any one of the commercial VLF detectors have done such fancy processing.
Aziz

[Aziz]

Hi all,

it gets better:
Let's start with a simplified dual frequency VLF/LF detector. To get things easier in the software, both output channels will drive the single ended TX coil to ground. Each channel with its own resonant frequency. Therefore we need a simple mixer. A series resonant LC-tank follows the mixer. Then the parallel resonant LC-tank (TX-coil with parallel capacitor) + the capacitive voltage divider for our TX reference signal. I will post a spice simulation file soon so you get an idea.
You have to decode the magnitue and phase in each resonant frequency. So 4 parameters for detection.

In the advanced software version, we will check around the resonant frequencies (max. 500 Hz bandwidth around resonant frequencies) to get 12 parameters (6 magnitudes, 6 phases). A simple narrow band chirp modulation will drive the TX coil in each separate frequency. This makes things easier in the software.
Cheers,
Aziz

[Aziz]

Hi all,

the headphone output of the G6 is really fine. No output amplifier is required at all. As we have 2 channel outputs (stereo), we won't waste one of them for driving the TX coil. A differential output using both channels will get more TX power.
I have made a TX spice simulation with the specs of the sound card and it delivered at least +/- 1 A TX coil current (TX: L=300 uH, LR=1 Ohm). This is fully enough (even too much!). 150 V peak to peak TX coil voltage is there. No problem, I can go even much more. But this will suck the battery of the app device quickly empty. Due to the high voltage we need a differential capacitive voltage divider to get our low voltage TX coil reference signal. This will be fed into one line in channel. The other input is the RX signal.
I'm sure, we don't need any RX amplifier too.
All we need is: the USB sound card, some capacitors and diodes for high voltage protection, TX and RX coil in induction balance (IB) configuration and the DeepSeek software from other space.
Thats all.

Cheers

[Carl-NC]

it is obviously a C++ wrapper, which is based on opensl (dead!) and AAudio (new).
Wrappers commonly make things more complex and hurting regularly the KISS-principle.

I find that C++ wrappers can make coding far easier and easier to maintain. A good example is the STM Cube library, which begs to be written in C++. Until that's done, I'll use a C++ wrapper to make it easy to use.

I hate wrapper coders too.

I'm hurt.

If you'd like to use C++, here's a simple example of how you might structure the same firmware in C++:

If that's what AI came up with for C++ I think I'll continue to write my own code. Also, if you use the CODE tag (# button on the editor toolbar) then code formatting isn't lost:

class MetalDetector {
public:
  MetalDetector() {
    HAL_Init();
    SystemClock_Config();
    GPIO_Init();
    ADC_Init();
    DMA_Init();
    TIM_Init();
    LCD_Init();
    arm_fir_init_f32(&fir_instance, FILTER_ORDER, (float32_t*)fir_coeff, fir_state, BUFFER_SIZE);
  }

  void Run() {
    HAL_ADC_Start_DMA(&hadc, (uint32_t*)adc_buffer, BUFFER_SIZE);
    while (true) {
      if (HAL_ADC_PollForConversion(&hadc, 100) == HAL_OK) {
        ProcessSamples();
        UpdateDisplay();
      }
    }
  }
...
​

[dbanner]

I am no expert on coding, that much I can say without reservation. However I asked deepseek : "I would like you to write code in c++ for transmit signal based on patent US6653838"

That's it.

It came back with code, which generated a timing sequence as outlined in the patent ( a short and long period) such that "an average transmit coil energy at termination of the long periods is similar to that of an average transmit coil energy at termination of the short periods"

It produced a waveform just as in fig.1 of the patent. It must have used physics knowlege which lay outside the scope of the patent to arrive at a proper timing sequence in order to satisfy the requirements outlined in the patent, which I thought was astounding, just in a few seconds.

But now I see deepseek has been sabotaged or hacked.

[Aziz]

Oh well,

I have some good and bad news regarding the USB Sound Blasterx G6:
- Line output is very bad on high frequency region. It gets distorted and even clipped.
Vpp is 5.6 V (+- 2.8 V). Causing much noise to the low frequency region too. WTF!

- Ear phone output has really huge bang. It is not much distorting and not much noisy.
Vpp low-gain: 3.5 V (+/- 1.75 V)
Vpp high-gain: 14 V (+/- 7 V)
Low output impedance: 1 Ohm typical
You can make hundreds of volts on the TX-coil. This will blow out your coil. I can go up to 90 kHz TX frequency. So you have enough power for the TX-coil.

I have detected a glitch issue on the sound card output. Could be a software bug. Or the USB port is too much noisy on my PC. I haven't found the reason yet.

Aziz

[Qiaozhi]

I am confident that if you were to provide very specific instructions to deepseek, it can write most of the code.

I requested it to write the code for transmit signal based on Minelab's US6653838.

Deepseek analyzed the patent and wrote the code in a few seconds, with a full explanation.

[dbanner]

Excellent.

how about asking DeepSeek to generate entire code and testing it?
I wont have to wait for April to start working on the code.
it will be really helpful
I guess, DeepSeek will generate the entire code.

I am confident that if you were to provide very specific instructions to deepseek, it can write most of the code.

I requested it to write the code for transmit signal based on Minelab's US6653838.

Deepseek analyzed the patent and wrote the code in a few seconds, with a full explanation.

[Aziz]

Deep Seek. DeepSeek. It's a good name for a metal detector.
Made by Deepseek for deep seeking.

All programmers should be fired now. Deepseek is making it for you.
You are all fired!

Aziz

[Atul Asthana]

Now I noticed it wrote the program in C. So I then asked deepseek which programming language it used (I never requested it ...............;
DMA_Init();!

Excellent.

how about asking DeepSeek to generate entire code and testing it?
I wont have to wait for April to start working on the code.
it will be really helpful
I guess, DeepSeek will generate the entire code.

[Aziz]

This is the end of AI.

Deepseek will cause a thermo nuclear meltdown to AI companies.

Yeah, back to the roots.

[moodz]

Once again American tech gets ahead of itself ....and is proven bigger ain't always better.

Thinking back to Microsoft / Linux wars.

[dbanner]

Deepseek is super intuitive. I can see the war rooms being set up elsewhere.

[dbanner]

Now I noticed it wrote the program in C. So I then asked deepseek which programming language it used (I never requested it rewrite the program in any other language). This was the reply:

The code I provided is written in C, not C++. This is because embedded systems programming, especially for microcontrollers like the STM32, is typically done in C due to its efficiency, low-level hardware control, and widespread support in the embedded systems ecosystem. Why C and Not C++?

1. Performance: C is generally faster and more predictable than C++ for low-level hardware control.
2. Memory Usage: C has a smaller memory footprint, which is critical for resource-constrained microcontrollers.
3. Compatibility: Most microcontroller vendors (like STMicroelectronics) provide hardware abstraction libraries (HAL) and examples in C.
4. Simplicity: C is simpler and avoids the overhead of C++ features like classes, templates, and exceptions, which are often unnecessary in embedded systems.

C++ in Embedded Systems


While C++ can be used in embedded systems, it is less common for small microcontrollers like the STM32. However, C++ can be beneficial for larger systems or when object-oriented programming (OOP) is required. If you prefer C++, you can still use it with STM32, but you'll need to:

1. Enable C++ support in your toolchain (e.g., STM32CubeIDE or Keil).
2. Avoid using heavy C++ features (e.g., dynamic memory allocation, exceptions, RTTI) to keep the code efficient.

Example of C++ for STM32


If you'd like to use C++, here's a simple example of how you might structure the same firmware in C++:

#include "stm32f1xx_hal.h"
#include <cstring>

class MetalDetector {
public:
MetalDetector() {
HAL_Init();
SystemClock_Config();
GPIO_Init();
ADC_Init();
DMA_Init();
TIM_Init();
LCD_Init();
arm_fir_init_f32(&fir_instance, FILTER_ORDER, (float32_t*)fir_coeff, fir_state, BUFFER_SIZE);
}

void Run() {
HAL_ADC_Start_DMA(&hadc, (uint32_t*)adc_buffer, BUFFER_SIZE);
while (true) {
if (HAL_ADC_PollForConversion(&hadc, 100) == HAL_OK) {
ProcessSamples();
UpdateDisplay();
}
}
}

private:
void ProcessSamples() {
float32_t input[BUFFER_SIZE], output[BUFFER_SIZE];
for (uint16_t i = 0; i < BUFFER_SIZE; i++) {
input[i] = (float32_t)adc_buffer[i];
}
arm_fir_f32(&fir_instance, input, output, BUFFER_SIZE);

float32_t max_value = 0;
arm_max_f32(output, BUFFER_SIZE, &max_value, nullptr);
target_detected = (max_value > TARGET_THRESHOLD);
}

void UpdateDisplay() {
if (target_detected) {
LCD_Display("Target Found!");
Beep(1000, 200);
} else {
LCD_Display("No Target");
}
}

void Beep(uint16_t frequency, uint16_t duration) {
__HAL_TIM_SET_AUTORELOAD(&htim2, (SystemCoreClock / frequency) - 1);
__HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, (SystemCoreClock / frequency) / 2);
HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_1);
HAL_Delay(duration);
HAL_TIM_PWM_Stop(&htim2, TIM_CHANNEL_1);
}

void LCD_Display(const char* text) {
memset(lcd_buffer, 0, sizeof(lcd_buffer));
strncpy(lcd_buffer, text, 15);
// Send to LCD
}

// Hardware initialization functions (GPIO_Init, ADC_Init, etc.)
void GPIO_Init() { /* ... */ }
void ADC_Init() { /* ... */ }
void DMA_Init() { /* ... */ }
void TIM_Init() { /* ... */ }
void LCD_Init() { /* ... */ }
void SystemClock_Config() { /* ... */ }

// Constants and variables
static constexpr uint16_t BUFFER_SIZE = 256;
static constexpr uint16_t TARGET_THRESHOLD = 1000;
static constexpr uint8_t FILTER_ORDER = 5;
const float32_t fir_coeff[FILTER_ORDER] = {0.1, 0.2, 0.4, 0.2, 0.1};

volatile uint16_t adc_buffer[BUFFER_SIZE];
bool target_detected = false;
char lcd_buffer[16];
arm_fir_instance_f32 fir_instance;
float32_t fir_state[BUFFER_SIZE + FILTER_ORDER - 1];
};

int main() {
MetalDetector detector;
detector.Run();
return 0;
}
Key Differences in C++:

1. Encapsulation: The firmware is encapsulated in a MetalDetector class.
2. Readability: The code is more modular and easier to extend.
3. Reusability: Functions like Beep and LCD_Display are reusable methods.

Should You Use C or C++?

• Use C if:
  • You need maximum performance and minimal memory usage.
  • You're working with existing C-based libraries (e.g., STM32 HAL).
  • Your team is more familiar with C.
• Use C++ if:
  • You need better code organization and abstraction.
  • You're working on a larger project with complex logic.
  • You want to leverage C++ features like classes and templates.

Let me know if you'd like further clarification or help with either language!

[dbanner]

Can you believe that? It took deepseek all of 12 seconds. Now this is a powerful AI.

It gave a basis on which to hang everything that's needed.

I gave it no specifics, I was very vague. The request: "Write firmware for a metal detector based on an STM32 microcontroller."

Amazing.