In the screenshot above we can see from left to right
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
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
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"}
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.
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
dwt_setrxtimeout was set higher than the step_ms parameter, which result in a shift out of sync of the whole sequencein 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;