I check the lps-node-firmware code, find the spi speed is 3M clcok, according to the dw1000 spec, when the the speed may reach 20MHZ.
the dw1000 user manual record the following:
In the IDLE state the DW1000 internal clock generator CLKPLL is locked running and
ready for use but is gated off to most circuitry to minimize power consumption. In the
IDLE state SPI communications can operate at up to 20 MHz, the maximum SPICLK
frequency.
so we maybe try the 20M clock? or faster than 3MHZ?
Yes there is a lot of optimisation possible there. The node already has double speed, a slow and a fast one. It is setup there: https://github.com/bitcraze/lps-node-fi ... #L139-L146. The fast speed is "only" 12MHz because it has to be an integer division of the CPU clock and the CPU is currently running at 48MHz. Maybe we could try 24MHz or reducing a bit the CPU clock. Though I did not see much improvement with faster SPI and I suspect it comes from the interrupt handling: we might need DMA.
Mike Hamer actually solved it in his crazyflie firmware fork: he implemented the SPI with DMA and with fast speed (21MHz). I have just merged the pull request from mike so thanks to him this is now fixed on the copter. We just need to do the same on the node .
The next subject on SPI though is the efficiency of the driver: I feel the current DW1000 driver is not optimized and might be communicating more than necessary which can limit the ranging speed.
Got it.Thanka!
I have already measure the time of a successful distance between tag and anchor, about 4~5ms. I will try 12MHZ spi speed. test code and research the DMA transmit for spi for improving the time.
Addition, I try the crazyflie-firmware dwm1000 code, force mount the dwm1000 deck board with 6 anchors, and throught ROS display the position, but the ROS don't any action. where config have some problem? the post: viewtopic.php?f=6&t=2072
Just an update, I did some more investigation on the ranging speed situation:
I measured the ranging time from node-to-node to be about 3.3ms (this is the time for the 4 packets between the POLL packet is sent until the REPORT packet is received).
By reorganizing a bit the code: by putting the receive time reading and calculation after sending an answer, I could reduce this time to 2.5ms.
I tried to play with SPI speed without success (I went to 24MHz SPI speed, it works but I could not observe any noticeable change in ranging time). So I figured that we are CPU-bound and we are compiling the node without any optimisation. By enabling optimisation (-O3) I am down to 1.7ms per ranging.
This means that we go from ~300Hz ranging rate up to ~575Hz, for 6 anchors it is almost 100Hz ranging on the system.
I just pushed the changes. It seems that the SPI speed is still not the limiting factor: I can go down to 1.3ms if I put the last receive time under the transmission: https://github.com/bitcraze/lps-node-fi ... ain.c#L235. The DW1000 allows to start transmitting before setting the data but we need to make sure the time is well calculated first.
So cool, I will try it. Thank you for your effort! we can get more distances per seconds.
I have added lock anchor code for support more tags rather than only one tag with 6 anchors.
when the code stable, I will source the code for you.
and add get distance frequence, more easily filter and support more tags.
another a problem, about time 3.3ms, 2.5ms or 1.3ms, do you measure the time between node and node?
These measurement comes from this line: https://github.com/bitcraze/lps-node-fi ... ain.c#L320 so it is measured with the node DWM1000 timer. I took them from node to node but since then I have tested Crazyflie to node and I get similar results.
Nice for multiple tag, how are your synchronizing the different tag so that they do not range all at the same time?
about measure time, Got it!
I don't sync tags, instead lock anchor, two points:
1, when one tag and anchor ranging, lock the anchor, block range with other tag. when ranging complete, unlock the anchor.
2, from the anchors rxcallback function see, I feel any poll will enter the function, then through address to judge whether belong to its information. I add MAC filter condition with address to filter out unmatched package. this will avoid anchor too often to enter rxcallback. for example, the mode and address as follow:
(1)tag 0 and 9;
(2)anchor 1,2,3,4
tag 0 rangeing with anchor1, lock anchor1, when tag 9 also will range with anchor1, because ancho1 be locked, so anchor1 don't return package. because we range time about ~3ms normally, so tag 9 can wait 3ms no any anchor1 reponse, tag 9 will range with anchor2.
I have already test 4 tags with 6 anchors over night, no any problem, only one whole range with 6 anchors, maybe less range data with someone anchor.
but the next sencond/third should be get loss range. I feel taht select the wait time is important, need simulation to select best wait time to avoid conflict.
.