Respected,
I am writing on this forum with reference to 3 DW1000 having a STM onboard chip. I am unable to interface the 2 anchors and 1 tag. I am very new to this tech so I did do some digging and found out about AT commands. I used Docklight and SSCOM to run my DW1000s but at a time only 1 tag and 1 anchor are working. Why is the tag not intefacing with the other anchor? If you guys have a approach please guide me. Ill be really grateful for the help
Hoping for some support.
Thanks!
The DW1000 is a radio chip with no processor.
The DWM1000 is a DW1000 on a module to make it easier to use. It has no processor.
The DWM1001 is a DW1000 and a Nordic nRF52832 processor on a module. It has a processor but not from STM.
You are going to need to be a lot more specific about the hardware and firmware you are using if you want any meaningful help.
Hi thanks for the heads up. Just to clarify I am right now using a dwm1000 stm based.
So I have figured out a way to use 2 tags with 3 anchors. But !!! I am receiving some huge interference like if I used tag A and 3 anchors I am getting accurate distances in the tag. But unfortunately when I use 2 tags under the same anchors. The distance readings start getting noisy. Like earlier it was around 2m from anchor A but now that there are two tags this reading has increased to 15m and more. And the interference keeps on increasing it. At one time it reached 100ms (This was shocking). I have read documents from QORVO using the same dwm1000 stm chip with multiple anchors and multiple tags. That means this is do-able with accuracy. Can you or anyone provide some guidance on reducing this noise. I need accurate distance readings.
I am sorry for this convenience but I will really appreciate the help you guys can provide me!
What method are you using to avoid collisions between the tags?
You need some method to ensure that you don’t end up with two different tags trying to talk to the same anchor at the same time or hearing a reply to the other tag and thinking that it’s for them.
Normally this means some form of TDMA where the tags each take turns ranging to the anchors.
Okay so I have set different time slots for each tag to send info. Like every 2 secs tag A communicates and every 5 seconds tag B. Will this work? Because I noticed that my 2nd tag distance wasnt showing up because the “send every” value of each tag from sscom software was same. Thats why I changed the time intervals of each tag and it started showing up. But after that came the interferences.
That would help.
The simple solution if you can use it is to make the duty cycle low, Tag A spends 0.1 seconds measuring ranges and then waits 5 seconds, Tag B does the same. And then make the wait time slightly random somewhere between 4 and 6 seconds. If they happen to be at the same time for one transmit they probably won’t be for the next one.
As long as the wait is long in comparison to the active time and you don’t have too many tags this is simple and works fairly well. You do still need some way for a tag to realise that an anchor was talking to a different tag and it should ignore the message. Without that you’ll still get the occasional bad result.
If you need faster rates or lots of tags then you need something like Tag B hears Tag A (or hears an anchor respond to tag A) and waits until Tag A has finished before starting it’s turn.
Either way the messages should include which tag an anchor is replying to.
This sounds promising! But can you provide some method or document I can go through to work on this. Please I have purchased 7 of these and I cant return it so I am willing to learn and work.
I don’t have any documents or method other that what was posted above.
This involves a minor change to the radio packets being sent and some logic around when a tag initiates a set of measurements. Both of these are relatively simple firmware tasks to change.
The one thing I would say is that a lot of the example code defines the radio message as a uint8_t array and then uses seemingly random hard coded offsets into that to modify the data being sent as needed.
If your code is based off those examples and is still doing that then the first I would recommend is throw that part of the code away (or keep it as an example of how not to do things) and define your radio messages as packed structs.You can keep the actual data sent identical but that way the code is more readable, easier to maintain, and far easier to change if you want to add an extra field into the message.