packets Loss in nRF51 & iOS streaming.

RE: packets Loss in nRF51 & iOS streaming.

run_ar — Fri, 02 Feb 2018 12:32:58 GMT

There is no hard limit with iOS, i.e. you can send a lot of packets in each event. Anyway I'm not sure what happens in lightblue. So you have to check with a ble sniffer to see if you are loosing packets or not. If you follow the flow you describe on the nrf5, I guess it might be an issue with displaying received content in lightblue. Remeber that a notification will be retransmitted until it is received by the peer or until the connection is lost. So it is not possible to loose packets unless the receiving side overwrites it's RX buffers, or the application does not handle the packets correctly.

RE: packets Loss in nRF51 & iOS streaming.

Bayram ZAYET — Fri, 02 Feb 2018 10:24:57 GMT

I was testing with LightBlue iOS application and I got packets loss.

But assuming that the connection interval isn't the problem, can I be sure that iOS packets per connection interval reaches 6 packets? Isn't it limited to 4 or 3 ?

Many thanks.

RE: packets Loss in nRF51 & iOS streaming.

run_ar — Thu, 01 Feb 2018 20:08:47 GMT

What iOS app are you testing with? are you sure you handle all the peripheral:didUpdateValueForCharacteristic:error: callbacks?

RE: packets Loss in nRF51 & iOS streaming.

Nguyen Hoan Hoang — Tue, 30 Jan 2018 14:42:33 GMT

I started with iOS 8 up to the latest. See the video on this page. It was done on an older version using nRF51 & iOS8. transmitting realtime 9 axis motion data.

RE: packets Loss in nRF51 & iOS streaming.

run_ar — Tue, 30 Jan 2018 14:07:55 GMT

What iOS app are you testing with? are you sure you handle all the peripheral:didUpdateValueForCharacteristic:error: callbacks?

RE: packets Loss in nRF51 & iOS streaming.

Bayram ZAYET — Tue, 30 Jan 2018 10:21:38 GMT

The transfer is from nRF51 to iOS. I am suspecting iOS application because I got no loss using MCP as a master. I my implementation: I am checking on HVX return and TX_COMPLETE:

void stream(void)

{

while(1)

{ err_code = ble_send(&m_service, data); if(err_code != NRF_SUCCESS) { break; } } }

ble_send() function contains the HVX call.

	case BLE_EVT_TX_COMPLETE:
					stream();												
                   break;

RE: packets Loss in nRF51 & iOS streaming.

Bayram ZAYET — Tue, 30 Jan 2018 10:01:24 GMT

Yes of course, I am checking the return of the HVX function, especially when I get the NO_TX_PACKETS error, in that case, I wait untill TX_COMPLETE to send again. Also, a similar streaming test went well without any loss using MCP as a master receiving packets.

RE: packets Loss in nRF51 & iOS streaming.

run_ar — Tue, 30 Jan 2018 09:29:57 GMT

Actually you shouldn't lose packets at all. at least not if you are transferring from nRF to iOS. Are you checking the return value of the HVX function?

RE: packets Loss in nRF51 & iOS streaming.

Bayram ZAYET — Mon, 29 Jan 2018 19:20:20 GMT

Hello, Actually, I got considerably less packets loss by reducing the slave (nRF51) bandwidth which gives only 3 packets per connection interval. But still didn't get any hint about iOS stack limits or configuration.

RE: packets Loss in nRF51 & iOS streaming.

Nguyen Hoan Hoang — Fri, 26 Jan 2018 13:41:36 GMT

There are min and max values settings. Wouldn't that means your firmware can handle that range ?! Your mobile device would work if it falls into the range. So a range from 7.5 - 40 still falls within the range. Guidelines means you need to support it as a minimum. It does not mean you can't support a wider range than that.

RE: packets Loss in nRF51 & iOS streaming.

run_ar — Fri, 26 Jan 2018 08:58:41 GMT

Are you transfering data from iOS to nRF51 or the other way around? If you are transfering data from iOS to nRF51 using write without response it is possible to overwrite the tx buffers on the iOS side. If you are transfering data from nRF51 to iOS it is not possible to overwrite the tx buffers. instead you will get an error message when calling the hvx function. Please make sure you check this and try again when you get the tx-complete event in case there are no available tx buffers.

RE: packets Loss in nRF51 & iOS streaming.

run_ar — Fri, 26 Jan 2018 08:56:15 GMT

You should follow Apples bluetooth design guidelines. I have never seen an iOS device accepting connection intervals of 7.5ms. HID devices will be able to get down to 11.25ms. But I have usually ended up with 12.5 - 15. But seems like the spec has changed a little so you might be able to get 15 ms now.

RE: packets Loss in nRF51 & iOS streaming.

Bayram ZAYET — Fri, 26 Jan 2018 08:24:12 GMT

Can I know how did you do that with iPhone? Because I think that iOS developers cannot set or modify neither connection interval nor number of packets per connection interval.

Regards,

RE: packets Loss in nRF51 & iOS streaming.

Nguyen Hoan Hoang — Thu, 25 Jan 2018 20:33:30 GMT

Ok, I don't know where that 30ms limit comes from. I've worked with iPhone6 at 7.5ms (old SDK) and 10ms (new SDK14) and 10ms on Android. Anyway that is up to you.

RE: packets Loss in nRF51 & iOS streaming.

Bayram ZAYET — Thu, 25 Jan 2018 20:04:36 GMT

Thank you for your answer. But I believe that iPhone cannot work with less than 30ms refering to this link and others. Am I refering to wrong sources ?

RE: packets Loss in nRF51 & iOS streaming.

Nguyen Hoan Hoang — Thu, 25 Jan 2018 18:25:49 GMT

iPhone can work at 7.5ms, try min interval at 10ms see what happens