VLF MD with digital signal processing : Bee-Buzz 1

[Aziz]

If you want a compact development platform just get hold of an android phone with decent specs eg LGV50 has a really excellent codec onboard ..... sound cards are from 10 years ago.



Android is way easier to code than windows anyway.

Also you still have not done a signal flow / system diagram ( with maths ) and you have missed one big GOTCHA ( dont worry ... the commercial manufacturers missed it also - but that is a story for a later time ).

Hi Moodz,

do you think it is worth to invest some time to learn Kotlin (regarding Android App development)?
But
I hate Java!
I hate Javascript!
I hate C#!
I hate Rust!
I hate Pyhton!
I hate Basic!
I hate any other programming language I dont know.
I hate programming language developer too.


The support for C/C++ isn't good for Android App development however. But I am not well informed about it. Kotlin seems to be a good alternate to C/C++.

Aziz

[Atul Asthana]

It has been said that a true scientist is a cynical opportunist ... believe in something absolutely until something new comes along . Another quote that comes to mind from Lord of the RIngs is "much that once was is lost, for none now live who remember it"

Nowadays engineers apply lego block principles .. this ADC that opamp this CPU .... it leads to mistakes due to assumptions that are made at the block level when what is needed is a continuum signal analysis. When it is done this way there actually is no difference between a PI and VLF or even a GPR detector ... its all just numbers. The question is what numbers are important and what is the relationship over time those numbers have.

In short if you sample any waveform ( PI VLF even GPR ) with a high enough bandwidth ( sample rate ) and high enough resolution ( efffective number of bits ) then all the detector modes ( VLF PI GPR etc ) can be performed using the right math transforms on the sampled data. This is not what the missing ingredient is though ... there is always something that can be made better hence we have patents ( though some are rubbish ).

You are greatly encouraged to pick holes in this design, do point out mistakrs, ommissions, enhancements etc.

It will be evident to a person skilled in the art that the entire process—starting from the generation of the transmission (TX) signal to the extraction of the VDI—has already been detailed in the first paper. Subsequent descriptions elaborate on the mathematical foundations and methodologies devised to address some of the limitations identified during the process.

I will only be able to dedicate more time to this work from or after April. In the meantime, feel free to suggest any improvements you would like to see and let others provide feedback on your suggestions. However, please bear in mind that this experimental concept is constrained by the use of the STM32F103C8T6 microcontroller, utilizing its internal ADC for implementation.

[moodz]

Hi Moodz,

do you think it is worth to invest some time to learn Kotlin (regarding Android App development)?
But
I hate Java!
I hate Javascript!
I hate C#!
I hate Rust!
I hate Pyhton!
I hate Basic!
I hate any other programming language I dont know.
I hate programming language developer too.


The support for C/C++ isn't good for Android App development however. But I am not well informed about it. Kotlin seems to be a good alternate to C/C++.

Aziz

C++ is fully supported under android.

A good starting point is google OBOE ... its a framework for developing audio apps on Android and is an active project. Lots of people doing audio development work start here. You can even hook your new USB audio dongle to a phone and access it.

Oboe is a C++ library which makes it easy to build high-performance audio apps on Android. It was created primarily to allow developers to target a simplified API that works across multiple API levels back to API level 16 (Jelly Bean).

https://github.com/google/oboe

[Aziz]

C++ is fully supported under android.

A good starting point is google OBOE ... its a framework for developing audio apps on Android and is an active project. Lots of people doing audio development work start here. You can even hook your new USB audio dongle to a phone and access it.

Oboe is a C++ library which makes it easy to build high-performance audio apps on Android. It was created primarily to allow developers to target a simplified API that works across multiple API levels back to API level 16 (Jelly Bean).

https://github.com/google/oboe

Thanks Moodz,

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 hate wrapper coders too.

I find the AAudio API much simpler to use and it fits into the design model of my software.

Cheers
Aziz

[Aziz]

Hi all,

this is a good video introduction for an AAudio API. Its nearly same principle on Windows systems.

Best practices for Android Audio (Google I/O '17)
https://m.youtube.com/watch?v=C0BPXZIvG-Q

Again, will a 6 inch Android tablet or Android smartphone accept an external USB sound card for signal processing (USB Audio Class 2)? I dont know the answer yet.
Aziz

[moodz]

The NDK is not a wrapper its more of a Java ByPass direct access to CPU.

It's called the NDK "NATIVE" development kit for a reason... DSP code written in C/Cpp is much more efficient than java code because the code runs directly on the CPU.
The Native Development Kit (NDK) is a set of tools provided by Google for Android developers. It allows developers to incorporate native code written in languages like C and C++ into their Android applications. Unlike Java, which runs on the Android Runtime (ART) virtual machine, native code compiled with the NDK runs directly on the device’s CPU, offering performance benefits for computationally intensive tasks.

By leveraging the NDK, developers can optimize performance, access platform-specific features, and reuse existing C/C++ libraries in their Android apps. The NDK provides toolchains, libraries, and build system integration to streamline the development process and enable seamless communication between native code and Java components using the Java Native Interface (JNI).

[moodz]

Hi all,

this is a good video introduction for an AAudio API. Its nearly same principle on Windows systems.

Best practices for Android Audio (Google I/O '17)
https://m.youtube.com/watch?v=C0BPXZIvG-Q

Again, will a 6 inch Android tablet or Android smartphone accept an external USB sound card for signal processing (USB Audio Class 2)? I dont know the answer yet.
Aziz

Well thats some time I wont get back again LOL

USB audio dongles that are compliant with the USB Audio Standard will work with android. To verify if your phone is compliant with the USB Audio Standard, you will have to approach your mobile device's manufacturer.

Dunno about the soundblaster you have ... but the SoundBlaster 4 Play works directly with Android phones version 8+ ... cheap as chips too.

[Aziz]

Hi Moodz,

the Sound Blaster 4 Play is totally useless for my App.
No 2-ch line input. Reduced sampling rate (48 kHz).
I dont use mic inputs.
I need two channels (signal and reference) line inputs for clean an stable decoding.
The head-set input with mono mic input is not a good solution.
Aziz

[Aziz]

Btw,

the mic input is often band limitted (up to 8-10 kHz). Or modified with DSP functions (noise suppression, echo chancellation, ...). It is biased with a DC voltage to realise some functions:
Mute, play, pause and so on by a simple pull down resistor switches.

But in general, a simplied detector would still be possible. Even with Headset plug (Stereo output + mono mic input). All effects must be switched off so the signal data wont get modified. Stereo output will drive on one channel the TX coil and on the other channel beep output. And we would have some latency to beep output sound. Or take the internal sound part of the device (Tablet or smartphone).
As we have no reference to TX phase info, we must implement a motion mode detector.

So in general it is possible if we dont want a super-duper detector.
Aziz

[moodz]

Well if you don’t want a supa dupa detector you are in the right place

[Aziz]

Well if you don’t want a supa dupa detector you are in the right place

Super-Duper-Oreshnik-Detector!

[dbanner]

Huh, you guys don't pull your punches, do you.

And Moodz, how the hell do you know so much?

[moodz]

Were just AI's ...this is how we learn.

[dbanner]

Does anyone have the floppy disk file which accompanied this book?

[Aziz]

Hi all,

I'm going to buy the Creative Sound Blaster G3 soon. I was confused with the Sound Blaster Play xxx devices, which won't be appropriate for the project. Headset plug only is no-go (4 pole TRRS)!

But the G3 has true line input (combo plug with digital input). And it has ear phone output (no line out). But only 24 bit @96 kHz SR. It can be plugged into an Android device (Android 8 +). The G3 is cheap, lightweight and small. Perfect for some testing.
Aziz