Hi,
My configuration is: Raspberry Pi 3B with Tag DWM1001-DEV in SPI mode connected with short wires (10cm)
Raspberry is powered with official raspberry adatator
DWM1001-DEV is powered with Li-ion 3V7 700maH battery
Tag configuration: normal & stationnary update rate is 100ms
operating firmware is FW2
I’m using 4 anchors
On Raspberry: SPI is mode 0 ; max SPI speed is 1MHz ;
I’ using PYTHON; I’m waiting 1ms between each SPI command (also tried with 2mS)
I read position (dwm_pos_get) every 120mS
it works fine during 1h10 …1h30 and after that it c’ant communicate anymore on SPI; it always return 0x00 datas even after a sofware reset;
I’ve verified with oscilloscope that signal from rasperry are still good
On the ANDROID API the Tag appears frozen
I’ve tried a rasperry Pi zero and even a raspberry Pi3B+ too
I’ve also tried with new raspbian
I’ve tried to reduce SPI speed to 250KHz
Any idea?
With a reading every 500mS on SPI, I find it can work fine along 10h00 and perhaps more
but I need faster.
I’ve also tried with UART port to compare, with reading every 120mS but the behavior is the same than with the SPI.
In details, it can work fine 90min sometimes 120min and it begins to stop about 3…10seconds and it can works fine again by 30 minutes (sometimes less or more) and repeat like this a few times and a moment later stop to work definitively.
I noticed, just by writing a new configuration (just by putting LED off or ON for example) with Andoid API, it begins to work fine again…
I’ve also tried with a DWM1001 module with the same behavior
But I need something to work fine all the time.
I suspect it can’t work so fast but if you want to drive a moving robot for example, it is really a problem
long ago I gave myself the task of passing the gateway rpi to an orange pi.
I had identical problems to the ones you mention, first I thought it was a defect in the orange pi, so I did tests in an rpi, but the problem would be exactly the same “after a few hours it stops receiving data by spi”.
In short I solved it, but the solution is not simple.
The loss of communication is due to the fact that Linux is not a real time system, there are two totally different spaces, the user space and the kernel space.
The problem lies in the use of libraries to access the spi module.
I tried with c, c++, java and pytho, I always lost connection after a time.
The solution is to create your own kernel module to access the spi module, this implies natively managing the registers corresponding to the spi.
Writing a kernel module can be a real challenge if you do not have a broad understanding of how the kernel works Linux, electronics and microcontroller programming.
I wrote my kernel module for orange pi with h3 processor and solved the loss of communication problem.
I did not test with rpi because it involved double work and my objective was the module for orange pi.
As I planed last time, I wrote a program to read localization from tag DWM1001 with a PIC16F877 in SPI mode with a loop polling every 110mS.
About one hour later the tag don’t answer anymore. and I have to drive a hard RESET from the tag with the program and it begin to work again; but after 3…5 RESET the tag lose the network…
This is a big unreliability from that tag.
Finally I solve the problem by working with reading the ready pin with interrupt on loc_ready and spi_data_ready.
It’s the only way to work fine all the time.
I think datasheet should be more precise about ready timing in TLV communication.
I’m quite disappointed with decawave’s lack of interest in this post.
To resume don’t use polling in SPI or UART mode it will crash the tag; only use data ready pin
Didier
Hello
The truth is that I only use interruptions for efficiency reasons, but what you say can be given to the mechanism for recovering communication errors, in reality the module is not blocked, only that it is waiting for the synchronization to send data, as it does not receive the frame If any command you send is not recognized, I recommend checking the document DWM1001-API-Guide.pdf in section 3.2.6