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