• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Question about CBATTRequest.offset
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question about CBATTRequest.offset


  • Subject: Re: Question about CBATTRequest.offset
  • From: Sébastien Martini <email@hidden>
  • Date: Fri, 12 Apr 2013 13:55:16 +0200

Great, thanks.

I guess, I've got a bit lost after reading the sample code "BTLE_Tranfer" where notifications are explicitly sent by chunks. It's not super easy to see at first what the CB framework does implement of the specifications and how much the CB framework assists you.


On Fri, Apr 12, 2013 at 1:39 PM, Etan Kissling <email@hidden> wrote:
Sébastien,

Yep, that's true. You can read about the exact underlying process in 
Bluetooth Core Spec V4.0 Volume 3 Part G Section 4.9.4 and 4.8.3.
 (https://www.bluetooth.org/en-us/specification/adopted-specifications)

Etan


On 12.04.2013, at 13:33, Sébastien Martini <email@hidden>
 wrote:

Ok, thank you Etan I see now.

I've just tested with a long read characteristic value request and indeed it asks for increasing offset values on my peripheral manager delegate method, here is my code:

- (void)peripheralManager:(CBPeripheralManager *)peripheral didReceiveReadRequest:(CBATTRequest *)request {
  NSData *value = ... // my long value
   
  NSRange chunkRange = NSMakeRange(request.offset, [value length] - request.offset);
  request.value = [value subdataWithRange:chunkRange];
 
  [self.peripheralManager respondToRequest:request
                                                       withResult:CBATTErrorSuccess]; 
}

So what happens if I understand correctly is that when I emit a -readValueForCharacteristic: on my central, it internally asks the peripheral to send him the data by issuing requests with increasing offset values and will detect there is no more data to read when a returned chunk is 0 or less than the size of the MTU. Is this correct?

Thanks for your help!




On Fri, Apr 12, 2013 at 1:00 PM, Etan Kissling <email@hidden> wrote:
Sébastien,

BLE allows to send bigger data packets than 20 bytes (Write Long Characteristic Value /
Read Long Characteristic Value). In these cases, the data is split to smaller chunks in which
the offset value may be used in iOS. Note that you cannot increase throughput by using these
values, though.

If you don't use Write / Read Long Characteristic Value procedures, offset should always be 0.

Etan


On 12.04.2013, at 12:51, Sébastien Martini <email@hidden>
 wrote:

> Hi list,
>
> Is there a case in practical where this attribute can have a value different than 0 ?
>
> Given it seems it is already our responsibility to send data by 20 bytes chunks, I don't see where this offset could be different than 0, especially given it is a read-only attribute for us.
>
>
> _______________________________________________
> 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




 _______________________________________________
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

  • Follow-Ups:
    • Re: Question about CBATTRequest.offset
      • From: Etan Kissling <email@hidden>
References: 
 >Question about CBATTRequest.offset (From: Sébastien Martini <email@hidden>)
 >Re: Question about CBATTRequest.offset (From: Etan Kissling <email@hidden>)

  • Prev by Date: Re: Question about CBATTRequest.offset
  • Next by Date: Re: Question about CBATTRequest.offset
  • Previous by thread: Re: Question about CBATTRequest.offset
  • Next by thread: Re: Question about CBATTRequest.offset
  • Index(es):
    • Date
    • Thread