Tests on ranging accuracy

[thotro]

First ranging tests are planned to be done till the end of June.

[ankitbhatia]

Hey,

It looks like you're working hard towards getting this library out there. Thanks!

I'm trying to implement your library on two arduino nanos. I was able to validate your sender and receiver examples but unfortunately the two way ranging code doesn't work well yet. Have you tested your two way ranging code successfully? I seem to get either completely absurd time measurements or a constant time of about 1.4~1.5 ns.

[thotro]

Hi there,

my pleasure, I hope it will be entirely useful in the near future! ;)

Unfortunately I had some other parts to work on the last couple of days, so I could not spend to much on the ranging reference example. For the moment this code has definitely issues: Either the LDE microcode is not yet fully loaded, IC calibration is the key or there is a hidden bug in timestamp management. Finally, on the surface I print the TOF as a float value, which is inherently imprecise.

Currently I do a first draft of some API docs, but will then immediately head over to fix/implement the ranging stuff.

If there's anything that occurs to you that you think could be a bug, please drop me some lines; otherwise I'll keep you posted!

Cheers, Thomas

[ankitbhatia]

Hey, I do not know if you are able to run the ranging code. It does nothing for me. The basic sender and receiver code is also not working. I get very rare message transmissions.

[thotro]

Yes, for me the ranging code did work on the last commit (but will check again tomorrow).

Rare message transmission sounds like there is still a bug in the tuning of the currently employed mode. For a quick test you could choose another mode (see http://tinyurl.com/enableModeFunc, call within "new..." and "commitConfiguration", MODE_SHORTDATA_FAST_LOWPOWER would be the chip default) and see if things can be made working.

Hope it helps!(?)

[jonathand1]

Hi,

For me, the ranging test does not work anymore. No message sent from the tag for beginning ranging process.

However, send/receive tests works perfectly.

😊

Waiting for reply,

Thanks for your work !

De : Thomas Trojer Envoyé : ‎jeudi‎ ‎9‎ ‎juillet‎ ‎2015 ‎01‎:‎05 À : thotro/arduino-dw1000

Yes, for me the ranging code did work on the last commit (but will check again tomorrow).

Rare message transmission sounds like there is still a bug in the tuning of the currently employed mode. For a quick test you could choose another mode (see http://tinyurl.com/enableModeFunc, call within "new..." and "commitConfiguration", MODE_SHORTDATA_FAST_LOWPOWER would be the chip default) and see if things can be made working.

Hope it helps!(?)

— Reply to this email directly or view it on GitHub.

[ankitbhatia]

Hey,

So I tried a bunch of other modes. The ranging demo doesn't work on any of them. I was only able to get the send recv demo to work on the LONGDATA_FAST_ACCURACY mode and the SHORTDATA_FAST_LOWPOWER mode.

Do you have any ideas why that could be happening?

My arduino sees a reset in almost all other modes after the first message.

Regards, Ankit

[thotro]

I'm sorry that you're stuck with it for the moment and the delay, I was horribly busy for the last few days. :-/

I will do a thorough check of all tuning parameters and regular settings (something I have to do anyway for a stable release) to see the problem. It usually boils down to this one bit, set at the wrong place at the wrong time. ;-)

Best, Thomas

[leosayous21]

Hi ! I'm waiting for my DW1000 to arrive in order to try your code and work on it if i can :-) Did you hear about that ? : http://www.pozyx.io (It seems that they are using this module). They have a very good accuracy on the video... Also, they will partly open the source. from here: https://www.kickstarter.com/projects/pozyx/pozyx-accurate-indoor-positioning-for-arduino/comments "Most of the software will be open source:

• all the Arduino libraries to communicate with the pozyx board.
• all the Arduino examples for the board.
• The pozyx firmware will be partly open: we will make most of the firmware available, including tutorials and examples to read out all the different sensors or how to make range measurements. However, the positioning algorithms will only be available through a library." Regards, Léopold

[thotro]

Hi all,

@ankitbhatia and @jonathand1 in the latest commit I did some minor bugfixes and tested all modes for use with the ranging example; so far I had no problems. Would be pleased to here if it works for you again.

@leosayous21 yeah, just recently heard about their work on pozyx, thanks for the pointer. Hopefully I can get one when it's out on the market - looks like a nicely produced piece of hardware. :-)

[ankitbhatia]

Ranging seems to work now although it is not very accurate. I will try to do an accuracy test and share the results with you.

[leosayous21]

I think we need to do some average accuracy and to see how many samples we need in order to have a good accuray at the end.

[thotro]

@ankitbhatia That would be great, thanks!

With one of the currently implemented modes (forgot which one, I just noticed during testing) and current parameters for tuning the chip I can get at best about +-30cm.

Below a certain distance (~75cm) results jump and don't seem to be very stable. Also negative values can/should be dropped I think.

Please note that this is not yet the optimally configured device - obviously ;-)

