Mikko: Can't help you on Linux I'm afraid - I'm Windows. I use Windows sockets to read the data. If you're doing something similar you do need to know that the underlying TCP/IP protocol doesn't send data as the packets you send. It can break them down so a receive doesn't necessarily receive your arbitrary packet, rather it receives a subset of the data. You need to keep doing receive commands till you get a packet - basically you need to keep track of where you are in the data stream. There was a thread here about this a year or so ago - search the archive for the subject "bluetooth packet fragmentation".
Phil Reaston 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 Tue, Jul 24, 2012 at 10:16 AM, Mikko Rasa <[email protected]> wrote: > Yes, it's a custom program. The goal is to visualize the position of the > Shimmer module (or multiple modules) in a 3D scene, but for now I'm just > dumping the data read over bluetooth to the terminal. > > Is there anything particular I should check about the program? At the > moment it just opens the rfcomm device, writes the command to start > streaming data (0x07), reads the response (0xFF) and starts reading the > data. Is there some example code for Linux that's known to work? > > Mikko > > > On 24.07.2012 19:53, Phil Reaston wrote: > >> Hi Mikko: >> >> What are you using to receive the data? I think you said earlier it was >> your own program. If so, I'd check that. >> >> Phil Reaston >> >> >> 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 Tue, Jul 24, 2012 at 9:46 AM, Mikko Rasa<[email protected]> wrote: >> >> Okay, magnetometer is working now. Even the data transmission seems to >>> be >>> more reliable, although there are still a few errors per second (with >>> 50Hz >>> sampling). Should be usable provided that I manage to improve the >>> filtering to accept packets with real zero bytes, or alter the firmware >>> to >>> provide better synchronization. >>> >>> However, the inquiry command still fails to produce a valid response. A >>> varying amount of bytes from the middle of the packet are always lost, >>> sometimes starting right from the ack byte. The most common case is >>> that I >>> receive the ack byte and the last five channels (out of nine). This is >>> not >>> a huge problem in itself, since I can hardcode the channels, but it does >>> indicate that something is going wrong with sending data over BT. >>> >>> To eliminate possible radio interference, I grabbed my laptop and a >>> Shimmer and went outside to a spot with no other radio sources (that I >>> know >>> of) nearby. This had no effect on reliability. >>> >>> Mikko >>> >>> >>> On 24.07.2012 18:43, Benjamin Kuris wrote: >>> >>> Open your shimmer, reseat the 9DoF board. You should get magnetometer >>>> data using stock FW and shimmer connect when following the quickstart >>>> in the manual. If that fails, email [email protected] for >>>> further assistance. >>>> >>>> -Ben >>>> >>>> >>>> On Tue, Jul 24, 2012 at 11:33 AM, Mikko Rasa<[email protected]> wrote: >>>> >>>> I tried various sample rates between 5Hz and 50Hz. I'm using the >>>>> accelerometer and gyro, so six channels in total. If I enable the >>>>> magnetometer channels, I don't get any data; I guess the device is >>>>> unable to >>>>> read the sensors. >>>>> >>>>> I have two Shimmer modules at my disposal, and am testing with one at a >>>>> time >>>>> for now. In the final application I hope to use two or three >>>>> simultaneously. I have a WLAN, a couple of wireless mice and a >>>>> BT-enabled >>>>> cellphone here as well, and of course my laptop which I'm receiving the >>>>> data >>>>> on. However, when I tested rfcomm between the cellphone (N900, running >>>>> Linux) and the laptop, I was able to transfer large amounts of data >>>>> without >>>>> any errors (several kilobytes; I'm lucky if I get 100 sequential >>>>> error-free >>>>> bytes from the Shimmer). >>>>> >>>>> This is stock boilerplate firmware, aside from whatever hacks I've put >>>>> in >>>>> while testing and might not have reverted fully. I also tried the >>>>> official >>>>> firmware from shimmer-research.com (in case my build environment >>>>> somehow >>>>> introduced errors), but it has the same problems. >>>>> >>>>> The problem seems to be very data-sensitive; If I turn the Shimmer to >>>>> its >>>>> side so that the X axis accelerometer gets a low value, I receive >>>>> almost >>>>> no >>>>> zero bytes at all, and when I do manage to receive a valid packet >>>>> (i.e. a >>>>> zero byte followed by 14 non-zero bytes), the contents are badly >>>>> mangled. >>>>> >>>>> Mikko >>>>> >>>>> >>>>> On 24.07.2012 18:11, Benjamin Kuris wrote: >>>>> >>>>> >>>>>> What sample rate and how many channels? >>>>>> How many devices in your piconet? >>>>>> Any other RF in 2.4GHz band? >>>>>> >>>>>> Are you using stock boilerplate data packets or are you sending full >>>>>> ACL packets (~128bytes data) to minimize BT overhead? >>>>>> >>>>>> Typically you don't need to mess with the baudrate but minimizing BT >>>>>> overhead will improve results if you can accept a little bit of >>>>>> latency. >>>>>> >>>>>> I'm sure others will chime in. >>>>>> >>>>>> -Ben >>>>>> >>>>>> On Tue, Jul 24, 2012 at 10:57 AM, Mikko Rasa<[email protected]> wrote: >>>>>> >>>>>> >>>>>>> I'm trying to use a Shimmer 9DoF sensor with the boilerplate >>>>>>> firmware, >>>>>>> but >>>>>>> bluetooth transmission is giving me a hard time. It's dropping a lot >>>>>>> of >>>>>>> bytes, making data streaming unreliable and certain commands >>>>>>> unusable. >>>>>>> In >>>>>>> particular, I can't get an intact reply from the inquiry command to >>>>>>> discover >>>>>>> the order of channels being sent, so I have to hardcode this into my >>>>>>> program >>>>>>> based on the boilerplate sources. With the data packets I could use >>>>>>> the >>>>>>> packet identifier to synchronize the stream and throw out any >>>>>>> truncated >>>>>>> packets; this might spuriously reject good packets if they contain >>>>>>> embedded >>>>>>> zero bytes, but I estimate I could recover around 80% of the packets >>>>>>> this >>>>>>> way. >>>>>>> >>>>>>> Is there anything I could do to improve the reliability? I've >>>>>>> already >>>>>>> tried >>>>>>> different sampling rates, as well as messing with the baud rate used >>>>>>> between >>>>>>> the MSP430 and the BT module. Neither of these seems to have any >>>>>>> effect >>>>>>> on >>>>>>> the reliability, unless I change the baud rate so far out of spec >>>>>>> that >>>>>>> all >>>>>>> transmissions stops. >>>>>>> >>>>>>> -- >>>>>>> Mikko >>>>>>> ______________________________****_________________ >>>>>>> Shimmer-users mailing list >>>>>>> [email protected] >>>>>>> https://lists.eecs.harvard.****edu/mailman/listinfo/shimmer-*** >>>>>>> *users<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< >>> 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
