V_88:
I will change my code and try it again using serial commands. But coming to the jumpers first, consider the picture attached.
My jumpers were in that position while I was trying to transmit and receive. I didn't change the jumpers on D0 and D1 at any point.
I did change the the other jumpers with the "3.3V" and "JMP" label, I shorted A-B and D-E ("left" position), during configuring the XBees using PuTTY. I changed them back to the B-C and E-F ("right" positions) after that.
Why would you change those? Those are zone 5 jumpers and the datasheet seems to indicate they have to do with operating voltage. I tried to look at the shield's schematic to figure out what that does, and I can't seem to figure out how changing those jumpers effects operation for 3.3V versus 5V. Not a very good schematic... I would actually use it as a teaching tool of some things not to do in schematics.
But none of that matters for the task at hand. For what we are doing, leave the zone 5 jumpers the way you have them in your picture.
Does the position of the jumpers at DIN and DOUT imply that Pin1 is the RX and Pin0 is the TX? If this is true then would I keep the corresponding jumpers in vice-versa in the other XBee?
Well, this can get a bit confusing. The DIN and DOUT on the shield are from the point of view of the XBee module.
- DIN is data in, also could be called receive or RX, metaphorically the XBee's ear.
- DOUT is data out, also could be called transmit or RX, metaphorically the XBee's mouth.
So, yes the way they are configured right now, Pin1 of the shield is the XBee's RX and Pin0 of the shield is the XBee's TX. It is done this way so the XBee's mouth is connected to the Arduino's ear (Arduino Pin0) and the XBee's ear is connected to the Arduino's mouth (Arduino Pin1).
Like in one XBee, I have the DIN of Pin1 shorted to the center and the DOUT of Pin2 shorted to the center. Would that mean in the other one I would have DOUT of Pin1 shorted to the center and the DIN of Pin 2 shorted to the center?
Not quite. Those pins are only for communication from an XBee to it's physically connected Arduino. I want you to connect them up the same way on both shields: DIN on pin3 and DOUT on pin2. We will then use software serial (with RX set to 2 and TX set to 3) to communicate from each Arduino to their attached XBees. (Because of the way the XBees are configured they should already communicate with each other.)
This way you can use the hardware serial to communicate back to the computer so you can monitor debugging and diagnostics with serial monitor. (Where ever I can on my designs, I avoid using Arduino pins 0 and 1 for anything so I can look at debugging information on my computer when the Arduino is connected via USB.)
If you have two USB cables (if you don't, I would highly suggest getting a second one), connect both Arduinos to your computer at the same time. Have two ArduinoIDE windows running at the same time with the "SoftwareSerialExample" sketch loaded in both. Set one to the COM port of one of the attached Arduino boards, and the other to the COM port of the other attached Arduino board. In both IDE windows, change line 30 from SoftwareSerial mySerial(10, 11); // RX, TX
to SoftwareSerial mySerial(2, 3); // RX, TX
. Then change line 44 (mySerial.begin(4800);
) to the baud rate that your XBees are configured for. (I use X-CTU to configure my XBees, because I'm running Windows and it is easier to click buttons than to manually use lookup tables to find command and setting codes. I presume you are also running Windows because you used PuTTy which is a Windows application... Why didn't you use X-CTU?) You can also change the header comment to reflect these changes, but for what we are doing this isn't important because you don't need to save the modified sketch. Upload the sketches to both Arduinos, and open the Serial Monitor for both IDE windows. What you type in one serial monitor should show up in the other serial monitor.
Once you are sure that you are able to communicate from one Arduino to the other, you know the hardware is correct. Now it is time to start writing code that will do what you want to do. If you are having hardware problems, ignore the following until we get the hardware sussed out.
When structuring your code, the more I think about it I think the raw 2-byte code plus some unique separator from the temperature sensor is what should be transmitted via XBee, and then do the conversions on the receiver end. Transmitting and receiving a float value isn't quite as straight forward.
Take a look at how you get the data from the temperature sensor. First you send it a command requesting data. Based on the command you sent you know exactly what data to expect so you put the first byte into data_low (this should actually be initialized as byte, not int), then you put the second byte into data_high (again, should be initialized as byte), and finally you put the third byte into pec. You know what format to expect and when the first, second, and third bytes will be transmitted. But with your Arduino to Arduino communication it might be simpler to not request data and just receive the data. Because only 1 byte at a time is transmitted over the XBees, how does the receiver know which byte it received is data_high or data_low? You will need some sort of handshaking to say "the following byte is the start of the data", or "the last byte was the end of the data", or both. And, that handshaking byte needs to be some byte value that will never be part of valid data. Unfortunately, looking at the possible values of both data_high and data_low i see all the possible values that can be contained in 1 byte (0x00 through 0xFF), particularly with the data_low byte. We will need to encode the values some how. The simplest would be to transmit the ASCII characters representing the hex value. I.E for the hex value of 0x2A, you would transmit the two ASCII characters '2' and 'A'. This type of conversion is already built into the print method we will be using to send the data from the Arduino to the transmitting XBee. Based on that, we know that the individual values being transmitted will all fall into the set of values for the ASCII digits and the ASCII capital letters 'A' through 'F'. These are 0x30 inclusively through 0x39 and 0x41 inclusively through 0x46, respectively. (If you don't already have an ASCII table bookmarked, I suggest this one. I don't even have it bookmarked because the url is so easy to remember: "asciitable.com".) You have literally every other one byte hex value to choose for your start and/or stop bytes. But for ease of troubleshooting, I'd probably suggest another printable ASCII character, and would probably avoid any in the two ranges 0x30 inclusively through 0x3F and 0x40 inclusively through 0x4F. This still leaves most of the symbols, all the lowercase letters, and uppercase letters 'P' inclusively through 'Z'. This would allow you to echo all the characters received for troubleshooting/diagnostics, even if you just act on the ones your are interested in.
I would probably suggest going with a start byte only. That way when your receiver sees that start byte it captures the next 4 bytes as data. Checking to see if the 4 bytes represent the only possible valid values, and if so then convert them. If one checks each one while receiving them then you can ignore bad data sooner. (Sort of like buzzing in on Jeopardy before Alex Trebek finishes reading the clue.) Then wait for the next valid start byte while throwing away any received bytes until then. This allows you to send new line characters for your first echo tests. Because the new line characters (CR and LF) will be the 5th and 6th bytes after the start byte, your receiving code would just throw them away along with any other noise.
Receiving the ASCII representations and reconstituting the hex value might be a bit tougher, so for now just write your receiver code to echo everything back to the hardware serial port by leaving the example loaded that we used to test the hardware connection.
You don't need to be constantly transmitting. What happens if you can't receive as fast as you can transmit? It would look like the scene from the old Lucy show when she is working at the candy factory. The conveyor belt speed would be analogous to baud-rate, and the spacing of the chocolates would be how often you transmit the temperature code. Even on a fast baud-rate, spacing the transmits out would allow the receiver time to catch all the packets and do other things (like process the packets, send the result on elsewhere, etc). For now I would suggest a nice even cadence of 1 second between each transmission of temperature. You can adjust this later if needed. You should also send over the hardware serial what you are sending over software serial. That way you can verify that what you are receiving is actually what you sent (just like with the hardware configuration testing I had you do earlier).