As we all know, CIR data under the NLOS environment should be more difficult to identify the first path. Why do I stack CIR data measured in the Los environment and cir data measured in the NLOS environment have little difference? Is the data I read true or processed by dacwave?
What is your environment? For both of them you have a very strong signal and virtually no reflections so my guess would be fairly short range and in an open field.
It looks like your NLOS signal is very slightly weaker and has a few more reflections but not a lot. What did you use to block the line of sight?
It depends what your partition is made of. Cloth, plastic, plasterboard or even thin sheets of wood have very little impact while a thin layer of metal will have a huge effect.
Water is also a very effective at blocking the signal so standing in between the antennas is a rude but effective way to block the direct signal.
Also your CIR data has negative values which implies you are only looking at one part of it. The output gives both real and imaginary data, looking at the magnitude of the two combined (sqrt(real^2 + imag^2)) will give you a better view of total signal power.
It’s an approximation in order to run on lower end hardware.
Few embedded microcontrollers have hardware support for floating point maths, this means that it will take several hundred clock cycles to perform an accurate square root calculation.
In this situation the exact number isn’t too critical and so the speed / accuracy trade off of the approximation is worth it.
If you are running on a PC or something with a hardware FPU (or don’t care about speed) then ignore this approximation and use the true square root.
I noticed that you’re using mdek1001 to capture the CIR data. I wish to do the same thing using DWM1001 Dev Boards. But I came across with a post saying that the PANS came together with DWM1001 Dev doesn’t allow access to CIR data.
I’m new to Decawave and really appreciate if you could give me some hint how you did that. Are you using a customized firmware other than PANS? Is there any open-source code? How to get started?
Hello @jleng,
Yes you have to make your own firmware to capture the CIR data. The “original” firmware do not have that funcionality (as i remenber). There are some examples on the decawave site where you can obain a zip file thats shows how you could implement a different type of things, i dont know if there is one there for the CIR. There is another document(something like API guide decawave) that shows as describes all the API on the Decawave C library and i belive there exists one api to load the CIR data on a variable. Keep in mind that the real part and imaginary comes seprated and you have to determine the mod.
Hope i could help.
Cheers
Just want to double check — could the zip file you mentioned serve as a starting point to developing custom firmware for dwm1001-dev? Another thing is that I keep seeing people talking about this which also include some examples, but not sure if this is also relevant to customizing the firmware. Are you by any chance familiar with it?
Hello @jleng,
Yes that’s the exacly the starting code you have to use of you really want to build your owm firmware. Keep in mind that in that examples is used the ss-twr (single-side TWR). The other api document fallows a number of examples of code “how to use” on various situations. Find something like source code on Decawave site platform.
I need to refer one thing that can make you confused. The actual PANS 2.0 offers the possibility to actual write simple code inside their firmware but you cannot control the ranging process. It depends in what you want to use or developed. Ther documentation shows how all the “stack” is arranged.
Hope I could help.
Cheers