I Would Like to Welcome the Following Organizations to the GPR-SLICE Community

Newsletter – October, 2006

GPR-SLICE Users,

I would like to welcome the following organizations to the GPR-SLICE community:

Kyongbuk College of Science, Korea

Historical Archaeological Research, Indiana

Geocarta, France

Professor Guja Bong of the Kyongbuk College of Science in Korea is an archaeologist. He was recommended to the software by Dr. Hyundok Oh of the Korean National Cultural Properties Research Institute who has been user of the software since it was in DOS. Professor Bong has signed on for GPR-SLICE, our Open GL module VIEW, and also GPRSIM. I am very indebted to Dr. Oh as he is currently helping to train Professor Bong's research group on the operations inall of thesoftwares.

Rich Green from Historical Archaeological Research ( in Indiana is also an archaeologist that was recommended to the software. We ran a training session over the phone and he was able to get out some fairly nice images with the software. If you have an opportunity to visit Rich’s website, there are also many great links that you can locate in the field of archaeological remote sensing.

I am also very happy to inform the GPR-SLICE community that Dr. Michel Dabas and his company Geocarta ( in France has also signed on. I have worked with Michel on the Wroxeter Roman Town project in England back in 1995. Michel is one of the original developer andpioneers in ERT (electrical resitivity tomography) andhis companyare the first to develop new equipment for this geophysical remote sensing technique.Michel was also an instructor recently at the University of Sienna workshop and also he will be an instructor at the upcoming EriceFieldSchool in Sicily next week. Michel's company will be our first organization to join the GPR-SLICE community in France.

We welcome these new friends to the GPR-SLICE community! We are now at 75 organizations using GPR-SLICE v5.0!

Update:

There have been4 new options added to GPR-SLICE: 1)tunnel/cylinder warping of radargrams, 2) GPS/GPR staggering corrections, 3) automatic deletion of consecutive and identical GPS readings, and 4) automatic filtering of GPS fallout points:

1)Tunnel/cylinder warping of radagrams: Warping of radargrams for use in tunnel surveys is now available. Last year we made available tunnel and cylindrical warping of 3D volumes, however, we did not have the option available for doing this to the raw or processed radargrams. This was implemented into the software using a new menu in the Radar pull down call Cylinder or Tunnel Warping (see Figure 1). In the Radargram Tunnel Warping menu, one can set the starting and ending angle to warp the radargram over. Tunnel warping from a survey made on the inside or from the outside of the tunnel can be implemented. The example shown is for tunnel warping from inside. The user can also set the starting and endingsamplevalues within the radargram to warp. A separate menu called radargram cylinder warpingis also available, but this is essentiallythe same function of tunnel warping when the inside radiusis set to 0. An example ofcylindrical warping of a radargram is shown in Figure 2.

When the warping process is complete a message box will appear that will indicate the name of an automatically created information file to describe the warped radargrams. Tunnel warped radargrams will have an information file appended with the word tunnel; similarly cylindrical warped radargrams will be appended with the word cylinder...eg. info-tunnel.dat or info-cylinder.dat. Warped radargrams have a new scan length associated with the radargram. For cylinders the new scan length is simply 2*(sample end - sample start). The new tunnel scan length forthe radargramsis 2*(sample end - sample start + inside radius in samples). This is written into the new information files describing the warped radargrams. The warped radargrams are written to the \topo\ folder. You will need to make these info files active in order to properly display the warped radargrams.

2)GPR/GPS staggering corrections: GPR/GPS navigated images can also suffer the same kind of noises present in typical gridded surveys. Last year we implemented staggering corrections which account forimage noises causedby making azig-zag survey. The small spatial offset between forward and reverse lines can be caused by either phase delays in the data buffer that get recorded from the GPR control unit, or user induced by improper navigation such as not using the center part of the antenna as the 0 start/end location of a profile. The staggering correction was added to the Grid Menu in May of 2005.

Well, staggering can also occur with GPS navigated surveys. An example was recently sent by Erik Kitt and Brian Herridgeof 3DGeophysics.com. Their company is also the US distributor for Sensors and Software equipment as well as decimeter navigation equipment. Shown in Figure3 (bottomdiagram)is an example of the staggering problem that Erik found several weeks ago after performing a GPR/GPS survey. The problem is caused by a phase delay between the scan that is tagged with the current GPS navigation.Severalusershave been doing GPR/GPS surveys since 2003 and this may be the first time that this staggering noise was discovered. It may bedue todo GPS logging that hascreated some time delay in recording. Currently, we can implement a correction for this problem assuming the staggering is caused by a constant shift between the GPS reading and its corresponding scan number.

