Errors transmitting 10 bit number read with Atmega328 via serial and reading it with "od"
You cannot shove a multi-byte value through an 8-bit serial channel in a single operation.  As you are not selecting various bitfields in the source value, what actually happens is that you are sending the least significant 8 bits of successive readings.  And then misinterpreting 2 or 4 of them in a row as bogus multi-byte values.

If you can tolerate 256 distinct values, you could modify your code to right shift the conversion value (or operate in 8-bit mode to start) so that you send a legitimate unsigned single-byte measurement.  You will then need to make sure the Linux serial device is operating in a fully raw mode such that no codes are given special interpretations.  Finally, you would need to set your display code to interpret the values as 8-bit unsigned integers.

Sending higher resolution measurements is tricky


One naive approach is to write sending code which sends each byte of the value in sequence, remembering to make sure that the bytes all come from the same ADC reading.  But this approach is naive because it provides no mechanism to synchronize the transmitter and receiver.  If the receiver is not already listening before the transmitter starts, or if a byte is ever dropped due to an error, then the receiver may start combining bytes of different readings in shifted order to generate false values.  It is possible to work around this with special prohibited start codes that are then escaped if they appear in data, periodic magic-value multi-byte resynchronization headers, or least reliably time gaps between readings (which is especially unwise if USB serial converters may ever be used).


In the specific case where your readings are 10-bit you could do something like split them into two 5-bit words and use the high bits of each as a field code, for example 0b011mmmmm and 0b010nnnnn where 0bmmmmmnnnnn is a 10-bit value you want to send.  However this would need custom receiving software which looks for a reading beginning 0b011xxxxx and a following one beginning 0b010xxxxx and recombining the appropriated bits of each.  (The 0x40 bit is on in each case in the hopes of steering the codes into the printable range, perhaps preserving the possibility of using commandline tools to manipulate the data)



But generally this creates a lot of headache, so it's worth first seeing if a non-binary approach could be viable.


Send human readable  strings encoding the ASCII representation of digits with a space or newline delimiter.  Because the delimiting character cannot be mistaken for a numeric digit, it provides ready splitting of the readings and implicit synchronization.  Even in the case of an error, the impact won't persist but will be contained to one or two successive readings.  Using a newline is often the best choice, as many stream processing schemes are naturally line buffered, a behavior which may have to be explicitly changed to avoid delay when using a different delimiter.


Decimal values are most easily interpreted by eye, and may be fine for your purpose, but you'll either need to zero pad or accept that the number of characters per values is variable.
Hex values (padded with leading zeros) yield a clean fixed-size conversion of the data.  The value itself will be exactly twice the length of the binary value - ie, 16 bits becomes 4 8-bit characters or 32 bits, but the delimiter will also take a byte, so a 16-bit value requires five characters overall.  Given your source resolution is 10 bits, you actually could use just 3 hex digits and a delimiter, for a total of 4 characters per reading.  Of course consuming software will need  to interpret hex values, but this tends to work well with most things you'd run on Linux; still, figuring it out in some contexts may be a little tricky, might require injecting a prefixing "0x" before interpreting the received string, etc.





There are some additional potential problems in that you attempt to use a fixed but jittery programmatic delay to regulate two things which have more appropriate explicit ready conditions.


You are failing to verify that the serial UART is ready for new data before you write to the data register.  
you should check the data sheet to determine if it is legitimate to read the ADC conversion register when a conversion is not complete; if not, you need to wait for the conversion complete flag.