• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 16 subscribers
  • Views 757 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

WILINK-SW: Problems using NL5500 in dual mode

WILINK-SW: NL5500l issues with eSCO and Low Energy (Dual Mode)

Trevor Sutter
Prodigy 175 points
Part Number: WILINK-SW

As stated in the linked thread:

I am using TI’s NL5500L Navilink GPS/BT/FM combo chip.

Host platform details:

Processor: OMAP-L138

Kernel: Linux 4.12.0

Bluetooth Stack: BlueZ 5.50

I was having trouble even connecting with a BLE device when also connected to headset (any SCO connection).

I started to play with the latency parameter of the eSCO setup command and when it is low enough so that TeSCO is 6 slots and WeSCO is 2 slots, I am able to connect both a headset and a BLE device at the same time. However, the connection is very unreliable, and I get frequent connection timeouts (10 seconds to a few minutes after connection establishment) or connection/pair failures for LE devices. All of these failures seem to be accompanied by 1 or more the the below warning entries in logger.

"*** WARNING *** FBF not enough available slots for the next scheduling of (E)SCO instance"

Any idea what is happening?

Here is a log of a connection timeout. See the disconnect at line 88070

4174.hsp_le_connection_timeout.txt

Your help is much appreciated,

Trevor

  • 0
    TI__Mastermind 29250 points

    Hi Trevor,

    Sorry for the delay in reply.

    From the logs, it looks like the BLE connection is is causing scheduling problems for the eSCO connection. That's why the "*** WARNING *** FBF not enough available slots for the next scheduling of (E)SCO instance" trace appears on the logger. Since eSCO connection gets higher priority than BLE connection, it is likely overstepping on the BLE connection resulting in the disconnection due to connection timeout.

    Could you please see if turning off the AFH (by sending the following commands after the service-pack) improves the performance?

    # Disable AFH Slave
Send_HCI_VS_Set_Supported_Features 0xFF26, 0x04, 0x03, 0x00
Wait_HCI_Command_Complete_VS_Set_Supported_Features_Event 5000, 0x00, 0xff26, 0x00

# Disable AFH Classification Slave
Send_HCI_VS_Set_Supported_Features 0xFF26, 0x04, 0x04, 0x00
Wait_HCI_Command_Complete_VS_Set_Supported_Features_Event 5000, 0x00, 0xff26, 0x00

# Disable AFH Master
Send_HCI_VS_Set_Supported_Features 0xFF26, 0x05, 0x03, 0x00
Wait_HCI_Command_Complete_VS_Set_Supported_Features_Event 5000, 0x00, 0xff26, 0x00

# Disable AFH Classification Master
Send_HCI_VS_Set_Supported_Features 0xFF26, 0x05, 0x04, 0x00
Wait_HCI_Command_Complete_VS_Set_Supported_Features_Event 5000, 0x00, 0xff26, 0x00

# Command to disable AFH channel assessment
Send_HCI_Write_AFH_Channel_Assessment_Mode 0x00
Wait_HCI_Command_Complete_Write_AFH_Channel_Assessment_Mode_Event 5000, 0x00, 0x0c49, 0x00

    Best regards,

    Vihang

  • 0 in reply to Vihang Parmar
    Prodigy 175 points

    Vihang, 

    Thank you for the suggestion. I did some testing with this last week. 

    This seems to have made performance somewhat better. However, I am still able to get the radio to lose connection after some time. It all depends on the connection interval. If it is something like 50 ms, connection usually drops at around 1 or 2 hours. If the connection interval is at 500 ms the connection might last all day. The bad thing is that when this happens it is not just a matter of reconnecting, but the chip needs to be power cycled before I can connect again.

    I want to understand the nature of this problem a little better. Is the issue with how I am setting up my connection timings  or is it with the chip/firmware not able to handle processing for both of these connections at the same time? I want to know if there could ever be a "correct" solution to this problem, or if any fix will always involve some significant trade-off (i.e. disabling AFH).

    Your help is much appreciated,

    Trevor

  • 0 in reply to Trevor Sutter
    TI__Mastermind 29250 points
    Trevor,

    I'm afraid there would always be some significant trade-off to run this use-case since the availability of enough timeslots is the issue here. This trade-off may be disabling the AFH and/or reducing the BLE connection interval significantly.

    Best regards,
    Vihang