user2902: I'm implementing a filter for my IMU Sensor and thus I want close to real time data visualized on the computer. I use binary serial communication to facilitate the sending part for the arduino (as far as I know the serial.print is pretty slow). So I split my int16_t in two bytes and send it, like:
Serial.write((uint8_t)(gx >> 8)); Serial.write((uint8_t)(gx & 0xFF));

After that i directly send the next number (3 in total by now, maybe up to 7 2byte numbers in the future).
I read the thing in matlab with: 
dt(k) = toc;
tic;
bindata([1:6],k) = fread(s,[6,1],'int8');
time = cumsum(dt(1:k));

Which reads 6 bytes (3 numbers) and then I recalculate the binary representation, concatenate them and get the original number (if someone can suggest an easier way.. I found matlab pretty unhandy here).
The problem is, that the numbers get mixed by the time. Somewhen one byte isn't read or anything, so the bytes get messed up and a nonsense number is produced.One full number (2byte) is skipped for one sample exactly. Instead of this number one number is there twice. The next sample the order is messed up (shifted, such that the first number is second). This process appears after maybe 30 sec, sometimes a few minutes. After the first time it keeps shifting and jumping around.
Can someone tell me, what to do here? Can I include some 'breakpoint'/line terminator, where the reader (matlab) knows, that we are at the start of the first number? Or how is this done actually?
I guess I have to add my main goal: I want to make the sending as fast for the arduino as possible. No extra calculations should be necessary (if possible).
And: the reason for these shifts seems to be the some time delay (slowness). I suspect it to be a slow matlab reading, since I saw fluent processing scripts in HIL reading. The errors have stopped however, since I turned the baude rate down. Only wrong numbers are the problem still.
May there be a possibility to loop around the fread and read just store the values after an added 'header'? So let's say a wrong ordering occures. Then I discard everything until the next 'a' char/byte and use the following 6 bytes to produce my 3 values. Then I wait for an 'a' again. For that I would have to loop fread(s,[1,1],'int8'); and search for the header.
Full arduino code:
// Program to send the gyro/accel data via serialport
// corresponding matlab programs: sensing.m and sensing_binary.m
// 2 security loops to guarantee a constant sampling time

// #define DEBUG
#include "GY86.h"
#include "Wire.h"

GY86 gy86;
int16_t ax, ay, az;
int16_t gx, gy, gz;

uint32_t currenttime = 0;
uint32_t starttime = 0;
uint32_t starttime2 = 0;

// #define OUTPUT_ACCEL_COUNTS
#define OUTPUT_GYRO_COUNTS

// #define OUTPUT_ACCEL_BINARY
// #define OUTPUT_GYRO_BINARY


void setup () {
  Serial.begin(9600);
  gy86.setup();
}


void loop () {
  currenttime = millis();
  if (currenttime-starttime > 9)
  {
    while (micros()-starttime2 < 9000) { }
    starttime2 = micros();

    // read raw accel/gyro measurements from device
    gy86.getSensorValues(&ax, &ay, &az, &gx, &gy, &gz);
    // testing constants
    // gx = -29;
    // gy = 245;
    // gz = 17;

#ifdef OUTPUT_GYRO_COUNTS
    Serial.print((int)gx); Serial.print(F("\t"));
    Serial.print((int)gy); Serial.print(F("\t"));
    Serial.print((int)gz); Serial.print(F("\t"));
#endif
#ifdef OUTPUT_ACCEL_COUNTS
    Serial.print(ax);   Serial.print(F("\t"));
    Serial.print(ay);   Serial.print(F("\t"));
    Serial.println(az); Serial.print(F("\t"));
#endif
#if defined(OUTPUT_ACCEL_COUNTS) || defined(OUTPUT_GYRO_COUNTS)
    Serial.print(F("\n"));
#endif

#ifdef OUTPUT_ACCEL_BINARY
    Serial.write((uint8_t)(ax >> 8)); Serial.write((uint8_t)(ax & 0xFF));
    Serial.write((uint8_t)(ay >> 8)); Serial.write((uint8_t)(ay & 0xFF));
    Serial.write((uint8_t)(az >> 8)); Serial.write((uint8_t)(az & 0xFF));
#endif
#ifdef OUTPUT_GYRO_BINARY
    Serial.write((uint8_t)(gx >> 8)); Serial.write((uint8_t)(gx & 0xFF));
    Serial.write((uint8_t)(gy >> 8)); Serial.write((uint8_t)(gy & 0xFF));
    Serial.write((uint8_t)(gz >> 8)); Serial.write((uint8_t)(gz & 0xFF));
#endif

    starttime = currenttime;
  }
}


user1585: You could add some kind of packet header/footer to the serial output. For example, if you sent the characters "ab" before the bytes for your number you could reject packets that only had 2 bytes in them. the serial would look like 
"ab123ab123ab12ab123"
The matlab code could see another "ab" come in before the previous packet finished and ignore the packet that ended up as only "ab12", and then get itself back on track again. You should use 2 bytes for your header to avoid collisions with the actual data. Adding a checksum at the end of the packet would also allow you to detect bit swap errors. CRC or fletcher16 would work perfectly in this scenario, but in your case a checksum may be more than you need.

user220: Edit: It seems as the problem is overflow. That means that the USB connection isn't keeping up with the data trying to be sent. To fix this you need to do one of the following things (or both):

Higher baud rate. The baud rate is the frequency that data is sent. From what I've heard, anything above 500,000 as a baud rate isn't helpful with the Arduino libraries.

The Arduino IDE only goes up so high. Try an application such as PuTTY to get higher baud rates on the serial monitor.
Doing very high rates like this are best suited on as short of a cable as you can manage. I'd say 4 feet max, although it depends on many factors, including cable quality. A shorter cable has less resistance (thus less errors).
The rest of the answer still applies. You might want to add a simple parity bit to make sure the data doesn't get corrupted while sent. Adding two or three characters greatly reduces the risk of corruption, but at the expense of cutting your sampling rate in half and it doesn't verify data integrity. I don't know your exact situation, so adding a bit might not be possible.

Lower sampling rate: you're sending too much, so a simple solution is just to add delay(250); at the end of the loop so you don't overload the port.


Original Answer:
The only thing that comes to mind that is very efficient is a parity bit with another bit that's always the opposite of the parity bit. Why? Having an accidental thing where there the last two bits are opposite of each other and they all add up to a even number (ignoring the last bit) would be really odd.
A parity bit is an extra bit so all the bits added up with the parity bit equals an even number. If it isn't quite right, then you know there's a problem. It works only for odd numbers of bits changed, so it isn't foolproof. An example is you have the bits 10010110. There are four 1s, so it's an even number, thus the parity bit will be 0. If it was an odd number, it would be 1 to make the total count an even number. If the computer calculates it doesn't add up right (excuse my lame pun) then it's corrupted and the computer can discard it.
To implement this you'd need to convert the number(s) and the parity bit to ASCII and then count the 0s and 1s. You can use a remainder function and divide by two so there will be a remainder of 1 if it's odd, thus it's corrupted. I'd personally take the latest bit and the x number before it, and just keep looping until you find a combination that satisfies the whole parity bit thing and is within a reasonable range that you've specified in the code.
A line-break would suffice, but it takes up more bits and discovers only missing data, not corrupt data.
Maybe you should be looking into why there's a problem. Could you reduce the length of the USB cable? Upgrade your cable/try a different one? Slightly reduce the baud rate?

2902: <p>I'm implementing a filter for my IMU Sensor and thus I want close to real time data visualized on the computer. I use binary serial communication to facilitate the sending part for the arduino (as far as I know the serial.print is pretty slow). So I split my int16_t in two bytes and send it, like:</p>

<pre><code>Serial.write((uint8_t)(gx &gt;&gt; 8)); Serial.write((uint8_t)(gx &amp; 0xFF));
</code></pre>

<p>After that i directly send the next number (3 in total by now, maybe up to 7 2byte numbers in the future).
I read the thing in matlab with: </p>

<pre><code>dt(k) = toc;
tic;
bindata([1:6],k) = fread(s,[6,1],'int8');
time = cumsum(dt(1:k));
</code></pre>

<p>Which reads 6 bytes (3 numbers) and then I recalculate the binary representation, concatenate them and get the original number (if someone can suggest an easier way.. I found matlab pretty unhandy here).</p>

<p>The problem is, that the numbers get mixed by the time. Somewhen one byte isn't read or anything, so the bytes get messed up and a nonsense number is produced.One full number (2byte) is skipped for one sample exactly. Instead of this number one number is there twice. The next sample the order is messed up (shifted, such that the first number is second). This process appears after maybe 30 sec, sometimes a few minutes. After the first time it keeps shifting and jumping around.</p>

<p>Can someone tell me, what to do here? Can I include some 'breakpoint'/line terminator, where the reader (matlab) knows, that we are at the start of the first number? Or how is this done actually?</p>

<p>I guess I have to add my main goal: I want to make the sending as fast for the arduino as possible. No extra calculations should be necessary (if possible).
And: the reason for these shifts seems to be the some time delay (slowness). I suspect it to be a slow matlab reading, since I saw fluent processing scripts in HIL reading. The errors have stopped however, since I turned the baude rate down. Only wrong numbers are the problem still.</p>

<p>May there be a possibility to loop around the fread and read just store the values after an added 'header'? So let's say a wrong ordering occures. Then I discard everything until the next 'a' char/byte and use the following 6 bytes to produce my 3 values. Then I wait for an 'a' again. For that I would have to loop fread(s,[1,1],'int8'); and search for the header.</p>

<p>Full arduino code:</p>

<pre><code>// Program to send the gyro/accel data via serialport
// corresponding matlab programs: sensing.m and sensing_binary.m
// 2 security loops to guarantee a constant sampling time

// #define DEBUG
#include "GY86.h"
#include "Wire.h"

GY86 gy86;
int16_t ax, ay, az;
int16_t gx, gy, gz;

uint32_t currenttime = 0;
uint32_t starttime = 0;
uint32_t starttime2 = 0;

// #define OUTPUT_ACCEL_COUNTS
#define OUTPUT_GYRO_COUNTS

// #define OUTPUT_ACCEL_BINARY
// #define OUTPUT_GYRO_BINARY


void setup () {
  Serial.begin(9600);
  gy86.setup();
}


void loop () {
  currenttime = millis();
  if (currenttime-starttime &gt; 9)
  {
    while (micros()-starttime2 &lt; 9000) { }
    starttime2 = micros();

    // read raw accel/gyro measurements from device
    gy86.getSensorValues(&amp;ax, &amp;ay, &amp;az, &amp;gx, &amp;gy, &amp;gz);
    // testing constants
    // gx = -29;
    // gy = 245;
    // gz = 17;

#ifdef OUTPUT_GYRO_COUNTS
    Serial.print((int)gx); Serial.print(F("\t"));
    Serial.print((int)gy); Serial.print(F("\t"));
    Serial.print((int)gz); Serial.print(F("\t"));
#endif
#ifdef OUTPUT_ACCEL_COUNTS
    Serial.print(ax);   Serial.print(F("\t"));
    Serial.print(ay);   Serial.print(F("\t"));
    Serial.println(az); Serial.print(F("\t"));
#endif
#if defined(OUTPUT_ACCEL_COUNTS) || defined(OUTPUT_GYRO_COUNTS)
    Serial.print(F("\n"));
#endif

#ifdef OUTPUT_ACCEL_BINARY
    Serial.write((uint8_t)(ax &gt;&gt; 8)); Serial.write((uint8_t)(ax &amp; 0xFF));
    Serial.write((uint8_t)(ay &gt;&gt; 8)); Serial.write((uint8_t)(ay &amp; 0xFF));
    Serial.write((uint8_t)(az &gt;&gt; 8)); Serial.write((uint8_t)(az &amp; 0xFF));
#endif
#ifdef OUTPUT_GYRO_BINARY
    Serial.write((uint8_t)(gx &gt;&gt; 8)); Serial.write((uint8_t)(gx &amp; 0xFF));
    Serial.write((uint8_t)(gy &gt;&gt; 8)); Serial.write((uint8_t)(gy &amp; 0xFF));
    Serial.write((uint8_t)(gz &gt;&gt; 8)); Serial.write((uint8_t)(gz &amp; 0xFF));
#endif

    starttime = currenttime;
  }
}
</code></pre>
 1585: <p>You could add some kind of packet header/footer to the serial output. For example, if you sent the characters "ab" before the bytes for your number you could reject packets that only had 2 bytes in them. the serial would look like </p>

<p>"ab123ab123ab12ab123"</p>

<p>The matlab code could see another "ab" come in before the previous packet finished and ignore the packet that ended up as only "ab12", and then get itself back on track again. You should use 2 bytes for your header to avoid collisions with the actual data. Adding a checksum at the end of the packet would also allow you to detect bit swap errors. CRC or fletcher16 would work perfectly in this scenario, but in your case a checksum may be more than you need.</p>
 220: <p><strong>Edit:</strong> It seems as the problem is overflow. That means that the USB connection isn't keeping up with the data trying to be sent. To fix this you need to do one of the following things (or both):</p>

<ul>
<li><strong>Higher baud rate.</strong> The baud rate is the frequency that data is sent. From what I've heard, anything above <code>500,000</code> as a baud rate isn't helpful with the Arduino libraries.
<ul>
<li>The Arduino IDE only goes up so high. Try an application such as PuTTY to get higher baud rates on the serial monitor.</li>
<li>Doing very high rates like this are best suited on as short of a cable as you can manage. I'd say 4 feet <strong>max</strong>, although it depends on many factors, including cable quality. A shorter cable has less resistance (thus less errors).</li>
<li>The rest of the answer still applies. You might want to add a simple parity bit to make sure the data doesn't get corrupted while sent. Adding two or three characters greatly reduces the risk of corruption, but at the expense of cutting your sampling rate in half and it doesn't verify data integrity. I don't know your exact situation, so adding a bit might not be possible.</li>
</ul></li>
<li><strong>Lower sampling rate:</strong> you're sending too much, so a simple solution is just to add <code>delay(250);</code> at the end of the loop so you don't overload the port.</li>
</ul>

<hr>

<p><strong>Original Answer:</strong></p>

<p>The only thing that comes to mind that is very efficient is a parity bit with another bit that's always the opposite of the parity bit. Why? Having an accidental thing where there the last two bits are opposite of each other and they all add up to a even number (ignoring the last bit) would be really odd.</p>

<p>A parity bit is an extra bit so all the bits added up with the parity bit equals an even number. If it isn't quite right, then you know there's a problem. It works only for odd numbers of bits changed, so it isn't foolproof. An example is you have the bits <code>10010110</code>. There are four <code>1</code>s, so it's an even number, thus the parity bit will be <code>0</code>. If it was an odd number, it would be <code>1</code> to make the total count an even number. If the computer calculates it doesn't add up right (excuse my lame pun) then it's corrupted and the computer can discard it.</p>

<p>To implement this you'd need to convert the number(s) and the parity bit to ASCII and then count the 0s and 1s. You can use a remainder function and divide by two so there will be a remainder of 1 if it's odd, thus it's corrupted. I'd personally take the latest bit and the x number before it, and just keep looping until you find a combination that satisfies the whole parity bit thing and is within a reasonable range that you've specified in the code.</p>

<p>A line-break would suffice, but it takes up more bits and discovers only missing data, not corrupt data.</p>

<p>Maybe you should be looking into <em>why</em> there's a problem. Could you reduce the length of the USB cable? Upgrade your cable/try a different one? Slightly reduce the baud rate?</p>
