V_88:
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.
Noted. I noticed the omission of the zeros, and also that println() just sets the data in the next line.
Well, technically, println() sends both the "carriage return" and "line feed" characters after what prints, so the next thing that prints will be on a new line. (In the serial monitor the cursor is moved back to the first column and advanced down 1 row.) You will need to use print() to send the 6 character buffer that sprintf() filled... Read through the last code samples that I posted.
V_88:
Also, when I say XBeeRX.available() == 1 and then I say data_in = XBeeRX.read(); does this byte leave the Serial buffer and go into data_in or is it copied? I think its moved right?
When you say XBeeRX.available() == 1, you are asking if there is exactly 1 character in the XBeeRX's buffer (it is a FIFO buffer set up by the SoftwareSerial library). You really want to check to see if there is at least 1 character (i.e. greater than zero). But all that does is check to see if there is anything available.
When you say data_in = XBeeRX.read(); then you are copying the next available character from XBeeRX's buffer and then removing that character from the buffer. (If you wanted to read it and then leave it (bad idea in most cases) you would use data_in = XBeeRX.peek();.)
V_88:
To make sure I received the next byte should I put XBeeRX.available() == 2 (next byte along with already existing) or still XBeeRX.available() == 1 (new byte which came in)?
read() removes the byte from the buffer. The buffer has a fixed size so except for rare cases you always want to pull bytes out of the buffer so it doesn't overflow and you start loosing data.
V_88:
I couldn't work on this today due to other appointments. But I was thinking of trying :
if(XBeeRX.available() == 1 && readPosition == 0)
{
data_in = XBeeRX.read();
if (data_in == '*')
{
readPosition++;
}
}
if(XBeeRX.available() == 1 && readPosition == 1) // I assume the byte that went into data_in is moved and not copied.
{
data_high2 = XBeeRX.read(); //higher nibble of data_high
readPosition++;
}
if(XBeeRX.available() == 1 && readPosition == 2)
{
data_high1 = XBeeRX.read(); //lower nibble of data_high
readPosition++;
}
if(XBeeRX.available() == 1 && readPosition == 3)
{
data_low2 = XBeeRX.read(); //higher nibble of data_low
readPosition++;
}
if(XBeeRX.available() == 1 && readPosition == 4)
{
data_low1 = XBeeRX.read(); //lower nibble of data_low
readPosition++;
newReading = 1;
}
if (newReading == 1)
{
...
...
}
I could have enveloped a switch statement (switching the readPosition) into an if(XBeeRX.available() == 1) loop also I guess. But would this logic work?
Actually the code you came up with from my pseudocode did "enveloped a switch statement (switching the readPosition) into an if(XBeeRX.available() == 1) loop"... And it works as I have shown. If it doesn't work on your equipment then there may be a need to take a look at your hardware again...
Your multiple ifs will also work as well as long as you fix your comparisons, check to make sure available() is greater than zero. Checking to see if a value (any value, really) is not zero is easy because in C++ boolean false is zero and boolean true is not-zero. So if (XBeeRX.available() != 0) will evaluate the same as just if (XBeeRX.available()). Also, in the if statement for readPosition == 4 should set readPosition back to zero instead of incrementing it....
But if for some reason you want to change the name of the serial port you are accessing (like re-using this code in another project), the code I suggested there is only 2 places (in that part of the code) where the serial port name would need to change, and you would need to change it 2 places in every if (5 in this case).
There have been discussions on these forums comparing and contrasting the merits of switch case to multiple and/or nested if statements. There are some cases where one method is preferred over the other, but for most cases it comes down just to the style that the coder likes. Switch case does seem to be a more advanced (and in some peoples opinion more refined) method, but the important thing is whether you can understand it after not looking at it for 6 months.
V_88:
what is the -0.01 for? I don't remember seeing anything about this in the temperature sensor datasheet. But I may have missed it.
The '-0.01' came from the code in various blogs I searched. The resolution of the MLX90614 is 0.02 and the half of it is some offset I guessed. In any case, I never gave it much thought because the resolution is good anyway.
Well, if in theory if the temperature sensor returns a zero because it is almost at absolute zero, your equation would return -0.01kelvin which doesn't exist in traditional physics. I'd trust the data sheet and remove the - 0.01 from your code.
V_88:
What version of the IDE are you using?
I downloaded it from this website this year (in January).
I'm just curious, but to see what version it is look in the title bar of the IDE window. 
V_88:
Serial.begin(115200);
XBeeRX.begin(9600);
Is it a better idea to set the `Serial.begin()` at a higher baud than the `XBee.begin() `baud? What difference does it make?
Matching baud rates between software serial objects and hardware serial ports can be a bit magical. But for this case having a faster hardware serial for transmitting means the Arduino is spending less time sending messages out to the computer, leaving more time for other things (like the bit-banging that software serial is doing).
Again, like the switch case vs. multiple/nested if statements argument, the main contributing factor is personal style. I usually have my serial monitor at 115200 baud, and only change it if I need to. Why waste time sending characters if you don't need to?
V_88:
int frac; // what is this variable used for? Future use? Or can it be removed?
Removed I guess.
Let me run this and see what Celsius values I get.
Good luck. If you have issues, try swapping the RX and TX to the XBees (either by swapping the jumpers or by swapping 2 and 3 in the code at SoftwareSerial XBeeTX(2, 3); // RX, TX) on both the Transmit and Receive Arduinos. (I don't expect you to have problems because the SoftwareSerial library example did work.)