CC2642R: cc2642 connect

Hello Wang,

Thanks for reaching out. The IOS phone is connecting as a central roles correct? And sends data through gatt write commands? I dont see how the stack will not notify the application although it has already received it (because according to what you said it was received but showed later). How are you passing the gatt write value from the stack to the application layer?

BR,

David.

Hi

The IOS phone is connecting as a central roles correct.

I would like to ask you to determine whether there is such a possibility. At present, I have no evidence to prove that all such problems are caused by market users .

Thank you! 

Hello Wang,

This sounds like it could happen on the application layer. Do you have more details about it?

BR,

David.

Hello.  

I've probably figured out the problem with this issue  

After the iPhone is connected, the connection interval is set to high on the phone. A packet of data sent by the phone to the cc2642 is sent in two packets by our phone, with an interval of 100ms between the first and second packets. However, occasionally, the CC2642 receives both packets of data simultaneously  

Where might this problem be blocked?  

(1) Is your phone blocked?  When sending the second packet of data, are the two packets sent within the same connection interval?  

(2) cc2642 is blocked and only notifies upon receiving the second packet of data from the protocol stack?  

Which of the above could be the situation?  

Could you please explain in detail?

Thank you! 

Hello Wang,

It is possible for the central device (IOS device) to transmit more than one packet per connection interval. This will depend on the packet size, MTU size, connection interval and PHY for instance. The Bluetooth spec only defines that the "The central shall ensure that a connection event closes at least T_IFS before the anchor point of the next connection event", therefore the Iphone can send more than one packet per connection interval and the cc2642 is not properly parsing the received messages (only reading the first X number of bytes corresponding to one packet per connection for example). We could confirm this by using a Bluetooth sniffer and see in practice what is happening over the air.

BR,

David.

Hello

After the central device (IOS device) is connected to CC2642, the negotiated mtu is 186, the connection interval is the maximum, approximately 15ms, and the PHY is 1M  

The central device (IOS device) sends data to the CC2642. There is a packet of 240 bytes of data. The mobile phone sends two packets of data, the first one being 180 bytes and the second one 60 bytes. The interval between the first and second packets sent by the central device is 100ms. The cc2642 has a very low probability of receiving both packets of data simultaneously.  By calling back the results twice in a row through gattServiceCBs_t, the data packets are correct. The first packet is 180 bytes and the second packet is 60 bytes.  

Now I want to know under what circumstances this problem may occur occasionally. Currently, it does not affect the operation of the equipment. I need to provide a detailed explanation to the customer and I need your help.  

In addition, the probability of this phenomenon occurring occasionally is relatively low. By using a Bluetooth sniffer, long-term monitoring is required. I don't have a stable professional Bluetooth sniffer at hand.  

Thank you! 

Hello,

Alright, IOS devices seem to have a maximum ATT_MTU of 185 bytes, which means you can send a maximum of 182 data bytes per packet. When you say this

wang jiwei said:

An IOS phone connects to the CC2642 and sends data to it. Once, the phone sent A packet of data A to the CC2642, but the protocol stack did not notify the application layer to read it. When the phone sent data B to the CC2642 again, the protocol stack informed the application layer to read it, but the data read was the previous data A.

Do you mean that the packet B is the last 60 bytes of data or the next 180 (from the next 240 bytes size packet)? Because with the 100 ms interval I would have expected that device to send both packets (180 and 60) in the same connection interval.

BR,

David

hi.

Sorry, there's no need to consider the question asked at the beginning.

Now, we just need to explain what the possible causes of the following problems are? 

Could you please provide some possible reasons so that I can explain them to the client 

After the central device (IOS device) is connected to CC2642, the negotiated mtu is 186, the connection interval is the maximum, approximately 15ms, and the PHY is 1M  

The central device (IOS device) sends data to the CC2642. There is a packet of 240 bytes of data. The mobile phone sends two packets of data, the first one being 180 bytes and the second one 60 bytes. The interval between the first and second packets sent by the central device is 100ms. The cc2642 has a very low probability of receiving both packets of data simultaneously.  By calling back the results twice in a row through gattServiceCBs_t, the data packets are correct. The first packet is 180 bytes and the second packet is 60 bytes.  

Now I want to know under what circumstances this problem may occur occasionally. Currently, it does not affect the operation of the equipment. I need to provide a detailed explanation to the customer and I need your help.  

In addition, the probability of this phenomenon occurring occasionally is relatively low. By using a Bluetooth sniffer, long-term monitoring is required. I don't have a stable professional Bluetooth sniffer at hand. 

Thank you! 

Hello Wang,

As I mentioned, it is possible that the central device (phone) is transmitting the two packets (180 + 60) during the same connection interval, but this depends on several factors such as the MTU size and the connection interval (and the fact that DLE - Data Length Extension is enabled). The peripheral will know there is more data coming in the same connection interval based on the MD (More Data) bit, which is part of the Link Layer PDU and set by the controller when more data has been enqueued by the host. There is no direct user control of this field, but must be asserted. I don't see how this mechanism will fail under normal conditions (not considering over the air packet loss). However, what I don't get is that you mentioned that the conn interval is 15 ms, but the two fragmented packets are send 100 ms in between each other by the central device, is this correct? Why not sending both fragments at the same time? Having some sort of logs, if not sniffer logs ideally, would be useful to analyze what is actually happening.

BR,

David.