Here's the thing:1. To do a good gait analysis, a minimum sampling rate of 100Hz is required.2. I used 3 of the acce/gyro, connected to Pro Mini using SPI interface.3. With the Pro Mini, I will: a) Read from all three sensors, use Serial.print() to push it to the Bluetooth serial com, and process the data with Processing, or.... b) Do all the calculations on the Pro Mini, use Serial.print() to push it to the Bluetooth serial com, and plot the data with Processing.4. MPU-6000 gives acceleration and gyroscope reading. In order to acquire angle/orientation, calculations need to be done.5. Assume that I am setting the sensors correctly, the sensors should be giving out sampling rate of 1000Hz.

Questions:1. I used micros() to obtain the time delay with each loop, and found out that it is below 100Hz (I am expecting faster since it is a 8Mhz processor, and sensor is giving 1000Hz of readings). I need the Serial.print() cycle for every loop to be at least 100Hz. Is my method correct? Could it be that I am polling my sensors fast enough, but Serial.print() made it slow?2. How do I make it perform faster?

1. I used micros() to obtain the time delay with each loop, and found out that it is below 100Hz (I am expecting faster since it is a 8Mhz processor, and sensor is giving 1000Hz of readings). I need the Serial.print() cycle for every loop to be at least 100Hz. Is my method correct?

You are wasting a lot of time converting the int values to strings, sending the strings, and (on the other end) converting the strings back to values.

Using Serial.write() to send the high byte and then the low byte will be faster. A lot faster.

Quote

Could it be that I am polling my sensors fast enough, but Serial.print() made it slow?

You'll need some kind of separator between the pairs of bytes, so that if one gets lost, the receiver can know that and recover.

Or, you need some kind of separator between groups of bytes, and discard the whole group if the separator occurs again to soon, in the input stream.

Since you have no byte values that would not be part of the data stream, you have a couple of choices. One would be to split each byte into two nibbles, and send the 4 nibbles. Then, the separator can be any value over 127.

The other would be to send a series of (say 4) separator bytes (all the same value). That series of bytes is unlikely to appear in your data. That series of bytes could be 0s or 255s.

You'll need some kind of separator between the pairs of bytes, so that if one gets lost, the receiver can know that and recover.

Or, you need some kind of separator between groups of bytes, and discard the whole group if the separator occurs again to soon, in the input stream.

Since you have no byte values that would not be part of the data stream, you have a couple of choices. One would be to split each byte into two nibbles, and send the 4 nibbles. Then, the separator can be any value over 127.

The other would be to send a series of (say 4) separator bytes (all the same value). That series of bytes is unlikely to appear in your data. That series of bytes could be 0s or 255s.

May I just use space (that is, Serial.write(040)) to be the seperator?In such case, would it happen that my data from the sensor to be the same as some special ascii code, such as new line or carriage return?

PeterH

Thank you for your swift reply.I need a real time monitoring GUI, that is why I am streaming the data over the serial port (via Bluetooth) into Processing (and then plotted into a graph).

The term 'real time' means different things to different people. What does it mean to you? What sort of update frequency and latency are you trying to achieve? How much data needs to be transferred at each update? If you are only displaying the values on a screen then you can probably afford to update them considerably slower than 100Hz. In that case you might want to separate the sensor handling code from the output code so that you can perform them at different frequencies - you probably want to do your inertial extrapolation as frequently as possible to minimise cumulative errors and you don't need to pass all that data through the bottleneck of your serial port.

yan5619

Thank you for your swift reply.I need a real time monitoring GUI, that is why I am streaming the data over the serial port (via Bluetooth) into Processing (and then plotted into a graph).

The term 'real time' means different things to different people. What does it mean to you? What sort of update frequency and latency are you trying to achieve? How much data needs to be transferred at each update? If you are only displaying the values on a screen then you can probably afford to update them considerably slower than 100Hz. In that case you might want to separate the sensor handling code from the output code so that you can perform them at different frequencies - you probably want to do your inertial extrapolation as frequently as possible to minimise cumulative errors and you don't need to pass all that data through the bottleneck of your serial port.

Please allow me to explain my project.

It is a wireless inertial sensor network as mentioned on the first post, with three acce/gyro sensors.I need a data sampling rate of at least 100Hz, best if 200Hz can be achieved.After collecting the data from the sensor, it should be streamed to my computer (which within my limited knowledge, serial port would be the way), and displayed on the screen by plotting a graph (by using Processing, the only program I am a little familiar with). Furthermore, for analysis purposes, the data that is streamed to my computer must be logged, therefore 100Hz-200Hz is still necessary.

The frequency will be fixed, so any frequency from 100Hz will be fine.

Sending 12 bytes of data 100 times per second is possible. Error detection/correction will require that you send more than 12 bytes at a time. How many more depends on how robust the error detection must be, how reliable the wireless transmitter and receiver are, and how much interference there will be.

yan5619

Sending 12 bytes of data 100 times per second is possible. Error detection/correction will require that you send more than 12 bytes at a time. How many more depends on how robust the error detection must be, how reliable the wireless transmitter and receiver are, and how much interference there will be.

Well, 12 bytes per sensor, I'll have to send up to 36 bytes (since I used three), and furthermore I think I need more bytes for instructions such as spaces, CR and NL.What I am concerned is that if I am going to use spaces, CR and NL (and then get the data sent to Processing and processed), it is possible for my sensors to produce such values as well, and "confuse" Processing...am I right?

Quote

I can't see where "wireless" is a necessary condition.

It's supposed to be a wearable device, which will be attached on the foot, and track the acceleration, angular velocity changes, as well as angles of the foot when walking. It'd be very troublesome if it is not wireless.

Quote

You might want to rethink this.

Surprisingly, even though it is cheap, it is very reliable, as reviewed by many users and tested by myself.

The problem with any delimiter, when you are sending binary data, is that the delimiter can naturally be part of the data stream. So, seeing a 10 in the data stream does not necessarily mean that a CR was intended.

If can be assured that no data will ever be lost, then simply assume that 12 bytes are all the data for one sensor, and interpret the 12 bytes as 6 ints.

You can't, of course, assume that no data will ever be lost.

Quote

It'd be very troublesome if it is not wireless.

How is the wearer of the device supposed to see the output? Is the wearer supposed to cart a laptop around?

If the device is intended to be applied and the output studied in a clinical setting, wired is not necessarily out of the question.

Quote

Surprisingly, even though it is cheap, it is very reliable, as reviewed by many users and tested by myself.

It is only as good as the error detection and correction is applies. That is none. That is not what bluetooth is intended for.

XBees, on the other hand, do perform error detection and correction, and packet the data in a way that start and end markers (where a packet starts and ends) are present, so one can be assured that a packet does contain exactly 12 bytes in the correct order.

Of course, you can't get two XBees, a shield, and a USB explorer for $6, but you can't expect to get something for nothing. TANSTAAFL.