• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 52 subscribers
  • Views 1244 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Sniffing cc2650's Advertising: preamble == 0x2D

FrankS
Intellectual 440 points
Other Parts Discussed in Thread: CC2650

We're using a TI CC2540EMK-USB dongle for sniffing what is going on on the BLE radio interface when working with cc2650.

When looking at the Advertising we see the Access Address as expected (0x8E89BED6). Looking at the octet right in front of it, I expect to see the Preamble as 0x55 or 0xAA according to Core_v4.2.pdf. But the sniffer's GUI is displaying 0x2D instead. Everything else in the Advertising packet we can account for.

Does anyone have an idea what is going on?

Many thanks in advance!

-- Frank.

  • 0
    TI__Mastermind 34660 points
    Hi Frank. Is this preamble part of the advertising payload or a header added by a lower layer of the stack? Can you post a screen shot to accompany this?
  • 0 in reply to Tim C
    Intellectual 440 points

    Hi Tim,


    please find the requested screen shot attached.

    It has been produced with TI software that comes with the said USB dongle. Below is my interpretation, please do let me know what you think of it.

    Thanks.

    -- Frank.

    Field 'Length' is as expected: 2e 00

    Field 'Packet data'

    • 2D is where I've been expecting the Preamble 0x55 or 0xaa
    • D6 BE 89 8E is Access Address, a constant from Core Spec 0x8E89BED6
    • 00 22 seems to be Adv PDU Type and Adv PDU header
    • 04 55 FB 8F C3 20 is the AdvAddress

  • 0 in reply to FrankS
    TI__Genius 10955 points
    I believe this must be a length field, used internally in the packet sniffer. The packet sniffer does not really receive the preamble; as any other BLE receiver, it uses it for synchronization purposes.
  • 0 in reply to hec
    Intellectual 440 points

    Hi hec,

    thanks for your reply.

    But I'm not convinced (yet). Let's assume it is a length field, then the question is: What length field, and where is it defined?

    The book I take information from (Bluetooth Low Energy --  The Developer's Handbook' by Robin Heydon) explains in ch. 7.3 Packet Structure

    • 8 bits Preamble
    • 32 bits Access Address
    • 8 bits Header
    • 8 bits Length
    • 0 .. 296 bits Data
    • 24 bits CRC

    Same definition in Core_v4.2.pdf, vol. 6, ch.2 Air Interface Packets, fig. 2.1.

    Quite everything in my sniffer's output is spot on, except for the octet preceding the Access Address.

  • 0 in reply to FrankS
    TI__Expert 4470 points

    Hi,

    It is correct as was mentioned that this is a length byte added by the Packet Sniffer and used internally. This byte is not sent over air.  It holds the length of the data that follows it.

    Regards,

    Bjørn

     

  • 0 in reply to Bjørn
    TI__Mastermind 34660 points

    Thanks Bjørn. Please see the SmartRF Packet Sniffer User Manual for more information: http://www.ti.com/lit/ug/swru187g/swru187g.pdf