when reading ACC_MEM, we are interested in a CIR, which is as detailed as possible, the first path or the distance calculated out of that information is not the goal. For that, it seems reasonable to use longer preambles, e.g. 1024 or even longer. In this context there are a few questions:
Is the assumption correct that a longer preamble will deliver more details in CIR? In my mind, the summation of more symbols should “lift of” the symbols or reflected parts of them out of the noise.
Is there a kind of limit, how much symbols might be summed up, before there is a clipping of the values due to the number of available bits in the register? It is clear that here the distance is of importance, but in a worst case, i.e. a short distance of maybe a few meters only, there might be such a limit.
If there is a clipping, at which value? In other words, will the register width of 18 bits (18 out of 24 according manual) will be used in total (0x3FFFF) or is there another max value?
Is there any influence of the PAC size in terms of CIR details? PAC size is in my mind the “portion of samples”, which is used to detect the presence of a preamble. There will be an influence on the preamble detection time, i.e. the starting point of symbol summation for CIR estimation, which might change the number of symbols to be summed up a little. I assume that this effect is not that important as long a detection is reliable, but is there any other effect?
A longer preamble can improve the SNR of the CIR estimate because more correlated preamble symbols are accumulated. It does not increase the CIR time resolution or number of useful delay samples; those are determined by the PHY bandwidth and accumulator sampling.
Each ACC_MEM real and imaginary component is stored as a signed 18-bit value in a 24-bit field. The nominal signed range is therefore -131072 to +131071, not 0x3FFFF as an unsigned value. Clipping behavior depends on the internal accumulator scaling, so it is good practice to verify signal levels on the target setup to ensure operation within the linear range.
PAC size primarily affects preamble detection. The PAC used to acquire the preamble does not contribute to the CIR accumulation, so a larger PAC can reduce the accumulated symbol count slightly. It does not otherwise improve CIR resolution or detail. PAC should be selected according to the recommended setting for the preamble length.
For preambles of 256 symbols or longer, also use the receiver’s Long operating parameter set rather than the default Short parameter set.
Hi Akash,
thanks for mentioning the long parameter set. We missed this point up to now and we will test it.
Just to be sure regarding the bits in ACC_MEM: According to the manual “Each value is actually 18-bit precision, with the upper 6-bits being all zero or ones depending on the sign of the value.”. This would mean we could have twice 262143 (or -262143 to +262142), since we have 18 bits for the value and the sign is coded in the upper 6 bits. Or does that mean we have an 18 bit signed number and the upper 6 bits are useless (but these bits are not constant and therefore might be the sign as written). We assume the value is given in two’s complement, right?
Yes, the ACC_MEM real and imaginary components should be interpreted as signed two’s-complement values.
Each component is stored in a 24-bit field, but only the lower 18 bits contain precision. Bit 17 is the sign bit, and bits 23:18 are sign-extension bits: they are all zero for positive values and all one for negative values.
The valid signed range is therefore:
-131072 to +131071
The upper six bits do not provide additional magnitude or precision; they only extend the sign of the 18-bit value into the 24-bit storage field. See the ACC_MEM description in the DW3000 User Manual, page 228.
When reading the values the first stage is almost always to store them as singed 32 bit integers, few processors support 24 bit integers. When doing that don’t forget to sign extend the 24 bit value into that top byte.
I get the impression that you would have already realized this but it’s caught enough people out in the past that it’s worth mentioning just in case.
thanks for the clarification regarding the 18 bit signed numbers. But this leads directly to a new question.
Looking to the MSByte only, there are just two bits of interest - one data bit and the sign. The latter one than is extended to the six remaining bits. That means, there are only four values, which are possible for the MSByte: 0x00, 0x01, 0xFE, and 0xFF. But we also see a lot of other values here, from 0x03 to 0xFD. These values occur only in the CIR part, i.e. not in the noise parts before the first path, and it happens for the real as well as the imaginary values. Therefore, it might be related to the signal power. Is it possible in case of high signal power (i.e. short distances) that there might be such effects? Could this be a side effect of an internal clipping or overrun?
And we observe another fact, which we can’t explain. The middle byte of the values (again the real as well as the imaginary values, this time for the complete 1024 samples) shows just two numbers - 0x00 or 0xFF. This leads to a quite limited structure of the CIR, which shows a few large steps and some small noise-like ripples, where I would expect a more smooth picture. So far we didn’t recognize any pattern in the changes. Do you have any idea what happens here? Might there be a config detail, which we missed so far and which could influence the internal processing or the data exchange?
Are you sure you have the data correctly aligned? MSB values of only 0x00 or 0xFF would be expected if none of the values are exceeding 50% of maximum.
The results you are getting are exactly what would happen if you had missed the line in the user manual that said “Note, when reading out the CIR data, the first byte of the transaction data is a dummy byte and should be ignored.”
you’re completely right, we misinterpreted something here. Our SPI function already skips the two address bytes, so our calculation was based on wrong mapping.
As a suggestion: In a further version of the manual one could skip the SPI transaction header in table 42, since this is nothing specific for ACC_MEM, but for all SPI transfers. Specific for ACC_MEM is just this single dummy byte. If revising table 42, one is then in line with the wording above.
So we are now fine with the CIR we read from ACC_MEM. Thanks for the help and kind regards
Axel