Tag's TWR strategy

[simonesciarretta]

Hi,

I have a question about TWR strategy.
I have a network with 30 anchors and 1 tag and I save the location data in a .csv log file to be able to make some statistics and retrieve the trajectory offline.
In some cases I observe that in the log files there are “holes” in the trajectory, meaning that for a certain period of about 15 seconds the calculated locations of the tag are always (0, 0, 0).
What could be the problem? The anchors are spaced about 20 meters from each other and in LOS as adviced in the documentation…
In section 4.9 Tag’s TWR strategy the document DWM1001 System Overview and Performance, version 2.0 says “(if it does not know its position it will use 0, 0, 0)”.What does it mean? Why the tag does not know its position? In some cases the tag receive the positions from just 2 anchors but in that cases in the log file i see the repetition of the last position known… Maybe there can be another reason?

Thanks for reply,
Simone

[leapslabs]

Hi Simone,

are you using PANS Release 2 firmware? In Release 2 if Location engine cannot calculate position it should return you NaN and not 0,0,0. The description in the documentation is probably obsolete and referring to Release 1.

How did you log the positions? If the Location Engine could not calculate the position you should not get position via the on-module shell, only distances.

Cheers,
TDK

[simonesciarretta]

Yes, I am using PANS Release 2 firmware both in the anchors and in the tag! I simply receive some superframes correctly formatted and I write the distances like an int32 in millimeters on the .csv file, but in that period the superframe is full of zeros, and after some seconds I newly have some useful data…
I downloaded the documentation about DWM1001 Module from the Decawave website Product Documentation - Decawave and I think that it’s not obsolete…
The accuracy of the positioning is ok and I should extend the network to a much large area adding much more anchors to the network, but for my indoor application I can’t afford such a long time (or maybe indefinite time) with correct superframe structure but without measured distances! Can you suggest me a solution to this problem?
I add to this post an extract of one of the .csv log files, where you can see the zeros from line 180 to line 328.
I also attach a map where you can see the position of the anchors marked with a red X.

Thanks a lot,
Simone

20190709_115338_DWM extract.csv (74.7 KB)

[Yves_Bernard_Qorvo]

Hi Simone,

How di you get the data logged in the CSV file ? I can’t make sense of it so far.

Are you saying that there is an area within your network for which the tag always reports a 0;0;0 position ?

Your anchor placement looks ok, could you indicate the distance between two anchors for scale, and also is the lines represents wall or something as such that could potentially reduce line of sight ?

Thanks
Yves

[simonesciarretta]

Hi Yves,

Sorry for answering with so much delay.

I get the data from the tag trough SPI connection with a micro which send the data to a computer and then the data are saved in the CSV log file.

I attach the new map with the distance between two anchors.

The lines in the map don’t represent walls but only wall beams of the warehouse and does not influence the LOS between the anchors. All the anchors are attached at the ceiling at about 6 meters height, and the tag is mounted over a forklift at about 2,30 meters height.

When the tag is in that area I don’t get always 0;0;0. This happen only occasionally and for some seconds.

The only problem for the LOS between the tag and the anchors could be the presence of paper pallet inside the warehouse, but the in most cases the tag is in LOS with 3 or 4 anchors. Moreover, in other areas of the warehouse where there are high columns of paper pallet, this problem does not occur!

[Yves_Bernard_Qorvo]

Hi Simone,

This looks fairly odd indeed. Do you observe the same directly with the LES command over UART interface ? At some stage the tag completely lose track of the anchors ?

Thanks
Yves

[simonesciarretta]

Hi Yves,

Yes, I obtain the same also over the UART interface. It seems like sometimes the tag receives all zeros from the anchors, and after some seconds it restart receiving correct data. I can’t explain this behavior because in different log files, also in the same area, there is not this problem…

Thanks,
Simone

[leapslabs]

Hi Simone,

would it be possible for you to create a log using the ‘les’ command only? Just to rule out issues generated outside the module, e.g. obtaining the data via the SPI. Also please mark where is the [0,0].

@simonesciarretta

When the tag is in that area I don’t get always 0;0;0. This happen only occasionally and for some seconds.

Does it mean that you don’t see always 0,0,0 within the area in the picture above? Where does it have problem then and how long the issue last? Do the tag need to move until the problem is fixed.

Thanks,
TDK

[simonesciarretta]

20190917_110754_DWM.xlsx (787.8 KB)
I can’t create a log file using the LES command because I’m not using shell commands! I get the row data through SPI connection and simply save them in the log file!
Here is a new complete log file in which the tag were moving around the whole warehouse. As you can see in the second sheet of the file, the trajectory presents some points where it receive (0, 0, 0) for some seconds, then it restart following the real trajectory of the forklift.

I mean that I don’t see (0, 0, 0) always in the same area! maybe the second time in that area I have correct measurements, but I have (0, 0, 0) in another area of the warehouse!
It looks like a bug because the timestamp, the message count, and the format of the messages are correct!

Thanks,
Simone

[simonesciarretta]

Hi,

We did other experiments in order to try explaining our problem, and I ask you to confirm our reasoning is correct.
We made a simple network with just 4 anchors (1 of which is initiator) and 1 tag, powered by battery, configured with autopositioning. The configuration was ok and the tag correctly started to trace its position in the network. At this point we tried theese experiments:

(1). We removed the battery of the initiator, expecting the network wuold have gone completely out of work, contrariwise the tag continued ranging with the other 3 anchors for some seconds, then with 2 anchors, and then just 1 anchor, but continued to receive ranging measures from the last anchor in the network also without the initiator. Shutting down the tag and restarting it, the tag effectively did not range with any anchor.

