Uh well, I don't get one thing - since a packet is formed from a few bytes (using 9600 - for now - 8, N, 1, btw), how exactly would I know what is dropped from the data stream?

For example, I could simply send data without any headers - raw info. If I have two pins scanned, that's four bytes. The problem is that, if one byte is missed, weird values will end up (part from the current packet, part from the next packet). So, the PC can send from time to time a "sync" - where the device will send the bytes in a given order.

Another thing I'm thinking of is using header, but simply counting them. For example, if the device is only scanning two pins, it can alwasy send a sync byte, and then the four bytes of data. Of course, these will be a bit modified (as you suggested, by altering the data in a known fashion and adding an escape char for example) so nothing will interfere with the sync byte.

The PC side will wait for a sync byte, and it will discard everything if the fifth character after a sync byte is not a sync byte. Where should I process this? The receiving thread should simply put out everything in a buffer, or process the data, and only put the sampled values?

Another thing - about the deque on the sending side, do you think that's necessary? I was talking about a queue on the receiving side. The sending device is a PIC microcontroller which can't operate higher than 4Mhz.. and a bunch of this cycles are eaten up by the sending algo, and another bunch by the A/D conversion, so I really don't think things will need to queue up here what do you think?