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,000as 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?