(2). We replicated the experiment (1) but removing the battery of one anchor instead of the initiator, and the network correctly continued to work as expected.

(3). We retried onother time to remove the battery of the initiator and replace it immediately, before the network went out of work. The result was that some seconds after we turn on the initiator, the network went off for some seconds (about 10 seconds) and then restarted working correctly. It looked like the initiator restarted to configure the network, and there was some delay in the communication between the nodes.

In our implementation inside the warehouse shown before, the anchors are powered by the power grid trough six independent electrical busways on the ceiling and we thougth that an unexpected instantaneous interruption of the power supply for one busway, will result in shutting down all the anchors in that busway, so if the initiator was there, the network would stop working for some seconds.

We thought that configuring the network with more initiators would be a sort of backup to prevent that issue. Do you thing that it is good for our actual network configuration in the warehouse? For example if there are 2 initiators in the network and one of them lose the power supply, the other initiator immediately takes control of the superframe or there will be the same problem due to a new network configuration?

We would have to cover a larger area of about 25.000 square meters, whith about 250 anchors and 15 tags, and we can’t afford theese kind of network interruptions. The final configuration will be the repetition of the same configuration shown previously in the pictures, replicated more times and eventually with more than one initiator if you think that precaution would fix this problem.

I keep waiting for your feedback

Thanks,
Simone

[simonesciarretta]

Hi,

For now we have bypassed the problem using the “dwm_pos_get” API function instead of “dwm_loc_get”.

Using “dwm_loc_get” we always faced the problem mentioned above in about 1 hour of use. After the change in “dwm_pos_get” we haven’t got this problem. It seems that the longer output message of “dwm_loc_get” (compared to the only 14 bytes output message of “dwm_pos_get”) causes the hang of the serial communication and it takes some seconds before restart.

Nevertheless we would like to receive informations about anchors distances and we would prefer using the “dwm_loc_get” in the future. Is that a known problem? Is there a solution?

Thanks,
Simone

[leapslabs]

Hi Simone,

apologies for not responding. I forgot about this thread.

Thanks for your feedback! I will try to respond step by step your questions.

Regarding the excel sheet 20190917_110754_DWM.xlsx: does it mean, that when the issue occurred all readings were zeros? Did it happen also on a small 4 anchor installation?

Regarding your tests:

1. If you wait long enough (few tens of seconds), all anchors and tags should disconnect. Only in case there would be an Initiator it would take over control of the network. How long have you waited?

2. Ok

3. This is correct behavior. When the Initiator goes down the network will keep running for a while. If the Initiator reconnects immediately it will connect to the already running network as a normal Anchor. But since there is no real-Initiator the network will go off. The Initiator will then reinitialize the network.

One of the solution I would propose is to have 2-3 Initiators in range with each other, powered from different sources if possible. So one of them will initialize the network and become a real Initiators. The other Initiators will connect as normal Anchors. If it will be re-powered then the other two will take control over the network seamlessly and no network hiccups will happen. The re-powered Initiator will become a normal Anchor and will take over the control if the real-Initiator dropped. The Initiator redundancy is most effective when the Initiators are in range with each other. The latency of issue propagation will be as low as possible. I hope it is clearer now.

@simonesciarretta

Using “dwm_loc_get” we always faced the problem mentioned above in about 1 hour of use. After the change in “dwm_pos_get” we haven’t got this problem. It seems that the longer output message of “dwm_loc_get” (compared to the only 14 bytes output message of “dwm_pos_get”) causes the hang of the serial communication and it takes some seconds before restart.

This is interesting, we are not aware of a such issue. Could you please provide some information:

1. Can you reproduce this issue also with 4 Anchors and 1 Tag?
2. What is the update rate of the Tag?
3. The issue happen on the Tag when reading the location data via SPI, doesn’t it?
4. What is your SPI speed and how often do you issue the dwm_loc_get call?

Thanks,
TDK

[simonesciarretta]

Hi TDK,

Thanks for reply! I will answer your questions:

Regarding the excel sheet 20190917_110754_DWM.xlsx: does it mean, that when the issue occurred all readings were zeros? Did it happen also on a small 4 anchor installation?

Yes, exactly! even with the small 4 anchor network we faced the same problem

One of the solution I would propose is to have 2-3 Initiators in range with each other, powered from different sources if possible.

Ok we will try this configuration next.

As for your questions about the dwm_loc_get call:

1. Yes
2. The tag update rate is 10Hz.
3. No sorry, I was wrong! We used the UART connection, not SPI.
4. UART speed is 115200 and the dwm_loc_get call rate is once every 100 ms.

We observed the behavior with an oscilloscope for the small 4 anchor network and it seems that a reset of the board occurs. According to our software engineer it could be a sort of internal watchdog that, after the long message of dwm_loc_get (about 100 bytes), sends a reset command. Also the leds of the tag turn off for a while in that moments, confirming this theory. Is it possible?

Thanks,
Simone

[leapslabs]

Hi Simone,

@simonesciarretta

• No sorry, I was wrong! We used the UART connection, not SPI .
• UART speed is 115200 and the dwm_loc_get call rate is once every 100 ms .

Ok, we have received once a such report for UART, but internally we have not been enable to reproduced that (using the same steps 1 to 4 as you have done in your test). Our tests have run for multiple days without any issue. Your theory is probably correct, i.e. the UART API got stucked and the watchdog reseted the module after around 12s.

Thanks for the report, we will keep an eye on that and if we could reproduce that then we will fix it in future release. If you have an idea how to reproduce it reliably please let us know.

Thanks!
TDK