What about the Serial.print lines? If you remove all those, does the program work? I had a problem recently when I started using Serial.print for debugging and it ended up restarting the arduino over and over again while it was trying to run the code. I think it was something to do with a memory issue.
char Sensor1CharMsg[4];
...
void dataRX()
{
...
uint8_t buflen = VW_MAX_MESSAGE_LEN;
// Non-blocking
if (vw_get_message(buf, &buflen))
{
...
// Message with a good checksum received, dump it.
for (i = 0; i < buflen; i++)
{
// Fill Sensor1CharMsg Char array with corresponding
// chars from buffer.
Sensor1CharMsg[i] = char(buf[i]);
}
Classic buffer overflow bug. Even if you have increased Sensor1CharMsg to 5 elements, the version of VirtualWire.h I just looked at (1.9) defines VW_MAX_MESSAGE_LEN as 30. So the above code will write beyond the end of the buffer, if you receive a message more than 4 or 5 bytes long. Never trust input to be in the expected form, even if it is (in theory) under your control.
On my hard disk the version that I have claims to be 1.6 (!) and in that, the vw_get_message function appears to only return the requested number of bytes, at most.
That compiled, as I suspect you already knew. Unfortunately I will have to wait a couple of hours before I can try it live. However as I do like to know what I'm coding could you please tell me or point me in a good direction to find reading material as to what actually is done in that line. Am I just stating that buf is a const char* or does (const char*)buf perform some sort of change?
Am I just stating that buf is a const char* or does (const char*)buf perform some sort of change?
You're just telling the compiler that you want the pointer to "buf" to be treated as though it were a "const char*", even though you know it is a pointer to a different type.
Because it is a pointer to a datatype with the same size, this is normally perfectly OK, particularly as in this case, where the buffer simply contains ASCII data.
Sorry to say I got the same problem as before. A couple of lines fly by in the Serial Monitor before it hangs. Commenting out the Serial.print lines does not help either.
Again if I don't include the colorControl(); function everything seems to work just fine.
Ok, so I've changed the ledpins to use pin 3, 5 and 6.
This actually stops Serial Monitor output from hanging. But it still seems to hang after a while when the Sensor1Data gets stuck with the same number.
Makkan:
But it still seems to hang after a while when the Sensor1Data gets stuck with the same number.
Perhaps the device is no longer receiving data over VirtualWire then? In which case, either receiving has stopped, or the other device has stopped sending data. You need to determine which.
It's the receiver that stops receiving.
And it seems it is colorControl() that somehow mixes things up. If I just comment that one out, I can go on for ages.
You appear to still have your LEDs connected to pins 9 and 10, which the VirtualWire class uses, unless you tell it to use other pins. Which you don't.
So, it's hardly surprising that as soon as you write to those pins VirtualWire quits working.
PaulS:
You appear to still have your LEDs connected to pins 9 and 10, which the VirtualWire class uses, unless you tell it to use other pins. Which you don't.
So, it's hardly surprising that as soon as you write to those pins VirtualWire quits working.
Nope, dc42 noted this a while back so I've changed to pins 3,5 and 6.
dc42:
What happens if you just comment out the analogWrite calls?
That works, it's up and running hand still works after five minutes of continous running. So it seems to be analogWrite that causes trouble.