在交换数据包BLE接收 [英] Packets swapped on BLE receive

问题描述

首先，一个简短的介绍给应用程序。
我们正在开发使用单个特征（硬件限制）到客户端UWP应用超过BLE发送数据的无线传感器。这些消息的规模从不到20字节，512字节。该消息由一个起始字符（start_char），preamble，数据，CRC检测错误和结束字符（end_char）的。如果消息中出现这些特殊字符，它们逃脱了。

First of all, a short introduction to the application. We are developing a wireless sensor that sends data over BLE using a single characteristic (hardware limitation) to a client UWP app. The messages vary in size from under 20 bytes, to 512 bytes. The messages consist of a start character (start_char), preamble, data, CRC for detecting errors and an end character (end_char). If these special characters occur inside the message, they are escaped.

在客户端消息处理包括以下内容：

Message processing on the client side consists of the following:

1. 监听的GattCharacteristic的Characteristic.ValueChanged事件。


2. 传递所产生的字节数组它建立消息的分析器。


3. 使所得到的消息，国米pretation设备对象。

如果该消息是超过20个字节时，该BLE层自动拆分成多个较小的字节数组，其中每个触发Characteristic.ValueChanged事件。
分析器由一个AddBytes（字节[]数据）的方法，它开始直到收到end_char在收到start_char并存储后续数据一封新邮件，然后计算该消息的CRC并将其传递。

If the message is larger than 20 bytes, the BLE layer automatically splits it into multiple smaller byte arrays, each of which triggers a Characteristic.ValueChanged event. The parser consists of an AddBytes(byte[] data) method, which starts a new message when it receives a start_char and stores subsequent data until it receives an end_char, then calculates the CRC of the message and passes it on.

接收超过20个字节较大的消息时出现问题，它看起来像一些20字节长的阵列越来越交换。以下图片显示了，进行调试，设置为重新present三角波（2上升）一个512字节的消息。我已经标示出其中的数据被破坏的地点。

The problem occurs when receiving messages larger than 20 bytes and it looks like some of the 20 byte long arrays are getting swapped. The following pictures shows a 512 byte message which, for debugging purposes, was set to represent a triangle wave (2 rises). I've marked out the places where the data gets corrupted.

IMG1
IMG2

起初我以为这是一个线程的问题，因为在一个单独的线程每Characteristic.ValueChanged事件触发（我可能是错的这一个），所以我尝试使用这样的：

At first I thought that this was a threading issue, because every Characteristic.ValueChanged event fires on a separate thread (I might be wrong about this one), so I tried using this:

public class ScheduledBuffer : MessageBuffer
{

    #region Fields / Properties

    TaskScheduler scheduler;
    TaskFactory taskFactory;

    #endregion

    #region Methods

    #region Constructors        

    public ScheduledBuffer() : base()
    {
        scheduler = TaskScheduler.FromCurrentSynchronizationContext();
        taskFactory = new TaskFactory(scheduler);
    }

    #endregion

    #region Private Methods

    void ProcessByteArray(byte[] buffer)
    {
        foreach (byte b in buffer)
        {
            ProcessByte(b);
        }
    }

    #endregion

    #region Public Methods

    public override void AddBytes(byte[] newData)
    {
        taskFactory
            .StartNew(() => { ProcessByteArray(newData); })
            .ContinueWith(t => { });
    }

    #endregion

    #endregion

    #region Events        

    #endregion

    #region Commands        

    #endregion

}

我们的目标是要排队20字节长数组进行处理，这样我就不会开始处理previous一人之前完成一个新的数组。
ProcessByte（字节b）是MessageBuffer的方法，并采取逸出后，加入到新的消息缓冲器的照顾。当它得到一个end_char，它通过的messageReceived事件将消息传递到潜在的用户。

The goal was to queue the 20 byte long arrays for processing so that I wouldn't start processing a new array before the previous one was done. ProcessByte(byte b) is a method of MessageBuffer and takes care of escaping and adding to the new message buffer. When it gets an end_char, it passes the message to potential subscribers through a MessageReceived event.

这有什么错这个实现，或者是有可能的BLE层交换的字节数组它给我的通知的ValueChanged之前？这种行为有什么其他可能的来源可能有呢？

Is there anything wrong with this implementation, or is it possible that the BLE layer is swapping the byte arrays before it gives me the ValueChanged notification? What other possible sources for this behavior could there be?

作为一个方面说明，应用程序正在为Android和iOS还开发了，有没有这样的问题，无论是对这些平台。

As a side note, the app is being developed for Android and iOS also, and there is no such issue on either those platforms.

值得一提的另一件事是，运行更强大的机器上的应用程序的时候，而在我的Lumia 640我很少得到正确的消息，这些错误的频率降低。

Another thing worth mentioning is that the frequency of these errors decreases when running the app on a more powerful machine, while on my Lumia 640 I very rarely get a correct message.

推荐答案

一个任务是在一个线程池协同程序运行，所以你可能会或可能不会实际在多线程方面取决于处理器的功耗和设备上运行，但这个问题肯定看起来像某种形式的竞争状态。

A Task is a coroutine run on a threadpool, so you may or may not actually be running in a multithreaded context depending on processor power and device, but this issue definitely seems like a race condition of some kind.

是有可能的BLE层交换的字节数组它给我的通知的ValueChanged前？

is it possible that the BLE layer is swapping the byte arrays before it gives me the ValueChanged notification?

它种有，除非该通知的ValueChanged还包括一个的新的的字节数组的引用。不知道更多，我猜，有一个在BLE侧单重用缓冲区，它的读入同一组字节一遍又一遍，而你只是赛车它与下一组覆盖之前阅读。

It kind of has to, unless the ValueChanged notification also includes a reference to a new byte array. Without knowing more, I'm guessing that there's a single reused buffer on the BLE side and it's reading into the same set of bytes over and over, and you're just racing to read them before it overwrites it with the next set.

尝试复制字节缓冲区到一个新的字节数组（ .Clone（）用途是罚款原始类型的数组，它会做一个深，因为副本有字节数组内）内AddBytes或克隆阵列传递到一个新的任务，看看问题是否仍然存在之前没有提及事件处理函数（取同一个线程从BLE层读取上）。

Try cloning the byte buffer to a new byte array (.Clone() use is fine for a primitive type array, it'll do a "deep" copy since there are no references inside byte arrays) inside AddBytes or your event handler (whichever is on the same thread as the read from the BLE layer) before passing the cloned array to a new Task and see if the problem persists.

这篇关于在交换数据包BLE接收的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！