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 @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.