-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GSSI data issues #3
Comments
P.S. The fork is here: https://github.com/iannesbitt/GPRPy |
Also, this file format description GSSI sent me may be of help to you: https://github.com/NSGeophysics/GPRPy/files/2810655/DZT.File.Format.6-14-16.pdf |
Hi Ian, Thanks so much for pointing this out and for providing a solution! I wonder why the header in your DZT file is different from the headers in the DZT files I had been working with. Have you tested your import with the provided example data (gprpy/exampledata/GSSI/FILE____032.DZT)? Could it be that perhaps GSSI updated their headers at some point and you have a newer system? In that case I should probably write gprIO_dzt such that it can discern between the two versions. Do you have an example data file that you are ok sharing that I can use to test? What year was your system manufactured? Or do you have a special version? Thanks and cheers, |
Alain, From what I understand, GSSI headers have changed many times over the years. The PDF I linked to describes some calculations you can do to determine which type of header a certain file has. Yes, I can open your DZT with readgssi: I'm still not sure if I can open all of the old versions of DZT though. I've tested and been successful with probably three generations of the file structure (including some new ones with more than one radar channel) but I think there are more I haven't come across yet. If you'd like to test with one of my files, I've provided one here: I love your software and can't wait to use it with my data! Ian |
Here's some more potentially useful info I have kicking around: GSSI user manual from 2015. Pages 55-57 have similar information to that given in the 2016 DZT File Format pdf linked above: A 2002 USGS document which describes the DZT file format from that era (p.85-86): |
Thank so much Ian, |
This may be a bigger can of worms than you're willing to open, but I also have a dual-channel example file here if you'd like to test with that as well. Antenna 0 frequency is 800 MHz, and antenna 1 frequency is 300 MHz. Previous versions of my software could read dual channel files but I'm working on fixing a bug in the current version that causes it to crash when reading. |
About the multichannel: |
It works! Thank you! I will add to my readgssi to-do list a way to export multichannel array data to separate files with the same basename (numpy binary and JSON, for example). Would something like this work?
Alternatively, I could try writing to multiple separate DZTs. |
Awesome! Thanks again for pointing out the issue and providing help with solving it! For exporting multichannel data as individual files for each channel: I think something like json and npy could work. Or perhaps just a binary file of the raw data per channel and a separate ASCII text file header containing some information with keywords such as "ntraces", "traces per meter", "trace length [ns]". I'll leave it up to you what you find the most intuitive. You could also create DZT files but that could be a bit tricky as you'd need to write the header bits exactly like they do it... |
Hi Alain,
I tried to open some of my own GSSI data (example file TEST__001.DZT attached)
with GPRPy and ran into some trouble. My own import function reads it just fine.
I'm relatively sure that your import script thinks the header of my DZT is 8 bytes larger than it really is. After some head scratching, I was able to at least rewrite
gprIO_DZT.py
to at least be able to reshape the array correctly. But it seems to still get the datatype wrong (or perhaps there's still a byteshift somewhere), so the profile looks kind of weird. I still can't quite figure out why this is the case. What I've done to temporarily lazily patch it is rewritegprpy.importdata
to use a function I wrote calledreadgssi.dzt.readdzt_gprpy
that loads DZT header data and array in the same format asgprpy.toolbox.gprIO_DZT
does.Line 17 in
gprpy.py
:Lines 87 and 88:
However since my file did not use a DMI (this was a lake profile so it uses scans per second instead), it has no distance data attached to it. So I've also rewritten line 90 to handle a
ZeroDivisionError
in case scans per meter is zero in order to calculate profile position:This seems to work reasonably well but since I haven't changed anything in the gui it still displays the plot position in meters.
I have the changes in a fork and will open a pull request if you'd like. Otherwise, take a look at how gprpy and readgssi import DZTs and see if you can figure out how they read the array differently.
Best,
Ian
The text was updated successfully, but these errors were encountered: