traditional TDoA

All discussions related to the Loco Positioning system
Post Reply
justinleeyang
Expert
Posts: 184
Joined: Mon Dec 28, 2015 5:07 am

traditional TDoA

Post by justinleeyang » Mon Feb 13, 2017 3:24 pm

Hi, arnaud:

Sometimes, we need transmit the position to the server, but our crazyflie2 only transmit the data with radio.
can lps system keep some slot time for tag upload the position data to anchor x ?
and the anchor x transmit the position to server throught UDP/TCP.

or I also see the traditional TDoA as following, http://www.sewio.net/rtls-tdoa/technolo ... f-arrival/
xxxxxx.png
if realize it, Please provide some advice.



arnaud
Bitcraze
Posts: 2275
Joined: Tue Feb 06, 2007 12:36 pm

Re: traditional TDoA

Post by arnaud » Tue Feb 14, 2017 8:05 am

Yes it would be possible to allows the Crazyflie 2 to upload some data, though it requires reprogramming the TDoA algorithm in the Crazyflie. As you suggest it should be possible to allocate some timeslots to the Crazyflies, during these timeslots the crazyflies will be able to send data to the anchor system.

The drawing you are sending look more like an asset tracking setup where the tag is typically battery powered and sends "blinks" at random 'large' intervals. This should be possible with the LPS hardware but requires to write the algorithm for it. If you want to keep the kalman filter this is also not the best solution (the tag in that case do not get the position).

For TCP/UDP there is not support for it in the nodes but we have cabled the expansion connector (between the button) to be compatible with common ESP8266 wifi breakout board, the idea with it was to be able to connect the anchor system to the network using Wifi. The nodes can also be connected to a raspberry pi or something similar.

justinleeyang
Expert
Posts: 184
Joined: Mon Dec 28, 2015 5:07 am

Re: traditional TDoA

Post by justinleeyang » Wed Feb 15, 2017 2:55 am

hi, arnaud:

I have an idea, if we have 4 anchors and n tags:
set the NSLOTS=8, so 4 anchors only need 4 slot, and other 4 slot allocate the n tags to upload data.
or if system have more tag, we can set the NSLOTS=16, 12 slots provide enough time for upload data.
I worry about that if two tags or more upload the data at the same time, will generate conflict. no like zigbee, it have the CSMA/CA(Carrier Sense Multiple Access with Collision Avoidance). about uwb avoid conflict, welcome more suggestions.

arnaud
Bitcraze
Posts: 2275
Joined: Tue Feb 06, 2007 12:36 pm

Re: traditional TDoA

Post by arnaud » Wed Feb 15, 2017 8:56 am

Hi,

Your idea will work, I was thinking about doing the same thing instead of TWR TDoA: it would allow to have TWR that scales much better than with the current TDoA.

As far as I understand CSMA/CA will not work with UWB: the UWB radio cannot sense input power from another UWB signal since the signal can be bellow the noise floor (which is cool! :)). The reception is done by doing a cross-correlation of the preamble with the air.

One alternative way would be to distribute slot to anchor: if the tag do not need to send data on all frame, they could send data on every second frame or even less, this means that in the case of 4 anchor and 8 slot, the 4 data slot are used by different anchors each frame.

Another interesting characteristic of UWB is that there is orthogonal preamble: if two anchors are set to different preamble, they can communicate in the same timeslot without interference. This is not so useful for the 4 anchors slots, but for sending back data to the anchors it means that you can send 4 packets to 4 anchors per timeslot.

justinleeyang
Expert
Posts: 184
Joined: Mon Dec 28, 2015 5:07 am

Re: traditional TDoA

Post by justinleeyang » Wed Feb 15, 2017 11:09 am

hi, arnaud:

One alternative way would be to distribute slot to anchor: if the tag do not need to send data on all frame, they could send data on every second frame or even less, this means that in the case of 4 anchor and 8 slot, the 4 data slot are used by different anchors each frame.

my understand is that every frame have 8 slot, anchor0 still sync other anchor x in every frame, but tag don't need transmit data in every frame, so reduce the tag upload data fraquence. avoid the conflict. right ? but why the 4 data slot are used by different anchors each frame ? I don't understand your mean.

Another interesting characteristic of UWB is that there is orthogonal preamble: if two anchors are set to different preamble, they can communicate in the same timeslot without interference. This is not so useful for the 4 anchors slots, but for sending back data to the anchors it means that you can send 4 packets to 4 anchors per timeslot.

so if two groups system, tag0 and anchor1 set the preamble code is PREAMBLE_CODE_64MHZ_9, another group tag7 and anchor2 set the preamble code is PREAMBLE_CODE_64MHZ_12, they can communicate without interference ? but the peramble code only the following 20 groups,
xxxxxxxxxxxxx.png
xxxxxxxxxxxxx.png (19.96 KiB) Viewed 2233 times
if I have 1000 tags, always generate the conflict.

arnaud
Bitcraze
Posts: 2275
Joined: Tue Feb 06, 2007 12:36 pm

Re: traditional TDoA

Post by arnaud » Wed Feb 15, 2017 12:12 pm

Hi Justin,

For the slot I meant that the anchor could use one slot in each frame, the tags could use only one slot per seconds or something like that. This way there is much more possible slot for the tag to use.

For the preamble you will just multiply by 4 the possible bandwidth (you can only use 4 different channel/preamble for your 4 anchors). So it helps a little bit the scaling.

However it all depends of your use-case and your scale: if you need to locate 1000 tag at the edge (typical asset tracking) then having the tag pinging feels like a much better option, unless you also want to use the kalman filter.

Post Reply