PDoA kit node interrupt processing


I am currently working through the node S/W to understand the S/W flow.

The interrupt processing on the PDoA node seems strange to me. The interrupt setup on the Nordic nRF52840 only sets up the interrupt for the Master DW1000 (see interrupts_init() in dw_pdoa_node_common.c )

The problem is that the RX callback (in function twr_rx_node_cb()) reads timestamps from both devices as if both devices have received the message. This probably works for good radio conditions, but under marginal conditions the slave may not have received the message, while the master has. This can lead to stale information being used in the phase calculation as well, because phase is read assuming both DW1000’s have received the packet.

Am I interpreting the S/W flow correctly?


Nearly correctly.
And yes, only one IRQ is used.

The TWR is based on the master chip only. The second chip is used in RX only for the Final msg, for phase calculation, and there is should be a check, that the slave has the RX good in its status.

Just to confirm you, that the reading of TS for Poll is useless for slave. TS for Final is also kinda useless, but for code unification and debug purposes is required. With the final TS you should see that both chips are synched, i.e. TS_Final_Master - TS_Final_Slave == should be very small constant.

Hi Alliv,

I can see that the DW1000 slave timestamp is not really important in the TWR exchange. Do you know where the check is performed for synchronised master/slave DW1000 reception?

The flow that I am seeing is:
RX_interrupt (for final) from DW1000 Master -> twr_rx_node_cb callback -> RXtask mutex signalled
RXtask calls the twr_responder_algorithm() function (which decodes it as a final message) and calls node_received_final()
After that:
node_received_final() reads the phase data
The RX task then posts the data to the calcTask mailbox.
And finally:
CalcTask calculates the angle of arrival


Hi PE1,

You correct, and this is a bug in the PDoA Node project.

Now the “node_received_final(pRxPckt, pTwrInfo);” is called irrespective to the RxGood of the Slave chip.

A simple check should be added that Final has been received correctly by both Master and Slave.

Hopefully, Decawave will fix it.

Hi PE1 amd Alliv,

Thanks for finding and highlighting the issue. We’ll fix this in the next releasesof the software.

Have a nice weekend