I am implementing the Range Doppler Algorithm for a Synthetic Aperture Radar project and I am at the step where I must perform Range Cell Migration Correction. This step involves creating a sinc interpolator to correct the spread of the signals energy across range cells. See example image SAR Sample data that has migrated across range cells

The interpolation is needed to get all of the data into one range cell. Is it possible to confirm that an interpolation worked properly without looking at a plot of the signal? If so how would I do that?


DSP is mostly like any other discipline of software development ¹.

If software quality hinges on you understanding what you see, then you will never find mistakes later on, when you can't look at internal plots anymore. As you noted, looking at plots doesn't usually pose the best method of checking validity of an algorithm, especially because the criteria for acceptance or rejection are not formally y defined. On an especially frustrating Friday, you might accept something that you'd clearly spot as wrong next Monday! And that without any intent to cheat: humans are not good at checking constraints.


You write some code, and then you wonder whether it is correct. The time-proven remedy for this kind of issue is the ability to test that hypothesis. In software engineering, we call such rests unit tests when applied to functional units (like your RCM implementation), and integration tests when they are used to verify a complex system of individually tested units still works together.

So, here, you'd want to write unit tests. In my experience, it's important to not start with a very complex example - start with a signal that you feed into your RCM (i.e. what would normally come out of pulse compression) that consists of all zeros but for a single one in a cell that will not migrate. Input should be output, and if that works, you probably got a lot of things right. Then calculate a point where the migration is a multiple of of full cells. Test with the same single-target signal. Works? Great!

Only after actually test the sinc interpolation. Calculate a point where you will have a rational amount of cells to migrate, say $\frac{15}8$ of a cell. Sinc-interpolate your signal by the appropriate factor (8): fft of your input signal with the length of the same, add 7 times as many zeros to the end of the result, ifft, take the 15., 23., 31., ... sample of the result. Compare what you get that way with you RCM.

general tricks and tips for unit tests:

  • write them as dumbly as necessary. Having an error there will cost you much time. Clear and dumb is better than so elegant in idea that you miss a bug.
  • when you think "I now need to calculate something to use as parameter", do that calculation in the unit test itself, or at least write down the formula you used and the parameter. You need to trace back where the numbers came from next week
  • give your individual tests descriptive names or documentation. What is it you're testing here?
  • DSP is a bit special in that we need to work on noisy signal. So noise is part of our tests. Test with enough noisy signal so that you're fairly confident that if you catch a bug, you catch it every run of your unit test. Having a unit test that fails ever 12 to 1000 times it is run helps nobody, especially when one can't reconstruct the noise that led to the failure.
  • never actually make unit tests random: use a seed for initializing the pseudo random number generator and seed in every run. Because you picked the amount of noise large enough to be sure you're not missing anything in your single run, having different nose realizations in different runs has only downsides.
    • I know I'm spending a lot of time on randomness in testing, but: use a thread-safe, good prng. If you find something which uses C's rand(), be very vary: the random numbers coming out of that are typically seriously not good, and something else in your program using the function mutates state!
  • use an existing unit test framework. This is important. You don't want to spend your time designing, questioning and fixing your own way of running tests. The existence of such a framework can heavily influence your choice of programming language and DSP frameworks
  • start small, work from trivial to integration test

¹ or digital hardware development, which is mostly the same as software development, just that the tooling is worse but expensive and most tests are more awkward to write

  • 1
    $\begingroup$ Thank you for the thorough answer! I'm new to DSP so this was very helpful information! $\endgroup$
    – level2fast
    Jul 15 '21 at 3:48
  • $\begingroup$ You're very welcome! I hope you build great systems! $\endgroup$
    – mmmm
    Jul 16 '21 at 1:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.