Hi Travis, Jakub, On Wed, May 11, 2016 at 7:29 PM, Jakub Pawlowski <jpawlowski@xxxxxxxxxx> wrote: > On Tue, May 10, 2016 at 6:23 PM, Travis Griggs <travisgriggs@xxxxxxxxx> wrote: >> The GATT architecture of BLE lends itself to small fixed pieces of data (20 bytes max per characteristic). But in some cases, you end up wanting to “stream” some arbitrary length of data, that is greater than 20 bytes. For example, a firmware upgrade, even if you know its slow. >> >> I’m curious what scheme others have used if any, to “stream” data (even if small and slow) over BLE characteristics. I’m also curious how fast I can expect the bluez stuff to go when it’s having to channel through dbus. I’ve used two different schemes to date. One was to use a control characteristic, where the receiving device notify the sending device how much data it had received, and the sending device then used that to trigger the next write (I did both with_response, and without) on a different characteristic. Another scheme I did recently, was to basically chunk the data into 19 byte segments, where the first byte indicates the number of packets to follow, when it hits 0, that clues the receiver that all of the recent updates can be concatenated and processed as a single packet. >> >> I’m finding bluez pretty slow. Running between iOS and an STMicro chip, I can get around 500bytes/sec. But between iOS and bluez (embedded Linux, python3 with dbus), I’m getting much less, about 125 bytes/sec. The speed isn’t a show stopper. I’m really just curious what schemes (if any) others have used. It might be the connection parameters are not optimal for speed, but also the fact that this goes over D-Bus makes things even slower but I would say it is the major different here. > > Hi Travis, > > For firmware update there is BLE DFU. > For general data transfer: if you can, change MTU to bigger value, it > can go from 23 up to 512. It will depend on controllers on both sides. > Then change connection paramters to make it as fast as possible, > having small connection interval helps alot. > Another thing: for transfering data use Notifications (slave->master) > and Write Command (master->slave). When you use Indications, or > regular Write commands, you can have only one "transaction" happening > at a time. So it takes 2 connection intervals to transfer MTU of data. > Depending on controller, you can send multiple notifications/write > commands during one connection interval ant this should give huge > speed improvement. Best I achieved was around 10 - 20 kb/s, but as I > said, it will depend on controllers and connection parameters. Well that taken out the possibility to use L2CAP channels directly which should prevent interleaved GATT commands which can block the channel for up to 30 seconds, it really beats me how vendor even consider doing DFU over GATT since the transfer can stall at any point and the default behavior is to disconnect if the channel timeout, besides in L2CAP CoC you can have a MTU of up to 64K which should translate in much better transfer speed. -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
