FWIW there is no reason to truncate the time domain transform except for lack of memory.
A routine means of resampling data is to transform to frequency, pad the high frequencies with zeros and inverse transform.
The length of the trace in time is set by the frequency increment. For a full sweep of from 70 kHz to 900 MHz with 101 points, the length of the TDR trace is ~111 ns. That limits the maximum cable length to about 11 meters. Sampling at 1 MHz intervals will increase the length of the TDR trace to 1 microsecond which is sufficient for 100 meters.
Measuring the length of a cable is best done in the frequency domain by fitting a line to the phase of an open or short reflection from the end of the cable. That will provide very precise information, much better than trying to pick a peak in the time domain. Picosecond travel time to the end of a cable should be obtainable by doing a linear fit to the phase.
It gets more complex if there are multiple reflection events, but the problem is tractable on a PC using a sparse L1 (aka basis) pursuit. The multiple reflection case is probably not solved well by least squares, though it might be stable for 2-3 reflectors.
If there are multiple reflections, the frequency domain will be a sum of R1*exp(j*2*pi*f*t1) + R2*(exp(j*2*pi*f*t2) .... etc. Because it is a sum of products, the A matrix gets rather messy. The only way I can think of to solve it using least squares (L2) would be to transform to time, window the desired event, transform back to frequency and then solve for Ri & ti.
This is where having an STM32F303CCT6 would make life a lot easier.
BTW thanks for documenting the build process on Linux.
Have Fun!
Reg
