BLE Master-Slave mode can avoid colision?

            We have 3 nRF52840 to establish a net. one for master device, One for Master device, One for HUB(Msater-Slave) device, and One for Slave device. The data flow is Slave device--> HUB(Master-Slave) device -->Master device.

             So there is two BLE link: one for the master device and the HUB device. One for the HUB device and the Slave device. For the HUB device , The most important design is to avoid the link colision. I think if the HUB connect the master first,  then connect slave, nRF52840 can arrange the anchor proper to avoid link colision. because if HUB connect the Master device, The master deivce deside the anchor point and notify the HUB the anchor point by connect req PDU. when the HUB decide the anchor pointer for slave connection, It can arrange it proper to avoid colision.

              So when the HUB connect the master device, It will disconnect the Slave device and rescan for the slave device for connect.

              But it fullfilled in the nRF52840 SDK, It just a guess, I can't confirm it. 

              Can Noridc engeneer confirm it, Or tell me the how the WInoff and winsize are caculated in the SDK?

              

             

Parents
  • Hello,

    Yes, the SoftDevice will handle this for you as detailed in the SoftDevice scheduling documentation.
    When the SoftDevice is working in the multirole configuration (both central and peripheral role) it will use the Timeslot API to makes sure that there are no collision between the radio usage of each role.

    Best regards,
    Karl

  • So I want to confirm if the multirole device connect the slave device first , Can Nordic avoid the colision. We have test that it can't. But I think if the multirole device connect the master device first , It will be different.

    Can you help confirm it?

  • All three device set connect interval  7.5ms  and  event length 7.5ms. 

    The data flow is  slave device-->multirole device-->master device. 

    The data throughput is  15kbps 

    RSSI is about  -75dbm.

    If data throughput is 30kbps , it will drop data.

  • zhangkui said:

    All three device set connect interval  7.5ms  and  event length 7.5ms. 

    The data flow is  slave device-->multirole device-->master device. 

    The data throughput is  15kbps 

    Thank you for confirming.
    What throughput did you achieve on the central and two peripheral test, for comparison?

    Could you elaborate on why you need to have the multirole-intermidiate device, by the way?

    zhangkui said:
    If data throughput is 30kbps , it will drop data.

    Could you elaborate on what you mean when you say that data is dropped? No data is lost on the BLE link, so this must be happening in the application logic.
    For the record, 15 kbps is considered a very low throughput
    , so I suspect that there is an issue with the application somewhere.

    Best regards,
    Karl

  • We transmit a wave for example the ECG wave data.. we can see gaps of the wave. 30kbps is also a very low throughput.  But the noise is big and the RSSI is -75 dim.

    We test a multirole connect two slave.  The data flow is slave-->multirole-->slave They can achieve 30kbps. No wave gap. And the RSSI is also -75dim.

  • zhangkui said:
    30kbps is also a very low throughput.

    Yes, 30 kbps is also a very low throughput indeed.

    zhangkui said:
    We transmit a wave for example the ECG wave data.. we can see gaps of the wave.

    Does these gaps indicate that no data was received in time for it to be rendered? Or does it indicate that certain timestamps / parts of the sequence was never received?

    In case of the former it sounds like an issue strictly about throughput, in case of the latter we will also need to look into how your application is handling the data up until transmission.

    zhangkui said:
    But the noise is big and the RSSI is -75 dim.

    Which MTU size are you using in your application? If you are operating in an environment with a lot of noise where packets frequently gets corrupted it will help to divide the transfers into multiple packets instead, to reduce the chance of corruption due to noise.

    Best regards,
    Karl

  • n case of the former it sounds like an issue strictly about throughput, in case of the latter we will also need to look into how your application is handling the data up until transmission.

    -------you think the buffer for example the quene exceed may drop data  before BLE tansmit? But when the HUB be only center, there will no data be dropped.

    Which MTU size are you using in your application? If you are operating in an environment with a lot of noise where packets frequently gets corrupted it will help to divide the transfers into multiple packets instead, to reduce the chance of corruption due to noise.

    -------The MTU is 64, The MIN and MAX interval is 6(7.5ms).  If the anchor point of different connection is the key, The connection update ind will ajust anchor point. Which case will the link layer send connection update ind?

Reply
  • n case of the former it sounds like an issue strictly about throughput, in case of the latter we will also need to look into how your application is handling the data up until transmission.

    -------you think the buffer for example the quene exceed may drop data  before BLE tansmit? But when the HUB be only center, there will no data be dropped.

    Which MTU size are you using in your application? If you are operating in an environment with a lot of noise where packets frequently gets corrupted it will help to divide the transfers into multiple packets instead, to reduce the chance of corruption due to noise.

    -------The MTU is 64, The MIN and MAX interval is 6(7.5ms).  If the anchor point of different connection is the key, The connection update ind will ajust anchor point. Which case will the link layer send connection update ind?

Children
  • zhangkui said:
    -------you think the buffer for example the quene exceed may drop data  before BLE tansmit? But when the HUB be only center, there will no data be dropped.

    I think this could be the case, yes. Does your call to queue data for transfer ever return with a non-NRF_SUCCESS error code?

    zhangkui said:
    -------The MTU is 64, The MIN and MAX interval is 6(7.5ms).  If the anchor point of different connection is the key, The connection update ind will ajust anchor point. Which case will the link layer send connection update ind?

    Connection update indications are sent when one of the devices wants to update the connection parameters / configuration.
    Some of these are set by the SoftDevice directly, or you may also request to have the connection parameters updated using the SoftDevice API in your application.

    Best regards,
    Karl

  • I want to know whether the same MIN and MAX interval will stop the SDK updata connect parameter?  If the MIN and MAX interval are different values, when a new BLE is connected, Will the SDK of master change the interval and rearrange the anchor point?

  • zhangkui said:
    If the MIN and MAX interval are different values, when a new BLE is connected, Will the SDK of master change the interval and rearrange the anchor point?

    The central is the one that decides which connection parameters that will actually be used - the peripheral can only set some preferences, but the central may choose to ignore the peripheral's preferences. The SoftDevice will perform scheduling so that the different timeslots for the different roles do not overlap as according to the documentation, correct.

    Best regards,
    Karl

  • Can you tell me the detail scheduling logic that center SDK excute?

    We have different dropping data when the hub be center only or be center-peripheral.

    So when the hub be a peripheral to connect a center . Maybe the schedule is not as good as be center only.

  • And the schedule can only be excuted when connecting or connection parameter update?

Related