蓝牙低功耗 - 重复更新的特征值 [英] Bluetooth Low Energy - updating a characteristic value repeatedly
问题描述
<一个href=\"http://electronics.stackexchange.com/questions/30964/improving-throughput-of-a-bluetooth-low-energy-connection\">Follow-Up电气工程Stackexchange问题
我要反复写在很短的时间量的蓝牙低功耗特性值（作为一个可能的使用情况下，想象一个鼠标）。
- 有128位UUID的特点就是 20字节长。因此，它可以被写成单个低能事务。
- 写发生在50 Hz的频率，等于写的每20ms一次
- 因此，20 * 50 * 8 = 8 kbit / s的被写入文件。
- 我使用的命令 / 撰写无反应模式来写的特点。因此，没有确认发生属性层上。
- 没有其他蓝牙或蓝牙低功耗设备相连接。没有什么是通过WLAN进行。没有其他的特性在测试期间读取或写入。
我测试通过发送从iPhone 4S的含有序列号的分组方案。序列号由一个各发送分组之后递增。
在接收侧，可编程开发板，其包括一个 CSR1000 的BLE芯片中，使用接收的报文，并打印所接收的序列号的串行连接。
我的问题如下：
-
一段时间后，包开始越来越下降。第一〜100个数据包做工精细@ 50赫兹。从此，包开始越来越下降。
0×00 - 0×46收到
0X47，0x48失踪
0x49，0x4a，0x4b，收到0x4c
送出0x4d失踪
0x4e，0x4f，为0x50，0x51收
0×52失踪
0x53，0x54，将0x55，0x56收
失踪的0x57
...大多数情况下，四包一包的传输精（很少，只有2包）。然后，1-7分组丢失。
当我减少的特征值的大小，问题依然存在。
当我写在100Hz，而不是为50Hz，画面是一样的 - 只有那滴开始约35文后存在的和5-7包四包的成功传输之间降至
使用该丢失的分组，将所得的传输速率是大约为5千比特/秒，而不管写入的频率。这显然是低于305〜kbit / s的，应该是技术上可以通过蓝牙低功耗。
-
该问题也将出现相反方向，当我从开发板到iPhone 4S的发送数据包。同样，5 kbit / s的是，我得到的最大值。通知机制用于此方案。同样，没有确认发生属性层上。
-
当我尝试在两个方向上同时发送，做起事情来炸毁的地方我一定要复位两个开发板和iPhone 4S的点。
问题：
-
这可能是蓝牙低耗能芯片的问题，就是在开发板上使用？
如果是，为什么问题也出现成相反的方向，其中，在iPhone充当接收机
是否有支持高频率的访问特性在市场上的任何开发板？
-
这可能是什么问题的根源？
请还尝试引用蓝牙规格/ presentation幻灯片/品及其零件，除了假设。
有存在的市场上低功耗蓝牙鼠标。小鼠有125赫兹的典型轮询率，必须至少派两名16字节值加上每个时钟周期的额外开销HID。因此，对于我的问题的解决方案应该是可用的。
更新
的 LE连接完成事件的中的蓝牙规范4.0版第2卷第E部分章节7.7.65.1描述的。我收到下面的值不同的连接参数：
参数值说明
--------------------------------------------------
Conn_Interval 0x0054时间= 105毫秒
Conn_Latency为0x0000时间= 0毫秒
Supervision_Timeout 0x00fc时间= 2520毫秒
Master_Clock_Accuracy 0×05 50ppm的
发行5千位一的连接参数更新的解决了这个问题，并提高吞吐量/ s到〜33 kbit / s的。然而，这是预期的〜305千比特/秒仍低于
Conn_Interval = 0x000f = 18.75毫秒
Conn_Latency = 0×0000
Supervision_Timeout = 0x00fc
有没有什么方法来达到全〜305 kbit / s的？
<一个href=\"http://electronics.stackexchange.com/questions/30964/improving-throughput-of-a-bluetooth-low-energy-connection\">Follow-Up电气工程Stackexchange问题
可以通过燃烧TSI和等待了一个月得到苹果回复。
基本上，他们告诉该行为的目的是iOS中5.1。它
某种程度上是有道理的，因为他们不希望你的应用程序的
性能依赖于另一个应用程序是否使用蓝牙或WiFi。
每工程师评论 - 下的iOS 5.1应该有一个连接间隔期间6双通知，这意味着
6 * PACKETSIZE * 1000 /间隔。这应该转化为〜55kbps最大（分
间隔为20ms，PACKETSIZE是23字节）。我们做出决定
限制每个间隔对的数目，并有因一个最小时间间隔
到iPhone和iPad双方都共用天线的事实
经典的BT，BT LE和WiFi。
的iOS LE被设计为一个低功率传输。对于更高的吞吐量BT经典是一个更好的传输方法。
回到我身边 - 基于上述工程师的意见，如果愿望是实现了200 KBS吞吐量，经典蓝牙就是答案。
然而，如果愿望是与iPhone应用程序的工作，我
可以理解，这不是一个简单的变化 - 经典BT需要MFI
许可。
Follow-Up question on Electrical Engineering Stackexchange
I want to write the value of a Bluetooth Low Energy characteristic repeatedly in a short amount of time (as a possible use case, imagine a mouse).
- The characteristic with a 128bit UUID is 20 bytes long. Therefore, it can be written in a single Low Energy transaction.
- Writes occur at a rate of 50 Hz, that is equal to a write once every 20ms.
- Therefore, 20 * 50 * 8 = 8 kbit/s are written.
- I am using the Command / Write without response mode to write the characteristic. Therefore, no acknowledgments happen on the attribute layer.
- No other Bluetooth or Bluetooth Low Energy devices are connected. Nothing is performed over WLAN. No other characteristics are read or written during the tests.
I test the program by sending packets containing sequence numbers from an iPhone 4S. The sequence number is incremented by one after each sent packet.
On the receiving side, a programmable development board, that incorporates a CSR1000 BLE chip, is used that receives the packets and prints the received sequence numbers to the serial connection.
My problems are the following:
After some time, packets start getting dropped. The first ~100 packets work fine @ 50 Hz. From then on, packets start getting dropped.
0x00 - 0x46 received 0x47, 0x48 missing 0x49, 0x4a, 0x4b, 0x4c received 0x4d missing 0x4e, 0x4f, 0x50, 0x51 received 0x52 missing 0x53, 0x54, 0x55, 0x56 received 0x57 missing ...Most often, a pack of four packets is transmitted fine (rarely, only 2 packets). Then, 1-7 packets are missing.
When I reduce the characteristic value size, the problem still persists.
When I write at 100Hz instead of at 50Hz, the picture is the same - only that the drops start occuring after around 35 packets and that 5-7 packets are dropped between the successful transmission of four packets.
With the lost packets, the resulting transmission rate is around 5 kbit/s, regardless of the frequency of writes. This is clearly below the ~305 kbit/s that should be technically possible over Bluetooth Low Energy.
The problem also occurs into the opposite direction, when I am sending packets from the development board to the iPhone 4S. Again, 5 kbit/s is the maximum that I am getting. The Notification mechanism is used for this scenario. Again, no acknowledgments happen on the attribute layer.
When I try to send in both directions simultaneously, things start to blow up to the point where I have to reset both the development board and the iPhone 4S.
Questions:
May this be a problem of the Bluetooth Low Energy chip, that is used on the development board?
If yes, why does the problem also occur into the opposite direction, where the iPhone acts as the receiver?
Are there any development boards on the market that support high-frequency access to characteristics?
What could be the origin of the problem?
Please also try to reference parts of the Bluetooth Spec / presentation slides / articles in addition to assumptions.
There exist Bluetooth Low Energy mice on the market. Mice have typical polling rates of 125 Hz and have to at least send two 16 byte values plus additional HID overhead per tick. Therefore, a solution for my problem should be available.
Update
The LE Connection Complete Event is described in Bluetooth Specification Version 4.0 Vol 2 Part E Section 7.7.65.1. I receive the following values for the different connection parameters:
Parameter Value Description -------------------------------------------------- Conn_Interval 0x0054 Time = 105 ms Conn_Latency 0x0000 Time = 0 ms Supervision_Timeout 0x00fc Time = 2520 ms Master_Clock_Accuracy 0x05 50 ppm
解决方案Issuing a Connection Parameters Update solved the problem and increased throughput from 5 kbit/s to ~33 kbit/s. However, this is still below the expected ~305 kbit/s.
Conn_Interval = 0x000f = 18.75 ms Conn_Latency = 0x0000 Supervision_Timeout = 0x00fcAre there any methods to reach the full ~305 kbit/s?
Follow-Up question on Electrical Engineering Stackexchange
Could get a reply from Apple by burning a TSI and waiting for a month.
Basically, they tell that the behavior is intended in iOS 5.1. It somehow makes sense, because they don't want that your app's performance depends on whether another app uses Bluetooth or WiFi.
Per the engineers comments - Under iOS 5.1 there should be 6 pairs of notifications during a connection interval, meaning 6*packetSize*1000/interval . This should translate to ~55kbps max (min interval is 20ms, packetsize is 23 bytes). We made the decision to limit the number of pairs per interval and have a minimum interval due to the fact that the iPhone and iPad both have shared antenna between BT classic, BT LE and WiFi.
iOS LE is designed to be a low power transport. For higher throughput BT classic is a better transport method.
Back to me - Based on the engineers comments above, if the desire is to achieve a 200 kbs throughput, Classic bluetooth is the answer. However, if the desire is to work with an application on the iPhone, I can understand that this is no simple change - Classic BT requires MFI licensing.
这篇关于蓝牙低功耗 - 重复更新的特征值的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
