Re: data transmission rate...to slow...
Re: data transmission rate...to slow...
- Subject: Re: data transmission rate...to slow...
- From: Chris Herbert <email@hidden>
- Date: Thu, 11 Apr 2013 13:52:56 -0700
The secret sauce in BLE low energy is restricting the packet size.
Think about this way. Yelling across a football field the pledge of allegiance takes a lot of effort. Yelling across a football field "Hike!" is a lot easier and can be done repeatedly without wasting energy.
If you are looking for speed and larger packet sizes. I suggest Bluetooth 2.1 or even 3.0. MFi supports this.
-Chris
On Apr 11, 2013, at 12:00 PM, email@hidden wrote:
> Send Bluetooth-dev mailing list submissions to
> email@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.apple.com/mailman/listinfo/bluetooth-dev
> or, via email, send a message with subject or body 'help' to
> email@hidden
>
> You can reach the person managing the list at
> email@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bluetooth-dev digest..."
>
>
> Today's Topics:
>
> 1. data transmission rate...to slow... (Frederic Visticot)
> 2. Re: data transmission rate...to slow... (Etan Kissling)
> 3. Re: A2DP with AAC codec: non-existent document reference in
> the "Bluetooth Accessory Design Guidelines for Apple Products"
> (John Westing)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 11 Apr 2013 14:54:49 +0200
> From: Frederic Visticot <email@hidden>
> To: "email@hidden" <email@hidden>
> Subject: data transmission rate...to slow...
> Message-ID:
> <email@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I have made some tests to exchange data between 2 iDevices (iOS6
> iPad3/iPhone5) using CBPeripheralManagerConnectionLatencyLow settings.
>
> The maximum rate I have is 1135 bytes / s (1.1KB/s)
>
> - Is it possible to get better speed ?
> - What is the maximum I can have with iOS stack ?
>
>> From some documents:
> BLE: 200kbits/s -> 25KB/s
> NFC: 424kbits/s
>
> Why is the difference so huge (20x slower) ?
>
> Fred
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.apple.com/mailman/private/bluetooth-dev/attachments/20130411/1cc86336/attachment.html>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 11 Apr 2013 13:00:45 +0000
> From: Etan Kissling <email@hidden>
> To: Frederic Visticot <email@hidden>
> Cc: "email@hidden" <email@hidden>
> Subject: Re: data transmission rate...to slow...
> Message-ID:
> <email@hidden>
> Content-Type: text/plain; charset=iso-8859-1
>
> Frederic,
>
> there is only one packet of up to ~20 bytes transmitted every two connection events if you use reliable data transfer.
>
> If you want to increase that to ~ four packets every connection event, you have to use unreliable data transfer (WriteWithoutResponse / Notification)
> and have to add reliability in your app layer.
>
> Note that WiFi interferes with BLE, disabling it should net you a small boost in throughput.
>
> These are the throughputs I could achieve with iPhone as central and dedicated peripheral: http://www.scriptreactor.com/conn_interval-throughput.pdf
>
> Etan
>
>
> On 11.04.2013, at 14:54, Frederic Visticot <email@hidden>
> wrote:
>
>> I have made some tests to exchange data between 2 iDevices (iOS6 iPad3/iPhone5) using CBPeripheralManagerConnectionLatencyLow settings.
>>
>> The maximum rate I have is 1135 bytes / s (1.1KB/s)
>>
>> - Is it possible to get better speed ?
>> - What is the maximum I can have with iOS stack ?
>>
>> From some documents:
>> BLE: 200kbits/s -> 25KB/s
>> NFC: 424kbits/s
>>
>> Why is the difference so huge (20x slower) ?
>>
>> Fred
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Bluetooth-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 11 Apr 2013 11:04:36 -0400
> From: John Westing <email@hidden>
> To: email@hidden
> Subject: Re: A2DP with AAC codec: non-existent document reference in
> the "Bluetooth Accessory Design Guidelines for Apple Products"
> Message-ID:
> <CAPjuhm69R=_3CzLmbD=email@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Apologies, I mis-spoke. RFC 3016 says that the RTP Market Bit will specify
> AudioMuxElement() boundaries, not the muxConfigPresent argument. This is
> the part of the spec that Apple does not follow: they do not set the RTP
> Market Bit to 1 which signals that a complete AudioMuxElement() has been
> received. If you are writing an application-specific LATM depayloader then
> that is fine, but existing LATM depayloaders that follow the spec will not
> be able to decode the data unless the RTP Market Bit is forced to one
> before being passed to the depayloader. Pretty weak.
>
>
>
>
> On Tue, Apr 9, 2013 at 9:47 AM, John Westing
> <email@hidden>wrote:
>
>> I was never able to find the document ISO/IEC 13818-3:2005, but ISO/IEC
>> 14496-3:2005 contained the information I needed to decode
>> AudioMuxElement(). It does seem however that Apple does not follow the RTP
>> spec, RFC 3016, correctly though. Apple's Bluetooth Design Guidelines
>> document states that: "The muxConfigPresent argument to the AudioMuxElement
>> is set to 1 (in-band mode), as recommended in Section 4.1 of RFC 3016." And
>> if you look at RFC 3016 it states that the RTP Marker Bit is used to
>> specify muxConfigPresent, but in the Apple's case the RTP Market Bit
>> received is always 0, which makes existing RTP LATM parsers unable to parse
>> Apple's packet. Either an Apple-specific LATM parser must be written which
>> assumes muxConfigPresent is always 1, or the bit must be set to 1 at higher
>> level before passing to the LATM parser.
>>
>>
>>
>>
>> On Thu, Apr 4, 2013 at 4:40 PM, John Westing <email@hidden
>>> wrote:
>>
>>> Shawn,
>>>
>>> Did you ever find the answer to your question? I am stuck in a similar
>>> situation, but it sounds like you have gotten further than me. I don't
>>> understand the explanation of the packet header given in
>>> https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf,
>>> and like you I can't find a document titled ISO/IEC 13818-3:2005, the
>>> latest version I could find was from 1998.
>>>
>>> If the AVDTP header is the header found in Figure 4 of RFC 3016 then the
>>> RTP Market Bit (audioMuxElement for LATM) should always be 1 according to
>>> the Bluetooth Design Guidelines PDF. I'm not seeing that, I decoded the
>>> data with Wireshark (v1.9.2) and the bit is always 0.
>>>
>>> Do I have something configured wrong? How did you figure out how to
>>> bypass the RTP header and get to the AAC audio? I took a look at the
>>> document you mentioned, ISO/IEC 14496-3:2005, but it looks like this
>>> document gives an algorithm for decoding the packet and does not give the
>>> actual breakdown of fields in the packet.
>>>
>>> I'm trying to use built-in GStreamer elements to decode the RTP but I'm
>>> not having any luck. I'm wondering if I need to write own GStreamer plugin.
>>> I tried the rtpmp4adepay element to decode the data but the element gets
>>> hung waiting for the Market Bit/audioMuxElement bit.
>>>
>>> Any help is appreciated.
>>>
>>> Thanks,
>>> Sam
>>>
>>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.apple.com/mailman/private/bluetooth-dev/attachments/20130411/ccd9bf67/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> Bluetooth-dev mailing list
> email@hidden
> https://lists.apple.com/mailman/listinfo/bluetooth-dev
>
> End of Bluetooth-dev Digest, Vol 10, Issue 96
> *********************************************
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden