Problem:
I am transmitting Quaternion IMU data and other 3 10-bit ADC data from arduino to my Windows 7 laptop via USB.
The baudrate is 115200 (as suggested in IMU 6050 firmware sample codes).
I am getting noise (or as per some guys back here buffer overflow, i dont know if its valid term for this scenario!!!) for 20 byte frame which i am transmitting from arduino to java code using rxtx lib.
Description
I am passing following frame constructed in arduino:
// packet structure .
uint8_t customPacket[20] = { '
where byte 3 to byte 8 is IMU data and byte 9 to byte 16 is 10 bit adc data.
I modified this code(https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/Examples/MPU6050_DMP6/MPU6050_DMP6.ino) from i2cdev mpu6050 firmware example codes for my application with my custom packet.
the modified code fragment is written below:
....
...
#ifdef OUTPUT_CUSTOM
customPacket[2] = fifoBuffer[0];
customPacket[3] = fifoBuffer[1];
customPacket[4] = fifoBuffer[4];
customPacket[5] = fifoBuffer[5];
customPacket[6] = fifoBuffer[8];
customPacket[7] = fifoBuffer[9];
customPacket[8] = fifoBuffer[12];
customPacket[9] = fifoBuffer[13];
// setting the analog reads and seperating lower and higher bits in order to transmit serial
int sensorValue = analogRead(xpin);
customPacket[10] = (sensorValue & 0x300) >> 8;
customPacket[11] = sensorValue & 0xFF;
int sensorValue1 = analogRead(ypin);
customPacket[12] = (sensorValue1 & 0x300) >> 8;
customPacket[13] = sensorValue1 & 0xFF;
int sensorValue2 = analogRead(zpin);
customPacket[14] = (sensorValue2 & 0x300) >> 8;
customPacket[15] = sensorValue2 & 0xFF;
Serial.write(customPacket, 20);
#endif
..
....
My java code is derived from Arduino Playground. Arduino Playground - Java
Modifications are are follows:
...
..
public synchronized void serialEvent(SerialPortEvent oEvent) {
if (oEvent.getEventType() == SerialPortEvent.DATA_AVAILABLE) {
try {
if (aligned == false) {
if (input.read() == '
the logic is to have 20 bytes in read buffer starting from first marker $.
below are the first 11 frames(varies from trials to trials) of the code which can be considered as "clean" data as the marker is at the first position of the frame. (its byte data hence must be showing junk in ur utf conversion. my concern is alignment of marker at this point of time rather then parsing values of these bytes)
[$, , !, ?, 4, ?, , &, ?, ?, , ?, , ?, , ?, ]
but then the marker position get disaligned or lost (yikes!!) at all:
...
..
[,,, 4, ?, , , ?, ?, , ?, , ?, , ?, ] (wheres the marker gone???)
..
[, 4, ?, , ?, ?, d, , ?, , ?, , ?, $, , "] (whats $ dollar doing there? he should be the first (pun intended))
..
...
earlier I tried to read the frame byte-by-byte but in vain partitioning the data with $ start points and frame size by if-else logic. But the data received were too slow than the actual baud rate of 115200. I used to get only 50-60 samples of frame per second approx. the earlier version of java rxtx code is:
...
..
public synchronized void serialEvent(SerialPortEvent oEvent) {
if (oEvent.getEventType() == SerialPortEvent.DATA_AVAILABLE) {
try {
int c = input.read();
if (c == '
So basically first method (my new method) brings noise or disalignment of markers and second one is too slow.
Either something is wrong in the above codes or there is some basic fundamental of serial communication I am missing.
Please guide me with this. Its quite crucial for me at this point of time.
Thanks and regards,
Parth J Joshi
, 0x02, 0,0, 0,0,0, 0,0, 0,0, 0,0, 0,0, 0,0x00, 0x00, '\r', '\n' };
where byte 3 to byte 8 is IMU data and byte 9 to byte 16 is 10 bit adc data.
I modified this code(https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/Examples/MPU6050_DMP6/MPU6050_DMP6.ino) from i2cdev mpu6050 firmware example codes for my application with my custom packet.
the modified code fragment is written below:
§DISCOURSE_HOISTED_CODE_1§
My java code is derived from Arduino Playground. http://playground.arduino.cc/Interfacing/Java
Modifications are are follows:
§DISCOURSE_HOISTED_CODE_2§
the logic is to have 20 bytes in read buffer starting from first marker $.
below are the first 11 frames(varies from trials to trials) of the code which can be considered as "clean" data as the marker is at the first position of the frame. (its byte data hence must be showing junk in ur utf conversion. my concern is alignment of marker at this point of time rather then parsing values of these bytes)
§DISCOURSE_HOISTED_CODE_3§
but then the marker position get disaligned or lost (yikes!!) at all:
§DISCOURSE_HOISTED_CODE_4§
earlier I tried to read the frame byte-by-byte but in vain partitioning the data with $ start points and frame size by if-else logic. But the data received were too slow than the actual baud rate of 115200. I used to get only 50-60 samples of frame per second approx. the earlier version of java rxtx code is:
§DISCOURSE_HOISTED_CODE_5§
So basically first method (my new method) brings noise or disalignment of markers and second one is too slow.
Either something is wrong in the above codes or there is some basic fundamental of serial communication I am missing.
Please guide me with this. Its quite crucial for me at this point of time.
Thanks and regards,
Parth J Joshi
) {
input.skip(19); // seems to be aligned with $, skip this frame and start from another...
aligned = true;
}
return;
}
input.read(bufferPacket);
System.out.println((count) + ":" + Arrays.toString(bufferPacket));
count++;
} catch (Exception e) {
System.err.println(e.toString());
}
}
}
..
...
the logic is to have 20 bytes in read buffer starting from first marker $.
below are the first 11 frames(varies from trials to trials) of the code which can be considered as "clean" data as the marker is at the first position of the frame. (its byte data hence must be showing junk in ur utf conversion. my concern is alignment of marker at this point of time rather then parsing values of these bytes)
§_DISCOURSE_HOISTED_CODE_3_§
but then the marker position get disaligned or lost (yikes!!) at all:
§_DISCOURSE_HOISTED_CODE_4_§
earlier I tried to read the frame byte-by-byte but in vain partitioning the data with $ start points and frame size by if-else logic. But the data received were too slow than the actual baud rate of 115200. I used to get only 50-60 samples of frame per second approx. the earlier version of java rxtx code is:
§_DISCOURSE_HOISTED_CODE_5_§
So basically first method (my new method) brings noise or disalignment of markers and second one is too slow.
Either something is wrong in the above codes or there is some basic fundamental of serial communication I am missing.
Please guide me with this. Its quite crucial for me at this point of time.
Thanks and regards,
Parth J Joshi
, 0x02, 0,0, 0,0,0, 0,0, 0,0, 0,0, 0,0, 0,0x00, 0x00, '\r', '\n' };
where byte 3 to byte 8 is IMU data and byte 9 to byte 16 is 10 bit adc data.
I modified this code(https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/Examples/MPU6050_DMP6/MPU6050_DMP6.ino) from i2cdev mpu6050 firmware example codes for my application with my custom packet.
the modified code fragment is written below:
§DISCOURSE_HOISTED_CODE_1§
My java code is derived from Arduino Playground. http://playground.arduino.cc/Interfacing/Java
Modifications are are follows:
§DISCOURSE_HOISTED_CODE_2§
the logic is to have 20 bytes in read buffer starting from first marker $.
below are the first 11 frames(varies from trials to trials) of the code which can be considered as "clean" data as the marker is at the first position of the frame. (its byte data hence must be showing junk in ur utf conversion. my concern is alignment of marker at this point of time rather then parsing values of these bytes)
§DISCOURSE_HOISTED_CODE_3§
but then the marker position get disaligned or lost (yikes!!) at all:
§DISCOURSE_HOISTED_CODE_4§
earlier I tried to read the frame byte-by-byte but in vain partitioning the data with $ start points and frame size by if-else logic. But the data received were too slow than the actual baud rate of 115200. I used to get only 50-60 samples of frame per second approx. the earlier version of java rxtx code is:
§DISCOURSE_HOISTED_CODE_5§
So basically first method (my new method) brings noise or disalignment of markers and second one is too slow.
Either something is wrong in the above codes or there is some basic fundamental of serial communication I am missing.
Please guide me with this. Its quite crucial for me at this point of time.
Thanks and regards,
Parth J Joshi
) {
if (counter != FRAME_LEN) {
counter++;
} else if (counter == FRAME_LEN) {
counter = 0; //useless;
}
} else {
if (counter == 1 && c == 0x02) {
counter++;
} else if (counter == (FRAME_LEN - 1)) {
currentFrame[counter] = c;
frameCalculations(currentFrame); // calculations to convert quaternion data to ypr once a single frame is received. the same functions also logs the data in a file.
System.out.println(scounter++);
counter = 0;
} else if (counter >= 2 && counter < 19) {
currentFrame[counter] = c;
counter++;
}
}
// System.out.println(counter);
} catch (Exception e) {
System.out.println("error:" + e);
}
}
}
..
...
So basically first method (my new method) brings noise or disalignment of markers and second one is too slow.
Either something is wrong in the above codes or there is some basic fundamental of serial communication I am missing.
Please guide me with this. Its quite crucial for me at this point of time.
Thanks and regards,
Parth J Joshi
, 0x02, 0,0, 0,0,0, 0,0, 0,0, 0,0, 0,0, 0,0x00, 0x00, '\r', '\n' };
where byte 3 to byte 8 is IMU data and byte 9 to byte 16 is 10 bit adc data.
I modified this code(https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/Examples/MPU6050_DMP6/MPU6050_DMP6.ino) from i2cdev mpu6050 firmware example codes for my application with my custom packet.
the modified code fragment is written below:
§DISCOURSE_HOISTED_CODE_1§
My java code is derived from Arduino Playground. http://playground.arduino.cc/Interfacing/Java
Modifications are are follows:
§DISCOURSE_HOISTED_CODE_2§
the logic is to have 20 bytes in read buffer starting from first marker $.
below are the first 11 frames(varies from trials to trials) of the code which can be considered as "clean" data as the marker is at the first position of the frame. (its byte data hence must be showing junk in ur utf conversion. my concern is alignment of marker at this point of time rather then parsing values of these bytes)
§DISCOURSE_HOISTED_CODE_3§
but then the marker position get disaligned or lost (yikes!!) at all:
§DISCOURSE_HOISTED_CODE_4§
earlier I tried to read the frame byte-by-byte but in vain partitioning the data with $ start points and frame size by if-else logic. But the data received were too slow than the actual baud rate of 115200. I used to get only 50-60 samples of frame per second approx. the earlier version of java rxtx code is:
§DISCOURSE_HOISTED_CODE_5§
So basically first method (my new method) brings noise or disalignment of markers and second one is too slow.
Either something is wrong in the above codes or there is some basic fundamental of serial communication I am missing.
Please guide me with this. Its quite crucial for me at this point of time.
Thanks and regards,
Parth J Joshi
) {
input.skip(19); // seems to be aligned with $, skip this frame and start from another...
aligned = true;
}
return;
}
input.read(bufferPacket);
System.out.println((count) + ":" + Arrays.toString(bufferPacket));
count++;
} catch (Exception e) {
System.err.println(e.toString());
}
}
}
..
...
the logic is to have 20 bytes in read buffer starting from first marker $.
below are the first 11 frames(varies from trials to trials) of the code which can be considered as "clean" data as the marker is at the first position of the frame. (its byte data hence must be showing junk in ur utf conversion. my concern is alignment of marker at this point of time rather then parsing values of these bytes)
§_DISCOURSE_HOISTED_CODE_3_§
but then the marker position get disaligned or lost (yikes!!) at all:
§_DISCOURSE_HOISTED_CODE_4_§
earlier I tried to read the frame byte-by-byte but in vain partitioning the data with $ start points and frame size by if-else logic. But the data received were too slow than the actual baud rate of 115200. I used to get only 50-60 samples of frame per second approx. the earlier version of java rxtx code is:
§_DISCOURSE_HOISTED_CODE_5_§
So basically first method (my new method) brings noise or disalignment of markers and second one is too slow.
Either something is wrong in the above codes or there is some basic fundamental of serial communication I am missing.
Please guide me with this. Its quite crucial for me at this point of time.
Thanks and regards,
Parth J Joshi
, 0x02, 0,0, 0,0,0, 0,0, 0,0, 0,0, 0,0, 0,0x00, 0x00, '\r', '\n' };
where byte 3 to byte 8 is IMU data and byte 9 to byte 16 is 10 bit adc data.
I modified this code(https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/Examples/MPU6050_DMP6/MPU6050_DMP6.ino) from i2cdev mpu6050 firmware example codes for my application with my custom packet.
the modified code fragment is written below:
§DISCOURSE_HOISTED_CODE_1§
My java code is derived from Arduino Playground. http://playground.arduino.cc/Interfacing/Java
Modifications are are follows:
§DISCOURSE_HOISTED_CODE_2§
the logic is to have 20 bytes in read buffer starting from first marker $.
below are the first 11 frames(varies from trials to trials) of the code which can be considered as "clean" data as the marker is at the first position of the frame. (its byte data hence must be showing junk in ur utf conversion. my concern is alignment of marker at this point of time rather then parsing values of these bytes)
§DISCOURSE_HOISTED_CODE_3§
but then the marker position get disaligned or lost (yikes!!) at all:
§DISCOURSE_HOISTED_CODE_4§
earlier I tried to read the frame byte-by-byte but in vain partitioning the data with $ start points and frame size by if-else logic. But the data received were too slow than the actual baud rate of 115200. I used to get only 50-60 samples of frame per second approx. the earlier version of java rxtx code is:
§DISCOURSE_HOISTED_CODE_5§
So basically first method (my new method) brings noise or disalignment of markers and second one is too slow.
Either something is wrong in the above codes or there is some basic fundamental of serial communication I am missing.
Please guide me with this. Its quite crucial for me at this point of time.
Thanks and regards,
Parth J Joshi