• Considering measured noise, RX power level and first path signal power level should yield accuracy of another few cm.
• Smart TX power is still on; this may not be the best option for ranging.
• The code still uses standard SFD, although Decawave says their custom one gives better results.
• ... (and I'm sure there is something else left to tweak)

@leosayous21 yes, for actual production code anything from averaging samples to Kalman filters might be an option to improve or stabilize results further.

I will find time to implement the new features by mid-to-end of this week and then let's see again. It would be great to see that +-10cm are possible out-of-the-box.

[ankitbhatia]

I believe you on the tuning parameters. This is a complex enough chip that I bet there must be something more.

As for the measurements at short range, I think the distance becomes non-linear there and we need to average for a bit and then try to fit a non-linear function. I don't know what function yet. Maybe the negative values have information in them. I will report back when I actually do some ranging tests.

[leosayous21]

@thotro did you read "Sources of error in DW100 based two-way ranging schemes" (APS011 Application Notes) ? They talk about errors related to clock drift in two nodes and related to the incident signal level at a node It seems that there are a lot of differents bias possible. here you have the graphs:

[leosayous21]

Also, the clock drift seems to have a huge impact on the ranging accuracy

[thotro]

@leosayous21 many thanks for pointing out - yes, I know the document. Parts of this will directly find itself in the timestamp correction routine that will then automatically adjust each RX timestamp right away. Next on the agenda! :-)

[leosayous21]

@thotro Hi ! Thank you for your release :-) What ranging accuracy do you obtain at the end ? What additional optimisation can be done now in your opinion ? Also did you try to pass through wall ? (they say it can work through 1 or 2 walls) Cheers, Léopold

[thotro]

Hey Léopold,

in the current release I obtain about +-15cm (just a guess from my observations). What I mean by this is that the ranging results are stable with these tolerances from measurement to measurement.

To get absolute and correct distance measurements the module needs to be calibrated/biased (e.g. choosing values for the antenna delay) - but this should be easy then and stable ranging results are definitely more important, I think. (... the API for calibration will be available soon)

Yes, I also read about the "1 or 2 walls". I guess it depends on the walls: No chance to get through a single of my 50cm brick walls at my home! ;-) But I still need to try it with increased TX power and better antennas are obviously an option as well. Let's see if I stumble across a few other types of walls to test this furthermore. :-)

I keep you posted if I have results.

Cheers, Thomas

[leosayous21]

hey thomas, I really look forward to see the accuracy you get at the end :-) Do you know how long take a ranging (1 or 2ms no ?) and so what ranging frequency we can have with the module ? cheers, leopold

[leosayous21]

@thotro Hi ! Here the distribution I have with your examples for ranging Samples number: 446 mean: -3,118587444 (m in relative) std: 0,085572889 RX power around -95dBm

It's really good i think ! You did a very good job :-) Léopold

[thotro]

Great!! Thanks Léopold, that's very helpful! You provide the stats I somehow never find time for! :-) Very much appreciated!

Let's see if we can get better! ;-)

[leosayous21]

@thotro I've had such a hard time to enter your code so i decided to do something easier XD I'm happy that you like it. :-)

Here an other test ! Samples number: 618 mean: -2,897082683 std: 0,078181635 RX power around -90dBm

I didn't move the modules, so the real distance is the same as for the other graphs. It's interesting to see that the mean has a 20cm drift in comparison to the other experience. The second experience had a mean RX power of -90 dBm whereas the first one was around -95 dBm. Also, the temperature might be different.

An other feeling i have is about a tiny drift while it was working, that why we have a "plateau" around -2.9 This can be due to the heating of the chip which drift the result a little bit ?

[leosayous21]

Hi! I did others tests ! I created my own pcb because of this problem of 3.3v for me... Also, it allows me to put my own regulator which has a limit of 800mA. I put a ground under the module but it was just a one sided PCB so there is no ground in the other side.

(i can share the files if you want)

I noticed that the RX dBm is really better when putting the module at the vertical and not horizontal ! (it goes from -90dBm to -67dBm !). Also the module heat more maybe because the supply is more powerfull (i need to measure the current)

here my results: Samples number: 558 mean: 1.501 std: 0.0228 RX power: around -67dBm Receive quality: around 350 FP power: -82 dBm Real distance: around 1.3m (not measured)

The ranging is really accurate ! I'm really impressed Cheers, Léopold

[thotro]

Hi Léopold,

great, the results really look impressive! RX power levels for this specific distance should be like that - hence my PCB layout was far from optimal. If you want to share your files with us this would be great. Always good to have some more resources and knowledge gathered together.

Thanks, Thomas

[MarioRuz]

Hi!

