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