BT LE channel blacklisting

How can I blacklist BT LE channels/frequency from operation?

Context:  I have the nRF52840 integrated into our product's design.  The device is going into an environment where we are being mandated operational restrictions to not use 2.4 GHz frequencies that are employed other systems.  So we have a need to be able to command the BT module to operate:

  • No 2.4 GHz  frequencies that overlap with Wi-Fi 2.4 GHz Ch 1
  • No 2.4 GHz  frequencies that overlap with Wi-Fi 2.4 GHz Ch 11
  • Operate with all frequencies supported

The concern that the requirement is derived from has to do with telemedicine & emergency systems that clearly have a higher priority.

Parents
  • Hello,

    In general, a Bluetooth Central has a lot more control of connection parameters than the peripheral, so to what degree you are able to do this depends on what you plan to do. So what kind of BLE device do you plan to be? 

    As a central, you can scan on whatever channels you want to (as it will not interfere with the WiFi). Then you can set the channel map before connecting to the peripheral. 

    As a peripheral however, I believe you can request a channel map update, but I am not sure you have much to say before that. I will have to test though, if this is the case, that you are developing a BLE peripheral.

    That being said. I don't think that a BLE device with the TX power that is used in BLE communication will be able to do much harm to your WiFi part of the product. But I assume that doesn't really matter, if the requirement is coming from some medical device requirement, rather than practical consequences?

    Best regards,

    Edvin

  • It should however be quite straight forward to test, using the bt_le_set_chan_map(), and then check what channel map that is given when the central connects. Let me know if you need help with this, and I will try to set up something to test.

    Best regards,

    Edvin

  • Hey Edvin, we're looking to use the module as a host for LE Audio streaming primarily.  So definitely looks like this is feasible which is great.

    The other piece that I forgot to write in the initial post was if the module can have Tx adjusted and how fine the intervals would be.  The environment that the product is going in is rather reflective so we're trying to minimize the field to a bare minimum

  • Oh,

    Disclaimer: I am not that familiar with Bluetooth LE Audio. So are we talking broadcast or unicast? And are you the source/server or the sink/client? And are you controlling the other side of the stream as well?

    The reason I ask is that this is possible, but strictly speaking, it depends on the role on the device.

    1. Broadcast:
      1. Source: You will be the originator of the signals, and you can set the channel map as you like.
      2. Sink: You will pick up an advertisement saying where the audio stream is present, and it will tune in to those channels. On the other hand, this will only receive, so it will not transmit anything on the channels that you want to avoid. 
    2. Unicast: This is closer to a normal BLE connection.
      1. Server: This is a BLE peripheral, meaning you can determine what advertising channel you want to use. However, when you enter a connection, the peripheral has to do what the central says. It can request a channel map after the connection, but there is no guarantee that the channel map will be accepted, and it is no guarantee that the "forbidden channels" will not be used before that channel map update request.
      2. Client: This is a BLE central. It can decide what channels to enter the connection in, so in this case you are good.

    Will you control both sides, or only one side of the stream? 

    Best regards,

    Edvin

Reply
  • Oh,

    Disclaimer: I am not that familiar with Bluetooth LE Audio. So are we talking broadcast or unicast? And are you the source/server or the sink/client? And are you controlling the other side of the stream as well?

    The reason I ask is that this is possible, but strictly speaking, it depends on the role on the device.

    1. Broadcast:
      1. Source: You will be the originator of the signals, and you can set the channel map as you like.
      2. Sink: You will pick up an advertisement saying where the audio stream is present, and it will tune in to those channels. On the other hand, this will only receive, so it will not transmit anything on the channels that you want to avoid. 
    2. Unicast: This is closer to a normal BLE connection.
      1. Server: This is a BLE peripheral, meaning you can determine what advertising channel you want to use. However, when you enter a connection, the peripheral has to do what the central says. It can request a channel map after the connection, but there is no guarantee that the channel map will be accepted, and it is no guarantee that the "forbidden channels" will not be used before that channel map update request.
      2. Client: This is a BLE central. It can decide what channels to enter the connection in, so in this case you are good.

    Will you control both sides, or only one side of the stream? 

    Best regards,

    Edvin

Children
  • Here is the response from our development team:


    To be clear, we are the source of the audio and the clients are headphones.  So it looks like for broadcast we do not have any problems.

    For unicast, from our previous work on Bluetooth Classic, upon making a connection, we may be master or slave, and only when we are master can we set the channel blacklisting map.  But there is a command to set ourselves as a master, and therefore we can always set the channel blacklisting map.

    When you said "Client: This is a BLE central.", do you mean the client (headphone) is the master, and therefore could set the blacklisting map.  Is it possible to switch the Server to the Central role after the connection was made and therefore allow the Server (audio source) to set the channel blacklisting map?  Or does BLE work differently and only the Client can be the Central?

  • It is not possible to switch the central/peripheral role, unfortunately. In BLE it is always the peripheral that advertises, and the central that scans for advertisement packets before connection. However, I think you can have the unicast streams going whatever direction you want, so actually it would make sense that the headphones would be the peripheral, the one sends advertising packets, and the central can be the device that scan for advertisements, and then sends the stream after that.

    For unicast: Would you have only one connection? Or several? 

Related