I am a student working on thesis about WSN, focusing on network and data transfer instead of ranging or positioning. Now I am running into a problem in DWM1000 reception. Details are explained as below.
Hardware: a customed board , i.e. STM32F103CBT6 for RFD(reduced-facility device) and STM32F407VGT6 for Coordinator.
Sofware: Decawave DW1000 driver, one task with mutiple interrupts, without RTOS.
Problem: Coordinator sends a beacon frame with a period of 1024ms, and a node (another name for RFD in my thesis) shall send a data frame to the coordinator on receiving a beacon frame. In most cases, the scenario works well, however, the node CAN NOT receive the beacon EVERY NOW AND THEN. Moreover, the node will be ABLE to receive beacon frame after appoximately 2~60 seconds again. After days of test, I’m sure that the coordinator is always working well, and when one node can’t receive anything(this is not a specific one), other nodes can receive beacon frames.
When a node can’t perform reception, SYS_STATE register centent shows that it’s in RX/Preamble Find, and RX LED is blinking,
SYS_STATUS content is 0x8000F2:
Clock PLL lock;
status corresponding to TX events.
SLP2INIT.
Also, diagnostics information shows that there is no frame received at all;
Here is my DW1000 configuration:
static dwt_config_t dw1000_config = {
.chan = 2, // channel 2
.prf = DWT_PRF_64M, // pulse repetiton frequency 64MHz
.txPreambLength = DWT_PLEN_1024,// preamble length
.rxPAC = DWT_PAC32, // packet acquisition chunk size
.txCode = 9,
.rxCode = 9,
.nsSFD = 1, // non-standard SFD
.dataRate = DWT_BR_6M8, // datarate 110kbps
.phrMode = DWT_PHRMODE_EXT, // standard MAC header
.sfdTO = (1024 + 1 + 64 - 32), // sfd TIMEOUT = preamble length + 1 + PRF - PAC
};
Auto-re-enable receiver is enabled in my project. Sometimes there exists some PHY Header error and Reed Solomon Frame Sync Loss.
I have been stuck in this problem for more than a week, ANY help and thoughts appreciated!!!
Hi Darren
You’re using 2 different MCUs , to it could be a timing /delay issue .
Have you tested this with two identical MCUs.
Also if you just left the device in RX will it receive frame/error after some time and finishes the receive?
Finally can you just change the PAC size, see reg 0x27:08 in the User Manual.
When the receiver is in RX state but not receiving anything, can you just change the PAC size, see reg 0x27:08 in the User Manual, and see if receiver receives a frame or error? eg After no packet reception change the PAC size from 32 to 16.
Hey, Leo! First of all, thanks very much for your help!
For these two different MCUs, I haven’t tested the application with 2 identical MCUs… but, the period of the beacon frame is 1024ms, which is long enough for a MCU like STM32F1/4XX. And, I am keeping receiver in the node staying in RX state as long as possible except the time when there is a need for the node to send a response.
If the device is just left in RX state, it will generate some RX events as normal, which is exactly the same as Usermannual describes. The scenario I described above worked well most of time. But during the time the node ‘can’t’ receive anything , I really don’t know what’s going on, so…
For PAC size, tbn, I haven’t understood that well, so I just followed the configuration mode 2 which is recommended in the datasheet. I will try to change the PAC size and test.
What’s more, today I enabled preamble-detection-timeout feature with time of approximately 320ms. Every time the preamble detection timer expires, the receiver will be hunting for preamble again(auto-re-enable feature has been enabled before). After hours of test, it seems that the number of reception failures is significantly reduced, and the time when malfunction occurs is much shorter. Maybe auto-re-enable is not working as I understood.
I will keep debugging, testing, and post the result later.
Finally, I really appreciate your help, thank you!
I got new trouble yesterday. Clock PLL lock loss happened in my application after some time, and it seemed that DW1000 just didn’t work anymore unless reset. So I set up a timer that is responsible for detecting the status of DW1000 and resetting when the fatal errors occur. I am trying to make DW1000 work as long as possible. Now, things are gettting much better.
so, still debuging. And I will post the result of PAC size change tomorrow.
