I’m having a hard time understanding from the DWM1001 firmware guide or the API docs how to use the DW1000 (and its wrappers, such as the DWM1001 or DWM1000) to transmit wireless data. I don’t want to use Bluetooth. The whole point is to use the DW1000’s wireless comms, but not for distance or range-finding, rather as a data comm.
I don’t understand how to do this. It isn’t clear from the single tiny sample code file dwm-simple.c how to get started in this area.
Does anyone have any ideas how to bootstrap my learning on this topic?
I’m still trying to figure out how to do data transmission from a DWM1001. The API guide, 2.3, says SPI and UART use TLV for data transmission. Curiously, it doesn’t say the C API should TLV for data transmission, but I can’t see any other way to do it, so I assume that’s the intended method. However, 2.3 also says to refer to section 6 for the various types and section 6 doesn’t list any type that would suggest general data transmission. How do I send an arbitrary string from one DWM1001 to another?
This is not documented and there isn’t example code for it. I don’t know what to do.
The release 1 of PANS FW does not support sending of data from one DWM1001 to another. This should be possible in release 2 of PANS FW, however even then you will need to send data from one module up to the Webclient/MQTT client/application, and then send it back to another node.
Ah, that’s important information. Thank you. May I assume this does not preclude two low-level DW1000s chips from communicating, just the wrapper board that is the DWM1001, right? Assuming I’m understanding that correctly, should I then be able to code up an SPI-based DW1000 wireless communication system with two DWM1000s? I have access to those as well as DWM1001s and have had some initial success with basic SPI communication with the DWM1000 from a controller (a PyBoard).
I am a little bit confused concerning HOW the new capabilities of the new firmware could be accesed.
In some thread, you talk about a Raspberry Pi (only model B) as the only host controller in which the PANS gateway software could run: “So I would recommend to use a raspberry pi 3 model B in order to have access to the full range of features”. Also, in this thread, you talk about how to send data from one DWM1001 to another: “… you will need to send data from one module up to the Webclient/MQTT client/application, and then send it back to another node”.
As we do not have any info or description of the new firmware (not even basic description), we need to interpret the raw info you give in the posts. So, from the above posts, I interpret that the ONLY WAY to send UWB custom frames between DWM1001 modules, anchors or tags, will be using a RaspPI model B, and from a web/MQTT application … Is this correct?
If this is correct, I found this very limitating. Why should an integrator use a MQTT broquer or a Rasp model B? Why can’t we use another controller with SPI/UART interfaces?
As the communication to the DWM1001 module has to be done by SPI/UART interfaces, does this mean that the serial protocoll/API to send some command to a DWM1001 (for example to configure the xyz coordintes to anther anchor) will not be OPENED?
The new software release (R2) will introduce a new hardware component : the gateway.
The gateway is built around a Raspberry Pi 3B and a DWM1001 (Bridge node).
There will be various software components running on the gateway and interfacing with the UWB network. Among those software components :
The Kernel module will be the lowest interface between the UWB network and the RBPi3b. It is a low level piece of software, timing critical and designed for the RBPi3b.
The Daemon will ensure the interface between the kernel and the MQTT broker
The MQTT broker will allow user to retrieve information from the UWB network as well as sending configuration or custom messages.
I believe that if required a customer should be able to use a different broker than MQTT, but it will be the preferred solution. I
It will be very difficult to use a different hardware because of the Kernel software and the fact it is timing critical.
In order to send UWB message, you will need ta Gateway indeed as it is in charge of assigning data slot to the nodes within the UWB network.
Let me know if you have any other question,
Thank you,
Regards
Yves
Please, let me know the answers to the next questions:
1.- In the present release, a module can be configured by a local host (either a PC, Raspberry, Arduino or whatever) using the simple API and serial interfaces described in DWM1001 API guide.
In the next release, will it be possible to use a similar API and a host (either a PC, Raspberry, Arduino or whatever) connected to a DWM1001 bridge node to configure a remote DWM1001? For example, will there be a simple API function to set the xyz coordinates of a remote DWM1001 (similar to ‘dwm_pos_set’ for a local DWM1001)?
2.- In figure 3 of DWM1001-SystemOverview it seems that the communication with the UWB network must be made only externally to the Raspberry through ethernet/wifi.
In our case, the UWB network is only a part of the functionallity of the system (our host will be in charge of other tasks). So, if a Raspberry must be used as the host, we would like to run our extra aplication in the same Raspberry where the Release 2 will be running. The question is, will it be possible to run this extra aplication, in the same Raspberry, which can connect locally to the MQTT broker (not using ethernet/wifi)?
3.- Will the new release run in a cheaper host than a Raspberry 3, for example Raspberry Zero?
There will be no SPI/UART api at the bridge node level allowing a remote node configuration.
The remote configuration of a node will be possible through :
BLE (connecting directly to the node itself and configuring it)
MQTT broker (By publishing configuration messages. The configuration will be transferred to the remote node through the bridge node)
It should be possible to run other application on the raspberry pi, but some of the interface will be reserved for the gateway application. Similarly, the kernel is timing critical and should have the priority against other real time applications. Regarding the wifi/ethernet solution, it is used to allow the user to interact with the bridge node and connect to the MQTT broker (hosted on the raspberry pi).
The new release will run only on raspberry pi 3b model.
I’m having some trouble following this discussion. I believe it was stated in an earlier response that the DWM1001 firmware doesn’t support or otherwise enable UWB data transmission between two DWM1001s. I’m rather surprised given that UWB is the primary feature of the DW1000 and any supporting boards built around it. Are the most recent messages, the last two or so, which have delved into areas I’m really not understanding, still on this topic of DW1000 UWB data transmission, or has the thread veered into some other territory?
The earlier answer from Zoran stated that it is impossible to send data other than location over UWB with DWM1001 firmware release 1. This is a correct statement.
The release 2 that is currently developed will introduce a new feature allowing to transfer data other than location over UWB. This data transmission will follow a very well defined protocol : the data will go from a DWM1001 to a Bridge node over UWB. The bridge node will transfer the data to a MQTT broker and the user can access it there.
The last few message were all related to the release 2.
My question concerning running a user appilcation in the same Rasp was related to how to communicate directly to the MQTT broker from this user appliaction. See the attached diagram. I woudn’t like to use another controller to host our application, and connect it to the Raspberry either by wifi or ethernet cable. I would like to use the same Raspberry as a single controller to do the whole tasks. Is there a way to communicate with the MQTT broker from this local user application?
I’m not 100% sure i’ll have to double check. I’d say it is ok as the broker can be hosted locally on the rbp3b but don’t take it for granted as I am not completely sure.
I’ll update the thread once I have a chance to look at it into more details.
Any update on this?
Should we consider that it will not be possible to communicate with the MQTT broker from a local user application running in the same Raspberry?