UWB Mesh and 2.4 GHz Simple Mesh

In the screenshot above we can see from left to right

  • UWB listener
  • 2.4 GHz Simple Mesh listener
  • UWB Initiator
  • UWB Responder

This is still in early experimentation stage where only the UWB listener is registred as simplemesh node which uwb listening parameters are configurable through simplemesh backend with a json structure

UWB repo

Simple mesh listener repo/directory

The simple mesh is also a west dependency from the uwb repo

This is the first successful Two Way Ranging request handled from the reception of a simple mesh json packet

  • broadcasted command : sm{"twr_command":{"initiator":1,"responder":0}}

execution log on all of initiator node, responder node and a simple mesh sniffing node

zoom on the TWR gpio debug pulses

new parameter at_ms allows each thread to poll and syncs relative to the RF packet rx interrupt.

sm{"twr_command":{"initiator":0,"responder":1,"at_ms":50}}

despite a jitter of interrupt to thread that can go up to 60 ms, now both uwb nodes start the command sequence with a sync of around 5 us !!!

MQTT like request and response, currently tested on serial console

and in case of stressing the system with tight deadline, the error is also returned in the json response

RF diagnosis commands ping and target_ping
image

details documented in

TWR ranging multi commands request is up and running

sm{"uwb_cmd":"twr","initiator":0,"responders":[1,1],"at_ms":100,"step_ms":10,"count":3,"count_ms":50}

test with a responders list of two with the same id each twr with a node from the list is a step that happen at 10 ms of interval, once the list is done, then another round starts at 50 ms interval. So the whole sequence is repeated every 50 ms and x3 times as of count = 3.

console request and RF responses (note the negative numbers due to very close uncalibrated uwb nodes)

sm{"uwb_cmd":"twr","initiator":0,"responders":[1,1],"at_ms":100,"step_ms":10,"count":3,"count_ms":50}
>sm/1CF6567337562176{"result":{"range":"0.014"},"uwb_cmd":"twr"}
sm/1CF6567337562176{"result":{"range":"0.019"},"uwb_cmd":"twr"}
sm/1CF6567337562176{"result":{"range":"-0.019"},"uwb_cmd":"twr"}
sm/1CF6567337562176{"result":{"range":"-0.005"},"uwb_cmd":"twr"}
sm/1CF6567337562176{"result":{"range":"0.005"},"uwb_cmd":"twr"}
sm/1CF6567337562176{"result":{"range":"-0.005"},"uwb_cmd":"twr"}

example with 10 double success

Test with x1 Tag (id 5) and x4 Anchors (ids 0,1,2,3) count x3

sm{"uwb_cmd":"twr","initiator":4,"responders":[0,1,2,3],"at_ms":100,"step_ms":10,"count":3,"count_ms":50}

sm/98501ED22B42EB41{"initiator":4,"range":"0.938","responder":0,"seq":0,"uwb_cmd":"twr"}
sm/E8D81FEE52C283EB{"initiator":4,"range":"2.087","responder":1,"seq":1,"uwb_cmd":"twr"}
sm/530BE91D3559D690{"initiator":4,"range":"0.891","responder":2,"seq":2,"uwb_cmd":"twr"}
sm/C24FD51212E905F0{"initiator":4,"range":"3.232","responder":3,"seq":3,"uwb_cmd":"twr"}

sm/98501ED22B42EB41{"initiator":4,"range":"0.966","responder":0,"seq":4,"uwb_cmd":"twr"}
sm/E8D81FEE52C283EB{"initiator":4,"range":"2.097","responder":1,"seq":5,"uwb_cmd":"twr"}
sm/530BE91D3559D690{"initiator":4,"range":"0.919","responder":2,"seq":6,"uwb_cmd":"twr"}
sm/C24FD51212E905F0{"initiator":4,"range":"3.222","responder":3,"seq":7,"uwb_cmd":"twr"}

sm/98501ED22B42EB41{"initiator":4,"range":"0.962","responder":0,"seq":8,"uwb_cmd":"twr"}
sm/E8D81FEE52C283EB{"initiator":4,"range":"2.087","responder":1,"seq":9,"uwb_cmd":"twr"}
sm/530BE91D3559D690{"initiator":4,"range":"0.891","responder":2,"seq":10,"uwb_cmd":"twr"}
sm/C24FD51212E905F0{"initiator":4,"range":"3.213","responder":3,"seq":11,"uwb_cmd":"twr"}

what is the average range of ur uwb modules? i was thinking that since uwb can transmit data so fast, it would consume much less power than BT5.2, so a remote or sensor node on battery would last longer.

I still did not perform range tests but others did see this as example

UWB is not competitive with BT as it is much more expensive.

1 Like

test with 1 initiator and 7 responders successful

