Hi Mike, Was just wondering if you could send me the mote code you used for testing 127 bytes @ 100Hz. That way i can figure out of its a host problem or my mote implementation.
Much Thanks, Nick On Fri, May 20, 2011 at 11:21 AM, Nicholas Hosein <[email protected]>wrote: > 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
