Yes, good point. The 12495 is the 30CF portion of the entire BF30CF hex command. All commands start with the "BF". So the question is, how to transmit this 12333263 number byte-wise over the serial interface, and reconstruct it on the other side, and transform it to hex so as to send the proper command to the IRsend.send NEC and emitter?
It looks also like the IRsend.sendNEC can use the decimal representation 12333263, altough the pattern lookss a little compressed in time. I don't know if it will still work. Would it make the communication be any easier if I just sent the decimal representation? If so, I will see if the TV will respond to this pattern as well.
Funny, of the wireless, IR and communication protocol aspects of this project, I thought this would be the easy part! Thanks for your help.
So the question is, how to transmit this 12333263 number byte-wise over the serial interface
You can send the value, as a decimal string or a hexadecimal string, or you can send the value as 4 bytes. Converting the value to a string and sending up to 10 characters and converting the received string back to a number will take longer than sending the value as 4 bytes.
Create a union to make the long and a 4 byte array occupy the same space. Assign the long, and send the 4 byte array, using Serial.write(buf, len) (where buf is the 4 byte array and len is 4).
Receive the 4 bytes, and place in the array, and use the long.
Only 4 bytes need to be sent, and no value to string or string to value conversion needs to be done.
Can you point me to a reference for this type of thing? I feel like I will take up too much time asking you all these details, and I don't see this kind of thing on the Arduino reference page. Is "union" for example, a standard C command?
Or if you have the time, maybe you can walk me through this? I have little experience with manipulating arrays in this environment.
How do I send the number BF30CF (in hex) in four bytes over the serial interface one byte at a time, and reassemble it on the other side? Do I just Serial.print(BF), then Serial.print(30), then Serial.print(CF);? Why isn't it only 3 bytes?
I then want to use the reconstructed hex number in the command IRsend.sendNEC(0xBF30CF, 32);
I'm not sure what this means
"Create a union to make the long and a 4 byte array occupy the same space. Assign the long, and send the 4 byte array, using Serial.write(buf, len) (where buf is the 4 byte array and len is 4).
Receive the 4 bytes, and place in the array, and use the long."
Here is my first attempt to do this. "Long" is surely not the right operator to use here. I need something that will concatenate the four byte array into the key which should be 0xBF30CF, which I will send to the IRsend.sendNEC function.
Here is my first try to construct and send the array. I'm trying to use the Serial.print() function to see what the concatenated array will look like. I would like to see "BF30CF" on the serial monitor, but instead I get gibberish.
I appreciate everyone's patience here, I know these are basic, ignorant questions.
#include <IRremote.h>
IRsend irsend;
byte array[4] = {0x00, 0xBF, 0x30, 0xCF};
unsigned long key = 0;
void setup()
{
Serial.begin(9600);
}
void loop() {
Serial.write(array, 4);
key = long(array);
Serial.print("\t");Serial.println(key, HEX);
/*
irsend.sendNEC(0xBF30CF, 32); // TV power code
delay(2000);
irsend.sendNEC(message1, 32); // TV power code
*/
delay(2000);
}
EXCELLENT, Jack! Now if you can just tell me how to read the transmission back into an array, and then back into the myNumber.UL, I may be in business!
Would it be something like:
for (int x = 0; x < 5; x++)
{
myNumber.B = Serial.read();
}
or maybe it's a "Stream.read"?
I did confirm that the IRsend.sendNEC will take the myNumber.UL as an argument, and the signal pattern looks just fine, so this may be the last piece!
That's a cool terminal program you have. What is it?
union {
unsigned long UL;
byte B[4]; // This needs to be an array!
} myNumber;
The union shown is OK on the sender, but on the receiver, the B member must be an array.
Would it be something like:
for (int x = 0; x < 5; x++)
{
myNumber.B = Serial.read();
Almost. Look at the for loop. x will be set to 0, and the block will execute. x will then be set to 1, 2, and 3 and the block will execute, reading the 2nd, 3rd, and 4th bytes. Then, x will be set to 4, AND THE BLOCK WILL EXECUTE, reading the 5th byte. Oops.
God knows how long this would have taken me otherwise. But now I have one Arduino decoding the remote IR signal, passing the key to the serial link, and a second Arduino receiving the code and driving the IR emitter with it. Now all that remains is to replace the USB with the RF link, but now that I have a "coordinator" on the network, what can possibly go wrong? But since then I will no longer be able to see what is being transmitted (will I?) this would appear to be the last step.
The cool term is great too, a big help with all this.
Here is the code that retrieves the key and drives the emitter:
IRsend irsend;
union {
unsigned long UL;
byte B[4];
} myNumber;
void setup() {
Serial.begin(9600); // opens serial port, sets data rate to 9600 bps
}
void loop() {
if (Serial.available() > 0) {
for (int x = 0; x < 4; x++){
myNumber.B[x] = Serial.read();
}
Serial.print(myNumber.UL, HEX);
}
irsend.sendNEC(myNumber.UL, 32);
delay(10000);
}
Umm, no. I thought it read one byte at a time, loaded them into memory one at a time.
This statement, myNumber.B = Serial.read(); wouldn't compile because of "incompatible types in assignment 'int' to 'Byte'.
Arrays in C++ seem to work differently than other languages I have used, which have an index designating the position in the array. So I tried this myNumber.B[x] = Serial.read();
and it did compile, and it did seem to work...until you told me it didn't!
Yikes, what is wrong with my picture? Can I have another hint?
The business about USB/RF is that right now I have both Arduinos connected to my PC and communicating over USB. I can see what is being read/written via the USB. Ultimately, I want them communicating directing over RF. I don't know how to see what is being read/written since they won't be communicating any longer with the PC. So I wanted to get all the kinks out before this last piece.
Hint: Serial.read() will return a value whether there is something to be read or not. RTFM: Serial - Arduino Reference XD
So I'm still not following, the XBees aren't in the picture at this point?
This is another reason I prefer API mode to AT mode. Debug messages can be intermixed with the XBee frames, and because they don't contain the start delimiter, the XBee ignores them. But you could use Software Serial to write debug messages to I suppose.
for (int x = 0; x < 4; x++){
myNumber.B[x] = Serial.read();
The risk there is that if for some unforeseen reason, more than four bytes were received, the index (x) would overrun the array. This can cause all sorts of funny behavior and it can be difficult to track down.
The example below avoids that problem by waiting for exactly four bytes to be received. Of course this can create a different problem, if one byte gets lost somehow, the loop will just wait. Either approach might work as long as everything goes as planned, but I would sure avoid a possible out-of-bounds array index. It's not trivial to make these things bulletproof, it takes a little thinking. A start delimiter would be useful to mark the start of the number. Because the number is sent in binary, though, there is the question of what to use for a delimiter since theoretically any value could occur in one of the four bytes that represent the number. So now we are into escape sequences etc.
int x = 0;
while (x < 4) {
if (Serial.available()) myNumber.B[x++] = Serial.read();
}
The system is working perfectly over USB. I have confirmed the code transmission is correct, received correctly, the IR emitter is being driven correctly. But since the Arduinos cannot communicate directly (yet) I am manually sending the decoded signal that I get from the IR receiving Arduino, to the IR sending Arduino using the "Send" function of CoolTerm. I can see the signal generated by the sending Arduino in the same IR decoder, and I can turn a TV on and off with this signal.
So I guess I am ready to do the wireless. All I should need to do is switch the jumpers to the RF position from the USB position. Is there any way to monitor the transmission at this point, i.e. I will no longer have USB connection to either Arduino, how will I debug it if it doesn't work correctly right out of the chute?
Because the serial port is used by the XBees, the use of Serial.print() for debugging is kind of out the window, since the XBees in transparent mode will just send everything. I suppose it doesn't matter if the receiving end were to print extra stuff, that would be transmitted to the sending end, where it could just be thrown away. But whatever the transmitting end prints will be relayed to the receiver (and vice versa) and so I think it has to stick to just the data to be sent.
Guess I'm not sure what the best approach is, I hardly ever use transparent mode. But there should be folks around who maybe can make some suggestions. (I'd like to know, too!)
I think I said earlier, some other pins could be configured with SoftwareSerial, then something like an FTDI cable would be needed to connect back to a PC. Using an LCD is another idea.
Unless you happen to be using an Arduino Mega, which has four serial ports.
