LAUNCHXL-CC2640R2: AoA PDU data

Andy Yang78

According to following link,

http://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_2_20_00_49/docs/blestack/ble_user_guide/html/localization/index.html

In order to get a good estimate of ϕ (phase), all other intentional phase shifts in the signal should be removed. AoA packets (based on the BLE PHY) achieve this by adding a section of consecutive 1’s as part of the PDU, effectively transmitting a single tone at the carrier frequency of 250kHz.

When we use sniffer to capture the TI sender AoA PDU, the packet data isn't section of consecutive 1’s.

1. Is there a explanation of this behavior?

2. What are the usage/porpose of those non consecutive 1’s packet data?

3. How to generate those data for the TI AoA receiver?

4. If we sent a section of consecutive 1’s PDU as following to TI AoA receiver, Will the TI receiver collect correct I/Q samples and estimate the precise angle?

0x1E, 0xFF, 0x0D, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF

over 6 years ago

0 Evan W over 6 years ago

TI__Mastermind 39620 points

Hi,

I see a very long amount of consecutive ones in the example packet that you've provided. The beginning of the packet is identified via aoa header padding and ton info along with the TI Company ID and then the AOA Tone via 0xFF.

To question 4, unless I'm misunderstanding your question, this is what it is currently doing.

In AoA.c you can find the source code for how this packet is constructed.

static void transmitterInitAdvData(uint8_t *advData, uint8_t packetId)
{
    // Initialize header
    advData[0] = AOA_ADV_HDR_LEN + AOA_ADV_PADDING_LEN + AOA_ADV_TONE_LEN;
    advData[1] = 0xFF;
    advData[2] = (COMPANY_ID_TEXAS_INSTRUMENTS & 0xFF);     // TI Company ID
    advData[3] = (COMPANY_ID_TEXAS_INSTRUMENTS >> 8);       // TI Company ID
    advData[4] = packetId;   // Packet ID, for receiver to filter

    for (uint8_t i = AOA_ADV_TONE_OFFSET; i < AOA_ADV_LEN; i++)
    {
      advData[i] = 0xFF;    // DF_extension, first 2 bytes are still for padding
    }
}

0 Andy Yang78 over 6 years ago in reply to Evan W

Intellectual 380 points

Hello

Yes, for my understanding, I think the following example packet should be the correct one.
0x1E, 0xFF, 0x0D, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
So, just double confirm, the example packet above should be the one TI AoA sender sends to TI AoA receiver, is it correct?

But the packet we collect by sniffer/wirshark is "non consecutive 1’s packet" and the value of last 20 bytes of PDU different for every single advertised PDU.
This is why I asked the question 1 ~3.
1. Is there a explanation of this behavior?
2. What are the usage/porpose of those "non consecutive 1’s packet" data?
3. How to generate those "non consecutive 1’s packet" data for the TI AoA receiver?

[Following is the wireshark log for TI AoA sender]
Frame 10967: 63 bytes on wire (504 bits), 63 bytes captured (504 bits) on interface 0
Nordic BLE Sniffer
Bluetooth Low Energy Link Layer
Access Address: 0x8e89bed6
Packet Header: 0x2502 (PDU Type: ADV_NONCONN_IND, ChSel: #1, TxAdd: Public)
Advertising Address: TexasIns_83:3e:7a (54:6c:0e:83:3e:7a)
Advertising Data
Manufacturer Specific
Length: 30
Type: Manufacturer Specific (0xff)
Company ID: Texas Instruments Inc. (0x000d)
Data: 040105000000002f61accc274567f7db34c4038e5c0baa97...
CRC: 0x010295

0 Evan W over 6 years ago in reply to Andy Yang78

TI__Mastermind 39620 points

Hi Andy,

I can see what you're seeing as well. Allow me to look into this a bit.

0 Evan W over 6 years ago in reply to Evan W

TI__Mastermind 39620 points

Hi Andy,

I actually realized why you see this. So, since this AoA packet is a proprietary packet, in order to get around the BLE devices whitening the data, the AoA sender and AoA receiver use the RF commands at the lowest level without passing it through the data whittening portion of our BLE Stack. So, when a sniffer sees the 0xFF tone over the area, the sniffer will try to decode it and de-whiten the data which is then what you see in your sniffer log. The tone cannot be sniffed since it's a non-whitened transmission and in that sense does not follow the BLE spec.

0 Andy Yang78 over 6 years ago in reply to Evan W

Intellectual 380 points

Hello Evan

Thank you for the reply.

Assume the behavior we observed is cause by "TI sender disable whitening encode" and "sniffer receiver enable whitening decode".

We do the following test.

We tried to enable the sender whitening by edit following file in RED and sinffer receiver still output "non consecutive 1’s packet data".

1. According to our assumption, once we enable the TI sender whitening, the sniffer receiver should output consecutive 0xFF, isn't it?

2. Is any suggestion for how to check the whitening is enabled or disabled?

aoa_sender_cc2640r2lp_app

AoA.c

// CMD_BLE_Advertisor
rfc_CMD_BLE_ADV_NC_t RF_cmdBleAdvNc =
{
.commandNo = CMD_BLE_ADV_NC,
.status = 0x0000,
.pNextOp = 0, // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
.startTime = 0x00000000,
.startTrigger.triggerType = 0x0,
.startTrigger.bEnaCmd = 0x0,
.startTrigger.triggerNo = 0x0,
.startTrigger.pastTrig = 0x0,
.condition.rule = 0x1,
.condition.nSkip = 0x0,
.channel = 37,
.whitening = 1,
.pParams = &RF_bleAdvPar,
.pOutput = NULL,
};

0 Evan W over 6 years ago in reply to Andy Yang78

TI__Mastermind 39620 points

Hi,

The RF driver is dynamically turning whitening at on and off at other points in the program. However, we do not recommend turning whitening on for this solution because it will not be able to detect the constant tone and run the AoA algorithm.

We are sure that a constant tone is being emitted and therefore the packets are all 0xFF for the tone portion of the advertisement. Can you inform me why you want to test this stuff?

0 Andy Yang78 over 6 years ago in reply to Evan W

Intellectual 380 points

Hello Evan
There are two purposes for enable the whitening so far.
1. We may add customized data in the future. Since we are using "whitening enable" sniffer to check the PDU, we may need to enable whitening on the sender as well in order to check the PDU correctness.
2. Since the angle we get from the TI AoA receiver isn't precise, we will like to check all possible factors, such as PDU, multipath etc.

Therefore,
Is it possible for us to enable the whitening for the TI AoA sender?
or
Is there any method for us to check the "non-whitening" PDU from the sender? We tried to check PDU with the nordic sniffer and tablet/smart phone with beacon app installed, all whitening decode. Unable to skip the whitening decode apart and provide the "non-whitening" PDU check.

Regards,
Andy

0 Evan W over 6 years ago in reply to Andy Yang78

TI__Mastermind 39620 points

Hi Andy,

I can assure you that the PDU if you've not adjusted the transmitterInitAdvData function, is accurate. I would look at multipath and other potential causes. When yous ay they aren't precise, can you describe your setup, what your expectations are and what you're receiving in results?

For instance, how many antennas are you using? How many arrays?

Have you followed a few workarounds that were listed in this post related to SDK 2.30? e2e.ti.com/.../737944

0 Evan W over 6 years ago in reply to Evan W

TI__Mastermind 39620 points

Closing thread due to inactivity.

Bluetooth®︎

Bluetooth forum

LAUNCHXL-CC2640R2: AoA PDU data