Lag in OSX corresponding with FCE error

Hello. None of those sniffer captures show a connection; they are only showing advertising and scanning. Is the CC2541 address 0xAABEFFFFBBDD? Did you choose this address?

You are just using the OSX stack to attempt to connect to the CC2541, correct? Or are you writing your own app? Or are you using the TI CC2540 dongle?
Is the software on the CC2541 just the default HIDEmuKbrd project?
Are you using a whitelist on the CC2541?

The HCI commands you mention look they are configuring the OSX device to advertise. Note that these commands are not getting sent over the air; they are being sent down the stack of your OSX device to configure it for advertising. I'm assuming there must be other HCI commands that configure OSX to scan and attempt to connect since we do see scan requests in the sniffer capture.

The FCE error means that the sniffer did not correctly receive the packet due to a signal strength issue or an RF collision. Another possibility is that OSX is sending bad packets.

In any case, there appear to be 2 problems (likely related to each other):
1. CC2541 not responding to scan requests. The only reason I can think of this happening is that the CC2541 is not receiving the scan request which would be either an RF issue or OSX sending bad packets. If you implemented a whitelist on the CC2541, this could also explain it but there is no whitelist with the default HIDEmuKbd project.
2. OSX not sending connection request. This is likely because it is not receiving a response to its scan request.

You can take the following debugging step:
- Send a scan request (with a known good RF environment) to the CC2541 using BTool or some other device which you know works. This would verify whether the CC2541 is responding correctly to scan requests (you should see a scan response). If it does respond, then I have to imagine the OSX is sending bad scan requests.

Another item that may be helpful is if you could post a sniffer capture of when this works with an iOS device.

ios-connection-records.zip

Hello Tim,

Unfortunately I do not know how to interpret these files. But I can tell you that the packet sniffer was recording as I paired the device to the computer, and new packets did appear in the packet sniffer log after I had connected, paired, and transmitted HID over GATT. Each record has several seconds of typing with HID-over-GATT packets being successfully sent, but periodically there were several seconds of delays. I tried to end the record a few seconds after a serious lag event.

The device address in the OSX records is  0xAABEFFFFBBDD. The device address in the attached iOS records is 0x00000000001A (but both run the same software).

I am using the OSX stack to connect to the CC2541.

The software on the CC2541 is not just the default HIDEmuKbrd project, it has some modifications.

I am not using a whitelist on the CC2541.

You say the commands are configuring the behavior of the OSX device, not the OSX device trying to configure the behavior of the CC2541? There are other commands, and in fact we can also log the HID-over-GATT events as they come in, but those particular HCI events that I highlighted correlate with the lag in the OSX getting the HID-over-GATT events.

You say 2 problems, but what you mention confuses me. We are successfully connecting to and transmitting HID-over-GATT packets to OSX. It is working. The problem I am seeing is lag. The connection is successfully established, we do pair, and to my understanding that means we must have responded to the OSX scan request and received a connection request.

I have attached a series of sniffer captures of when this works with an iOS device. I hope this clears things up, because I do not understand why my packet sniffs of the OSX connection would fail to show that a connection was successfully established.

Thanks!

We will need a sniffer capture to debug this further. Out of the last sniffer captures you sent, the only one that shows a connection is #2 and it only captures the first 2 packets. Do you have the sniffer dongle close enough to the connected devices? Green packets are only advertising events. You will know that you have captured the connection when you see yellow packets. You may need to change the channel that the sniffer is listening on (under the Radio Configuration tab) to capture the connection. There are many posts on this forum discussing the sniffer. There is also a user guide under help->User Manual.

Also, can you test with the default HIDEmuKbrd project so that we know you are testing with a working project?

iOS-conn-keyfobproject.psd

Hello,

The problem still occurs with the default HIDEmuKbrd project.

I also found that the OSX host sends an HCI command "LE Create Connection Cancel" and "LE Remove Device From White List" every time this error occurs.

I took a log with the TI Packet Sniffer. It seemed to have yellow packets as you described. I hope this helps.

Thanks,

S

Hello Sarah,

Can you advise which P.nbr's have the issue in the latest capture? I see several connections.
Do you know why the OSX Host is sending "LE Create Connection Cancel" and "LE Remove Device From White List" ?

Also, since we do have access to an MBA running OSX, can you describe the procedure to reproduce using the keyfob and default HIDEmuKbrd project?

Best wishes

Hello JXS,

What do you mean by P.nbr ?

I do not know why the host is sending these events, only that it is. There is nothing obviously wrong before this happens. The event immediately prior tends to be "Set Extended Advertising Enable" but this happens a lot and does not have bad effects in other cases.

To reproduce this issue, pair the keyfob running HIDEmuKbrd project to the OSX host. Repeatedly press the buttons that create left and right arrow keys. Randomly, at a period of about 5 - 10 minutes, the keys fail to go through for about 30 seconds. The system then recovers and the left and right arrow keys start going through again.

I recommend running the OSX PacketLogger at the same time, as it will show the create connection cancel and remove device from white list events.

Thanks,
S

Hello Sarah,

We just recently observed that iOS 8.3 has issues when the slave sends the Slave Security Request, this can lead to a condition where iOS "ignores" certain HID reports even though they are properly sent by the slave. To make this change:

// Default GAP pairing mode
//#define DEFAULT_PAIRING_MODE GAPBOND_PAIRING_MODE_INITIATE
#define DEFAULT_PAIRING_MODE GAPBOND_PAIRING_MODE_WAIT_FOR_REQ

Although you are on OSX, it may help and is still compliant with the HOGP specification.

Note that P.nbr is the Packet Number in the TI sniffer. It's the left-most column of the sniffer. Please indicate in the "iOS-conn-keyfobproject.psd" trace the packet number(s) where the problem is observed. This will help correlate the observed behavior with the sniffer.

Given that you are doing higher level protocol analysis, can you use a Frontline or other sniffer that has protocol decode capability? This will be helpful with the analysis.

Finally, given that you have correlated the behavior to operations on the Central/OSX, we'll need input from you on this as well.

Best wishes