Hi Mike, I have found the problem I had with the shifted data that caused the high valued data-peaks.
In my application, I read each first byte received on the serialport and when such a byte represents "0xc0" (begin of file) I read the next 21 bytes as a packet. To check if the packet has been read-in completely without errors I check whether byte 21 from the packet represents "0xc1" (end of file). Sometimes, the Bluetooth module sends the data from a packet as single bytes, when such a split-up packet has sequence number "192" or "0xc0", the application thinks that a new packet is coming next and so it dumps the previous data and reads the new packet. If then, with all the luck, the 21st byte contains value "193" or "0xc1", the packet passes the check and the data which is now shifted by 3 values causes these unwanted data-peaks. Is there any way to make the bluetooth module or sensor send it's data always as a full packet? Cause I have read that the bluetooth module can be set to optimize for throughput or latency. Could this fix the problem? If that is not possible then I'll try to fix it in the software but I'm not sure how. Matthias Van Gysel 2012/5/24 mike healy <[email protected]> > Hi Matthias, > > I wrote BoilerPlate but I wouldn't say I have used it extensively (other > than when writing ShimmerConnect). However there are 3 other engineers > sitting in the same room as me here that have used it very extensively for > over a year (streaming from it for 6+ hours a day, almost every day) and > none of us have seen this problem. > > ShimmerConnect does not have an explicit mechanism to recover from this > type of problem. The Labview and Matlab solutions do but they then report > back to the UI if this occurs (or packets are missed for any reason). So > what I'm trying to say is that if this is occurring I think we should have > noticed. > > If you are convinced that the problem is not on the PC side that leaves > the RF as the biggest variable. Is it possible that you are working in an > environment that is very noisy in the 2.4GHz spectrum (even though BT > should be able to handle very high levels of noise)? I normally use a WiSpy > to keep an eye on this: http://www.metageek.net/products/wi-spy/ > > If you do manage to track down the problem to an issue with BoilerPlate > let me know and I'll be sure to fix it. > > Sorry I can't be of more help, > Mike > > > > On Wed, May 23, 2012 at 2:28 PM, Matthias Van Gysel < > [email protected]> wrote: > >> Hi Mike, >> >> I know that it seems unlikely that the sensor would cause these errors to >> the data but I'm almost 100% sure that it's not the application itself >> because that data is already corrupted when it is read on the serialport. >> I am using the BoilerPlate firmware on a Shimmer2r sensor device. The >> host application is indeed a custom code. >> >> I have attached a print screen from a possible explanation for the >> problem. >> I saw yesterday that the Bluetooth module from roving networks can be set >> to optimize for latency or throughput. >> It is standard set to optimize for throughput and this could cause >> problems on the host application? >> >> >> >> >> 2012/5/23 mike healy <[email protected]> >> >>> Hi Matthias, >>> >>> From your two emails I'm unsure what firmware you are running on the >>> Shimmers and what application you are using on the PC side to capture the >>> data (is it custom?). >>> >>> This looks more like a software problem (on one side of the link) rather >>> than a hardware or communication problem (remember Bluetooth is a >>> "reliable" protocol). >>> >>> If you are using one of the example Shimmer apps then I can rule out the >>> suggestion that "the AD-conversion on the Shimmer device itself that is >>> still changing values when the data is already being transmitted to the >>> application" as all these apps perform double buffering on the shimmer to >>> prevent this exact problem. >>> >>> If you are using custom code on the shimmer or the PC the one suggestion >>> I do have is to use the standard BoilerPlate image with either >>> ShimmerConnect or one of the Labview sample applications to see if the same >>> thing happens. >>> >>> Mike >>> >>> >>> >>> On Tue, May 22, 2012 at 9:58 PM, Matthias Van Gysel < >>> [email protected]> wrote: >>> >>>> Hi again, >>>> >>>> I've noticed that the AccelGyro firmware sends a CRC code along with >>>> its data. >>>> How do I use this checksum to verify the authenticity of my data packet? >>>> And does the BoilerPlate firmware provides some sort of check? >>>> >>>> I want to know this because I have noticed that when I receive an error >>>> (data-peak) in my logfile, >>>> the corresponding package has all its data shifted 2 places back. But >>>> it seems as if the checksum is still in its original place. >>>> If I can show that the checksum is ok for the corrupted package then >>>> its probably the fault of the sensor itself right? >>>> >>>> I've made a screenshot of the corrupted data-package so you can see for >>>> yourself. >>>> >>>> I hope someone can help me out! >>>> >>>> Matthias Van Gysel >>>> >>>> >>>> 2012/5/22 Leonid Ivonin <[email protected]> >>>> >>>>> Hi Matthias, >>>>> >>>>> In our lab we have recently experienced a problem that is very similar >>>>> to the one you described. We recorded ECG signal with Shimmer sensor and >>>>> the C# application provided by Shimmer. The data collected with this >>>>> sensor >>>>> for 10 our of 36 participants was corrupted by a strong noise with high >>>>> amplitude. We are pretty sure that this noise was not caused by external >>>>> factors, because during the measurement our participants were instructed >>>>> to >>>>> sit still and also we made sure that the connection of electrodes to their >>>>> skin was good. Moreover we were not able to find any pattern in this >>>>> problem, it happened randomly. We assume that at some point of measurement >>>>> something went wrong in the sensor, but we have no idea what caused it. >>>>> >>>>> I have attached a sample screenshot. On the left side of the picture >>>>> you can see normal ECG signal, then at some point of time it just becomes >>>>> a >>>>> high amplitude noise. Filters do not help to eliminate this noise. >>>>> >>>>> That is our experience :) >>>>> >>>>> Regards, >>>>> >>>>> Leonid >>>>> >>>>> >>>>> On Tue, May 22, 2012 at 6:09 PM, Matthias Van Gysel < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I'm currently working on a project that streams data over a Bluetooth >>>>>> connection from a Shimmer2r sensor to a C# application. >>>>>> I record this data, but when I open the recorded data-file, lots of >>>>>> the data seems to be corrupted or something like that. >>>>>> Data peaks that go as high as 60, when actually the data is >>>>>> normalised to change its value between -1.5 and 1.5. >>>>>> >>>>>> I have tried to test whether it is the sensor, the connection or the >>>>>> application that is causing these errors to the data but I can't work it >>>>>> out. >>>>>> Does anyone ever had the same type of problems? Or knows what this >>>>>> data means and where it comes from? >>>>>> >>>>>> I have talked about this to one of my supervisors and he said that it >>>>>> might be the AD-conversion on the Shimmer device itself that is still >>>>>> changing values when the data is already being transmitted to the >>>>>> application. >>>>>> >>>>>> I don't have a single clue anymore so I really hope someone can help >>>>>> me out here. >>>>>> >>>>>> I inserted a screenshot of the corrupted data into this mail. The >>>>>> screenshot shows the corrupted data and what it normally should be. >>>>>> >>>>>> >>>>>> Matthias Van Gysel >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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
