• State Not Answered
  • Replies 3 replies
  • Subscribers 25 subscribers
  • Views 160 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 289217
Options
nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs

Fastest/Smallest/Shortest BLE5 data exchange

user116227

Hi all,

It's my first post here so hello everybody! Slight smile

I'm quite new in BLE5, but I have been playing with BLE4 some years ago (around 12) and I want to confirm some information with somebody who knows BLE5 better than me.

In my project (some kind of "smart gardening") I want to use nRF52805 as sensor nodes (battery powered) and some other nRF528xx as central (with power supply).

Every node will need to exchange some data (around 30 bytes) with central every 10minutes. To make whole system more deterministic I want to use central with direct advertising and every node will know when to wake up and start scanning ("sleep for around 599s and wake up for around 1s").

Central will establish connection with node, exchange data, disconnect and start direct advertising to the next node. If I would know how fast data exchange can be executed, I would know how many nodes I can handle every X minutes. I could you only one advertisement channel to shorten establishing connection time

My question here is how short/fast this connection can be. Please correct me if I'm wrong but whole transmission "log" would look like this:

Central: ADV_DIRECT_IND  to #1 node  - how much it may take? 1B preamble + 4B Access-Address + 2B header + 6B AdvertiserAddress + 6B TargetAddress + 3B CRC? 22 Bytes in total?

Node: CONNECT_IND - can be send first direct advertise packet with T_IFS 150us time? This frame contains connection configuration, right?

Central: 1# data frame - "hi node, gimme some this specific data"

Node: 2# data frame - "ok, here's my data"

Central: 3# data frame - "That's all,disconnect and go to sleep for next X seconds" - I couldn't found disconnecting command I assume sensor can go immediately to sleep and central can just "destroy" connection in SW(?)

Central: ADV_DIRECT_IND to #2 node

and so on.

I don't want to use whole discovery services procedure, I would like to use my own kind of data since sensors will be connected only with specific central. I could use node as advertiser but I want to have place to put some additional commands like "go to sleep this time for 10 hours" or "give me your FW CRC value".

I would really appreciate for help!

  • 0

    Hi,

    It will be the sensor node that does the advertising and be the peripheral. And the central will do the scanning. Also you cannot assume that the scanner will find the first advertising packet, depending on scan interval and scan window, it might take a few packets.

    But if the central knows the GATT attribute handles for the characteristic, and don't do the service discovery each time, then from the first connection event, until the data is sent, and the link is disconnected, it should only take a few connection events. The total time the devices are connected will then be connection_interval(can be as low as 7.5ms) x #connection_events_needed.

    I could use node as advertiser but I want to have place to put some additional commands like "go to sleep this time for 10 hours" or "give me your FW CRC value".

    I don't see anything wrong in your approach, but just having the nodes as advertisers, and skip connecting to them, would be simpler. You can also put data in the scan-response packet.

  • 0

    Hi,

    thanks for reply. You're right, sensors as advertisers is simpler to develop solution, but I would like to avoid showing to somebody in close distance with BT scanner/sniffer huge amount of sensors.

    Also can I create in the sensor's FW whitelist for scan requesters and/or separated whitelists for Initiatiors and scan requesters? ("For this addresses I'll send SCAN_RSP, for everything else I don't"). If somebody with Android/iOS phone will start scanning and my sensors will not respond for SCAN_REQ, then sensors will not appear on the phone's devices list, right?

    I see that sequence like :

    Sensor: ADV_IND - no data, just "hey, I woke up"

    Central: SCAN_REQ - also as ACK for sensor that gateway received data

    Sensor: SCAN_RSP - actual sensor data

    Will be much faster than connecting. If the central will want to exchange more data (change configuration etc.) it can send CONNECT_IND.

    Additional question, how "low" I can go with controlling radio?

    I would like to simplify and shorten using radio as much as possible. Instead of sending in advertisement payload "length + data type + data + data type + data" etc. I would use my own custom structure. The same for connection data. Just my own short commands/responses.

    Thanks in advance! Slight smile

  • 0 in reply to user116227
    Kedlov said:
    Also can I create in the sensor's FW whitelist for scan requesters and/or separated whitelists for Initiatiors and scan requesters?

    I have not tested it, but it looks like there is an option for this:

    BT_LE_ADV_OPT_FILTER_SCAN_REQ - Use filter accept list to filter devices that can request scan response data.

    Kedlov said:

    Additional question, how "low" I can go with controlling radio?

    I would like to simplify and shorten using radio as much as possible. Instead of sending in advertisement payload "length + data type + data + data type + data" etc. I would use my own custom structure. The same for connection data. Just my own short commands/responses.

    If you want to go that low, and Bluetooth does not fit your needs, you can always use the radio directly, and run your own proprietary protocol e.g. based on ESB , but that will likely also be more work for you.

Related
Terms of service