Using DPCM to save bandwith?

alikianalikian
edited August 2014 in Hardware
The transfer speed required for 8 Channel with 24bit in 256 sampling rate is 49kpbs.
The max transfer rate for iOS 7 on BLE (Bluetooth Low Energy) is around 48kps

So I was wondering if we can use DPCM to reduce the bandwidth, basically sending delta of change on each channel.
Here is some DPCM document
http://en.wikipedia.org/wiki/Differential_pulse-code_modulation

I know we can use regular Bluetooth which is faster, but sending less data is allowing to work in higher range

Thanks,
Ali

Comments

  • chipaudettechipaudette
    When we move to Bluetooth, I had also been assuming that we'd need to do something to reduce the data rate. The easiest thing to do is to simply reduce our bit depth from 24-bits to 16-bits. For an 8-channel system, that should get our bit rate to a comfortable place below the BTLE limit.

    Your suggestion to do differential coding is a good one. I don't have any personal experience with it (yet) but it's definitely a good thing to look at. There are other compression schemes out there, too, but I like the conceptual simplicity of the differential coding.

    The real problem comes when moving to more than 8 EEG channels, or it comes when one wants to run at a higher sample rate. 16 channels at 500 Hz at 24 bits is pushing 192 kbps. Getting that to fit on a BTLE connection could require a compression approach that is much fancier...and that won't have too many negative trade-offs.

    Chip

  • alikianalikian
    The DPCM and ADPCM are widely used in Telecommunication industry to save bandwidth.

    The fact about BTLE is that is not design for high speed streaming and you may better of with regular Bluetooth 2.1 EDR.

    As a standard EEG required 21 channels it pushes bandwidth even higher.

    Did you decided on any Bluetooth chip yet?

    Thanks,
    Ali
  • wjcroftwjcroft Mount Shasta, CA
    On the Hardware / ADS1299 electrode impedance measurement algorithm thread, was this exchange between Chip and K. K has a 24 channel implementation running at 500 Hz.
    <blockquote>December 20, 2013 at 7:38 pm

    From: Chip

    How fast are you running your bluetooth link? On some BT modules, a robust consistent connection only seems to be reliable up to 56 kbps, which is quite constraining.

    In my situation, at 250 samples per second at 24-bits per sample times 8 channnels, I’m at 48 kbps of raw data. Given the overhead of the serial link, that is about as fast as a “56kpbs” link will go.

    If you’re doing 500Hz with 24 channels, you’re pumping at least 500 Hz x 24bits x 24channels = 288 kpbs, which is quite a lot of data.

    You’re really doing that over Bluetooth? Which module are you using? How do you have it configured? Have you tried this in multiple locations, or just at one location in your home/lab?

    I’m very curious!

    Chip

    ---

    December 21, 2013 at 11:01 am #492 Reply

    From: K

    Hi Chip,

    I’m using Bluegiga WT12 Bluetooth module. Baudrate between MCU and Bluetooth module is 921600b/s. I’m using SPP profile, so max baudrate in the air can 500kb/s. For this application you must use handshaking and ring buffer.

    K</blockquote>
    So it sounds like the need for compression is a non-issue. Provided we use this fast data rate. Perhaps BLE could be an option, but it imposes too many limitations, does it not?

    I'm sending a copy of this to K and Joel via email, so hopefully they'll comment. Can we verify that Joel is evaluating this Bluetooth chip for our board? Seems like a winning chip.

    Regards, William
  • chipaudettechipaudette
    I appreciate the extra info and the knowledge that the new modules are capable of running at high bit rates. Once design choice that we have to wrestle with is what we want our baseline data rate to be.

    The problem with selecting these high data rates is that they may not be well supported in other bluetooth chipsets...or in devices that utilize bluetooth as their primary interface for accepting in-coming data. Specifically I'm talking about phones and tablets.

    It may be that phones/tablets are oriented towards a paltry 56 kbps rate. If that's the case, it'll be quite a constraint and data compression methods may need to be considered.

    Clearly, more research needs to be done on BT(LE) formats accepted by mobile devices, and then some careful thinking needs to be done for deciding what path makes the most sense moving forward.

    Chip
  • alikianalikian
    There is an issue with Apple products iPhone/iPad.
    Apple doesn't support SPP (Srial Bluetooth) and it has its own iAP protocol
    iAP requires to be member of MFi (Made for iPhone) program, not easy to enter to that program.
    But Android doesn't have this issue.

    Thanks,
    Ali
  • wjcroftwjcroft Mount Shasta, CA
    Here is a list of the Apple iOS supported Bluetooth profiles,

    http://support.apple.com/kb/ht3647

    iOS supports neither SPP nor the more feature-full RFCOMM API.

    I was curious how Emotiv EPOC had dealt with these issues (in the past) and found this,

    http://emotiv.com/ideas/forum/forum15/topic231/

    See comments there about ruling out Bluetooth due to power constraints(!) This was before BLE. They use some kind of proprietary low power Nordic RF chip and a custom USB dongle. Which of course has NO iOS support.

    The yet to be released Emotiv Insight IS using BLE, but it is only 5 channels. Does claim to have iOS support. They must have signed up for this, https://developer.apple.com/programs/mfi/

    Some light reading,
    https://developer.apple.com/hardwaredrivers/bluetoothdesignguidelines.pdf

    ---

    I wonder if K could comment on Bluetooth power drain and battery life with his system. He is using a LiPoly cell (how many milliamp-hours?) What is the planned battery capacity of the OpenBCI device?
  • alikianalikian
    BLE (Bluetooth 4) doesn't required MFi and iOS fully support it.
    But for iOS it limited to:
    30 ms interval * 6 packets * 20 bytes per packet which will be = 4KB/sec

    Bluetooth 2 class 1 or 2 are much faster up 500kbps but iOS required MFi program for that.

    Power consumption of BLE chip from Nordic NRF 8001 is 11 mA at peak.
    And power consumption of Bluetooth 2.1 + EDR from Bluegiga WT12 is 70 mA
  • adminadmin
    It looks like Bluegiga is building on TI's CC2540, which does support high baud rates.
    http://www.bluegiga.com/en-US/products/bluetooth-classic-modules/wt12-bluetooth--class-2-module/
    http://www.ti.com/product/cc2540
    I'm also looking at the Nordic nRF51822 which advertises 1 megabaud uart. The nice folks at RFduino, (whom I supported during their kickstarter!) made a handy module.
    https://www.nordicsemi.com/eng/Products/Bluetooth-R-low-energy/nRF51822
    http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=48872

    It looks like the BTLE Battle is on! I've easily gotten the Adafruit module to work with 8 Channels, and use it during some tests for the convenience. but it's a power hog!
    http://learn.adafruit.com/introducing-bluefruit-ez-link/overview

    There may be a way to get around the iOS-SPP problem. You'd have to reset the pairing fuses on the BTLE stack in order to be visible.
  • alikianalikian
    This is from RFduino for communicating with iPhone
    - 32 kbit/sec at 1.5ft (4000 bytes per second)
    - 24 kbit/sec at 40ft (3000 bytes per second)

    I asked this question from their team, is there any way to increase it and they said no:
    http://forum.rfduino.com/index.php?topic=289.0

  • alikianalikian
    There are another series of Bluetooth UART from SparkFun
    RN41 class 1 and RN42 class 2

    https://www.sparkfun.com/categories/115
  • adminadmin
    There seems to be a change. This part
    http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=48477&cm_mmc=promo_lp-_-rf_digital-_-page_link-_-rfd51822
    is no longer available. Their replacement appears to use a different Nordic core with 8bit 8051. Too bad.
Sign In or Register to comment.

© Vanilla Keystone Theme 2026