Zephyr driver, C++ high level API, nRF mesh and Two Way Ranging GPIO Profiling

wassfila · June 28, 2021, 7:29pm

Hi,
I would like to share this work in progress with those interested in an open source framework that helps experimenting with different UWB algorithms.
The content is in this repo GitHub - nRFMesh/sdk-uwb-zephyr: Zephyr sdk for uwb module DWM1001C based on nRF52832 and DW1000 Transceiver which is a takeover from GitHub - foldedtoad/dwm1001: Decawave DWM1001-Dev board.

The additions include

Using west with a connected zephyr version dependency and a deca driver integration that can be enabled with the flag CONFIG_DW1000=y
using the already available board in Zephyr decawave_dwm1001_dev instead of the locally declared board nrf52_dwm1001
adding custom mesh network functionality. The issue is that testing UWB shall preferrably have another independent communication and configuration channel and normal Bluetooth cannot cover a bit network so a mesh is needed. nRF52832 do not support openthread and I considered Bluetooth Mesh as a big overhead compared to the simplemesh solution GitHub - HomeSmartMesh/sdk-hsm-sensortag: SensorTag SDK for Zephyr by hsm as Home Smart Mesh (warning simplemesh is simple but incomplete not recommended for other than experimenting)
adding a higher level API to greatly simplify TWR applications and others by eliminating redundant blocks in the code and fitting the whole ranging sequence on a single screen function, the new API MP as meshpositioning includes mp_receive() that is overloaded with the structure type intended to be received, mp_request() when sending a struct and expecting a response . Also for when initiating a delayed transmission either expecting a response mp_request_at() or not mp_send_at()
support for c++17 and standard library e.g. string, list, map. Now before the C / C++ skepticism takes over, please consider that c++ shall not be used in a real time system without knowing how c++ works. e.g. bad c++ is adding constructor without knowing when where are resources allocated. good c++ is using typed enums, any compile time typing verifications and dead simple iteration loops.
using json GitHub - nlohmann/json: JSON for Modern C++ for remote procedure call e.g. an uwb listener has an MQTT interface where an app throws a json config sent over simplemesh to use with dwt_configure()
verbose target log for status register thanks to a simple map flag to string

As example the whole responder RF transaction sequence is here

github.com

