• State Verified Answer
  • Replies 1 reply
  • Subscribers 69 subscribers
  • Views 31 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 338777
Options

Low level Bluetooth packet Output

AMarch01

I have a packet that I am sending out using the nrf52840. Using another piece of code supplied by Emil Lenngren, information from the solar_sensor_beacon project and raw data from the beacon project (the old one using Eddystone format).

The beacon project works fine, I can see the output on my simple receiver. An old ubertooth scanner can see it fine. The nrf Connect phone application can see it without issue. 

So that is my starting point. I stopped the beacon code inside the debugger to extract the in-memory configuration of the outgoing packet. I sort of re-worked it to create the following

uint8_t AdvertisementNordic[] = {
//    0x46, /* HEADER - ADV_NONCONN_IND PDU  - TXAdd = 1*/

    0x42, /* HEADER - ADV_NONCONN_IND PDU  - TXAdd = 1*/
    0x1F, /* HEADER - length of packet - ? */
    /* payload follows - below bt_data ad[] example */
    /* AdvA  - 6 bytes of address - made this up */
    0xf3,0x86,0x91,0x5c,0x88,0xF3,
    /* AdvData*/
    0x02, /* AD Struct - Length  */ /* Length-Type-Value (LTV) format*/
    0x01, /* AD Struct - Flags */
    0x04, /* AD STruct - Flags - BR/EDR Not Supported */

    0x03, /* AD Struct - Length  */
    0x03, /* BT_DATA_UUID16_ALL */
    0xaa, /* data */
    0xf3, /* data */

    0x11, /* AD Struct - Length */
    0x16, /* BT_DATA_SVC_DATA16 */
    0xaa, 0xfe, /* Eddystone UUID */
    0x10, /* Eddystone-URL frame type */
    0x00, /* Calibrated Tx power at 0m */
    0x01, /* URL Scheme Prefix https://www. */
    'n','o','r','d','i','c','s','e','m','i',
    0x00 /* .com */

};

I then setup for standard a standard BLE Output and start sending the packet every 100ms (read someplace that non connectable advertisements shouldn't be sent faster than 100ms). 


  • My low-level receiver seems to capture it, the CRC is correct at least. The receiver is picking up all kinds of packets as well, so it can see other correct advertising packets. The fact that the receiver code can receive the advertisement isn't so hard to understand since the receiver is configured identically as the sender.
  • My old ubertooth can detect it appropriately and identify it as an advertisement.
  • The nrf Connect phone app never sees it. 

My question is, if the nordic radio is configured properly as BLE 1mhz sender and it transmitted a simple binary packet that looked like an advertising packet, then the nrfConnect for phone application should see it, correct? There isn't some other magic in transmit that need to occur for the application to display it?

This is my crappy sensor beacon test code.
 sensor_beacon.zip

  • +1

    I went ahead and started converting the solar sensor radio example into a simple zephyr workspace.

    After powering it up and making an attempt to get it to work, it showed up on the nRF Connect phone app without issue. 
    That is how I knew it COULD be done.

    Then I went and looked at my other mess of code and realized I was off by an order of magnitude on sending rate. Changed it and my original data showed up on nRF Connect. 

    So yes, you can send a packet of advertising data through the radio without any other BLE library stuff (except all the nice defines for the values). It isn't smart. It isn't compliant. 
    This adventure gave me some clear insight on the operation of the Nordic RADIO peripheral. I am not sure, but it is probably all moot after the release of the nRF54. 

    I put the stuff I cobbled together in the original post. Might be fun for someone learning stuff about the radio. only works on the nrf52840-dk

Related