Read through the receiver code to see where, what, and how I outputted diagnostic messages to the serial port. You can see that once the code receives the 4th byte after the data_start token it calculates and outputs the temperature. Any data after that looks like data before the next data_start token. Changing the method when sending data_low to println results in this being printed in the receiver's serial monitor:
2A
33
41
32
36
*3A26
Celcius: 24.56
D
A
D
A
2A
33
41
32
36
*3A26
Celcius: 24.56
Notice the extra "D" and "A" lines. These are ASCII Carriage Return (0x0D) and ASCII Line Feed (0x0A) characters. But also notice that they are only printed as a single ASCII character. The leading zero was stripped by the println(var, HEX) method. (The print(var, HEX) method would do the same). For extra data it doesn't matter, but what if the high nybble of either data_high or data_low was zero. The high nybble wouldn't be transmitted at all, breaking our data stream format. Unless we can figure out if one can suppress leading zero trimming with the print(var, HEX) method, we will have to roll our own function. I'll start a new thread in case someone who may know the answer isn't watching this thread anymore before we roll our own function. (You are free to try creating a function that will always send two ASCII characters from a byte as an intellectual exercise.)
P.S. I thought the temperature unit spelling looked a bit odd... It should be spelled "Celsius".
Edit: Ok, question posted. Keep an eye on this thread for discussion. Once a solution/workaround is found there we can fold it back into this thread.