Ganglion/Simblee streaming Bluetooth to Android Studio Project?

NaughtiusMaximusNaughtiusMaximus San Diego, California
edited October 2018 in Ganglion
Hello Everyone!

I am thinking of buying a Ganglion.  I have another EEG headset that streams EEG to an Android application which I developed with Android Studio.  I'd like to use the Ganglion instead of the other headset.

So here is my question:
Does the firmware in the Ganglion/Simblee make it difficult or prevent interaction with my Android application?  Or is one restricted to just use the "SimbleeForMobile" from Google Play?

A second question:
Has anyone here developed a non-SimbleeForMobile for either iOS or Android with the Ganglion?

I presume that one could always replace the firmware that ships with the Ganglion, but I am hoping for minimal development effort.

Thanks in advance!
Max
«1

Comments

  • wjcroftwjcroft Mount Shasta, CA
    Max, hi.

    See these related threads,


    re: SimbleeForMobile. No, this is not used.

    Unfortunately due to the packet loss situation with Android, receiving the Ganglion stream there is not yet possible. See the threads for more discussion. Using an OTG adapter with the BLED112 dongle on your Android device, looks the most promising. If you have some time to develop the interface.

    Regards,

    William

    PS also related BLED112 threads


  • NaughtiusMaximusNaughtiusMaximus San Diego, California
    Thanks, William.  I shall study the information you supplied.
  • wjcroftwjcroft Mount Shasta, CA
    Can you mention what other EEG device you have working with your app? What radio protocol does that device use, is it Bluetooth, Wifi, etc.? Ganglion can use wifi via the optional Wifi Shield. Simblee is a Bluetooth Low Energy (BLE) device, sometimes referred to as Bluetooth 4.0. The earlier generations 3.x and 2.x support streaming of serial data at higher rates of speed than BLE, which is intended for smaller data transfer, for example from heart rate monitors.
  • NaughtiusMaximusNaughtiusMaximus San Diego, California
    Hi William,

    I used the Muse headband.  It is a great device, but does not quite suit my purposes.  I was able to stream four channels with the Muse via BLE to an Android tablet with no packet loss.  I then was experimenting with the Texas Instruments CC2640 evaluation board, which is an ARM Cortex M3 combined with BLE.  I was able to stream data equivalent to four channels of EEG data with no packet loss, but initially, I had high packet loss with the CC2640.  As it turns out, a key call to prevent packet loss was setting the connection priority to HIGH on the Android side during initialization:
    // See "Connection Parameters" here: http://software-dl.ti.com/lprf/simplelink_cc2640r2_sdk/1.00.00.22/exports/docs/blestack/html/ble-stack/index.html
    gatt.requestConnectionPriority(CONNECTION_PRIORITY_HIGH);

    Could this be the issue with the packet loss with Android devices and the Ganglion?

    Max
  • wjcroftwjcroft Mount Shasta, CA
    Muse samples are significantly smaller, 10 or 16 bits. Which size were you using? Ganglion's are 24 bits, and delta compressed @ 200 Hz. 

    I'll mention Florian @fwende, who found the packet loss.
  • wjcroftwjcroft Mount Shasta, CA
    Oops, I was looking at the old 2014 Muse specs, the 2016 spec shows 12 bit samples @ 256 Hz.
  • wjcroftwjcroft Mount Shasta, CA
    So if you can stream the Muse data over BLE, it might be possible to modify the Ganglion firmware to use the same BLE data format. The 24 bit samples could be high pass filtered at say .5 Hz on the Simblee. That would remove the DC offset, then you could truncate your samples (taking mid range of the 24) to 12 bits. 

    This has been mentioned before by AJ @pushtheworld, the dev responsible for both Ganglion firmware and the GUI / Hub.

    I was not aware that Muse does just fine at 256 Hz with 4 channels over BLE. 


    I thought I heard somewhere that Muse's protocol was proprietary / secret? Or maybe that was Emotiv's protocol. Is the document on their protocol available online? Link? So that would be interesting if Ganglion could have a config option to use either the original BLE protocol, or Muse's version. Might result in more sales of the Ganglion, especially for Android developers. Provided Muse doesnt sue us(!)

    Regards,

    William

  • NaughtiusMaximusNaughtiusMaximus San Diego, California
    Hi William,

    * As you imply, it is a question of the throughput from the Ganglion to the Android device via BLE.  Very roughly, the Muse data-packet size is 32 bytes (four Java doubles), so 4 x 8 x 256 = 8192 bytes/second.  But I don't know if Muse compresses the data.

    * From my notes, with the TI CC2640 over BLE, I was able to transfer an uncompressed packet of 200 bytes every 100ms (2000 bytes/second) for 12 hours with no packet loss.  I can't remember if I tried higher throughput.

    * I don't know if Muse has anything proprietary, but they freely provide the SDK.  For Android, I used the Muse Java libraries.  From the application's view, Muse gives you an instance of the 'MuseDataPacket' class, which has methods such as 'MuseDataPacket.getEegChannelValue(Eeg.EEG1)'.  It all works very well.  But I have no idea what goes on behind the scenes.

    * I'd agree that it should be possible to stream a couple of EEG channels or all four truncated channels from the Ganglion to an iPhone/Android device via BLE with no packet loss.  I'd speculate that the Muse data that rides upon the BLE protocol is probably fairly simple.  I defined such a packet type for my tests with the Texas Instruments CC2640, which was trivial once I learned the intricacies of the BLE protocol.

    Regards,
    Max

  • wjcroftwjcroft Mount Shasta, CA
    Max, thanks. Found this,



    So while Muse might allow individuals to decipher their proprietary radio packet format -- they might look at a potential 'competitor' differently. So would probably require an official blessing from Muse to offer such a Ganglion emulation.

    A significant complication is that the ADC on Ganglion is running at 200 Hz sample rate, whereas Muse is 256 Hz. Ganglion can internally change that rate to 400, 800, etc. So an oversample then downsample to 256 could be possible. But with these two strikes: sample rate and legal issues, Muse emulation looks unlikely. 

    And yet, the idea of removing the DC offset and truncating the sample width, is still valid.

  • NaughtiusMaximusNaughtiusMaximus San Diego, California
    Hi William,

    I must confess, I don't see the advantage of using the Muse packet format, unless someone does not want to need to change their, e.g., Android application.  I'd think Muse would be happy if someone's mobile application used their protocol if Muse's desire is to sell more headbands.

    So getting back to packet loss with the Ganglion: is there packet loss when streaming data when using the 'OpenBCI_GUI' with a PC and the 'CSR 4.0 Bluetooth Dongle' running in BLE mode?

    It would be a win-win for everyone if we could get no packet loss with the Ganglion and an iOS/Android device via BLE.  It would really help me out a lot!!!

    Best regards,
    Max
  • wjcroftwjcroft Mount Shasta, CA
    No packet loss with the GUI, using either CSR or BLED112 dongles.

    However OpenBCI_Python (which only runs on Linux with the CSR), some users have seen packet loss. This is probably due to the slower Python execution.

    If you want to get Android working with Ganglion, I highly suggest browsing those other threads mentioned earlier, and adapting the BLED112. Much of the code that @fwende wrote as far as decompression / packet parsing is reusable. You just have to add a 'wrapper' that pulls the data off off the BLED112 (which looks like a serial USB port). Then use an OTG adapter to plug the BLED112 into your tablet or mobile device. Most Android devices now support OTG.



    Also see this thread.


    There is a clear and relatively high demand for Android to work with Ganglion. You might be the hero.  :-)

  • wjcroftwjcroft Mount Shasta, CA
    To clarify: "However OpenBCI_Python (which only runs on Linux with the CSR), some users have seen packet loss."

    I'm not sure now, I think most Linux users are utilizing the built in BLE hardware / software in their laptops. So packet loss may vary in that case depending on whether a dongle is used or built-in.
  • NaughtiusMaximusNaughtiusMaximus San Diego, California
    Hi William,

    Thanks again for all your insights and responses.

    I am getting the impression that packet-loss or lack thereof is dependent on the amount of buffering in the BLE device and the responsiveness of the application/OS combination.  I suspect that a non-realtime operating system could occasional not service the buffer before it is over-written.

    To get the Ganglion working with an Android device, I guess I'll have to experiment with the Ganglion.

    A few questions:

    (1) Does AJ @pushtheworld tend to be active and responsive to questions?

    (2) Is the Ganglion firmware source code freely available?

    (3) Has anyone had no packet loss with the Ganglion streaming to an iPhone?

    (4) For my purpose, I need to stream only one channel.  Is one able to command the Ganglion to stream only one channel thus reducing 3/4 of the needed throughput?

    Many thanks!
    Max



  • wjcroftwjcroft Mount Shasta, CA
    Max, hi.

    1. Yes, just click on his user name in your last post and then click on the Message button to send him a PM.

    2. Yes, all OpenBCI source on Github, 


    3. I have not heard of any reports with iOS yet. AJ once mentioned trying with Swift. There have been packet loss issues with macOS on certain hardware platforms, where the BLED112 is used as the solution.

    4. This is not built in, but you could mod the firmware. @fwende was also considering a similar approach, by reducing sample rate to 100 Hz. Although 100 is going to lose some of the upper bands of the EEG. He may be open to collaborating on some type of firmware workaround. You can PM him also by clicking on his name.

    5. Sorry if I'm harping on this, but the BLED112 might be the best long term solution. Benefitting both you and future Android users. Examples of BLED112 usage in the previous links I gave, as well as the Hub code.


    Regards,

    William

  • NaughtiusMaximusNaughtiusMaximus San Diego, California
    Hi William,

    I'll likely order the board soon.  I am discussing it with my partners-in-crime.  I'll keep you and the forum updated.

    Thanks,
    Max
  • fwendefwende
    Hi Max,

    Those are some very interesting points.

    Regarding iOS, I have heard from others working on it, that it seems to be stable from the iPhone 6s and up, as well as Pixel 2 and up. Might be that if the cpu is powerful enough, Android and iOS can deal with it.
    However I haven't worked with iOS yet. As for the device comparison for Android you can see the packet loss thread, which William linked, but the devices only had midrange chips in them. 

    I haven't really been working on this issue, since with the Java library I posted it worked well enough for our purpose at around 6% packet loss. We currently switched to Unity for cross-plattform support among other things and have been having some issues with around 20% packet loss.
    I'll look into the connection priority and other ideas you posted hopefully either tomorrow or the week after next week, as I ll be away until the 14th.

    If you have any questions about the java code please let me know.




  • NaughtiusMaximusNaughtiusMaximus San Diego, California
    Hi Florian,

    I haven't worked with Unity, so I plead ignorance there.  But if you go from 6% packet loss with the Java library to 20% with Unity (same platform?), could it, as you say, simply be a CPU loading?  Maybe increasing the thread priority of the thread that reads incoming packets would help?

    I'll be on vacation this coming week too.

    Thanks,
    Max
  • fwendefwende
    edited October 2018
    @wjcroft I did some tests and here are the results with a Huawei Mediapad T3 10 and a Oneplus 5T:

    Mediapad T3 10
    High priority
    Lost: 86 out of 12473 % of loss= 0.6894892968812635
    Lost: 90 out of 15816 % of loss= 0.5690440060698028

    No priority
    Lost: 979 out of 11806 % of loss= 8.2923936981196
    Lost: 2458 out of 24895 % of loss= 9.873468567985539

    Oneplus5T
    High priority
    Lost: 82 out of 25652   % of loss= 0.3196631841571807
    Lost: 82 out of 16721   % of loss= 0.4904012917887686
    Lost: 82 out of 13898   % of loss= 0.5900129515038135

    No priority
    Lost: 655 out of 14426 % of loss= 4.540413142936365
    Lost: 544 out of 7635 % of loss= 7.125081859855927
    Lost: 613 out of 12035  % of loss= 5.093477357706689

    No priority was tested using the code similar to the github version and High priority was using the line of code @naughtiusMaximus posted in this context
    @Override
    public void onServicesDiscovered(BluetoothGatt gatt, int status) {
        if (status == BluetoothGatt.GATT_SUCCESS) {
            Log.v(TAG,"GattServer Services Discovered");
            broadcastUpdate(ACTION_GATT_SERVICES_DISCOVERED);
            gatt.requestConnectionPriority(CONNECTION_PRIORITY_HIGH);
        } else {
            Log.w(TAG, "onServicesDiscovered received: " + status);
        }
    }
    Some things to note: the roughly 100 packets dropped in High priority mode, drop at the start of the connection / during the impedance check in our app. Once the connection is established it seems to be lossless.
    The other things is with the Mediapad having a Snapdragon 425 and the Oneplus 5T having a Snapdragon 835 and the difference in packet loss between those two, I would say it is confirmed that the CPU makes a significant difference.

    I will update the Github code to include this and a few other tweaks soon.

  • wjcroftwjcroft Mount Shasta, CA
    Florian @fwende, that's great news! So it appears that your neurofeedback app will be able to utilize Ganglion. And that your Java / Android library will be of great help to other OpenBCI users. It seems like even the initial packet loss could be worked around, by some type of code modifications (delaying until the connection has stabilized.)

    Thanks so much to Max for pointing this out.
  • wjcroftwjcroft Mount Shasta, CA
    Can you apply this fix to your Unity version as well?
  • fwendefwende
    That's definitely great news. 
    Oh for sure, that's just because of the way the data is sent to the ganglion in our deprecated Java app. I believe if you have a delay between commands sent to the ganglion then it shouldn't be an issue.

    Also a big thank you to Max from me!

    We are using a modified version of a bluetooth asset from the unity asset store. In case you are not familiar with it, you can buy/download assets(plugins) and implement them fairly quickly to save time.
    We use this asset currently https://assetstore.unity.com/packages/tools/network/bluetooth-le-for-ios-tvos-and-android-26661, because it also supports iOS, which we haven't tested, but would like to implement in the near future.

    The thing with this asset is, that the java interface, which is called in the c#, is a compiled jar file. I will talk to the developer first, to see if we can get this added in a clean way, but if not, then there are other ways :) 


  • NaughtiusMaximusNaughtiusMaximus San Diego, California
    Hi Florian and William,

    My partners and I am going to order the Ganglion!  I am going on vacation now, but I'll study more if I have spare time during vacation.

    I look forward to using the Ganglion when I am back in town.

    Many thanks to you both!

    Best regards,
    Max
  • wjcroftwjcroft Mount Shasta, CA
    Florian, I also suggest that you make an announcement on the Community area of the main website,


    Your Android Ganglion library might also get mentioned in our OpenBCI email newsletter, sent out to customers and backers. Mentioning @openbci.

    I'll go through the various posts on the forum here regarding your library (and previous packet loss), and add updates with the correct information. Once you have everything in shape on your Github.

    Regards,
  • fwendefwende
    Sure, I will make a post. I will try to get it up by the end of the week after the coming one, as I will be away the coming week. I will let you know once it is done.
  • fwendefwende
    @wjcroft

    Good news, I have updated the Android library to include a couple of things such as the connection priority, but also 18Bit decompression and impedance check. More info in the Readme here:


    Let me know if you have any questions.
  • NaughtiusMaximusNaughtiusMaximus San Diego, California
    Hi Florian and William,

    Great news!  My Ganglion board has arrived.  So far all looks great.  I'm working with the OpenBCI_GUI now.  In a few days I'll see if I can connect to my Android application.  I'll keep you posted.

    Many Thanks!!!
    Max
  • wjcroftwjcroft Mount Shasta, CA
    Florian @fwende, that is wonderful news. Thanks for making this available.

    I'm imagining that Max @NaughtiusMaximus will be testing with your repo very soon. Possibly finishing up some final pieces such as the microvolts scaling. It would also make sense to test on a few different Android platforms of various performance levels / OS versions. So for example, those incorporating the library might know to avoid certain mobile devices that are "on the edge" of not having enough horsepower.

    As soon as that testing is complete, it would be great to announce this on the Community page,


    And @Shirley could add a paragraph to the next OpenBCI @openbci newsletter that goes out. There might even be some sample Android demo apps posted at that point; such as displaying the raw EEG channels, or recording to a file.

    Regards,
  • NaughtiusMaximusNaughtiusMaximus San Diego, California
    Hi Florian and William,

    I am integrating the repo now.  I am having a little problem, with which maybe you could help.

    I am adding the dependency (implementation 'com.github.Brain-Hero:GanglionAndroidBluetooth:Tag') to the 'build.gradle' app file, which I generated from the JitPack website :


    dependencies {
        ...
        implementation 'com.github.Brain-Hero:GanglionAndroidBluetooth:Tag'
    }

    and get this error in Android Studio:
    "Failed to resolve: com.github.Brain-Hero:GanglionAndroidBluetooth:Tag". 

    Am I missing something here?  Maybe the version?

    Thanks,
    Max
  • fwendefwende
    @NaughtiusMaximus ;
    I don´t have experience with JitPack, but from looking at the homepage, it seems like the issue might be that I didn´t add a release on Github yet. 
    I added a release now, maybe you can get it working with that:

    The scaling can be added any time. I didn´t add it because I thought that if the data is not processed in the same location and maybe sent to a different activity, it is more efficient to send them as integers and not as float variables. 
    Sounds good, let´s wait a bit to see if there are any issues first.
    As for the Android version, as long as the Version is 5.0+ it shouldnt not make a difference. 
    The processing power plays a role, but it is negligible with the high connection priority. The Huawei Medipad T3 10 we tested with has a Snapdragon 425 which is on the very low side of the performance spectrum. 
  • NaughtiusMaximusNaughtiusMaximus San Diego, California
    Hi Florian,

    I spent a short time trying to add the library, but on luck.  I suppose I could adapt the source code in the library as a last resort.

    Thanks,
    Max
Sign In or Register to comment.

© Vanilla Keystone Theme 2024