First of all, thank you @thotro for your valuable work. It is actually helping me to learn writing libraries :). I already have 3 dw1000. I can also confirm your libraries work with Arduino UNO and Arduinio Duemilanove. @leosayous21 , I would be interested in the gerber files to build that small pcb :).

I am planning to do a set of ranging tests to evaluate the accuracy. However, I am facing some issues, and maybe you already has the answer:

1- When running examples such as ranging (RangingAnchor and RangingTag), how do you proceed to start and how do you reset transmission? In my case I plug the arduino "anchor" and after the arduino "tag". However, sometimes transmission stops, with serial monitoring I only get "### DW1000-ard", and nothing else. Does this happen to you? To restart the transmission I need to deplug and plug the serial interface, and sometimes more than once.

2- Do you get "outliers" when getting the distance?. In the case of Léopold graphs I don't know if he filtered data first. I did some test. For example, when tag and anchor are 50 cm I get values like these (notice the outlier data -28446,8800000000, I also got positive outliers, like 13523)

... -2,01000000000000 -2,04000000000000 -1,97000000000000 -2,05000000000000 -2,02000000000000 -1,97000000000000 -2,04000000000000 -1,99000000000000 -2,18000000000000 -1,99000000000000 -28446,8800000000 -2 -1,98000000000000 -2,04000000000000 -2,07000000000000 -1,92000000000000 -2,05000000000000 -2,05000000000000 -2,02000000000000 -1,98000000000000 ....

Being this my case, If i suppose a normal distribution (just as a first analysis) my std will be much bigger than Leopold results. Let me know if you did some filtering.

3- It seems when anchor and tag are very close each other, let's say less than 10 cm, transmission stops, does this happen to you too? I am also interested in being able to get data even when tags are very close each other.

After I solve these problems I will begin the ranging statistical tests, and I will share them.

Cheers!

[leosayous21]

Hi @MarioRuz ! I don't have the gerber files but i will give the eagle files (and eagle library) to thomas in my next pull request :-) It's just a one sided pcb i did using the toner transfer method.

1. I used to have this problem due to the current problem. How do you supply your module ? The arduino uno provide only 50mA for the 3.3v ... It's really crap. That's why i did my own pcb with a onboard 3.3v regulator (LM1117).
2. Your values are not so bad i think. For my tests i erase the very huge number (as 28466) by hand because it really alters the results but i didn't do any other filtering. I think it comes from error when re-sending the message in case one message was lost. It added some microseconds which corresponds to ten thousands of meters...
3. I didn't try that..

@thotro I'm currently doing the correction on RX power ! I put these functions in the rangingAnchor sketch for now but i think it will be interesting to create a new class something like DW1000Ranging which will contain all the RanginAnchor & RangingTag functions. In this case it will be much easier to implement it in an arduino sketch and to add others functionalities (as multiple anchor, different correction, etc. !). What do you think about it ? We can do it in using the famous type: " DW1000Ranging.available() " and " DW1000Ranging.read()" "DW1000Ranging.write(String data)" etc..

Cheers, Léopold

[thotro]

@MarioRuz Hi! With the last commit I added correction of timestamps if system clock overflows occur. This should at least help with the really large value outliers. If a message was lost during the ranging protocol, the entire ranging sample should be discarded - at least this was the intention, so I will re-check the code on it. :-)

With distances below 50cm I have the feeling that the timestamping and hence the actually computed range is not very accurate anymore. It seems that even the official eval board's ranging algorithm does not treat such distances at all - if I observed correctly. Still, I guess a little more testing may further clarify low-distance ranging capabilities.

@leosayous21 Hey! Great that you did an implementation on timestamp correction. I very much like the idea to extend the library towards a ranging class (I think that in the end we all got onto the DW1000 to have this ;-)). Although I think that the timestamp correction should go directly into the existing DW1000Time class, since each and every timestamp can/should be corrected - what do you think? Also I think that we could try to approximate the functions given in the power level / distance bias graphs - would be more efficient and maybe more accurate.

For a ranging class I guess it will be really important to have MAC level messages and node addressing and filtering implemented. I would love to setup a node simple by saying "I'm a node with address XY and my anchors are A, B, C, D".

Cheers! :-)

[bigredbee]

I just want to thank all of you for the work you're doing. I was able to get mine up and running in just a few hours with no modifications to the code using a SparkFun Pro Micro. I had the adapter board fabbed at OSHPARK, three for just $7 USD, can't beat that price! If anyone is interested in getting these boards for yourself, I can make them public and you can order with a click of a button.

I really look forward to being able to introduce multiple anchors into the network!

Greg

[thotro]

Hi Greg, looks great! Will do our best to further improve and in the meanwhile, have fun! ;-) Cheers, Thomas

[leosayous21]

Hi @bigredbee ! Look that you have a good equipment for testing the module and the library :-) I look forward to see your result ! Cheers, Léopold