Shown in Figure4 is a screen shot of the new option in the Navigation menu. The Scan Lag menu item will shift a constant number of scans associated with extraction of the GPS trace number navigation. Remember, the 5th column of the *.gps files contain the trace number corresponding the eastings and northings values (which are in the 1st and 2nd columns of these files). When the GPS Trace # button is clicked in the Navigation menu, the constant scan lag value will be added or subtracted from from the extracted trace numbers (which are then stored in the /marker/ folder which is transparent to the user inGPR-SLICEoperations).

Shown in Figure3 (top diagram)is a GPS scan lag corrected time slice. It is quite dramatic how much improvement that can be seen in the corrected time slice! The scan lag offset for Erik's particular data was -30 scans. There is currently nomeasuring tool in GPR-SLICE to discover this value, but it is quite reasonable to estimate this. It can be done by measuring thestaggering lengthbetween adjacent lines in the staggered time slice image and determining the average samples per unitdistance you collected over the ground. In Erik's data the shift looked like about 2.5 meters, which corresponds to about 30 scans (where they collected about 12 scan per meter). Now, you may have to experiment whether the value needs to be shifted negative ( -) or in the positive (+) direction. You can look at the individual directions on the gps track map to determine thisk, or do what I did to correct this -I first guessed at +30 scans but the images got worse, so I did just the opposite and ran the time slice process a second time.

Now, Ryan North who works at the Geophysics Research Division at the US Army Corps of Engineers and is also concurrently working on a Phd in geophysics under Gary Ohloeft at the Colorado School of Mines, pointed out that solving the staggering problem will be better suited to shifting the data in time. We will need to approach this correction which will also be a more general approach. In this case we will need to begin using the time and date character information which will be written in the3rd and4th columns in the *.*.gps files. We hope to have this option for staggering corrections to GPS available before the end of the year.

3)Automatic deletion of consecutive and identical GPS navigation points: We are quickly solving a lot of unique issues associated with GPR/GPS navigation. Dru Wilbur who is at Brinkerhoff Environmental in NewJersey and is currently evaluating the software,had a unique GPS dataset. His GPS was recording navigation for every scan. Normally we have only seen GPS every 10 or 12 or some interval greater than 1. GPR-SLICE actually worked fine for data tagged every scan. For data being tagged every scan you are forced to use a cuts per mark setting of 1 in the Slice/Resample menu.. The problem with Dru's dataset was that maybe only every 10th or 17th or 25th scan actually had a different eastings and northings value.

If the GPS is notreceiving new information quick enough the time slice parameters will be bunched at the same location. To get the best possible navigation, you would normally want the data to be interpolated between gps readings. So having his conditioned data, would not give the best possible results. I imagine some of you will eventually be collecting GPS every scan and thus, I have included a new option called "del double GPS" - which will delete consecutive and identical GPS points in the *.*.gps files (Figure 5). This will allow deadreckoning to be more accurate in between GPS readings. In Dru's data, the original *.gps file had 6097 GPS navigation points or 1 for every scan. However, after using the "del double GPS" process in the Edit Info File menu, the number of points was reduced to 263!

I have included a copy of Dru's data (Figure 6).The dataset used a cuts per mark of 3 for the slice/resample menu. The time slices look a lot better by throwing away the extraneous GPS points.

4)Automatic filtering of GPS fallout points: Another embedded option was also implementedlast week for another GPS situation. Vicky Rystrom at Risk Reduction Resources is also evaluating the software and was using the Noggin cart system with GPS. Sensors and Software referred her to us since they said their own software is not capable of doing GPSimaging yet. Vicky's data had a lot of GPS fallout where the GPS eastings or northings values wereway off. She was forced to edit the *.gps files by hand to discover the bad GPS points.

We now have a quick fix for this. If any points are more the 15% away from the average eastings or northings values for a site, these are automatically removed when the user clicks the "del bad GPS" button (Figure 5). A message box will appear each time a file with one or more bad GPS points is found. I can imagine if 20 or 30% of the points are bad that this algorithm may not work, but you will quickly learn which are the problematic navigation files. We will make this and some other options in a separate GPS filtermenu with the ability to move points around in the GPS files with mouse in the future. Perhaps the ability to interpolate between good GPS points to replace bad ones can be accomplished in the next update.

One important note about using the "del bad GPS" process, if you do not have trace/scan numbers, e.g. they are 0in the 5th column of the *.gps files, a warning message will appear. You normally will not want to use this process because your only alternative to tagging the data is with the Artificial Marker process in the Navigation menu. And because you are removing a line or two, the tagging is no longer appropriate unless the GPS Trace Numbers are used as the navigation markers.

The update is available on the Subscribers Only page of the website, password to unzip is "Gypsy Ln".

Operational Notes:

An extremely important operational note for examining processed GPS/GPR radargrams. You should never used resampled data in the signal processing for GPS/GPR radargrams. The reason for this is that if you resample the radargrams to some different number of scans, then if you click the GPS Trace# navigation, the scan positionwill correspond to the radargrams located in the \radar\ folder. You can effectively use all the signal processing function on the radargrams in the \radar\ folder with no problem. The only function which may not be totally accurate yet is the migration operation for GPR/GPS navigated radargrams. Migration requires spatially constant radar pulses across the ground. If the GPS was triggered by continuous time and variable antenna velocity, migration is less appropriate.However, if the GPS is triggered by the survey wheel every constant number of scans and reasonably straight lines are being collected, then our 2D migration can be effectively applied. The only way to effectively migrate with a real random GPS track is to create a 3D radargram volume and apply 3D migration. We may eventually go there, but 3D migration is certainly not appropriate for single channel data that we mostly collect. The reason being that we often do not know the navigation accurate enough, to within a 1/4 wavelenth to use migration effectively. However, with the onset of either laser ranged surveys, or fixed multi-channel carts systems which are now being used, we will need to eventually develop 3D migration for these survey applications.

For those of you that are using 64 bit machines, you will need to go to the Supports page of the website and update your security device drive. Download the cbusb64.zip and run and install the correct drvier. There was also a firmware update for 32 bit machines which is what most of you are running. Download the CBUSETUP.zip, formerly called CBSETUP.zip and run the appropriate security device.

Upcoming Events:

The United States Forest Service workshop at the KisatchiNational Forest in Louisiana is filled up! 25 attendees have already signed up. I was asked by several of the more advanced users that are going to be attend the workshop, that we break off into another conference room to address their desires on the more advanced topic in the software. Brian Haley has volunteered to teach the introductoryportionat the workshop.I have discussed this with Velicia Bergstrom and John Ippolito and they concurred that it may be a good idea to break up the class for those that want to learn the advanced topics.. If this is the case, for those users that have signed up and wanted to split off into the advanced discussion, we can open more slots for the beginners that want to take the course. For those that want to come to the advanced course you must bring your own computer and your own security key. Also, if you want advanced instruction, please let me know what topics you would like to have. I would personally recommend that rather than make the advanced discussion formal, that you would bring your own data and I would act like the Slice Master and help you in a round robin sort of way. Some of the topics that overlap we can project theprocess operations on the screen. The introductory course taught by Brian will be in the formal computer room which has 25 computers.

Please get back to me and cc Velicia and John you are a seasoned user and want to get some moreadvanced training. Also, if you are a beginner, still contact Vel and John and they could still probably squeeze you in since we will be breaking off part of the class to the advanced session.

I am leaving for the Sicily to participate as an instructor at the EriceFieldSchool from Sept 26-Oct 4th, After the EriceSchoolI will be giving a talk at the GeoFluid conference in Milan along with Mario Foresta ( Michel Dabas of Geocarta has asked me to trainhisemployeeson the software at an ancient fort on the Island of Lerins, off the coast of Cannes right after the Erice workshop. I hope to return to Los Angeles by Oct 16th. if you need any technical support we will most likely have to accommodate this via email during the next 3 weeks.

Best wishes, Dean

Dean Goodman

Geophysicist, Phd
Geophysical Archaeometry Laboratory

Figure 1. Example of tunnel warping of a radargram. Warping was done for a survey collected from the inside of the tunnel.

Figure 2. Example of cylindrical warping of a radargram. (Warping was done from 0-330 degrees).

Figure 3. Example of Scan-Lag staggering correction for GPS navigation surveys. (Data courtesy Brian Herridge and Erik Kitt,