Ganglion dropped packets, using CSR dongle with Raspberry.

JM123JM123 Slovakia
edited September 2018 in Ganglion
Hello,
I'm working on BCI python software and I'm using for this purpose ganglion board and raspberry pi 3 with csr dongle, the quality of BLE data transmission is not very good (usually on average 1 lost packets per 2 second). Because ganglion use delta compression, when 1 packet is lost,  it affects data afterwards (until I receive raw packet, which contains real data, not deltas). it looks like big jump and after i get raw packet there is jump back. Did anyone work on this type of issue ? What is the best way to reconstruct lost packet ?
Thanks

Comments

  • wjcroftwjcroft Mount Shasta, CA
    edited September 2018
    JM, hi.

    The lost packets cannot be reconstructed. See this related thread,


    There is a more reliable dongle that can be used, called the BLED112. But the existing OpenBCI_Python code does not talk to it. However the OpenBCI_GUI DOES speak to the BLED112. And the GUI can create a LabStreamingLayer (LSL) or Open Sound Control (OSC) data stream. That data stream could then be consumed by Python calling the LSL library.

    Regards,

    William

  • JM123JM123 Slovakia
    edited September 2018
    hi William,
    thanks for your reply. Idea to use BLED112 looks interesting. I would like to try to write something with it in python.
    I already tried improving bluetooth connection by testing many combinations of conn_min_interval and conn_max_interval, (it proved that 8,8 for Rasp. is best), but despite that, the results are as I wrote.

    It is not so important to reconstruct lost data, but is there a way to remove these lost packets jumps ?  I tried to find some patterns in data (after dropped packet), which can adjust to remove these jumps, but I didn't succeed. Any ideas ?
  • wjcroftwjcroft Mount Shasta, CA
    Because the delta compression depends on previous packets, the packet loss results in indeterminate samples. I don't believe you can 'adjust', other than to wait for the next uncompressed sample point.

    The big advantage of the BLED112 is that it contains sufficient BLE buffering, independent of the OS and USB serial drivers. Such buffering can compensate for OS and driver latencies. CSR has no such capability. Moreover the CSR approach depends on adequate processor scheduling / availability from all the relevant layers: kernel, driver, user process, etc.

    As I wrote in other thread, it should be possible to adapt the OpenBCI_Python to use the BLED112, since all the packet parsing and decompression remains the same. You just get the raw data stream over the serial port interface, instead of getting it from the BLE / bluepy Python library. And the serial stream can return multiple packets that are buffered. Versus the BLE interface which I think is limited to one transaction.

    I would suggest coordinating with some of the people posting on that other thread, since they were investigating a BLED driver. You can Private Message them by clicking on their user names (bold face), then clicking on the Message button.

    Regards,

  • wjcroftwjcroft Mount Shasta, CA
    https://www.digikey.com/product-detail/en/silicon-labs/BLED112-V1/1446-1030-ND/4245505
  • wjcroftwjcroft Mount Shasta, CA
    BGAPI is the serial API used to talk to the BLED112. Here is a Python implementation,


    Other libraries,


  • JM123JM123 Slovakia
    thanks,
    it looks useful, i'll try to implement it
  • JM123JM123 Slovakia
    edited October 2018
    hello again,
    I tried to run my python code on my laptop - lenovo 20C6003QXS (in VirtualBox - Ubuntu) with CSR dongle. result : 0 dropped packets in 500 seconds. It seems to me, that of openbci_python library is receiving data and parsing data in one thread, so RSP3 with poor performance doesn't catch some packets. Am I right ? If not which aspect make the difference ? Can it be improved, by spliting data handling into multiple Threads ?

    Thanks

  • wjcroftwjcroft Mount Shasta, CA
    Not all Linux CPUs are successful with the CSR dongle. It depends on many factors, CPU performance the primary one. Since the CSR dongle has limited buffering, all BLE drivers / processes must receive optimal CPU scheduling to meet the demands. Your Raspberry likely just does not have enough horsepower. 

    Your statement "I'll try to implement it" (regarding the BLED112 dongle support in OpenBCI_Python), would be a long term solution.
  • JM123JM123 Slovakia
    ok, thanks. I'll use virtual machine for now, but in long term I would like to implement BLED112 dongle support. (I'm technically limited and it will let me to connect also over windows :) )
  • JM123JM123 Slovakia
    edited January 2019

    SOLUTION !!!

    CSR 4.0 dongle wasn't working properly (it should be blinking while using and it doesn't), I solved it by:
    • sudo rmmod btusb     which removes btusb, which is kernel module - bluetooth driver
    • sudo modprobe btusb   which add btusb to kernel
    After these commands CSR works properly. For better quality configure connection interval:
    • sudo bash -c 'echo 8 > /sys/kernel/debug/bluetooth/hci0/conn_min_interval'
    • sudo bash -c 'echo 8 > /sys/kernel/debug/bluetooth/hci0/conn_max_interval'
    0 dropped packets in 500 sec.

Sign In or Register to comment.

© Vanilla Keystone Theme 2026