High and Low Connection Mode Parameters

[Anonymous]

I have two sets of parameters defined in the master node as follow:

    // Used for low connection mode

    blecen_cen_cfg.low_conn_min_interval    = 200;      // frames; 1.25ms

    blecen_cen_cfg.low_conn_max_interval    = 220;      // frames

    blecen_cen_cfg.low_conn_latency         = 0;        // number of connection event

    blecen_cen_cfg.low_supervision_timeout  = 500;      // N * 10ms

    // Used for high connection mode

    blecen_cen_cfg.high_conn_min_interval   = 6;        // frames; 1.25ms

    blecen_cen_cfg.high_conn_max_interval   = 6;        // frames

    blecen_cen_cfg.high_conn_latency        = 0;        // number of connection event

    blecen_cen_cfg.high_supervision_timeout = 10;       // N * 10ms

The master node will first connect to a slave using high connection mode command blecen_Conn(HIGH_CONN, evt->wd_addr, evt->addressType)  and then disconnect.

The master node then connects to another node using low connection mode command blecen_Conn(LOW_CONN, evt->wd_addr, evt->addressType)

However, when I used emconninfo_getConnInterval() to check the parameters, it show that the master still uses the high connection mode parameters for the 2nd node.

I even program the 2nd slaves node to update the parameters via lel2cap_sendConnParamUpdateReq, but the master node still uses the high connection mode parameters.

So, why does the master node use high connection mode parameters even when I use the command blecen_Conn(LOW_CONN, evt->wd_addr, evt->addressType) ?

Any idea how to fix it?

[JacobT_81]

The first thing you need to test is setting the LOW_CONN min/max interval to something higher. Your currently have it set to the minimum possible value allowed by the BLE spec. Try giving yourself a margin to work with: pass it an interval of 20 frames first and see if that works.

Next, if that doesn't work, try passing it a range, as the parameters suggest. The API may be rejecting the parameters if the min and max are exactly equal to each other.

Finally, swap your high and low values. By default, a HIGH_CONN is the smaller interval and LOW_CONN is the higher interval. Perhaps, contention exists by editing only some of the parameters with characterisitics of a one connection type and leaving other parameters of the old connection type. E.g. latency less than a connection interval, etc.

If these tests don't work, we can bring this up to the developers next week.

Jacob

[Anonymous]

Please note that the system actually used the parameter with high intensity (interval=6) instead of (interval = 200). So, the problem is definitely not because of the minimum value.

I have passed a range and it does not work either.

I already used HIGH_CONN with smaller interval and LOW_CONN with higher interval.

For some unknown reason, the system uses HIGH_CONN parameters instead of LOW_CONN parameters even when I used blecen_Conn(LOW_CONN, evt->wd_addr, evt->addressType) to connect.

[JacobT_81]

We'll bring this up to the developers at our weekly meeting.

Jacob

[Anonymous]

Hello, is there any update regarding this issue?   Thank you.

[JacobT_81]

To rule out the possibility of a bug in the lel2cap_sendConnParamUpdateReq() function, the developers asked for traces with a BLE sniffer. Please confirm that the actual connection interval is the same as what is returned.

Jacob

[Anonymous]

We indeed found that the traffic is different.  We found that the traffic amount is high when we used low connection mode.

[Anonymous]

Hi, I would like to follow up with this issue.  I want to ask if there is a way to solve the problem (to configure the two sets of parameters correctly).  Thank you.

[Anonymous]

Hello Huang,

Please send us the traces of the traffic that you are observing.

Thanks

JT

[Anonymous]

Hi j.t  thank you for reply.   Could you please provide details on what kinds of traces you need?   What tool can I use to get them?   Thank you.

[Anonymous]

Hello Huang,

The debug traces from our SDK:

Let me know if this helps,

Thanks

JT