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
