Hey Mike,
I took your suggestion and things pretty much worked out (: It turns
out that in boilerplate the start_value is set to 1 since
data_packet_size is hardcoded to be 25, whereas my packet is only 10
bytes, so things got shifted which is why there was a zero column. So
what you said was about the conversion is right, given that the data
is read correctly. The reading part was as you said as well, given
that the storage buffer does not change in the time period, the data
gets bunched up together waiting to be read.
Thanks a lot for your help,
Richard
Quoting mike healy <[email protected]>:
Hi Richard,
The answer to your question will depend on how you are creating the
Bluetooth packet on the Shimmer. Also the method you are using to "convert
the data to uint8" in Matlab will be relevant.
The processor on the shimmer is little-endian. So, unless you are
manipulating data on the Shimmer, the first 8-bits (1 byte) received of the
16-bit number should be the least significant parts, and the second byte is
the most significant part. This is how ShimmerConnect handles the received
data. In which case when you say you are "multiplying the 7th column by 256
and adding it to the 8th", this should really be the other way around (but
then this will depend on how you populated the "columns", as the data you're
shown below doesn't support this).
Anyway, the easy way of figuring this out is to just hard code some values
in the Bluetooth packet on the Shimmer, and manipulate the data in Matlab
until you get these values back out. Of course use different values for each
(simulated) sensor reading, so you can correctly figure out how the
different sensors split up.
Also as for your fread question, I would guess that a call to fread will
read X (in your case 1000) values from the serial buffer. Then when you call
it again it will read the next X values from this buffer. As for whether or
not it is the 1000 currently being transferred, this will depend on the size
of the serial buffer.
Mike
On Mon, Jun 13, 2011 at 8:24 PM, <[email protected]> wrote:
Hi,
I'm working with the shimmer ECG module and trying to add bluetooth
functionality to JFATlogging. I'm getting the data stream through fread in
matlab and converted it to uint8 as such:
6 201 4 203 7 226 7 0 8 0
6 220 4 225 7 215 7 7 8 0
6 195 4 214 7 222 7 253 7 0
which presumably are 5 channels split into two bytes each (7&8th column
being ECG). So i'm just multiplying the 7th column by 256 and adding it to
the 8th, which is the same operation as the shimmerconnect code, however the
data looks much wonkier than if I just plotted the 8th column alone. Any
ideas on how to process these numbers?
Also, I'm calling bluetooth.write after every DMA0transferdone, which may
or may not take place depending on send_ready being reset in
bluetooth.writedone, which seems to cause the data to be sent in irregular
intervals (I've excluded the timestamp in the datapacket)?
Lastly, just a general serial port question: every time I call fread to
take in a stream of say 1000 numbers, is it the next 1000 numbers from the
last time i called fread, or is it the 1000 currently being transfered as
soon as I called fread?
Thanks,
Richard
_______________________________________________
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
