yes, but not necessarily in an arbitrary "packet" of user data. Phil Reaston CTO, iDi-dx Phone: (702) 291 8245 www.idi-dx.com
Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. The company accepts no liability for any damage caused by any virus transmitted by this email. On Sat, May 14, 2011 at 3:33 PM, steve ayer <[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]> 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 >> >
_______________________________________________ Shimmer-users mailing list [email protected] https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
