[Rash 0]

День добрый. Такой вот вопрос возник: Кто нибудь делал 3 SCO в один PCM канал (BlueTooth модуль WT11, спец. 2.0EDR), по средствам HCI команда (H4)? 1-ое SCO делается без проблем, когда делаешь 2-ое, с другим модулем, все данные сыпятся в UART , а не идут в PCM. Или мож это от PSKEY, каких зависит перепробывал уже их комбинации, те которые с _SCO_ или _PCM_ пока результата нету

[Rash 0]

Единственное, что прояснилось командой HCI_Add_SCO_Connection можно создать только одно SCO в PCM канал (эксперемент), а командой HCI_Setup_Synchronous_Connection можно создать несколько, но почемуто по линии PCM_OUT нет сигнала (смотрел осцилографом), а по линиям PCM_IN, PCM_CLK, PCM_SYNC сигналы идут. В команде HCI_Setup_Synchronous_Connection куча парметров:

Connection_Handle

Transmit_Bandwidth

Receive_Bandwidth

Max_Latency

Voice_Setting

Retransmission_Effort

Packet Type

в некоторых мне не понятно что указывать

Transmit_Bandwidth

Receive_Bandwidth

Max_Latency

Retransmission_Effort

результаты эксперементов не к чему не привели. Кто нибудь подскажет, какие значения нужно в них указывать?

[boroda1983 0]

Единственное, что прояснилось командой HCI_Add_SCO_Connection можно создать только одно SCO в PCM канал (эксперемент), а командой HCI_Setup_Synchronous_Connection можно создать несколько, но почемуто по линии PCM_OUT нет сигнала (смотрел осцилографом), а по линиям PCM_IN, PCM_CLK, PCM_SYNC сигналы идут. В команде HCI_Setup_Synchronous_Connection куча парметров:

Connection_Handle

Transmit_Bandwidth

Receive_Bandwidth

Max_Latency

Voice_Setting

Retransmission_Effort

Packet Type

в некоторых мне не понятно что указывать

Transmit_Bandwidth

Receive_Bandwidth

Max_Latency

Retransmission_Effort

результаты эксперементов не к чему не привели. Кто нибудь подскажет, какие значения нужно в них указывать?

Есть такое понятие Quality Of Service. Например для HFP 1.5 пункт 5.6

 

5.6 Synchronous Connection Interoperability Requirements

Synchronous connections may be realized by a SCO or by an eSCO logical transport. Only the support for SCO logical transports is mandated.

The remainder of this section relates to devices supporting eSCO logical transports. Here, “initiating” and “responding” refers to the initiating and responding (i.e. accept or reject) role in setting up the synchronous connection.

Table 5.6 defines eSCO configuration parameter sets S1, S2 and S3. HCI level parameters are given as a reference. On systems not incorporating HCI, values for LMP level eSCO parameters TeSCO, WeSCO and packet length shall be associated that correspond to these HCI parameters and fall into the mandatory parameter ranges for these packet types as given in the LMP specification, and the Voice Setting parameter translates into the air mode parameter of LMP.

 

eSCO parameter set             S1 “Safe Settings”         S2                     S3
Packet type                    EV3                       2-EV3                 2-EV3
Transmit/Receive Bandwidth     8000                      8000                  8000
Voice_Setting (air coding)     CVSD                      CVSD                  CVSD
Max_Latency                    0x0007 (7 ms)             0x0007 (7 ms)         0x000A (10ms)
Retransmission_Effort          0x01                      0x01                  0x01

Table 5.6: eSCO synchronous connections (HCI Reference parameters)

The following requirements apply to the support and use of eSCO logical transports and are based on parameter sets S1, S2 and S3:

• The device starting the request for a Synchronous Connection is known as the Initiator, the device receiving the request from the Initiator is known as the Responder. The Responder is able to accept or reject a request for eSCO transport. The Responder shall always accept a request for SCO transport.

• If support for eSCO logical transports is indicated at the Controller level, the Initiator may request the setup of an eSCO logical transport instead of SCO.

• The Initiators request for an eSCO transport may involve any configuration parameters matching the bidirectional throughput requirements of the voice codec (see section 5.5). If an HCI is supported on this device, the request for setting up a synchronous connection may include single or multiple packet types masked within the same request.

• The Responder may choose to accept or reject the request from the Initiator. It may reject the request for an eSCO transport, or may accept it with parameters that do not match the requested parameters. In this case the Initiator may retry the Synchronous Connection setup with different configuration parameters.

• If one or subsequent requests for an eSCO logical transport fails, the Initiator shall not abandon the setup of an eSCO transport without having requested eSCO using the “safe settings” S1.

• Only for HCI-based devices: if the Responder does not reject the request for an eSCO transport, the response shall include the parameters corresponding to the “safe settings” S1 when accepting a request. The Responder shall not request eSCO parameters that would inhibit the ability of the Initiator to negotiate the S1 settings.

• If the Initiator fails to establish an eSCO transport with the S1 settings, the Initiator shall request the setup of a SCO transport.

• Only for HCI-based devices: the Responder shall include the parameters for a SCO transport when accepting a request for a Synchronous Connection.

The following requirements apply if a device supports both eSCO logical transports and Enhanced Data Rate (as of Bluetooth core specification v2.0 + EDR or later).

• The Controller shall support the packet type 2-EV3, hence mandatory eSCO parameters ranges as given in the LMP specification and contained in settings S2 and S3.

• On an HCI-Responder, at least the settings S2 shall be included in the list of acceptable parameters.