• State Verified Answer
  • Locked Locked
  • Replies 10 replies
  • Subscribers 67 subscribers
  • Views 5764 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 100830
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Broadcaster/observer low level implementation

Paulo Borges

In one of my current projects, I need:

  • to have access to more than 8 kB of RAM (which is not possible when using SoftDevice)
  • to have Observer role (which apparently is not implemented in SoftDevice)

Since I don't use any other functionality from the SoftDevice, I decided to implement the Observer and to reimplement the Broadcaster roles. After reading the specification Bluetooth Low Energy Link Layer and nRF51822 RADIO specification I developed a little firmware that makes passive scanning in the advertise channels 37, 38 and 39 using a 1 second scanWindow and 2 seconds scanInterval.

To evaluate my implementation I put BlueZ 5.x to do advertising and I checked with another BlueZ 5.x if the advertising is correct. Then I put my firmware (source code attached) to run. Although the packet are apparently received, their contents are wrong (check the attached log):

  • received packets are different in each channel
  • CRC check fails
  • invalid header fields (PDU type, TxAdd, RxAdd, ...)
  • invalid payload (it doesn't contains the advertiser address 00:1B:DC:05:4B:DF)

I tried to put a lot of comments in the source file but english is not my first language, so I apologize in advance for any linguistic mistake.

What can I do to fix my firmware?

log.txt

main.c

Parents
  • FormerMember
    0 FormerMember

    Paulo, I guess at some point of time you were wondering why the third byte in there received data is always 0. Did you figure out why? While playing around I found that your configuration of PCNF0 wasn't correct, because you assumed wrong endianness. Here's the fix. [code type="xml"] /* Configure header size. * * The Advertise has the following format: * RxAdd(1b) | TxAdd(1b) | RFU(2b) | PDU Type(4b) | RFU(2b) | Length(6b) * * And the nRF51822 RADIO packet has the following format * (directly editable fields): * S0 (0/1 bytes) | LENGTH ([0, 8] bits) | S1 ([0, 8] bits) * * We can match those fields with the Link Layer fields: * S0 (1 byte) --> PDU Type(4bits)|RFU(2bits)|TxAdd(1bit)|RxAdd(1bit) * LENGTH (6 bits) --> Length(6bits) * S1 (0 bits) --> S1(0bits) / NRF_RADIO->PCNF0 |= (1 << RADIO_PCNF0_S0LEN_Pos) | / 1 byte / (8 << RADIO_PCNF0_LFLEN_Pos) | / 6 bits / (0 << RADIO_PCNF0_S1LEN_Pos); / 2 bits */ [/code]

Reply
  • FormerMember
    0 FormerMember

    Paulo, I guess at some point of time you were wondering why the third byte in there received data is always 0. Did you figure out why? While playing around I found that your configuration of PCNF0 wasn't correct, because you assumed wrong endianness. Here's the fix. [code type="xml"] /* Configure header size. * * The Advertise has the following format: * RxAdd(1b) | TxAdd(1b) | RFU(2b) | PDU Type(4b) | RFU(2b) | Length(6b) * * And the nRF51822 RADIO packet has the following format * (directly editable fields): * S0 (0/1 bytes) | LENGTH ([0, 8] bits) | S1 ([0, 8] bits) * * We can match those fields with the Link Layer fields: * S0 (1 byte) --> PDU Type(4bits)|RFU(2bits)|TxAdd(1bit)|RxAdd(1bit) * LENGTH (6 bits) --> Length(6bits) * S1 (0 bits) --> S1(0bits) / NRF_RADIO->PCNF0 |= (1 << RADIO_PCNF0_S0LEN_Pos) | / 1 byte / (8 << RADIO_PCNF0_LFLEN_Pos) | / 6 bits / (0 << RADIO_PCNF0_S1LEN_Pos); / 2 bits */ [/code]

Children
No Data
Related