RN42蓝牙在流数据的几秒钟内在iOS上断开连接 [英] RN42 Bluetooth disconnects on iOS within seconds of streaming data
问题描述
我一直在尝试使用RN-42通过蓝牙2.1从设备读取数据.该设备可与iPhone或iPad Mini配对，并且数据会短暂流过，但iOS& BT模块在几秒钟内(小于10)断开连接(不配对).该设备正在以5-10kB/s的速度输出数据，完全符合蓝牙规范.我还注意到，当我运行函数NSInputStream [NSInputStream读取:maxLength:]时，返回的字节数始终为158或更少.该应用程序和硬件不会崩溃，但蓝牙只是无法配对.
I've been trying to read data from a device via Bluetooth 2.1 using an RN-42. The device pairs to an iPhone or iPad Mini, and data is streamed across briefly, but the iOS & BT module disconnect (unpair) within seconds (less than 10). The device is outputting data 5-10kB/s, so well within Bluetooth’s spec. Something that I’ve also noticed is that when I run the function NSInputStream, [NSInputStream read: maxLength:], the number of bytes returned is always 158 or less. The app and hardware don’t crash, but the Bluetooth just unpairs.
即使断开连接后，设备仍在向RN42发送数据，这降低了电子设备侧出现问题的可能性.此设置在Android设备上也可以正常运行.我可以流式传输数据，而不会造成任何断开连接或崩溃.
The device is still sending data to the RN42 even after the disconnect, which reduces the likelihood of a problem on the electronics side. This setup also works perfectly fine on Android devices. I can stream data without any disconnects or crashes.
我尝试过的事情...
Things I’ve tried...
- 遵循Apple提供的外部附件示例EADemo.
- 仅使用运行循环而不是轮询.
- 按照本文中的建议将流放在后台线程上.
- 删除所有NSLog来提高性能.
- 以调试和发布模式进行编译.
一种可行的方法是减慢数据传输速度(即小于5kB/s)，因为它允许iOS和BT模块保持连接状态，并在断开连接之前传输数据的时间更长.
One thing which sort of works is slowing down the data transfer (i.e. less than 5kB/s), as that allows the iOS and BT module to stay connected and transfer data longer before disconnecting.
#define EAD_INPUT_BUFFER_SIZE 1024
/**
* Stream delegate
*/
- (void)stream:(NSStream *)aStream handleEvent:(NSStreamEvent)eventCode
{
switch (eventCode) {
[... other cases ...]
case NSStreamEventHasBytesAvailable:
{
uint8_t buf[EAD_INPUT_BUFFER_SIZE];
unsigned int len = 0;
len = [(NSInputStream *)aStream read:buf maxLength:EAD_INPUT_BUFFER_SIZE];
if(len) {
// Read successful, process data
} else {
// Fail
}
break;
}
default:
break;
}
}
/**
* Stream delegate with polling (for better or worse)
*/
[...]
case NSStreamEventHasBytesAvailable:
{
while ([[_session inputStream] hasBytesAvailable])
{
// Read the data
NSInteger bytesRead = [[_session inputStream] read:_buf maxLength:EAD_INPUT_BUFFER_SIZE];
if (bytesRead > 0) {
// Read successful, process data
} else if (bytesRead == 0) {
// End of buffer reached
return;
} else if (bytesRead == -1) {
// Failed to read
return;
}
}
break;
[...]
推荐答案
我已经与Microchip(购买Roving Networks的公司，该公司是RN42的原始制造商)的家伙就这种类型的问题进行了交谈，似乎有一个不幸的小功能"在RN42手册的任何地方都没有记录.
I've spoken with guys at Microchip (the company that bought Roving Networks, who were the original makers of the RN42) about this type of problem, and it seems that there is an unfortunate little "feature" that is not documented anywhere in the RN42 manuals.
当RN42用于与iOS设备进行通信时，其通信速度不能超过2.5-3kB/s ...如果用于与Android或计算机或其他任何设备进行通信，则它可以35kB/s的速度传输(通过SPP).
When the RN42 is used to communicate with an iOS device, it cannot communicate faster than 2.5-3kB/s... If it's used to communicate with an Android or computer or anything else, it can transfer at 35kB/s (over SPP).
其原因是RN42的电源不足，无法同时处理BT堆栈和以iOS设备所需的格式(iAP协议)重新打包字节.
The reason for this is an under-powered chip in the RN42, which can't handle both the BT stack AND re-packaging bytes in the format an iOS device needs (iAP protocol).
他们推荐以下选项:
- 切换为使用WiFi模块.
- 在您的微控制器上实施iAP协议，并使用普通RN42传输数据(理论上应以35kB/s的速度返回).
- 在设备上缓冲数据，并以较低的速率将其发送回去.
- 使用香草RN42及其实现iAP堆栈的PIC器件之一.
我有一个礼貌的第5条建议...查找一个新的Apple支持的蓝牙模块.
I have a polite 5th suggestion... Find a new Apple-supported Bluetooth module.
此外，使用4线UART通信应有助于避免崩溃.
Additionally, using 4-wire UART communication should help with the crashes.
这篇关于RN42蓝牙在流数据的几秒钟内在iOS上断开连接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
