why is the dwm_usr_data_write api commented out in the dwm-range-iot example in the source code bundle ?
can we use the dwm-range-iot example without having a Raspberry Pi. ?
I want to configure 4 anchors, 1 tag, 1 listener, 1 bridge. Write iot/user data from the tag and be able to read it on the listener or the birdge. Is it possible ?
I also want to know if the reverse can be done. i.e. write data from bridge/listener and receive it in the tag. Is it possible ?
Hi @Sarat
See my answers below
re dwm_usr_data_write) Actually this is not a LEAPS code… And I don’t know why it is commented. But the dwm_usr_data_write is normally working and you can use it.
re dwm-range-iot example without having a Raspberry Pi) No that is not possible, the gateways is a MUST for IoT data.
re Listener) Listener can receive only location data and not IoT data.
re reverse IoT data) Yes with bridge you can send/receive to/from end node
Cheers
JK
@leapslabs Thank you so much for your response.
I have a network set up - 4 acnhors, 1 tag, 1 bridge. the network is operational. I confirm this by seeing the DRTLS android app. I am able to see the anchors and tags in the app and tracking happens successfully.
Now i take the tag and flash the dwm range iot example code into it using the segger ide. Now if i perform dwm_usr_data_write function(dwm_usr_data_write(data_out,10,false)), it is returning DWM_ERR_BUSY.
if i give the 3rd parameter as true. i.e.with overwrite, it returns success, but I am not able to see DWM_EVT_USR_DATA_SENT event happening.
Is there anything I am missing ?
[Please note that I have not set up the RaspPi. I just want to test the dwm_usr_data_write and dwm_usr_data_read with custom firmware at the tag and bridge]
Hi @Sarat
the DWM_ERR_BUSY is returned while the previous paket has not been sent yet. When you set the overwrite flag than you are overwriting the unsent message (ie there is buffer only for one message).
You must be in the range with bridge unit to be able to send out the IoT message. If you dont have there the bridge then the node is not able to send then message within his cycle and then you get DWM_ERR_BUSY as a response.
Cheers JK
Thanks for your response @leapslabs I have the bridge and tag next to each other. Its still returning the same error.
Hi @Sarat
can you see the anchors in raspberry pi web server?
Cheers
JK
Hi @leapslabs As I have mentioned above in this thread, I have a network set up - 4 acnhors, 1 tag, 1 bridge. the network is operational. I confirm this by seeing the DRTLS android app. I am able to see the anchors and tags in the app and tracking happens successfully. I have not set up the RaspPi. I just want to test the dwm_usr_data_write and dwm_usr_data_read at the tag and bridge (custom firmware), without having the rasp pi.
Hi Sarat,
unfortunatelly this is not supported, you need Gateway to get the data. SPI communication between the Bridge and the GW is quite a complex task, it requires very precise timing and synchronization and it requires deep knowledge about the wireless communication protocol, therefore you need RPI which handles the SPI comunication.
JF
@leapslabs I have understood from multiple other discussions in the forum that the Bridge-RaspPi3B communication is tough to implement due to stringent timing constraints and so that interface is
not documented and releaseed to developers for the same reason.
i was just trying to see if i can get my hands on the data that is available on the bridge. If the bridge is able to send the user/iot data to the rasp pi then it must have that data somewhere. I thought that using the dwm_user_data_read/write would let me access that user/iot data on the bridge, even if the rasp pi did not exist.
The dwm_user_data_read/write are used to send data over UWB and read data received via UWB on the particular node (Tag, Anchor). These call do nothing on the Bridge. The user data from all the nodes that are connected to Bridge goes through the Bridge of course, but again, these data are there for short period of time and their extraction is handled by RPI.
JF
@leapslabs I assumed that dwm_user_data_read/write would work at the bridge. Its clear now. Thanks for the clarification.
With PANS as is, when I have data being generated in every tag (example, battery, accelerometer, etc), this data is accessed by the Raspberry Pi 3 which is connected to a bridge. This data is transferred between nodes when UWB ranging is happening, according with documentation, so I can not freely transfer this data from generator nodes (tags in this example) to the bridge, nor at a time where I see more fit.
As you mentioned, if the functions only work between tag and anchor, how does this information get to the bridge node? Does the bridge capture it over-the-air as it passes by from node to node, or is it directly sent to the bridge some way (redirected by anchors, for instance)?
I changed the gateway from the Raspberry Pi 3 to a ESP32 connected to a bridge node through UART. Not supported, but possible.
I know everything I am saying is possible, maybe just not supported.
I just don’t see how this IoT data gets to the bridge based on the information provided. Can you help enlight what is going on here?
Hi @WerneckH
you are a bit correct. The data are sniffed by the Bridge node.
With the regard to the bridge node, there is no way how to get those data from the node via UART. Over the SPI there is API command to read those data out. But we are not providing any support for this function as its proper implementation a lot of work and very good timing.
Cheers
JK
you are a bit correct. The data are sniffed by the Bridge node.
I take from this that the data is not sent directly to the Bridge node, probably it “hears” when the tag is communicating its data to the anchor node. Is that correct?
Over the SPI there is API command to read those data out.
Can you guys share what the command is? I can look into how to change from SPI to UART if needed. Since the command is working and known, knowing the command and how to use it, even if not further supported, would save up tons of time trying to figure it out.
On a separate note: if I were to work on my own firmware, I take I would probably be looking at how to integrate the nRF52 MCU API (nrf and nrf_drv libraries) with the DW1000 API (decadriver > deca_device_api.h, deca_device.c, etc) and doing my own ranging and trilateration implementations. Is that correct?
If so, is there any limitation that would stop me from including the decadriver within the main C code (like dwm-simple.c) and overloading/overriding existing stuff within the PANS firmware?
I ask that because I am still not comfortable doing the ranging thing myself. I can use that from PANS as is, while handling the other transmissions that don’t require precision, such as reporting some status data every now and then.
Hi @WerneckH
re bridge sniff) yes you are correct.
re API) see 5.4.2 dwm_backhaul_xfer
re Coding)
you need to start with nRF52 MCU API with the DW1000 API from scratch.
The PANS firmware is a quite complex and really I dont see a way how you could start " overloading/overriding existing stuff" in PANS. For this you will need to have a deep knowledge of how the FW is working inside. In my perspective this is NOGO 
even for really advanced programmers.
Just to let you know - there is a new devkit: QM33120WDK2 - Qorvo which does not support a user library. But it has a newer firmware inside which support more ranging schemes and it will be actively maintained for a longer time.
Cheers
JK