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.
_______________________________________________
Shimmer-users mailing list
[email protected]
https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
