Announcement

Collapse
No announcement yet.

VLF MD with digital signal processing : Bee-Buzz 1

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Aziz
    replied
    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)


    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

    Leave a comment:


  • Aziz
    replied
    Originally posted by moodz View Post

    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

    Leave a comment:


  • moodz
    replied
    Originally posted by Aziz View Post

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

    Oboe is a C++ library that makes it easy to build high-performance audio apps on Android. - google/oboe

    Leave a comment:


  • Atul Asthana
    replied
    Originally posted by moodz View Post

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

    Leave a comment:


  • Aziz
    replied
    Originally posted by moodz View Post
    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.

    Click image for larger version

Name:	image.png
Views:	346
Size:	19.8 KB
ID:	433429​

    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

    Leave a comment:


  • moodz
    replied
    Originally posted by Atul Asthana View Post

    Great observation, but unless the observation is revealed, its as good as not being there.

    And, If commercial manufacturers, with an Army of developers, researchers and umpteen resources missed something important, I think I can be pardoned, being a lone researcher, with very little time for all this, and completely out of electronics / signal processing / metal detector field for many decades.

    though, I am not sure that the commercial manufacturers would have missed out something important, it msy be that they havent revealed or found it too insignificant or have found better alternatives.
    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 ).

    Leave a comment:


  • Atul Asthana
    replied
    Originally posted by moodz View Post
    If you want a ............... and you have missed one big GOTCHA ( dont worry ... the commercial manufacturers missed it also - but that is a story for a later time ).
    Great observation, but unless the observation is revealed, its as good as not being there.

    And, If commercial manufacturers, with an Army of developers, researchers and umpteen resources missed something important, I think I can be pardoned, being a lone researcher, with very little time for all this, and completely out of electronics / signal processing / metal detector field for many decades.

    though, I am not sure that the commercial manufacturers would have missed out something important, it msy be that they havent revealed or found it too insignificant or have found better alternatives.

    Leave a comment:


  • moodz
    replied
    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.

    Click image for larger version

Name:	image.png
Views:	346
Size:	19.8 KB
ID:	433429​

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

    Leave a comment:


  • Aziz
    replied
    Originally posted by dbanner View Post

    I own one of these Alienware alphas. https://www.cnet.com/reviews/alienware-alpha-review/
    Can I adapt it to do what you are doing?
    Nice Box!
    ---

    Oh oh oh!
    I'm not happy with my new sound card (USB Creative Sound BlasterX G6). Too much noise in the upper frequency range (48 - 96 kHz). SNR down to -100 dB at Line out -> Line in loop back connection. This gets even worse sometimes.
    Below 48 kHz signal range it is acceptable (-110 dB). But I have better other sound cards.

    Found another issue: USB-Power supply does not seem to be good filtered in the sound card and is producing noise in the upper frequency range too.
    I have to buy or make an USB-Power filter. I hope, it gets better then.

    I have to redesign the old detector software (it has 1001 features ). A light weight, less power consumption version would be really nice for field testing and detecting.

    Cheers,
    Aziz

    Leave a comment:


  • dbanner
    replied
    Originally posted by Aziz View Post
    Hi all,

    just want to let you know, that my new USB sound card has been delivered and it works nice. Slighty more noise floor above 60 kHz. Between 70 - 80 kHz there is a low pass filter corner frequency. But I can still detect and process signals up to 95 kHz with some attenuation. Nice.
    Aziz
    I own one of these Alienware alphas. https://www.cnet.com/reviews/alienware-alpha-review/
    Can I adapt it to do what you are doing?

    Leave a comment:


  • dbanner
    replied
    Real-Time Linux preemptive.

    Leave a comment:


  • Aziz
    replied
    Hi all,

    just want to let you know, that my new USB sound card has been delivered and it works nice. Slighty more noise floor above 60 kHz. Between 70 - 80 kHz there is a low pass filter corner frequency. But I can still detect and process signals up to 95 kHz with some attenuation. Nice.
    Aziz

    Leave a comment:


  • Atul Asthana
    replied
    Originally posted by Aziz View Post
    Hi all,

    in my special USB high latency case (Windows isn't an RTOS),
    I have to decode even twice more to get the correct absolute phase lag between TX and RX. So I have to process the TX signal as well (besides the RX signal). Btw, any TX energy loss and frequency shift will be detected too. This gives more info for further processing.
    For a true dual frequency VLF/LF detector with three narrow frequencies around the resonant frequencies, I need 12 decoders. This is no problem with CPU power on Tablet PC. But can be critical on embedded systems with micro controllers.

    BTW, it is important, that the narrow band width should not be large, as we don't want to to operate the coils in the high Z region (Z is impedance of the LC-tank). We need some current flow through the TX coil of course. We are operating the TX coil in the low Z region around the resonant frequency fr.

    Heavy mineralisation will increase the TX/RX inductance (and thus lower the resonant frequency) and targets will lower the inductance slightly (hence increases the resonant frequency). Magnetic field conduction TX -> RX occurs on ferro magnetic materials nearby the coil. Eddy current induction on metal targets too. All possible effects can be processed at the same time.

    Aziz

    Aziz,
    YOUR EFFORTS will break the existing metal detector manufacturers

    btw, for your information, Window's monolithic structure and its irregular internal integration is a nightmare for any real time data acquisition/processing.

    Linux is much better : you can run it barebones to the minimum, and I know of radars, sonars and gun control systems happily running on Linux.

    You should try with ChromeOS tablets, seems the 'ChromeOS' is more of a shell and VM/compatibility layer (for android) with underlying everything on thinned out linux.

    I considered using my ChromeOS tablet before focusing on Bee-Buzz 1, but didnt have enoigh time to read thru the ChromeOS and analyse it for the real time requirements.

    Leave a comment:


  • moodz
    replied
    Originally posted by dbanner View Post

    Octave compares favorably with MatLab. It's also free and open source and has good support. Capability seems to be on par with most of the functionality.
    Yes .. I used both years ago. Either should work for VLF sims.

    Leave a comment:


  • moodz
    replied
    Originally posted by Aziz View Post
    Hi dbanner,

    529-ball grid BGA package
    Neural Cash Cow -oops- DSP.
    Typical marketing B$.

    Not enough pins to start with!
    I wouldn't touch a cpu/dsp under LGA1155 pin count.

    Don't dream of such machines. You can have much better machines without using soldering iron.
    Cheers
    Aziz
    Aziz ... start a new thread ... the Bee Buzz should be focussed on the blue pill and the VLF development and what can be done with it.

    Leave a comment:

Working...
X