from M.D to imaging

[AK48]

good evening, a technical question that is close to my heart, I would like to know how can we convert signals from any metal detector and / or magnetometer, resistivity meter into data that can be integrated and read by software 3D as for example the "3D visualizer" of okm which is a software written in Borland. I take for example, a simple detector, i.e. the surf master P.I, where to take the data and where to reinject them to transmit them to a PC to view them on a graphics software and what are the file extensions accepted by the graphics software , is it possible to convert these file extensions so that they are accepted from one software to another, ex: surfer , V3d , monMX , RES2D unv , RES3D inv , GRD HD 3D , Oasis montaj , SURFSEIS , etc., I would like a basic diagram in order to understand the migration of useful data from a given detector to a graphic software, thank you

[ivconic]

For my magnetometer "Euromag 3D" (an unfortunate name, I didn't know there was a company with that name at the time),
my younger son wrote software for windows and android platforms, according to my instructions.
For devices such as magnetometers; such software makes sense.
But for PI detector; I fail to see what the point would be, what is the use of it?
Although, a couple of years ago I made a "logger" for a PI detector, which also has a BT and which sends detection signals to similar software.
I did this at the express request of one customer. By the way, neither then nor now did I see any sense.
The same goes for IB detectors, what would be the point?
Ok, there are similar attempts, someone justifies it by the need to map the terrain, for example.
(Why bother and waste time and energy; when there are already free phenomenal Android apps that do it much better in combination with GPS mapping.)
If I'm not mistaken; Turkish Nokta has made a similar detector, which also has a lidar sensor, which monitors the movement of the search coil and plots it.
But I still see neither the meaning nor the need for such a thing.
Except ... to make the product look "smarter" and to sell better.
But such a product passes only to laymen and those who have no idea about anything.

[ivconic]

As for the "portability" of logged data ...
in an ideal world, all similar software would be able to capture such portable data.
When we were creating software with my son, I originally had this idea, to make my record format "open" and "portable".
Also to keep our software "open" to other formats.
But unfortunately this world is based on money and profit ...
So I temporarily gave up on that "socialist" idea, which is not really bad.
I left that for future revisions.
And I plan to do that.
But unfortunately (and fortunately) now my son has too much work and too little time for something like that.
And I'm kind of a programmer. But I noticed a strange phenomenon,
neither I manage to fit in and understand the philosophy of the code written by my son, nor does he succeed the same with my code!
So it is impossible for me to take over the work on further revisions now. I have to wait for him to find time.
And to start writing new code from the beginning would be totally pointless. Nor do I have a grain of motive for it.
But as a "socialist", I support such ideas and I will see to it that it comes true sooner or later.

[Krzysztof]

I agree with Ivconic about the sense of recording MAG/GPR results, the remaining data from MD would have too much surface dispersion to place them accurately - even GPS in combination with an accelerometer will not be accurate.
There is a trend among software companies to adopt generally known and accepted data layouts in their programs for money. Other cases of programs are most often addressed to specific devices.
You can make a transcoder by observing the output of the data assigned to the specific values measured in the device and knowing the accepted input values of the software. However, this requires a lot of time and willingness, it is even more difficult to do it on the fly.
However, it is best to make your own device with the output set for a specific available program.
I am not surprised by companies encoding output and input data, the protection of intellectual property and the contribution of labor protects against dishonesty.
Of course, there are free programs available for educational purposes.

[ivconic]

I would like to know what the general consensus is about the structure of data in such a portable format,
which would meet all expectations.
Ok, reading from the sensor is a mandatory part, coordinates, maybe temperature, humidity, some system settings on the device
from which you are logging in, maybe date and time, etc.
While all of this is feasible for Windows platforms as well; however, it is clear that the Android platform provides much more,
easier to perform, ease of transfer to a more powerful processing and storage and analysis system.
Because the Android platform already has all the necessary services that start automatically and work autonomously.
Everything is already very well done on Android.
So if I were to start thinking more seriously about a better revision; I would definitely opt for Android (or iOS).

[Krzysztof]

I think that the system we currently use, including coordinate values and the result, is the most concentrated and at the same time sufficient for 2D and 3D visualization.
A dozen or so years ago I also used GPS to mark the beginning of the measured field and the initial time, sometimes I still associated each measurement with time, today I consider it to be redundant data, but this GPS is always there. Then I had to send this whole set of data to Exel and select only the necessary data there.
Currently, I try to minimize the amount of data transferred by using only the column number and saving the data in order in this column - this allows you to perform visualization even with an unequal number of measurements in the column (the beginning of each measured column must be on one line). Any data from GPS can be included in the name of the transferred file.
Of course, I already perform all calculations in the device, and the data is ready to be presented on the LCD, stored in SD, or transmitted.

[AK48]

good evening and thank you, nevertheless my goal is not to hack a imaging program belonging to a company and subject to rights, nor to write a program for the surf master, my goal was only the learning and the know-how, I agree that for a pulse, the example is badly chosen but on the other hand for a no-motion or a magnetometer for example: Earth Resistivity Meter
by John M. Stanley, I just wanted to know the basic principles concerning where to take the data and how to transfer it to an imaging software for learning purposes
thank you

[Krzysztof]

I just wanted to know the basic principles concerning where to take the data and how to transfer it to an imaging software for learning purposes

The data is most often arranged immediately after each measurement in the form of XYZ, i.e. XY coordinates and Z result, the norm is also to store them in the SD card on an ongoing basis.
The transfer itself to a cooperating computer with a graphics program can be done in various ways:
1. manually - transfer the SD card.
2. wired - sent via UART as RS/TTL or USB.
3. wireless - via BT, BLE, Wi-Fi.
The rest depends on the visualization program.

[ivconic]

As I mentioned, a few years ago a customer wanted a 2D / 3D display and logger for a PI detector.
Although I personally don't see the point; of course I agreed to do it.
The lucky circumstance is that the PI detector is mostly of the "non motion" type.
Where to get the log signal; that was my dilemma.
In the end, I decided to take it from the final audio stage, since it is providing accurate information.
And then things get a lot simpler.
Audio is converted to digital value, via ADC, that value is logged in a unit of time.
It is then sent via BT to Android which has a 2D / 3D application.
The application shows a logged signal in real time.
If the object in the soil is very large and widespread; in this way its contours can be shown very clearly.
So, if we are talking about the data itself, it is a procession of simple data.
Now that I'm discussing this, imagining a similar application with non-motion VLF I / B detectors, I come up with an interesting idea.
The detector should have an option to monitor the GEB signal, a change in the GEB signal, something similar to the option on XP Deus, which shows the GEB VDI number.
So one important piece of information would be that and the other important piece of information would be the signal from the metal channel.
A 2D / 3D image would show the state and changes of the GEB and the state and changes of the metal channel.
When it comes to a sophisticated machine like Deus, it is not necessary for the detector to be of the "non-motion" type.
Conversely, if it is a "non-motion" type of detector, the conclusion is that it must be a very sophisticated machine.
And that's the "holy grail" for me ... for over 35 years.
Because here, I have never seen such a machine. And I?ve had a few ?non-motion? detectors so far.
So, in my humble opinion, that such a logging system would make any sense; above all, a very sophisticated VLF I / B non-motion machine must be designed first.
Give me such a machine and I will design such a logger and software for 2D / 3D imaging.
The closest thing that could be is probably White's MXT, which is a mixed mode type. But unfortunately I have never seen it live and I have no experience with it.
Then it might make sense. With such a set, terrain mapping could be done in order to monitor the GEB situation.
It would be really interesting to see how the GEB display is functionally done on XP Deus.

[ivconic]

The data is most often arranged immediately after each measurement in the form of XYZ, i.e. the coordinates of the result, the norm is also to store them in the SD card on an ongoing basis.
The transfer itself to a cooperating computer with a graphics program can be done in various ways:
1. manually - transfer the SD card.
2. wired - sent via UART as RS/TTL or USB.
3. wireless - via BT, BLE, Wi-Fi.
The rest depends on the visualization program.

Quite right.
I did it bit different.
The procession of data for each sample is formed and resembles the CSV format and as such is immediately sent via BT to Android,
which has an active application, which receives this data in the form of BT packets, parses them correctly and draws them on
the display with the help of mathematical algorithms.
Also can be saved on SD card or on Android device, for storing and future use.

[AK48]

good evening, thank you for the explanatory treatise, you said: "
The data is most often organized immediately after each measurement in the form of XYZ, i.e. XY coordinates and Z result "could we see this on a diagram? these XY and Z data are transferred to a computer under which format? binary? if so, how does the graphics software integrate them? hey, yes, I'm sorry but all these questions are necessary for my understanding, I have a vague idea that we can take audio signals via the headphone output of a no-motion detector to transfer them to a device such as Tim Williams' Arc Geo Logger ( https://lrlman.com/arc-geologger.htm ), see also an old post https://www.geotech1.com/forums/show...N-DATA-LOGGER; or the Icon Data Logger, this would be for example the basic diagram of the Arc Geo Logger genre and its explanation with diagram or a module to be integrated into any magnetometer
you also say: " The rest depends on the visualization program. " this interests me and deserves a development you say: " As I mentioned, a few years ago, a customer wanted a display and a 2D / 3D recorder for a PI detector.
Although personally I don't see the point; of course I agreed to do it.
The fortunate circumstance is that the PI detector is mostly of the "non-moving" type.
Where to get the log signal; that was my dilemma.
In the end, I decided to take it from the final audio stage, because it provides accurate information. And then things get much simpler. value is stored in a unit of time.
It is then sent via BT to Android which has a 2D/3D application.
The application displays a signal recorded in real time. very interesting, could we have a diagram? Naturally all my requests are purely didactic.

[Carl-NC]

The data format depends entirely on the plotting software you want to use but it would not be difficult to support a few different formats. In the data logger micro you can make any format you want and then write it out via UART to an SD card or whatever.

I was going to suggest looking at the Arc Geo Logger as an example. It is used typically with a TF900 or TM808 and takes data from the audio jack. I don't recall the software Tim uses but it's free. I have an Arc Geo Logger somewhere.

Data logging makes sense even for a metal detector. As Tim's results show, you can make out subtle variations in the detector response that you might not notice just listening to the audio. An even better method is to data-log the raw X & R signals from the demods. You could then plot ground phase and maybe visualize disturbed soil or magnetic pockets.

[AK48]

thank you for these very instructive answers, would there be some diagrams to visualize these answers

[ivconic]

thank you for these very instructive answers, would there be some diagrams to visualize these answers

This is final version, including not only PI audio logger but also addition of one fluxgate FGM sensor logger too.
Idea was to place FGM sensor in the centre of PI coil and use it for the discrimination.
Or FGM can be mounted on different "stick" and used as fast probe.
This is further modular, can be only PI logger or only FGM probe, by omitting extra parts.
In this version i used audio signal to poll the digital pin in interrupt.
Since i designed this mostly for use with Pulse Star II detector, which is giving variable (rising and falling) pitch at the audio.
So, not only that i can log plain audio response, i can log the "pitch" too, by counting the frequency of the audio pitch.
Which is much better information at the end.
This is still commercial product, so i am not ready to disclose everything. Code for MCU and code for Windows & Android.
So don't expect that from me.
But it is still illustrative enough.
Using digital pin polling in interrup is rock solid , stable and 100% accurate method.
Although using the ADC might work as well. But for better results it will demand better ADC and more processing power.
My initial attempt was the use of the ADC. I was not satisfied, since Atmega328p can not give rather usable resolution for what i wanted.

[ivconic]

By plugging the audio jack into Pulse Star II socket for earphones; you don't lose the audio.
There is anotther speaker inside the logger enclosure. So it continues the role of original speaker in PSII.
Also there is audio output from the MCU, for the system sounds (button clicks, warnings, alerts etc).
So there is another speaker in the logger enclosure too. Smaller one. Or even smaller piezo can be used.
Also is possible to use the same one speaker for both audio sources with a bit of rearranging the components.
So PSII keeps operating the same as usual. You hear it's audio from speaker included in the logger enclosure.
There is a LCD too, showing various data and progress bar style graphical presentantion, and when in menu mode, showing adjsutment variables.
The "pitch" (frequency) of the PSII audio is precisely measuring and logged constantly.
Than from internal buffer taken and sent by BT to Android aplication.
All the 2D/3D processing then is done in the application.