Hi, I’m using a RTLS based on asymmetric two way ranging, with 1 Tag and different anchors. I’m using 850k data rate. I read on this forum that anchor responses have not to be sent at the same moment since the RX of Tag has to re-enable every time a frame is received. Anchors timing for responding to Tag is based on anchor ID, so that every anchor triggers the one with subsequent ID, starting from the ID 0. My aim is to reach up to 40-50 Hz update rate by working with 4-6 anchors, but I have different issues:
sequential anchors responses, due to delay to re-enable tag RX, worsen a lot update rate. Therefore I switched to 6Mb data rate that works fine with MAXIMUM 2 anchors (update rate reaches up to 300Hz). With 3 or more anchors there’s a stuck of the whole system.
sequential anchors responses based on ID results problematic when some anchor does not respond or misses. In that case the anchors respond basing on a delay that is proportional to own ID, and this event generates a lot of latency. This case is likely to happen when there are lot of anchors that are placed in different or big areas. Is there any strategy for anchor sequential responses NOT based on ID?
I thought the best thing to do is to use a TDOA approach, but for my application it is unfeasible. Any suggestion for solving these issues?
Hi.
twr uses 9 messages to perform a location. For this reason it is recommended to use the fastest channel (6Mbps). TWR systems are slow by nature, employ TDMA strategies to service multiple devices, so the update rate is compromised (the more clients the lower the update frequency). If your application requires a high update frequency, the solution is definitely TDOA or you could develop a hybrid technology between TWR and TDOA.
Thank you so much for your answer. Unfortunately I don’t know if i can apply TDOA solution. I attempted to set this configuration for my TWR solution:
Channel number = 2
PRF = 64M
Preamble length = 128
Preamble acquisition chunk size = 8
TX preamble code = 9
RX preamble code = 9
Use non standard SFD = false
Data rate = 6.8M
PHY header mode = standard
SFD timeout = 129 +8 -8
Msg period = 5
but unfortunately communication does not work in most of the cases. Which could be the issue here?
Moreover, you could suggest me some strategy for anchors responses/timing that does not rely on anchor ID?
How custom is your system? Are you trying to build upon the PANS system or are you building it from the ground up?
I’ve built a TWR based positioning system that will run a 100 Hz update rate working with 8 anchors, all 8 are used every position output in order to reduce noise / errors. That’s still running at 850 kb/s data rate.
I think I can improve on this and get the rate up to 250 Hz or so without any impact on performance with a little bit of work on the radio protocol side. As a quick hack I did manage to get 3200 individual TWR range measurements a second to 8 anchors (so 400Hz to each of the 8) using the 6.8 Mb/s data rate but that didn’t give me the tag-anchor range I needed.
The downside with the system is that it can only run at this rate for 1 tag at a time. You can extend it to 2 tags by taking it in turn and there is no significant performance hit but to get more than 2 tags you start to lose the dynamic response and have to start to add latency on the output, both things that are probably an issue or you wouldn’t need the high update rate to start with.
So what you are aiming for is certainly possible as long as you are willing to make some trade offs.
You say that some anchors don’t respond or are not receiving messaging in time.
This could be for various reasons. Did you see any faultcodes? See APS022 for trouble shooting hints.
Anyways, for high data transmissions it’s important that SPI transactions:
(a) Occur with the fastest possible speed (eg 20Mhz) and are not interrupted
(b) Not to tuse short preamble (64 128) as each symbol is about 1 µs long.
You’re using 128 , but have you tried with 64?
Depending on your application it may make sense for the DW1000 not to use SLEEP / DEEPSLEEP modes as the IC needs wake-up time (for crystal to start up) to return to the active state.
I also sugggest you read the IC user manual (latest 2.18) where high speed transmission is described and some recommodations are suggested (eg start transmission before all of the transmit data has been written)
And finally once you’re reading the user manual, also have a look at section 12 APPENDIX 3: Two-Way Ranging. It describes some different TWR options. But ofcourse as FdiAz suggested you could implement your own version also .
Thank you. What do you mean for PANS or ground up? Sorry but I’m new to this topic. Just to give you an idea about the system I have. I have 1 tag that blinks a message and waits for an arbitrary number of anchors respond (4-6 anchors), after they response, tag sends another blink message and again it waits for anchors responses and finally it computes ToF for every anchor. In the system there will be N anchors but I want to consider just 4-6 anchors responses. The problem mainly relies on anchors timing for response to tag. Indeed if I allow every anchor to response without a time scheduling the tag gets stuck (I think because tag has not enough time to restart RX) and therefore time scheduling is based on AnchorID, and therefore every anchor that responses triggers the one with subsequent ID. This is bad since anchors responses start everytime from ID 0, regardless time blink message arrives (it may happens that anchor with ID 2 receives blink message before anchor 0, but it has to wait for anchor 0 response, or worse yet, anchor 0 may not response). You have some idea about to solve this big issue?
Hi
The problem is not your configuration. Uwb is only the physical medium through which a communication is made. You must establish rules for effective communication. Imagine a group of people speaking the same language at the same voice intensity at the same time without any issuer-reseptor rules, the result would be that few participants receive the message properly.
You must implement rules and time allocation mechanisms for each device, an example is the IEEE 802.15.4 standard which establishes very robust communication rules and anti-collision mechanisms.
As Fdiaz indicated the issue you are having is with your protocol, the method you use to set when each anchor should reply. But then I think you’ve realized that too.
The simple solution is to not use ID to decide when an anchor should reply. That’s only a good idea when you expect (and want) most of your anchors to reply every time.
Instead have something decide who should reply (probably the tag but there are other ways of doing things) and who should ignore the message. That way you don’t waste time on anchors that are out of range or you don’t care about.
At the most basic the tag can include an ID in the radio packet. Only that anchor replies. Since you know you only have one reply you don’t need to worry about collisions or enable times and can send the message as soon as you like every time.
This can be expanded to multiple anchors, the tag sends several a list of anchor IDs, the anchors set their delay not on their ID but on where their ID is in the list.
The down side to this is that the tag needs to know which anchors are in range and which aren’t and then has to decide which ranges to measure when. So you lose flexibility and gain complexity but can increase your radio utilization and so improve your measurement rate.
The other thing is to ensure your aren’t sending more than is needed over the radio, my current system works out as an average of 20 bytes total transmitted over UWB per range measurement. I think I can reduce that a little more.
Thank you everybody. I attempted to reduce as much as possible time slots of anchors to reply to tag, but it looks like tag misses some anchor message. So far the minimum time slot for anchors to reply causes an update rate of 40 Hz with 3 anchors, that looks so poor. For this reason I supposed there’s a way to re-enable tag RX faster than now. Could i be right? Any suggestion? I’m going to study DecaLeo suggestion about SLEEP / DEEPSLEEP solution and check if it is active or not on my tag, and if it affects my issue.
The decawave chip does feature what they call a swing buffer set. Basically there are two sets of receive buffers, you can be reading the received message out of one buffer while a new message is being received by the radio and written into the second one.
But you should be able to go faster than that. Do you have the SPI bus speed up as high as possible and are you keeping the number of reads/writes to the chip to a minimum? The time taken to talk to the chip can start to be a limiting factor if you are reading / writing too much.
Also what are you using to drive the SPI bus? If you’re using something running an OS like a raspberry pi then the time taken for the OS to respond to an interrupt can be fairly high which will in turn have a big impact on how long it takes you to re-arm the receive. Or if you’re using something like an arduino then you simply may not have the processing power needed to read the data out and process it quickly enough. Assuming reasonable coding a 100 MHz Arm M3 running without an OS is more than capable of running the DW1000 flat out without any problems.
You mean the double buffering operation? I think it is active but I have to check again. Unfortunately the code was already implemented by someone else, and I’m not so expert on this subject, but nevertheless I have the role to increase as much as possible the update rate.
I’m using a micro controller 168MHz, cortex M3 and it is not raspberry nor arduino.
Thank you again for your availability