Hi,
I’m currently working on a project that doesn’t allow for the gateway setup with a Raspberry Pi connected to the bridge node. However, I still want to be able to send IoT data (user data) from the anchor nodes to the bridge node. According to the DWM1001 FIRMWARE APPLICATION PROGRAMMING INTERFACE (API) GUIDE Version 2.2, this should be possible using dwm_backhaul_xfer.
Due to sparse documentation for the backhaul API functions, I decided to read out the SPI interface in a setup with a Raspberry Pi (as per the DWM1001 Gateway Quick Deployment Guide). When I create an uplink user data packet on the anchor node with the UUI command, I intercept the following SPI commands between the Raspberry Pi and the bridge node:
| MOSI | MISO |
|---|---|
| 0x37 0x02 0x00 0x00 | 0xFF 0xFF 0xFF 0xFF |
| 0xFF 0x02 | 0xFF 0x05 |
| 0xFF 0x02 0x00 0x00 0x00 0x00 0x79 0x00 0x10 0x01 0x1A 0x0C 0x10 0x00 0x00 0x02 0x13 0x24 0x00 … | 0x6E 0x30 0xB4 0x00 0x00 0x00 0x79 0x00 0x10 0x01 0x1A 0x0C 0x19 0x78 0x00 0x02 0xAB 0xCD 0x00 … |
| 0xFF 0x02 0x00 … | 0x6F 0x00 … |
| 0xFF 0x02 0x00 … | 0x70 0x00 … |
| 0xFF 0x02 0x00 … | 0x71 0x00 … |
| 0xFF 0x02 0x00 … | 0x72 0x00 … |
The SPI commands and the responses make sense and largely align with the documentation. The third response from the bridge node contains the uplink user data. I believe the response means the following:
0x6E: TLV Type
0x30: TLV Length
0xB4 0x00: current superframe number (sf_number)
0x00 0x00 0x00 0x79 0x00 0x10 0x01: no idea
0x1A 0x0C: Slave-ID in LSB
0x19 0x78 0x00 0x02: no idea
0xAB 0xCD: Uplinkdata
0x00 … : Dummy data
However, when I try to replicate the SPI commands with my own hardware, the response messages from the bridge node look like this:
| MOSI | MISO |
|---|---|
| 0x37 0x02 0x00 0x00 | 0xFF 0xFF 0xFF 0xFF |
| 0xFF 0x02 | 0xFF 0x05 |
| 0xFF 0x02 0x00 0x00 0x00 0x00 0x79 0x00 0x10 0x01 0x1A 0x0C 0x10 0x00 0x00 0x02 0x13 0x24 0x00 … | 0x6E 0x04 0x83 0x02 0x02 0x00 0x79 0x02 0x10 0x01 0x1A 0x0C 0x89 0x78 0x00 0x20 0x11 0x4A 0x6F 0x73 0x65 0x00 … |
| 0xFF 0x02 0x00 … | 0x6E 0x00 … |
| 0xFF 0x00 … | 0x6F 0x00 … |
As you can see, the response from the bridge node does not contain the uplink data. I strictly followed the documentation (3.2.4 and 3.2.5) for the sequence of SPI commands and the data ready pin.
I suspect the issue is related to timing. The Raspberry Pi sends the SPI command of type 0x37 only when uplink data is available. Perhaps the Raspberry Pi obtains the information whether data is available through the following SPI commands:
| MOSI | MISO |
|---|---|
| 0x32 0x00 | 0xFF 0xFF |
| 0xFF 0x00 | 0x07 0x01 |
| 0xFF 0x00 0x00 0x00 0x00 0x00 0x79 0x00 | 0x40 0x01 0x00 0x5A 0x02 0x1E 0x00 0xFF |
| 0x3A 0x00 | 0xFF 0xFF |
| 0xFF 0x00 | 0x18 0x01 |
| 0xFF 0x00 0x00 0x00 0x00 0x00 0x79 0x00 0x10 … | 0x40 0x01 0x00 0x5D 0x13 0xB7 0x04 0x07 0x00 0x00 … |
The Raspberry Pi sends the 0x32 and 0x3A commands regularly. However, my attempts so far have not been successful.
Does anyone have an idea why I’m not receiving any data? Has anyone successfully replaced the Raspberry Pi with their own hardware? Does anyone have any ideas on how to properly time the SPI commands? I would appreciate any help. I know that the issue has been discussed several times and so far no solution has been found. (Link, Link, Link, Link)
The DWM1001 is a fantastic product, but in my opinion, the gateway solution with the Raspberry Pi is not suitable for industrial applications of the DWM1001.
Sam