Proex GPR control software for unix systems

Purpose

This web page demonstrates the use of the ProEx GPR control software for un*x systems.
The Malå Proex GPR interfaces to a computer through an ethernet interface. The communication protocol, a raw ethernet point-to-point protocol, has been reverse engineered and implemented for un*x systems, tested on GNU/Linux. This implementation is in no way supported by the official manufacturer of the GPR, Malå (Sweden).
Features include reconfiguration of all parameters for a single channel control unit (sampling frequency, sample points and hence trace duration, window start sample).
The aim is on the one hand to prevent booting under MS-Windows during field trips and adding unsuported functionalities (multiple time windows measured simultaneously, real time subsurface feature identification). Especially, one topic of interest that cannot be implemented with the current proprietary software in interleaving multiple time windows, e.g for focusing on one shallow target and one deep target. In our particular case, the ``deep'' target is actually an artificial echo generated by a buried surface acoustic wave sensor acting as a passive cooperative target probed by the GPR.
For testing purposes, "short circuiting" (using an optical fiber) D and T will transfer the synchronization pulse from T to the receiver and trigger a measurement.

Results

As an example of the functional implementation of this protocol under GNU/Linux, some parameters have changed while acquiring traces generated by unshielded 200 MHz antennas fitted to a Malå ProEx control unit. Varying the position parameter for a fixed sampling rate and number of sampled points:

Varying the sampling rate and tuning the first point for the emitted pulse to be always located at the same abscissa

Varying the window (so called long, medium, short in the GroundVision 2 software) parameter which is obviously a prescaler to the frequency generator: notice the echoes returned by a Surface Acoustic Delay line located next to the emitting antenna:

Most significantly, we are interested in probing multiple time windows for sensing applications, considering the scenario in which a high frequency antenna is used to probe shallow subsurface structures (sampling window in the first hundreds of ns) and deep subsurface structures or sensors with large time delays. Current GPR software does not allow for a large enough number of samples to cover the whole duration range, while the samples between the shallow and deep reflectors are of little interest to the user (weak reflectors hidden in noise). An example of a script allowing for alternating between shallow and deep reflector measurements is 
HOM=$HOME/radar-c/bin
NBP=2048
rm t
while true; do
  $HOM/radar-c --sample $NBP --beeper 1 --stacks 4 --sampling 0x10 --signal_position 0xC4ff --interface eth1 --time-window 2 | sed 's/#Connection established//g' | sed 's/#Data acquired//g' | tr '\n' ' ' >> t
  echo " " >> t
  sleep 1
  $HOM/radar-c --sample $NBP --beeper 1 --stacks 4 --sampling 0x10 --signal_position 0xD4ff --interface eth1 --time-window 2 | sed 's/#Connection established//g' | sed 's/#Data acquired//g' | tr '\n' ' ' >> t
  echo " " >> t
  sleep 1
done
In this example, the file named t is filled alternatively with shallow (window offset of 0xC4ff) and deep (window offset 0xD4ff) measurements. The result is currently processed under GNU/Octave as follows
  1. load the whole record with alternating traces (top-left)
  2. extract each trace (data(1:2:end,:) and data(2:2:end,:)) for independent analysis (right). For the shallow traces (top-right), the emitted pulse is removed to emphasize the echoes,
  3. stitch the two datasets for continuous trace display (bottom-left). On this image, the vertical blue line in the middle of the graph indicates the separation between the two time windows.
In this example, the acoustic sensor was present next to the GPR antennas during traces 1-5, removed during traces 6-9, and then located back next to the GPR from traces 10-16 (right graphs).

Example of acoustic delay line measurement

Interfacing with Seismic Unix

