hi adrian,
i suppose we could take a look at the driver, but its simplicity belies
the wild variation in transmission size on the part of the module; the
uart pushes bytes in at a regular pace. hard to tell what triggers the
rn module to let them fly.
ah well, as long as we understand the limitation and a clean, simple
work-around, we can wait for a few enhancements to the control layer's
interface. we might try again to encourage rn to look at this.
-steve
On 05/14/2011 12:26 PM, Burns, Adrian 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]]
Sent: Saturday, May 14, 2011 3:28 PM
To: Burns, Adrian
Cc: Nicholas Hosein; [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]] On Behalf Of steve ayer
Sent: Friday, May 13, 2011 9:40 PM
To: Nicholas Hosein
Cc: [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]
https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
_______________________________________________
Shimmer-users mailing list
[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]
https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
