Windows 8.1 repeated key event

[Ignacio Lopez]

I have an issue with my keyboard working with the windows suface (on windows 8.1). Occasionally, the last character sent is repeated several times instead of one. I do not have the same isue with the ipad (iOS 7.0.3). Therefore, I was thinking if may be any problem with the USB HID events. This is how I am sending and clearing each key stroke:

static uint8_t m_sample_key_release_pattern[8] =                /**< Key pattern to be sent to simulate releasing keys. */
{ 
    0x00,
    0x00,
    0x00,
    0x00,
    0x00,
    0x00,
    0x00,
    0x00
};

Sending the event an clearing code. The ASCII character goes on the 3rd byte of an 8 byte array (packet->keyboard_keys).

// Code
err_code = ble_hids_inp_rep_send(&s_hids,
            INPUT_REPORT_KEYS_INDEX,
            packet_size,
            (uint8_t*)packet->keyboard_keys);  
ASSERT(packet_size == 8);
ASSERT(packet->keyboard_keys != 0);
// ADD
if (err_code == NRF_SUCCESS)
{
   err_code = ble_hids_inp_rep_send(&s_hids,
            INPUT_REPORT_KEYS_INDEX,
            packet_size,
            m_sample_key_release_pattern);
}

Please let me know if you need more info.

Thanks for your help!

[Ole Morten]

The softdevice have a limited number of buffers available, and if you try to send a packet when these buffers are full, ble_gatts_hvx() will return the BLE_ERROR_NO_TX_BUFFERS_AVAILABLE error.

Could it be that in your case, there is only room for the key press packet in the buffer, but the release is never queued, so that the release is only sent after then next press or release? If so, I'd suggest that you keep track of the numbers of buffers available. A strategy for this is proposed in this document. By doing this, you can know before trying to send the press whether there will also be room for the release, and if not, you can wait with sending the press.

[Ignacio Lopez]

Thanks Ole.

As you suggested I will try to keep track of the total packets sent. I have a couple of questions first. I am planning a variable that will keep track of the buffers availability. I will initialize this variable to the value return from sd_ble_tx_buffer_count_get function.

Every time I sent a key, I put through 16 bytes (press+release). 1st question: what is the size of a buffer? Buffer size will help me to know how many buffers I am using every time I sent a key event and then decrease the precise number from total buffers available.

Also, I will use the BLE_EVT_TX_COMPLETE event to increase the buffer once the packets have been sent. 2nd question: I would like to know when this event is called if it is every time a byte is sent or when a buffer is cleared.

Basically I need to know how the softdevice buffers are managed.;)

[Ignacio Lopez]

I am calling this function as it stands:

	err_code = sd_ble_tx_buffer_count_get (&s_packet_buffer.sd_buffers_available);

	ASSERT(err_code == NRF_SUCCESS);

The total number of buffers returned is 7. Is that right? Where can I find more info about the softdevice buffers?

[Ole Morten]

The buffers in the softdevice is managed on packets, not data size. This means that you can queue a number of packets, no matter how big they are (but obviously limited by the MTU size of the link). Each time you call sd_ble_gatts_hvx() you therefore consume one buffer space. The BLE_EVT_TX_COMPLETE will be delivered for each connection event, i.e. each connection interval.

There is some comments explaining the buffer behavior in ble_gatts.h, which may be useful. In addition, the document I linked to in my first answer should be useful.

[Ole Morten]

The softdevice does have an internal buffer of 7 packets, so that seems correct.