Announcement

Collapse
No announcement yet.

Android Phone Based Metal Detector - FCMD

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

  • moodz
    replied
    Originally posted by Carl-NC View Post
    99.99% of all VLF and MF designs use synchronous demodulation, whether it is done with a discrete analog demodulator or done with direct sampling in software. For the software demodulator, it becomes simple to multiply by cos/sin to produce narrowband demodulation instead of the usual square wave used in the analog demod, which is a wideband method. But Minelab got a patent on narrowband demodulation so Nokta got around the patent by using asynchronous narrowband demodulation, where the f in the prior equations are no longer the TX frequency but slightly offset. This means the demod outputs are no longer quasi-static DC values but are now slowly rotating vectors that must be un-rotated, which can be done using another software demod. Asynchrounous demodulation has been used before in analog detectors, the Fisher Gemini is an example.
    patenting a software algorithm is difficult because patent offices generally consider algorithms and abstract ideas unpatentable, and you must demonstrate that the software provides a specific technical solution to a technical problem. ( modulation / demodulation/ phase detection is well known - its not a problem specific to metal detectors to be solved ). To make an algorithm patentable, it must be implemented in a way that shows a tangible, inventive contribution beyond just automating a known process​. Its arguable that narrowband and wide band demodulation techniques were already being done ( certainly for many years in radio circuits ) in analog hardware for metal detectors. Just because it is now done in software is not an inventive step ( moving from hardware to software ). If wooden houses are built with nails .... I can not ( reasonably ) claim a patent for building a wooden boat with nails.
    Ferinstance if I "really" wanted to get around the BS patents published by some metal detector companies I would use a high precision programmable SDR circuit with some frontend adaptation circuitry to do exactly the same thing ( if not better ) without infringing patents as using an SDR for this purpose would not be inventive ( for modulation / demodulation / phase detection).

    Leave a comment:


  • ivconic
    replied
    Click image for larger version  Name:	IMG_0891.jpg Views:	0 Size:	422.9 KB ID:	442410Click image for larger version  Name:	IMG_0892.jpg Views:	0 Size:	412.0 KB ID:	442411

    Not that I'm too happy with this solution... but it's certainly more acceptable.
    My son is in charge of Android but now he has a lot of work to do.
    When he has time; I'll tell him to correct the first code.
    I liked the first version better.
    But this one is not bad either.
    Okay.
    It's a matter of taste.


    ​​​

    Leave a comment:


  • ivconic
    replied
    Altra, don't give the man a shovel!

    Leave a comment:


  • Carl-NC
    replied
    99.99% of all VLF and MF designs use synchronous demodulation, whether it is done with a discrete analog demodulator or done with direct sampling in software. For the software demodulator, it becomes simple to multiply by cos/sin to produce narrowband demodulation instead of the usual square wave used in the analog demod, which is a wideband method. But Minelab got a patent on narrowband demodulation so Nokta got around the patent by using asynchronous narrowband demodulation, where the f in the prior equations are no longer the TX frequency but slightly offset. This means the demod outputs are no longer quasi-static DC values but are now slowly rotating vectors that must be un-rotated, which can be done using another software demod. Asynchrounous demodulation has been used before in analog detectors, the Fisher Gemini is an example.

    Leave a comment:


  • Altra
    replied
    Carl, thank you for taking the time to explain. I'm not using the AI code. I have a dual frequency circuit that I want to program and test. That equation had me confused.after reading the Nokta patent.

    This invention is related to the method providing computation of the signal frequency components in an acceptable accuracy in contravention of the shifts in the phase and the magnitude information caused by asynchronous sampling of the signals in the process of asynchronous sampling of metal detectors wherein the received signal by the receiver unit (4) divided into time intervals, say timing values those are far shorter than the sampling period and correspond to nearest probable sampling of the ADC (6); providing the computation of the sine and cosine coefficients or exponents of time constant coefficients of the said timing value from previously located or dynamically generated coefficient table; resulting the elimination of the requirement of synchronous sampling and the requirement of the signal period is multiple of the sampling period.

    Leave a comment:


  • ivconic
    replied
    Excessive math and formulas always ruin the topic!
    That's too much "swearing" for my refined sensibilities!
    I'm going to do something productive!​


    Leave a comment:


  • Carl-NC
    replied
    Originally posted by Altra View Post
    Carl, while we're on the narrow band demodulator subject. Could you verify if t = 1/fs in the equation. And is this a syncronise demodulator, assuming regular sampling interval at a rate 2x higher than the frequency of interest?
    No, t is continuous time. In the equations

    I(t) = s(t) × cos(2πft)
    Q(t) = -s(t) × sin(2πft)​

    f is the TX frequency of interest, that is, you demodulate the signal (which might contain several other frequencies), low pass filter, and the result should be a quasi-DC value that represents the amplitude & phase of that frequency only, at that particular instance in time. That's why t drops out in the end:

    I = (A/2) cos(φ)
    Q = (A/2) sin(φ)
    ​
    fs is the RX sample rate which needs to be high enough (fs >= 2*f) for Nyquist but can be much higher. Assuming a typical 44kHz audio sample rate, you will just meet Nyquist for a 20kHz TX component but will be way above it for a 1kHz TX component. You will normally want to demodulate at the sample rate so that successive calculations:

    I(tn) = s(tn​) × cos(2πftn​)
    Q(tn​) = -s(tn​) × sin(2πftn​)​​

    I(tn+1) = s(tn+1​​) × cos(2πftn+1​​)
    Q(tn+1​​) = -s(tn+1​​) × sin(2πftn+1​​)​​
    ​
    happen where (tn+1​​​ - tn​)​​ = 1/fs. But even this is only necessarily true for, say, the 20kHz content. For the 1kHz content, you could throw out 19-of-20 data points and demodulate at 1/20th of fs. But I don't know why you would do this.

    Leave a comment:


  • moodz
    replied
    Originally posted by Carl-NC View Post

    But the phase reference IS needed, or you would not have added it. That's my whole point: you need to know what you are doing in order to be successful using AI. And it's funny that your solution is exactly how all VLF metal detectors do it, yet AI missed that point entirely -- it's a really basic element of synchronous VLF designs. And, yes, time does exist in code, in the same manner that signal voltages exist in code. Maybe not as literal time or voltage, but as coded representations.

    This is truly an impressive demonstration of what AI can do, but if it was not for you, it would not have worked properly.

    One other point: the narrowband demod method suggested by AI is an excellent solution, but it is covered by Minelab patent US7579839. Although the Australian version of this patent has lapsed, the US version has not, and there may be an active WIPO version. Personally, I view the patent as bogus -- the technique has been used for 100 years, so it's just an application of existing tech specifically to metal detectors, i.e., there was no inventive step -- but so far the courts have not.
    You are absolutely right Carl .... the AI did actually come up with an elaborate autotracking scheme using a reference tone at 20Khz being fed back from the TX to produce a phase error signal that would be applied to the demods internally and I did suggest that maybe a more simple solution was possible and it went with that. This is just an exploration of AI capability and I am not actually that interested in making a detector based on a phone.
    However the fact that it got it working at all without any coding input other than "conversational instructions" is very impressive IMHO also.

    Here is the patent report : Oh I can see the future is in machine written patents !

    Attached Files

    Leave a comment:


  • Altra
    replied
    Carl, while we're on the narrow band demodulator subject. Could you verify if t = 1/fs in the equation. And is this a syncronise demodulator, assuming regular sampling interval at a rate 2x higher than the frequency of interest?

    Thanks

    Leave a comment:


  • Carl-NC
    replied
    Originally posted by moodz View Post
    The reason that phase references are not needed is because time does not exist in software code. Its just code ... it has no time dimension. However time does exist once it comes outside the CPU where a real time TX and RX signal is generated. Just because you tell the Codec to produce 20 KHZ .. does not mean that the RX will sample at the same rate. So testing the hardware showed phase rotations occurring due to this problem.

    We just use the real TX signal as the demodulation Local oscillator signal. This compensates for the problem with the phase rotations due to CODEC clocking differences between TX and RX.
    ​
    But the phase reference IS needed, or you would not have added it. That's my whole point: you need to know what you are doing in order to be successful using AI. And it's funny that your solution is exactly how all VLF metal detectors do it, yet AI missed that point entirely -- it's a really basic element of synchronous VLF designs. And, yes, time does exist in code, in the same manner that signal voltages exist in code. Maybe not as literal time or voltage, but as coded representations.

    This is truly an impressive demonstration of what AI can do, but if it was not for you, it would not have worked properly.

    One other point: the narrowband demod method suggested by AI is an excellent solution, but it is covered by Minelab patent US7579839. Although the Australian version of this patent has lapsed, the US version has not, and there may be an active WIPO version. Personally, I view the patent as bogus -- the technique has been used for 100 years, so it's just an application of existing tech specifically to metal detectors, i.e., there was no inventive step -- but so far the courts have not.

    Leave a comment:


  • ivconic
    replied
    Perfect weight lifter and trench digger, I agree.

    Leave a comment:


  • moodz
    replied
    Originally posted by ivconic View Post
    Truth be told, the first thing I thought of was how the ESP32 would cope in performing those tasks and that's how I came up with the objective 3 frequency.
    The second thing that immediately came to mind is almost 1 year of off-road experience with the Vanquish and Equinox models.
    Vanquish as a (then) cheap model delighted me with its sensitivity to very small objects, grains... later Eqinox too.
    But it was rather disappointing (like all other models and brands ever made without exception) on the problem of various aluminum foils and lead chunks vs thin silver and especially gold coins.
    We have skipped an unforgivable amount of gold coins to this day because of that problem, and this is proven to me more and more every day.
    With this in mind, on most ancient terrains you have to be prepared to dig low VDI numbers as well.
    And that pretty much makes the whole story pointless, doesn't it?
    Maybe not in the vast deserts of Australia, where you have a clash of ferro vs gold.
    But on my grounds we have a fundamental problem here with pieces of aluminum foil and lead vs the most expensive finds.
    I will digress, but this has a bit of an analogy with covid vaccines. RNA vaccines have proven superior in laboratories.
    But in practice...?
    ...
    The reason I played around with Python code is quite practical. I can't figure out a way to do that on the Android devices I have; keep the system audio but also provide an output for TX.
    This is a pretty big problem to solve. A smart phone dongle is a solution, but not available to everyone.
    And then there are the mental images in the head; me on the field carrying a phone with an added dongle from which the cable goes to the coil! lol
    But for "laboratory" conditions, experiments and further learning; the project is really fantastic, my hat off!
    One thing led to another and then I remembered that there are small USB audio card dongles that register as a separate and independent device to the Windows system.
    The price is a couple of dollars and anyone can get them everywhere.
    I don't know how easy it is to do this under Android, but it's easy under Windows.

    ​
    Click image for larger version Name:	image.png Views:	0 Size:	294.2 KB ID:	442328​
    Yep .. FCMD project is just an experiment in AI usage. I never wrote even one line of code, wrote one document or drew a diagram. The AI generated it all. Not only all the code but it also set up an populated the Github site. Every time it generates a new feature. I load the app in the phone ... have a look then tell the AI to "update the eBook" and it just does everything. I only had to tell it my username on github. Its never failed a single compile ... the code quality is almost magical.

    I did make suggestions to it to solve some problems ... like fixing the phase rotation instability by injecting the TX signal from Lout to Rin and using it as the LO. But that is literally what I told it and it went off and generated the code and updated the documentation and pushed it to Github. Productivity just went up by 1000 X.

    The FCMD actually works .... it needs more finessing ( this can be human or AI ) but the point is to generate so much progress in such a short time would be impossible using previous manual coding.

    Some people have suggested that LLMs ( AIs ) are just big look up machines ... this is wrong ... they are massive probability vector fields with feed back ( See the sentinal paper in the subject "Attention is all you need " ) Nothing is stored verbatim in these probability vectors ... information is generated on probabilities and context. The feedback path feeds the output back into the input and it affects future output probabilities ... very simplified answer ... more complex than that. but anyway.

    The bottom line is if you know how to ask the right questions ... you dont have to write code any more / or compile it / debug it / document it.

    Leave a comment:


  • ivconic
    replied
    Originally posted by Carl-NC View Post
    ...But beware AI, I've used it and gotten a lot of wrong answers. It's important to know enough about the subject to keep it in check...
    You'll think I'm joking this time too, but no, this is the truth. Ever since the first AI's came out, I've tried many methods to get the AI ​​to not spout gibberish every other sentence.
    And after many unsuccessful attempts... I think I found the method! (it's similar to forum methods, lol).
    After every mistake the AI ​​makes, and it makes fairly banal mistakes very often; I burst into violent swearing and name-calling!
    The first reaction of all AIs so far is a sudden withdrawal and warnings that this is not a correct method of addressing.
    But if I persist in such behavior; The AI ​​"gets used" to me and after a few days accepts such behavior and considers it an indisputable part of my character.
    And then, miraculously; make fewer mistakes!
    ...
    What annoys me the most is when the AI ​​starts inventing pins and functions on the ESP32 that don't exist! Then a flood of swear words comes out of me!

    ​

    Leave a comment:


  • moodz
    replied
    The reason that phase references are not needed is because time does not exist in software code. Its just code ... it has no time dimension. However time does exist once it comes outside the CPU where a real time TX and RX signal is generated. Just because you tell the Codec to produce 20 KHZ .. does not mean that the RX will sample at the same rate. So testing the hardware showed phase rotations occurring due to this problem.

    So now we ( me and the AI ) use this scheme and it actually works because it compensates for the real world loop timing errors. See section 8 in the eBook its been updated.

    We just use the real TX signal as the demodulation Local oscillator signal. This compensates for the problem with the phase rotations due to CODEC clocking differences between TX and RX.

    I tested it with real hardware it works !

    Click image for larger version

Name:	image.png
Views:	415
Size:	55.0 KB
ID:	442330​

    Leave a comment:


  • ivconic
    replied
    Truth be told, the first thing I thought of was how the ESP32 would cope in performing those tasks and that's how I came up with the objective 3 frequency.
    The second thing that immediately came to mind is almost 1 year of off-road experience with the Vanquish and Equinox models.
    Vanquish as a (then) cheap model delighted me with its sensitivity to very small objects, grains... later Eqinox too.
    But it was rather disappointing (like all other models and brands ever made without exception) on the problem of various aluminum foils and lead chunks vs thin silver and especially gold coins.
    We have skipped an unforgivable amount of gold coins to this day because of that problem, and this is proven to me more and more every day.
    With this in mind, on most ancient terrains you have to be prepared to dig low VDI numbers as well.
    And that pretty much makes the whole story pointless, doesn't it?
    Maybe not in the vast deserts of Australia, where you have a clash of ferro vs gold.
    But on my grounds we have a fundamental problem here with pieces of aluminum foil and lead vs the most expensive finds.
    I will digress, but this has a bit of an analogy with covid vaccines. RNA vaccines have proven superior in laboratories.
    But in practice...?
    ...
    The reason I played around with Python code is quite practical. I can't figure out a way to do that on the Android devices I have; keep the system audio but also provide an output for TX.
    This is a pretty big problem to solve. A smart phone dongle is a solution, but not available to everyone.
    And then there are the mental images in the head; me on the field carrying a phone with an added dongle from which the cable goes to the coil! lol
    But for "laboratory" conditions, experiments and further learning; the project is really fantastic, my hat off!
    One thing led to another and then I remembered that there are small USB audio card dongles that register as a separate and independent device to the Windows system.
    The price is a couple of dollars and anyone can get them everywhere.
    I don't know how easy it is to do this under Android, but it's easy under Windows.

    ​
    Click image for larger version  Name:	image.png Views:	0 Size:	294.2 KB ID:	442328​

    Leave a comment:

Working...
X