Always peace dude (",)
Likewise if I get to it I will report back, my Bluetooth sniffer is out of
action here at the moment
cheers
-----Original Message-----
From: steve ayer [mailto:[email protected]]
Sent: Wednesday, May 25, 2011 5:08 PM
To: Burns, Adrian
Cc: Eric Decker; [email protected]
Subject: Re: [Shimmer-users] Bluetooth packet fragmentation
=8^O
thanks, will put this on the list to try at some point.
peace,
steve
On 05/25/2011 11:53 AM, Burns, Adrian wrote:
> Hi steve,
>
> Just sending on info Mike Conrad gave me, hopefully it at least concludes the
> way things are on RN-42.... Im happy with that,
> So at the moment it's a case of try using command "SQ,16" or you data will be
> likely chopped up
> I don't care about defending Bluetooth..
>
> cheers,
> Adrian
>
>
> -----Original Message-----
> From: steve ayer [mailto:[email protected]]
> Sent: Wednesday, May 25, 2011 3:46 PM
> To: Burns, Adrian
> Cc: Eric Decker; [email protected]
> Subject: Re: [Shimmer-users] Bluetooth packet fragmentation
>
> hi adrian,
>
> while i admire your stalwart defense of the protocol, i'm pretty sure
> that mike is right; the huge, stringent spec is rife with arbitrariness,
> and this is a prime example, though i don't buy the bit about the lqi
> interdependency. so, we live with it. just like many people live with
> other expensive, crippled, unfixable software bundles.
>
> what can you say?
>
> best,
>
> steve
>
> On 05/25/2011 09:35 AM, Burns, Adrian wrote:
>> To conclude this thread.
>>
>> I contacted Mike in Roving networks to ask him what could we do to stop
>> packets of data sent over SPP on the RN-42 getting fragmented by the RN-42.
>>
>> As expected, he said most of this occurs at the physical layer of the BT
>> stack and depending on the link quality the physical layer makes
>> decisions on data sizes throughout a connection.
>>
>> However, well worth a try would be the method described in section 7.4
>> ("Optimizing for Latency or Throughput") of
>> http://www.rovingnetworks.com/Docs/Bluetooth-RN-UM.pdf
>>
>> .......sending the "SQ,16" command to the RN-42.
>>
>> If you try this and it works, let us know!
>>
>> Regards,
>>
>> Adrian
>>
>> **
>>
>> *From:*[email protected]
>> [mailto:[email protected]] *On Behalf Of *Eric Decker
>> *Sent:* Saturday, May 14, 2011 11:45 PM
>> *To:* steve ayer
>> *Cc:* [email protected]; Phil Reaston
>> *Subject:* Re: [Shimmer-users] Bluetooth packet fragmentation
>>
>> it guarantees delivery. It doesn't guarantee packet boundarys. String of
>> bytes.s
>>
>> On Sat, May 14, 2011 at 3:33 PM, steve ayer<[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> um,
>>
>> "standard tcp programming" practice has a clear understanding that the
>> tcp protocol guarantees delivery of its payload.
>>
>> On 05/14/2011 02:45 PM, Phil Reaston wrote:
>>
>> Don't forget to consider the receiving end too. If you're on windows
>> for instance and you use sockets for the receive rather than a BT COM
>> port then you're going to get partial packets anyway. Standard tcp
>> programming.
>>
>> Phil Reaston
>> Sent from my iPad
>>
>> On May 14, 2011, at 9:44, Benjamin Kuris<[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Similar request went out to Roving Networks about 18 months ago from
>> another customer-- fell on ambivalent ears and there was no indication
>> of intent from RN to support at this level. In fact customer couldn't
>> even get an answer as to the size of the serial FIFO on the module.
>>
>> My understanding is that much of this functionality is defined by CSR
>> Bluecore implementation and RN is just running a command parser in the
>> measly virtual machine cycles they get. So the scheme is also quite
>> complex at the chip level...
>>
>> -Ben
>>
>>
>> On Sat, May 14, 2011 at 12:26 PM, Burns, Adrian<[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Don't disagree steve, the BT stack is overly complicated, and I think we
>> came to the same conclusion before on the SPP MTU discussion(see attached)
>>
>> the RN-42 physical layer seems to send random transmission unit sizes
>> and we assume the Shimmer Bluetooth driver is feeding it full payload
>> bytes continuously without a significant delay between any of the
>> payload bytes...
>> so RN-42 should see the delay after the last payload byte received from
>> MSP, parcel up app SPP data payload, add L2CAP framing and off it goes
>> over the air in whatever baseband transmission unit is big enough to fit
>> around the packet (they are defined in BT spec)....this aint happening
>> obviously on RN-42 and im not 100% sure if it's actually a bug or not
>> I think the only hope to fix this would be if Roving Networks changed
>> their virtual machine firmware to hold its bytes until a programmed
>> transmission unit size is met, then flush out a packet at a time rather
>> than just random chunks
>>
>> I might get ping Roving Networks on this next week if I get a chance,
>> they should be able to get to the bottom of it, otherwise I think this
>> issue may pop its head up again and again :-0
>>
>>
>>
>> -----Original Message-----
>> From: steve ayer [mailto:[email protected]<mailto:[email protected]>]
>> Sent: Saturday, May 14, 2011 3:28 PM
>> To: Burns, Adrian
>> Cc: Nicholas Hosein; [email protected]
>> <mailto:[email protected]>
>> Subject: Re: [Shimmer-users] Bluetooth packet fragmentation
>>
>> hi adrian,
>>
>> that may be, but the bottom line is that the bluetooth physical layer
>> apparently (go ahead, what's the bluetooth mtu?) has no concept of its
>> own transmission units, unlike other wireless protocols like 802.11 and
>> 802.15.4. depending upon payload-transport protocols to keep your bytes
>> together is a pretty taudry way to conduct stateful wireless
>> communications, imho...
>>
>> but as you point out, this is nothing (independent of the os) that a
>> couple of lines of python won't cure. it's just too bad that those
>> lines have to be carted around in middleware, or worse, in applications.
>>
>> $0.02,
>>
>> steve
>>
>> On 05/14/2011 07:44 AM, Burns, Adrian wrote:
>>
>> gents, Just to add here that what you are seeing is normal for SPP as
>> its just a serial interface type profile supporting streams of bytes..
>> If it were OBEX for example then you would have full re-assembly of
>> application level packets, but that's different profiles(OPP and FTP..)
>>
>> L2CAP has segmentation and reassembly to allow transfer of larger
>> packets than lower layers support but this is link level stuff not
>> application level....the chunks of data you see on the host are what the
>> baseband radio segmented and then transferred over the air
>> So as you know, the chunks will arrive at the host in sequence and you
>> have to wait on the host for a few segments until it adds up to 122
>> bytes, then you have a packet...Not ideal I know as I have had to do the
>> very same on android hosts
>>
>> cheers
>>
>>
>>
>>
>> -----Original Message-----
>> From: [email protected]
>> <mailto:[email protected]>
>> [mailto:[email protected]
>> <mailto:[email protected]>] On Behalf Of steve ayer
>> Sent: Friday, May 13, 2011 9:40 PM
>> To: Nicholas Hosein
>> Cc: [email protected]<mailto:[email protected]>
>> Subject: Re: [Shimmer-users] Bluetooth packet fragmentation
>>
>> yup,
>>
>> that's bluetooth for you. for all of the protocol's complexity, you
>> still have to frame your own packets.
>>
>> -steve
>>
>> On 05/13/2011 04:38 PM, Nicholas Hosein wrote:
>>
>> So i noticed when i send a packet from bluetooth (122 bytes / packet) it
>> comes to the host broken up into multiple packets. This is an example of
>> what the host receives when i send 4x122byte packets from the mote:
>>
>> **
>>
>> *Data Size: 1 *
>>
>> *Data Size: 64 *
>>
>> *Data Size: 57 *
>>
>> Data Size: 1
>>
>> Data Size: 66
>>
>> Data Size: 55
>>
>> *Data Size: 4 *
>>
>> *Data Size: 67 *
>>
>> *Data Size: 51 *
>>
>> Data Size: 11
>>
>> Data Size: 54
>>
>> Data Size: 57
>>
>>
>> Is this normal or am i doing something wrong? It would be much easier if
>> i just got one packet instead of having to send a payload and append
>> multiple packets together.
>>
>>
>> Much thanks guys,
>>
>>
>> Nick
>>
>>
>>
>> _______________________________________________
>> Shimmer-users mailing list
>> [email protected]<mailto:[email protected]>
>> https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
>>
>> _______________________________________________
>> Shimmer-users mailing list
>> [email protected]<mailto:[email protected]>
>> https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
>> -------------------------------------------------------------
>> Intel Ireland Limited (Branch)
>> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
>> Registered Number: E902934
>>
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>>
>> -------------------------------------------------------------
>> Intel Ireland Limited (Branch)
>> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
>> Registered Number: E902934
>>
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>>
>> _______________________________________________
>> Shimmer-users mailing list
>> [email protected]<mailto:[email protected]>
>> https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
>>
>> _______________________________________________
>> Shimmer-users mailing list
>> [email protected]<mailto:[email protected]>
>> https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
>>
>> _______________________________________________
>> Shimmer-users mailing list
>> [email protected]<mailto:[email protected]>
>> https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
>>
>> _______________________________________________
>> Shimmer-users mailing list
>> [email protected]<mailto:[email protected]>
>> https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
>>
>>
>>
>>
>> --
>> Eric B. Decker
>> Senior (over 50 :-) Researcher
>>
>> -------------------------------------------------------------
>> Intel Ireland Limited (Branch)
>> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
>> Registered Number: E902934
>>
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>
> -------------------------------------------------------------
> Intel Ireland Limited (Branch)
> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
> Registered Number: E902934
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
-------------------------------------------------------------
Intel Ireland Limited (Branch)
Collinstown Industrial Park, Leixlip, County Kildare, Ireland
Registered Number: E902934
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
Shimmer-users mailing list
[email protected]
https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
