I Would Like to Welcome the Followingorganizations to the GPR-SLICE Community s1

Newsletter -November2013

GPR-SLICE users,

I would like to welcome the followingorganizations to the GPR-SLICE community

·  Dept of Anthropology, University of Northern Colorado

·  Nakano Technology Co., Ltd., Saitama, Japan

·  Dept of Classics, University of Cambridge

·  Dept of Civil Engineering and Geoinformation, Oldenburg University, Germany

·  Terraprobe, Burnaby BC, Canada (www.terraprobe.com)

·  Dudek and Associates, Encinitas, California (www.dudek.com)

·  Terrasond, Palmer, Alaska (www.terrasond.com)

·  Informatic and Information Security Research Center

·  Tubitak Bilgem, Turkey

·  TAG Research by Sturm Inc, New Mexico (www.tagrsi.com)

·  Buyeo National Research Institute of Cultural Heritage, Korea

·  Connected Water Initiative, University of New South Wales, Australia

·  Cultural Resource Consultants LLC, Anchorage, Alaska

·  Bronx Community College, CUNY, New York

·  Geonorm Project Engineering Consultancy, Turkey (www.geonorm.com.tr)

·  Tongva Ancestral Territorial Tribal Nation Consulting, California

·  Dept of Mining Engineering, McGill University, Canada

In addition, GPRSIM licenses were delivered toDept of Earth Sciences, University of Toronto, Canada; Dept of Civil Engineering and Geoinformation, Oldenburg University, Germany;Guangxi Communications Investment Group Co., Ltd, China; Jiangsu Testing Center for Quality of Construction Engineering Co. China; Tubitak Bilgem, Turkey.

Software Updates

Among the most important improvements added to GPR-SLICE V7.0 Software are:

·  Navigation markers inserted directly on the \radar\ folder

·  Slice/XYZ operation for working with native density radargrams

·  2d/3d Kirchoff Migration added to filter menus

·  Improved auto hyperbola detection options

·  0 median grid mosaic correction

·  User defined labeling - scan header labeling override for ANG surveys

Navigationmarkersinserted directly on the \radar\ folder

The title of this new option "Navigation markers inserted directly on the \radar\ folder" may seem strange but it has significant meaning for streamlining operations in GPR-SLICE. Historically, since the inception with GPR-SLICE for DOS, navigation was only placed on the radar scans after slice/resample operations were completed. The \resample\ folder radargrams contained navigation tags in the 2nd sample of the radar scan and only on these radargrams or radargrams processed from this folder, could navigation labeling be available. GPR-SLICE axis labeling requires navigation tags to exist on the radar scan in order to obtain a drawn label. GPR-SLICE operations now directly place the navigation tags on the scan headers in the \radar\ folder (Figure 1). The operation is only run one time on the \radar\ folder after which the Navigation menu never needs to run again. PreviousGPR-SLICE applications required always returning to the navigation menu to apply navigation prior to running slicing operations on any processed folders. Also, had user tried todisplay \radar\ folderradargrams, no axis labeling would appear since navigation tags did

Figure 1. The new look in theNavigation menu where only the \radar\ folder initially has navigation appliedonly one time for all processes.

not exist on the \radar\ folder for survey wheel or GPScollections. Field marker radargramswould show axis labeling as the tags natively exist in the radargram scan header

Note: Previously, all operations for slicing would look at a file called the \marker\*.mrk files which were generated when running the navigation. These files contained the list of scan numbers in the radargram where xynavigation is known. These files most did not know existedas they were in aseparate folder inside all projects and never directly accessed. The \marker\*.mrk files are now not used although still being written. The marker tagsdirectly stored in the radargrams are read internallywherever operations requiring the scan numbers are needed, such as in slicing operations or xypoints etc.

Note: For users thatnavigate asurveywith field markers and do not use survey wheels or GPS, only the Field Markers operational button should be clicked in the Navigation menu. Clicking the Artificial Marker operation for instancewill erase the field markers in the converted radargrams. If this or any other navigational options such as Interval Markers or GPS navigation buttons are accidentally clicked, the user will need to reconvert the radargrams from the Convert menu in order to see the original field markers.

The idea to place navigation tags directly onto the radar scans in the \radar\ folder initially -rather than requiring resampling operations where marker tags are assigned, came about as several users asked about using the native radargrams without having to resample the radargrams, especially for data collected witha survey wheel for instance. By placing the tags into the \radar\ folder radargrams, working with the native scan density collected on a site from a survey wheel is now available. This discussion takes us to the next major operational option nowin the GPR-SLICE software:

Slice/XYZ operation for working with native density radargrams

Figure 2. Slice/XYZ operations were no resampled radargrams are generated are now available for working with only the native density radargrams.

With the application of placing navigation tags into the \radar\ folder radargrams, the necessity to resample radargrams is no longer a requirement. Users can now simply run the Slice/XYZoperation and never need togenerate the \resample\ radargrams if so desired (Figure 2). For those that are concerned about using only the native radargrams then this button may be the operation of choice. Resampled radargrams of coursehave advantages such as a constant number of desired scans between recorded navigation tags which can make 2D displays often morevisually desirable. In any event, if a user chooses a proper resample/scan value thenresampled radargrams willalways have the same resolution in the native- recorded radargram.

Restating these two latest options added to GPR-SLICE for streamlined operations are:

·  markers tags are now stored directly in the scan headers in the \radar\ folder

·  navigation only needs to be run one time initially on the \radar\ folder

·  processed folders from the Filter menu do NOT need to have navigation reapplied

·  native scan density \radar\ folders from can now be used for all processes

·  \resample\ folders will continue to be made and can also still be used for all processes

Note: BlueBoxBatch operations currentlystill contain resampling operations. We may see about providing options forworking with native scan density radargrams in the future for BlueBox operations.

Improved auto-hyperbola search function

Anew algorithm toautomatically detect hyperbola on radargramshas been advanced (Figure 3). The new Autosearch2button will engage a 5 point search.The search will look along a horizontal line from the mouse location which is typically placed near the apex of the hyperbola. Normally you will want to place the 5pt search line on the 2nd pulse of the return and center it. If you do this and properly adjust the migrator width, the software will set amplitude thresholds automatically on the center, points 1/4 and points 1/2 the total migrator width on each side. If you choose a proper migrator width, the outside points (#4 and #5) will have the opposite signs then the inner 3 points. Searching the hyperbola with this algorithm

Figure 3. Location of the new automatic hyperbola detection operation for examing 5 pts across the hyperbola apex.

has proven to work significantly better than the scan/threshold method which is still in the menu. The operations are to click the Help 5pt button, move the hyperbola/line to the desired location, then left click the mouse. This will update the search parameters dx1-5 which are the nearby

scan locations from the center, dy1-5 are the horizontal samples on the pulse, and a1-5 are the amplitudes at the 5 points. The amplitudes a1-5 are decreased from the actually amplitudes at those locations. The pointa1 is stored as .8 of the detected value, a2-3 are recorded as .5 and a4-5 are recorded as .25 the actual recorded values to insure that amplitudes of slightly weaker hyperbola can be detected. These slots can be manually adjusted as well. The dy1-5 slots are always shown as 0 for the help 5pt search. However, these can also be adjusted by the user for a more customized search. For instance, searching a Hilbert transform-migrated radargram, one might one to have a vertical search on the pulse to isolate a strong anomaly etc.

Note: Autosearch2 still requires one to set the N-Skip and the N-Nearby settings. The N-Nearby setting will automatically look N scan to the left and right, and N samples up and down from thefirst detectionlocationto find the peak response from the initial detection. The N-Nearby functionality is also engaged should the user want to manually insert hyperbolas into the detection window. A value of 0 on the N-Nearby would yield exactly the detected location; values of 2-4 can assist in making the detected hyperbola more centered on the feature. There is also new setting call S-Backup. S-Backup will move the drawn hyperbola N samples on the pulse. S-backup is used to predict the first arrival of the wave and not the peak response, to give a better estimate of the depth to the top of the rebar. Even though the S-backup is engaged, the value of the peak response is reported and not the value where the hyperbola is drawn if this options is set to other than 0.

Kirchoff migration

Figure 4. Kirchoff migration operation in the 2D Filter menu.

The first migration routine provided in GPR-SLICE was diffraction stacking of the recorded hyperbolic reflections (sometimes referred to assimple hyperbolic summation). An improved migration routine - Kirchoff migration - that works similar to hyperbolic summation but accounts for amplitude adjustments for spherical spreading of the radar wave and also the obliquity of the wave on its arrival to the ground surface is now available in the Filter menu for 2D and 3D processing. (Figure4) The Kirchoff migration is the recommended migration routine and it performs better than simplediffraction stack migration. This routine also does not have any edge effects at the bottom of the radargrams as spherical spreading adjustments will properly weight the diffraction stacking of amplitudes in the migrated pulse (as seen in the example in Figure 4).

0 Median grid mosaic correction

Figure 5. 0 Median grid and 0 mean grid operations buttons are now available in the Mosaic Correction menu.

A new algorithm to try and automatically correct mosaic correction has been added to the stand-alone Mosaic Correction menu (Figure 5). The operation works by calculating the median value of each defined griddivision (defined in the info menu) and then normalizing all the blocks by their median value. For certain kinds of surveys noises the median grid algorithm may work to balance the differentsurvey blocks. This method is best suited to surveys where the distribution of data are similar in each of the blocks. e.g. the same number of weak, medium and strong anomaly areas are about the samedensity in each of the blocks. 0 mean grid operations are also now provided in the stand-alone Mosaic Correction menu. To properly view the 0 median corrected grids the user should run the operation on grid #1 so that this grid set will appear in the Pixel Map for further viewing an display.

The Regrid option can also work very effectively in the menu to adjust mosaic noises real time. In this operation, the user sets the desired block with the div+/- button, adjusts the gain or the dc offset to balance the data with a nearby block, then uses the Regrid button to re-grid the *.dat using the adjustments. In this method, while applying the gain or dc adjustments to the actual grid, edge effects will be seen in the drawing along the block edges. This is to be expected since the gridded data at the edgeswere generated withunmatched searched data from both nearby blocks. However, on re-gridding, the original *.dat is used to recalculate the grids and those edge effects will not be present after the operation. For 0 median and 0 mean grids, new *.dat and *.grd data are generated with the "0m" appended identifier. For the Regrid option,the *.grd isoverwritten with the original name. For 0 median and 0 mean operations and the Regrid option, the original *.dat must exist for the corresponding displayed grid file. Direct gaining on the *.grd file real time with writing to the "m*.grd" file is available and does not require *.dat data to exist.

User defined labeling - scan header labeling override for ANG surveys

GPR-SLICE has traditionally only outputted labeling on 2D radargrams that comes from the scan headers where navigation tags are stored in the 2nd sample of the digitized pulse. This has been a double check on navigation - as only tagged scans can force a label in the radargram displays. Even if a radargram is defined as some length in the info.dat file and there are no navigtaion tags in the radargram scan headerthat were applied through the Navigation Menu, no labels will appear on displays. For ANG surveys, where there can be fractional line lengths, the navigation tags may not be at integral lengths in the radargrams. Navigation tags for ANG surveys can be at non-integral lengths. The reason for this is in the process of creating time slices and a need to properly include and equal weight all portions of the radargram in the time slice binning process, tags are set at non-integral locations. For instance a 10.0 meter radargram, would get tagged with 11 navigation tags but a 10.43 metter radargram for wouldget 12 navigation tags(including the scan #1). The user would be able to break down the 12 tags in the radargram with the Cut Per Mark option to generate additionally smaller bins for time slice operations. With that said, because of the non-integral location that can occur with ANG survey for the tagged scans, on displays, the labeling will show at fractional numbers. This also requires that the # of decimals in the x axis display be set to something other than 0. Several users complained that they could not get out equidistantly labels at a desired graphic increment. For this reason, an old option that was taken out of the software has been re-instated (Figure 6). The Big Tick frequency, if set to a negative value in the Options menu, will override the scan header navigation

Figure 6. Location of a flag for overriding scan header tags and customizing labeling to any interval desired (normally for ANG defined surveys).