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
>
>
_______________________________________________
Shimmer-users mailing list
[email protected]
https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users

Reply via email to