Possible range bug in newer (RLC 4) .REC files

Apparent Bug

Users have noticed inconsistencies in the range displayed by radR for .REC files recorded in 2009 vs. 2011.  Based on distances to known targets, the ranges are correct for 2009 files, but incorrect for 2011 files.  Attached below are examples showing this problem.  If you save them in the same folder, and run radR with the pointerinfo plugin unloaded, you can switch back and forth between the two files (which will appear as a single archive with two scans.)   Both files specify a base sampling rate of 100 MHz and a range index of 2, which implies an effective sampling rate of 25 MHz ( = 100 MHz / 2^2) and a range cell size of ~ 6 m.  This is correct for the 2009 file, but not for the 2011 file, where the range cell size appears to be approximately 3.25 m instead.

The inconsistency is also displayed by RTI's RadarSample (from version 1.5.0.012 of the RTI SDK), as seen in this screenshot of two copies of RadarSample running, showing the files (I had to duplicate each .REC file in its own folder, with sequential names, in order to show these):

It is entirely possible this "bug" is due to the 2011 file having been recorded with a newer version of the RTI SDK, and as soon as I have access to the latter, I will confirm and/or fix this.

Temporary radR workaround

In the meantime, the following workaround is available in radR, on the assumption the range cell sizes in 2011 files are too large by a factor of 6 / 3.25.  In the radR console, or in the file radR/main/startup.windows.R or startup.unix.R, add this line:

  rss.add.hook("GET_SCAN_INFO", function(si) {si$sample.dist <- si$sample.dist / (6 / 3.25); return(si)})

This line alters scan metadata before any further processing (including scan conversion) takes place.  You should only use this line when the file you are processing is known to have this bug (e.g. 2011 files).