Seismic Unix is a set of tools for processing seismic data. Since seismic and GPR traces, such signal processing is well suited to processing the traces we are acquiring. Most significantly, it is a command line interface that suits flawlessly our needs of processing the GPR data gathered by the command line software used to control the Proex GPR. As an example of real time SU data generation, the following bash script is used to acquire data and store them in a SU compatible file 
HOM=$HOME/radar-c/bin/
NBP=2048
PATH=$PATH:$HOME/su/bin
CWPROOT=$HOME/su/
rm t.su
while true; do
  $HOM/radar-c --sample $NBP --beeper 1 --stacks 4 --sampling 0x10 --signal_position 0xC4ff --interface eth1 --time-window 2 | grep -v ^\# | a2b n1=1 | suaddhead ns=$NBP | sushw key=dt a=1000 >> t.su
  sleep 1
done
The dt key indicates the time interval between two samples and has been here set to 1 ms, which is obviously erroneous and should be adapted to the actual sampling rate. The resulting dataset is displayed using suximage < t.su perc=98 and the following image is generated with supsimage < t.su perc=98 title="SAW sensor probing" label1="TWT [a.u.]" label2="trace number"

GPS tagging traces

I am familiar with the NMEA protocol generated by most GPS receivers on an asynchronous (RS232 compatible) serial port. NMEA sentences include the position in various fields but I believe the one easiest to parse is the one starting with GPGGA. Thus, having connected a GPS receiver to a serial port (in my case an ET312 OEM receiver from USGlobalSat connected to a genuine serial port -- when using a USB to RS232 converter replace ttyS0 with ttyUSB0), the GPS position is given by 
stty -F /dev/ttyS0 4800 && cat < /dev/ttyS0
However, the console is locked in reading ttyS0, that does not help us in recording GPR traces in parallel. The low-level programming for getting the last known GPS position would be an interrupt: the un*x equivalent of interrupts are signals, so we will update a position information whenever possible, and provide the GPR recording script the information asap when requested as a response to a signal request. Here is one proposal for such a strategy: first lauch a dedicated program for monitoring the GPS receiver, name for example gps.sh: 
print_foo() {
 echo "position is " $resn
}

trap print_foo USR1

stty -F /dev/ttyS0 4800
while true; do
  read -r f < /dev/ttyS0
  res=`echo $f | grep GPGGA | cut -d, -f3-6`
  if [ ! -z "$res" ] 
  then
     resn=$res  # only update resn if res is non null
  fi
#  echo $resn
done
In this example, each line from the GPS receiver is parsed after being stored in the variable f, and only if the result of the parsing in not empty is the resn variable updated. The mechanism for proving immediately the last position fix to the acquisition script is through the signal named USR1 which is trapped (interrupt like mechanism) and induces printing on the console the last known position. Hence, if this script is launched with 
./gps.sh
gps_pid=`echo $!`
then the command kill -USR1 gps_pid will induce a display on the console of the last known position. As an example:
jmfriedt@rugged:~/proex$ ./gps.sh &
[1] 15140
jmfriedt@rugged:~/proex$ gps_pid=`echo $!`
jmfriedt@rugged:~/proex$ kill -USR1 $gps_pid
position is  4714.9246,N,00601.2316,E
jmfriedt@rugged:~/proex$ kill -USR1 $gps_pid
position is  4714.9242,N,00601.2261,E
These two lines (lauching the gps.sh script, storing its Process ID and then in the main loop sending it the USR1 signal) can be included in the GPR recording script for storing in a separate file the GPS position as a trace is being captured, with no risk of delaying the next GPR trace acquisition.

Protocol description

A description of the various packets exchanged between the GPR and the PC are provided below based on reverse engineering the communication protocol as implemented in GroundVision 2. The packets are raw ethernet with no IP or TCP/UDP compliance, implementing a protocol identified as 0x5555.

The header is always the same, with the source MAC address provided by the GPR or PC and the destination MAC address either a broadcast request (0xff 0xff 0xff 0xff 0xff 0xff) or the destination MAC when known. A PC sends commands to the GPR in the following format

and the GPR answers with a common counter and the response to the PC request

One particularly interesting packet is the request for a trace, which yields the only large packet including two-byte word data which are then recorded by the PC, ready to be plotted using in our case gnuplot: