• State Verified Answer
  • Locked Locked
  • Replies 10 replies
  • Subscribers 67 subscribers
  • Views 5761 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

  • 0 in reply to Arnaud Waels

    This is really the complete opposite question than here, so it would have much better off separately. However, you may have use in taking a look at the packet configuration in the example here, as that would be very similar for an advertiser. In addition, I'd recommend you to read the RADIO chapter of the nRF51 Reference Manual thoroughly, read the appropriate parts of the Core Specification, primarily Volume 3, Part C, section 9.1 and 11, and Volume 6, Part B, section 2.3 and 4.4, and take a look at the radio_example in the SDK, as well as this here. What you plan to do isn't trivial, but should be perfectly doable if you read up a little first.

    If you have any further, specific questions, I'd recommend you to post them separately.

  • 0 in reply to Arnaud Waels

    Yes i agree it's the opposite as here. I'm conscious low level is not trivial ! Thank you for those detailed links to doc.

  • 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]

  • 0

    /LENGTH (6 bits) --> Length(6bits)/ NRF_RADIO->PCNF0 |= (1 << RADIO_PCNF0_S0LEN_Pos) | / * 1 byte / (8 << RADIO_PCNF0_LFLEN_Pos) | / 6 bits / (0 << RADIO_PCNF0_S1LEN_Pos); / 2 bits */ 1)why you set 8 to RADIO_PCNF0_LFLEN_Pos, not 6?

Related