A while back I asked for advice on a weird ranging issue where I was occasionally getting ranges less than the true range (See this post).
I finally got a chance to go back to the same building and measure the channel impulse response.
The building in question is around 90 m long and 50 m wide with 10 m high metal doors at both ends. Other than the radios it’s empty.
Since this is a direct line of sight environment I expect to see a nice strong pulse at a bin number of around 750 with a couple of strong reflections and some noise trailing off after that. I do indeed see that.
However before that initial spike I would only expect to see noise, I don’t. I see a strong spike around bin 390 or sometimes two spikes with around the same spacing as is seen between my direct signal and first reflection. A typical example is attached.
This early spike is right about the level where most of the time it’s ignored but every now and then it is incorrectly detected as the leading edge resulting in a range measurement that is 58m short.
My only conclusion is that I’m getting reflections bouncing around for long enough to interfere with the next pulse.
So how do I tune the system to cope with this? In theory it should be possible to avoid or at least greatly reduce the issue by playing with the threshold levels but this is tricky given the complete lack of documentation on what the various register settings actually do.
One of the ways to mitigate would be to ignore/remove timestamps if First Path index is < ~700… this can be tuned in your application. Also the threshold above which the FP signal is detected can be increased. Please review NLOS app notes which provide details on this.
I will look into that. I have some very tight timing requirements (under 300 us to process the packet around and transmit a reply) and so I’m trying to minimize register reads, even at 20 MHz every SPI transfer is a fairly large chunk of time gone. I don’t suppose there is some way to change the first pulse detection algorithm so that it only starts looking from an index of 700?
OK, given the number of reserved registers and that you have to command the device to load the algorithm on startup I’m fairly certain there would be a way to do that. So to be more accurate: Is there any publicly known way to modify where the first path detection starts looking or is that all propitiatory information?
The app notes provide some magic numbers to put in to the registers for different situations but give very little details about what these are actually doing. I’ve tried playing with them a little but given that the threshold varies all the time it’s had to come up with objective measures of the effect without knowing how the value is calculated.
I have previously asked for some more detail on how exactly the threshold is calculated for exactly this reason (see Decawave is now part of Qorvo) but didn’t receive any replies.