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
