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

wassfila · June 27, 2021, 8:55am

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

also important to mention the official debugging application note which focus on SPI debugging https://www.decawave.com/sites/default/files/aps022_debugging_dw1000_based_products_systems.pdf