sm{"uwb_cmd":"twr","initiator":6,"responders":[2,3,4,5,7,8,9],"at_ms":100,"step_ms":10}
>sm/DC1119997A56350D{"initiator":6,"range":"0.478","responder":2,"seq":0,"uwb_cmd":"twr"}
sm/C24FD51212E905F0{"initiator":6,"range":"0.324","responder":3,"seq":1,"uwb_cmd":"twr"}
sm/530BE91D3559D690{"initiator":6,"range":"0.038","responder":4,"seq":2,"uwb_cmd":"twr"}
sm/90A971A3D1A1B648{"initiator":6,"range":"-0.122","responder":5,"seq":3,"uwb_cmd":"twr"}
sm/98501ED22B42EB41{"initiator":6,"range":"0.417","responder":7,"seq":4,"uwb_cmd":"twr"}
sm/E8D81FEE52C283EB{"initiator":6,"range":"0.281","responder":8,"seq":5,"uwb_cmd":"twr"}
sm/5F7D70F99F462C99{"initiator":6,"range":"0.779","responder":9,"seq":6,"uwb_cmd":"twr"}

testing with two gateways gpio debug

8 responders have success and fails
success:

sm{"uwb_cmd":"twr","initiator":1,"responders":[2,3,4,5,6,7,8,9],"at_ms":100,"step_ms":10}

sm/E8D81FEE52C283EB{"initiator":1,"range":"0.385","responder":2,"seq":0,"uwb_cmd":"twr"}
sm/98501ED22B42EB41{"initiator":1,"range":"0.277","responder":3,"seq":1,"uwb_cmd":"twr"}
sm/BF5C1AC6B93150BF{"initiator":1,"range":"0.347","responder":4,"seq":2,"uwb_cmd":"twr"}
sm/5F7D70F99F462C99{"initiator":1,"range":"0.450","responder":5,"seq":3,"uwb_cmd":"twr"}
sm/E2F96EB1D7A476CC{"initiator":1,"range":"0.399","responder":6,"seq":4,"uwb_cmd":"twr"}
sm/90A971A3D1A1B648{"initiator":1,"range":"0.497","responder":7,"seq":5,"uwb_cmd":"twr"}
sm/530BE91D3559D690{"initiator":1,"range":"0.854","responder":8,"seq":6,"uwb_cmd":"twr"}
sm/C24FD51212E905F0{"initiator":1,"range":"0.774","responder":9,"seq":7,"uwb_cmd":"twr"}

Fail:

sm{"uwb_cmd":"twr","initiator":1,"responders":[2,3,4,5,6,7,8,9],"at_ms":100,"step_ms":10}
>sm/E8D81FEE52C283EB{"error":"mp_receive_1_failed","initiator":1,"responder":2,"seq":0,"uwb_cmd":"twr"}
sm/BF5C1AC6B93150BF{"initiator":1,"responder":4,"seq":2,"uwb_cmd":"twr"}
sm/98501ED22B42EB41{"initiator":1,"range":"0.310","responder":3,"seq":1,"uwb_cmd":"twr"}
sm/5F7D70F99F462C99{"initiator":1,"responder":5,"seq":3,"uwb_cmd":"twr"}
sm/C24FD51212E905F0{"initiator":1,"responder":9,"seq":7,"uwb_cmd":"twr"}

CONFIG FIX

  • Issue : when requesting a sequence of TWR responders list, and only one of the does not respond or does not exist, the UWB RX timeout that is configured with the function dwt_setrxtimeout was set higher than the step_ms parameter, which result in a shift out of sync of the whole sequence

in this example the twr timed out period was taking 21 ms instead of 10 ms (note init and resp names inverted)

which results in the following log output from the responders

initiator> success with frame 0
Receive Frame Wait Timeout; User defined RX timeouts;
sm> /!\ target_ticks_delay missed by (1037) us at seq(2)
Receive Frame Wait Timeout; User defined RX timeouts;
sm> /!\ target_ticks_delay missed by (7263) us at seq(3)
Receive Frame Wait Timeout; User defined RX timeouts;
sm> /!\ target_ticks_delay missed by (13488) us at seq(4)
Receive Frame Wait Timeout; User defined RX timeouts;
sm> /!\ target_ticks_delay missed by (19805) us at seq(5)
Receive Frame Wait Timeout; User defined RX timeouts;
sm> /!\ target_ticks_delay missed by (26092) us at seq(6)
Receive Frame Wait Timeout; User defined RX timeouts;

After having checked that nodes are still in 31 us sync after 1 sec of busy wait, the uwb rx timeout can be set lower now set to 1000 us. With that config we see in the below example a timing out uwb step that recovers and keeps in sync in the next 10 ms step

and the responder log is as expected notifying timeout only for non existing or non responding nodes but successfully running with the existing ones in between

initiator> success with frame 1
Receive Frame Wait Timeout; User defined RX timeouts;
Receive Frame Wait Timeout; User defined RX timeouts;
Receive Frame Wait Timeout; User defined RX timeouts;
Receive Frame Wait Timeout; User defined RX timeouts;
Receive Frame Wait Timeout; User defined RX timeouts;