Thanks guys. I am using bluez on linux for my bt host code. The reason i thought it was the mote code was because one mote would drop off at a time while the others would be displayed on the host fine. Also the motes can receive packets from the host even after the problem takes effect. The problem occurs more frequently as i 1) increase the number of motes, 2) request different data from the mote in addition to the 102 bytes are streaming at 10Hz, 3) I use the lab microwave which interferes with bluetooth (it kills my bt mouse and keyboard quite often).
I do agree though that the motes should be able to function fine under these conditions. Ill take a closer look at my code and get back to you guys. Thanks, Nick On Fri, May 20, 2011 at 8:22 AM, Phil Reaston <[email protected]> wrote: > I had no problem with the windows bt stack at high data rates. Win xp with > the latest updates. Admittedly that was 6 months ago and I haven't touched > it since then. > > Phil Reaston > Sent from my iPad > > On May 20, 2011, at 2:21, mike healy <[email protected]> wrote: > > Hi Nick, > > Just to add to Steve's comments, the one point that springs to mind is how > do you know the problem is on the Shimmer side? If you are using Windows you > should note that the Windows BT stack is notoriously unreliable. The Widcomm > BT stack on Windows is better, but in my own experience if you want > reliability you can't beat bluez on Linux. > > And just as a sanity check I set 4 shimmers transmitting 127 bytes @100Hz > running this morning, and they ran fine for over an hour. This was > transmitting to a Linux machine. When I tried the same think in Windows > Hyperterminal froze and had to be forcibly quit very very quickly (but > admittedly I was running XP within a VMware image, so your mileage may > vary...). > > Mike > > > On Fri, May 20, 2011 at 9:59 AM, steve ayer < <[email protected]> > [email protected]> wrote: > >> hi nick, >> >> the writeDone event indicates that all bytes fed to bluetooth.write have >> been delivered to the bluetooth module; it does not imply anything about the >> state of the module. >> >> two comments, if i may: >> >> 1) four nodes transmitting at 10 hz isn't exactly what i'd call a "heavy >> load." the difference between results running at 1hz and 10 is probably >> just a demonstration of how long it takes for a bug to take its cumulative >> toll. i won't get analytical on you, but at this pace you shouldn't even >> have to wait for the writeDone event to fire off a new packet... >> >> 2) this sounds like you have a bug in your app's state machine (please see >> above). >> >> have fun, >> >> steve >> >> >> On 05/20/2011 02:30 AM, Nicholas Hosein wrote: >> >>> So i am sending 102 bytes of data at 10 Hz from each of 4 motes to a >>> host over bluetooth. >>> >>> On the mote I only send a new packet once the previous one was sent via >>> checking for "event void Bluetooth.writeDone()" from the previous >>> packet. What ive noticed is that under stress the mote stops sending >>> packets altogether (but still receives fine). Even though no packets are >>> being sent from the mote the Bluetooth.writeDone event is still >>> triggered after a write command. Once the connection is reset the mote >>> can send packets again. >>> >>> This only seems to occur under stress. If i were to configure 1 mote to >>> send 102 bytes at 1Hz it would work fine for hours. Under any stress it >>> works for a matter of minuets or seconds. >>> >>> Does the writeDone event necessarily mean that the packet was sent or >>> that it is buffered to be sent? >>> >>> Thanks guys, >>> >>> Nick >>> >>> >>> >>> >>> _______________________________________________ >>> Shimmer-users mailing list >>> <[email protected]>[email protected] >>> <https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users> >>> https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users >>> >> _______________________________________________ >> Shimmer-users mailing list >> <[email protected]>[email protected] >> <https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users> >> 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
