whether the TDOA2 mode supports remote Settings of the base station

[cqutyoulang]

I can do it witch the tdoa3 model, but the tdoa2 model doesn't work. But I saw the LPP data section in the tdoa2 source code.

[krichardsson]

Yes, TDoA2 also supports setting anchor positions from the Crazyflie (same functionality as TDoA3)

[cqutyoulang]

hi ：
I tried to use the TDOA2 algorithm on the tag to send LPP packets with remote configuration ANCHOR coordinates.LPP packets cannot be received using TDAO2 algorithm on ANCHOR. However, I modified the algorithm on ANCHOR to the TDAO3 algorithm, so that the LPP packets sent by the TDAO2 tag could be well received. So, I have a few questions, can you help me answer, thank you.

1. I guess whether TDOA3 ANCHOR can receive the LPP short packet sent by TDAO2 tag because TDAO3 ANCHOR is in the receiving state most of the time.However, the TDAO2 ANCHOR has a strict time gap, when the TDAO2 tag sends the LPP packet, it happens that the TDAO2 ANCHOR is not in the receiving state, so it cannot receive.I directly transplanted the open source code of bitcrazy. It should be feasible to configure TDAO2 ANCHOR with TDAO2 tag, but I am very confused why not.

2. In question 1, in TDAO2 mode, I only have 3 anchors, which are 0, 1 and 2 respectively, but the program supports 8 anchors. May I ask if I have 3 anchors, will it affect my tag to configure the coordinates of anchors through TDAO2 algorithm?

3. On the issue of time synchronization between TDOA2 anchors, I did not understand the principle of time synchronization by reading the source code. Is there any related materials that I can refer to?

4. At present, TDOA2 is wireless synchronization between Anchors. If UWB wired synchronization is adopted, will the effect be much better than wireless synchronization?

5. In TDAO2 for timestamp assignment, there is such a code
   ctx.tdmaFrameStart.full = TDMA_LAST_FRAME(ctx.tdmaFrameStart.full) + 2*TDMA_FRAME_LEN;
   Why is *2 needed? How should we understand the allocation of this period of time? Is there any specific information for reference about the scheduling of TDAO2's timestamp?

Yes, I have a lot of questions. If possible, I would appreciate your help. I watched the source code for 5 days in a row and was still confused.

[cqutyoulang]

hello i am a uwb lover. According to the open source code, I transplanted the code of the UWB base station and tag in TDOA released in September 2019, and run it on the dw1000 chip, I did not transplant the code of the latest master branch.
I found that under the TDOA3 algorithm, the tag can realize the remote configuration of the coordinate data of the TDOA3 base station by calling lpsSendLppShort().
However, under the TDOA2 algorithm, I can't remotely configure the TDOA2 base station coordinate data by calling lpsSendLppShort(). What may be the reason why the base station cannot be remotely configured.

Then I compared the processing of LPP packets by TDOA2 and TDOA3 in onEvent(),
By modifying the LPP sending method of the tag under TDAO2, it is modified to detect and send an LPP packet once every onEvent event similar to TDOA3. Call the lpsSendLppShort function more than 100 times within 1s, so that the configuration can sometimes be successful once.

[knmcguire]

I'm transferring this issue to disscussions, as this is a question

[krichardsson]

The receiving functionaliy of TDoA2 and 3 is pretty much the same and should work fine.

You might have timing problems, get collisions and lose packets? In the Crazyflie firmware we transmit this data just after we received a packet from an anchor. This is a good time to transmit due to the timing of the system.

Another problem might be that the transmission power in the CF is a bit low. You can try to move closer to the anchor, but this should not be different from TDoA3.

[cqutyoulang]

I added a piece of code here link in the TDOA2 ACHOR, set the DW1000 to the receiving state, and then successfully received the LPP data packets sent by the TDOA2 tag. But I don't know if this will affect the operation of the system.
The added code is as follows:
else if (event == eventPacketSent) { deNewReceive(dev); dwSetDefaults(dev); dwStartReceive(dev); }

[krichardsson]

I don't think it will do any harm, but it is weird that it does not work without it

[cqutyoulang]

I tested it again, and the actual solution to the problem is to set a delay of about 200us in the following piece of code. for example:
else if (event == eventPacketSent) { delay_us(200); deNewReceive(dev); dwSetDefaults(dev); dwStartReceive(dev); }
I don't understand why a delay needs to be added here. In the TDAO2 ANCHOR source code, this piece of code is missing.

[cqutyoulang]

I found another interesting phenomenon, I modified the parameter of the time of receiving timeout after sending a packet. Here link in the code. Modify it to:
#define RECEIVE_SERVICE_TIMEOUT 1000

And the link is modified to:
else if (event == eventPacketSent) { deNewReceive(dev); dwSetDefaults(dev); dwStartReceive(dev); }

In the case of no delay, it is also possible to receive the LPP short packet data sent by the label.
It is 800 according to what is set, not other values.

[krichardsson]

I must admit that I'm not fully following what you are doing and the exact cause of your problems :-)

As far as I remember, the DW1000 is sensitive to timing and there are cases where delays are required, for instance when switching between rx and tx. The best source for information on this is Decawave's documentation on the DW1000 chip.

But if it working I guess everything is fine :-)