Yes, your idea can work, simply reprogram the entire CHAN_CTRL register when you switch from RX to TX and back again. That is assured to work since it programs RX_CHAN and TX_CHAN to the same value and thus doesn’t violate the user manual guidelines.
It may work to split RX_CHAN and TX_CHAN. This would be operating outside the guidance of the user manual and is not something that we have tested or tried. Simple enough to try it and see, but you always have the CHAN_CTRL reprogram option to fall back on if it doesn’t work.
You should note that when tags are close to each other, they can hear each other even on different channels. The signal can be so strong that it makes it through. So being on a different channel doesn’t absolutely assure non reception.
In our building, we have many software teams working on UWB system development, and we have tried all the various ways to isolate the networks, so we know what works and what doesn’t. In some cases, we operate a system inside a large metal garbage can, a cheap RF screen room, when the object of the exercise isn’t so much about location but other aspects.
This is correct. The preamble codes are some isolation, but not enough to be really separate. In a nutshell, the preamble code feature really doesn’t work to separate networks.
What does work well enough is PRF selection. Have the anchors send on PRF64 and the tags send on PRF16 and that stays mostly isolated.
Lastly, sounds like you are trying to solve the “network hunt” problem, that is, how does a tag know when to power down when off network and then power back up when it is near a network? Searching for network control packet can eat up a lot of energy, so this isn’t a trivial exercise. Indeed, sometimes a tag uses more energy when off network (periodically hunting for one) than being on a network (since it knows when to beacon and exactly when to listen for control packets).
I will point out that if a tag A hunting for the network hears tag B, then tag A knows it is near a network since tag B would only beacon if it heard a network. So why be worried about a tag hearing another tag? That’s a good sign that a network is nearby, so now listen longer for the control packet and join when you hear it.
In our CUWB system, a tag hunting for a network periodically listens for any UWB traffic. If it hears any, from either anchor or tag, it listens for a command packet and then it announces itself in a special announce time window indicated by the command packet. Then the next command packet sends it configuration information (network parameters, what slot time, what features to enable, etc, etc). The tag then periodically tracks the command packet to keep slot locked with the network and to get command updates (change in rate, features, etc). If it doesn’t hear the command window for some time, the tag drops off the network and hunts for it again. This system works quite well and allows a fully time slotted network with high capacity and very low tag power.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408