nRFMesh/sdk-uwb-zephyr/blob/28bb91069e5c51336cb47bf0d38d4b5f21947ed9/samples/twr_responder/src/main.cpp#L110

    
      
          // - pulse3: 'computing distance'
          uint32_t reg1 = mp_get_status();
          LOG_INF("responder> sequence(%u) starting ; statusreg = 0x%08x",sequence,reg1);
          APP_SET;
          mp_rx_now();
          msg_header_t rx_poll_msg;
          if(mp_receive(msg_id_t::twr_1_poll,rx_poll_msg)){
              APP_CLEAR;
              uint64_t poll_rx_ts = get_rx_timestamp_u64();
          
          
    mp_rx_after_tx(RESP_TX_TO_FINAL_RX_DLY_UUS);
              
              uint32_t resp_tx_time = (poll_rx_ts + (POLL_RX_TO_RESP_TX_DLY_UUS * UUS_TO_DWT_TIME)) >> 8;
          
          
    msg_header_t tx_resp_msg = {
                      msg_id_t::twr_2_resp, (uint8_t)(rx_poll_msg.header.sequence + 1),
                      rx_poll_msg.header.dest , rx_poll_msg.header.source,0
                  };
              APP_SET;
              if(mp_send_at((uint8_t*)&tx_resp_msg, sizeof(msg_header_t), resp_tx_time,DWT_RESPONSE_EXPECTED)){
                  msg_twr_final_t final_msg;

The goal for the future is to allow a central python server to remotely fully configure the dwt and role of each node through mesh and json config, let them do the job in a busy loop without any interference, and then collect the results.

Below a PIO debug setup that can also help for understanding and optimizing the code.

If anyone has questions or is interested in participating please let me know. I provide support for those who do not manage to get this framework to run details in this link

AkioR · July 1, 2021, 10:10am

Hi everyone
did you know any references or codes that tried to impelment triangulation on dwm1001c mounted on its dev board ?
because I am trying to adapt the code provided by decawave to support more than one RX/TX but I got nothing

wassfila · July 1, 2021, 3:28pm

If the dwm1001c is mounted on its dev board or not should not make any different, the dev board only adds debug and flashing facility.

By the code provided by Decawave I assume you mean the code provided for two way ranging like ex_05a_ds_twr_init and ex_05b_ds_twr_resp ? Otherwise you can mention the sample name or repo reference.

These basic demonstration examples are written for two boards only because they have hardcoded tx and rx messages as you can see here tx_poll_msg

github.com

Decawave/dwm1001-examples/blob/1b2a46e14546d8f24cf08ff3d64d802e109cd2d3/examples/ss_twr_init_int/ss_init_main.c#L37

    
      
          #include "deca_regs.h"
          #include "port_platform.h"
          #include "ss_init_main.h"
          
          
#define APP_NAME "SS TWR INIT v1.3"
          
          
/* Inter-ranging delay period, in milliseconds. */
          #define RNG_DELAY_MS 250
          
          
/* Frames used in the ranging process. See NOTE 1,2 below. */
          static uint8 tx_poll_msg[] = {0x41, 0x88, 0, 0xCA, 0xDE, 'W', 'A', 'V', 'E', 0xE0, 0, 0};
          static uint8 rx_resp_msg[] = {0x41, 0x88, 0, 0xCA, 0xDE, 'V', 'E', 'W', 'A', 0xE1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
          /* Length of the common part of the message (up to and including the function code, see NOTE 1 below). */
          #define ALL_MSG_COMMON_LEN 10
          /* Indexes to access some of the fields in the frames defined above. */
          #define ALL_MSG_SN_IDX 2
          #define RESP_MSG_POLL_RX_TS_IDX 10
          #define RESP_MSG_RESP_TX_TS_IDX 14
          #define RESP_MSG_TS_LEN 4
          /* Frame sequence number, incremented after each transmission. */
          static uint8 frame_seq_nb = 0;

If you flash these samples on more than two boards the following will happen :

two initiators, one responder => it will work but when you get a measure on the responder you do not know from whom is the distance measure
one initiator, two responders => a response collision will happen that prevent the system from working, you’d get errors

To create what you’re looking for (distance measure between multiple nodes) you need to customize the exchanged messages so that each sender and receiver knows if the message is addressed to him or not and decide to respond or not. Which boils down to defining your own protocol that will sequence the two way ranging process.

AkioR · July 1, 2021, 8:30pm

Thank you for your answer.
do u know any references that could help ?

wassfila · July 1, 2021, 8:40pm

All references I know that are open source are at ranging level only, not positionning. I’m searching for one still. Localino exist but is not free. That’s why I started creating one. Each company creates its own in order to fulfill very specific requirements. My requirements are to be open source and easy to experiment with but I’ll target only one tag and many anchors. It’s a work in progress that is only starting, I already customised the messages, next step is to add the nodes ids

If you find and existing open source positioning, you can post it on this forum and I can review it and tell you what it’s doing.

AkioR · July 5, 2021, 6:40am

okay thank you
I am trying to build smthg like that for now

wassfila · July 5, 2021, 11:34am

That’s nice, feel free to use it, but take care that what I developed is a concept only far from being complete, might take many months given the pace of my progress, maybe if others contribute it will progress faster. Also the license I inherited might not fit with some use cases.

AkioR · July 5, 2021, 10:11pm

yeah I read the licence that’s why I am trying to change decawave’s code as a first solution.

wassfila · July 7, 2021, 4:47pm

When it comes to the code I have written I can release it under MIT, but I can only do that once I get rid of the decadriver that is GPL, I don’t have the patience to do that rewriting one from the datasheet, if someone is willing to provide an MIT SPI driver for the dwt_ functions, I would use it and switch the license.

AkioR · July 16, 2021, 3:52pm

Hi guys
I want to achieve a communication between Multiple responders with one initiator using DWM1001-dev
I have the ss_twr_init and responder example running on 2 modules.
I tried to modify them( customize messages between Initiator and responders) to get what but I got nothing
I would be so grateful if someone could help

wassfila · July 16, 2021, 4:06pm

yes, sure I have a solution already that I can describe, can you post this on a new topic with its own title ?

AkioR · July 16, 2021, 4:34pm

yeah sure one moment

wassfila · July 16, 2021, 5:51pm

great, here’s a link for following the thread