I need to ensure that a random signal from a 433MHz Tx is captured when the circuit is doing other tasks but I cannot see how this can be done. It is easy if there is a dedicated processor circuit allocated to this where it can be periodically checked for any new data by another processor which is performing the other tasks but this complicates the system with additional hardware.
When using a single processor, the random signal could be missed if it is doing other processing such as reading a sensor. Interrupts would appear to be the way to go but the Tx data using Radiohead comprises:
36 bit training preamble consisting of 0-1 bit pairs
12 bit start symbol 0xb38
1 byte of message length byte count (4 to 30), count includes byte count and FCS bytes
n message bytes (uincluding 4 bytes of header), maximum n is RH_ASK_MAX_MESSAGE_LEN + 4 (64)
2 bytes FCS, sent low byte-hi byte
Maybe I could somehow use the 36 bit preamble to generate an interrupt?
Here is the problem with your project. There are millions of "random"signals in the 433.00-433.99 MHz region. There are hundreds right in your own neighborhood. Most weather stations with remote sensors use that range of frequencies. They avoid problems by encoding their data signals to be able to tell theirs from all the others. Other devices repeat a transmission many times to ensure at least one message is received.
You must have a method to select just the "random" signal you want, but to do that, you must receive all signals and find the one that you want.
Paul
An Arduino Pro Mini clone costs just $2 on eBay, so it seems wise and cost effective to dedicate one to receiving the signal of interest and leave other tasks to other processors.
Have you actually tried using the RadioHead library ASK in your application and experienced an issue?
My understanding is that it polls the receiver input on a timer interrupt. As such it should happily run in the background as long as interrupts remain enabled. Your code will need to check the status of the receive buffer often enough to prevent overflow which implies you can't have extended blocking in the other parts of you code.
Probably the best approach is to use a dedicated processor for the Rx such as a Pro Mini as suggested but I may be able to get away with the MrMark method as when using something like a Uno, the RadioHead documentation includes the following:
"The RH_ASK driver uses a timer-driven interrupt to generate 8 interrupts per bit period. RH_ASK
takes over a timer on Arduino-like platforms. By default it takes over Timer 1."
It is worth a try anyway. I am using an Ebay cheap superhetrodyne Rx which I have used successfully in the past.
I don't anticipate any trouble from other 433MHz sources as I plan to use this in a remote location.
"cheap 433 MHz transmitter/receiver pair" is exactly what I use but I make sure that I chose a pair with a superhetrodyne receiver rather a superegenerative receiver for better range and selectivity and have used these successfully for other projects.
My concern was whether a random transmission would be detected if the processor with the attached receiver was doing other things when the transmission occurred. It appears that the RH_ASK.h library causes a periodic interrupt which checks whether reception is occurring.
If that random transmission is using the correct frequency and modulation, then yes it will be detected, and as a result you may receive bogus data at times.
Wireless input should be treated as untrusted, so your code should do thorough sanity checking on the data received (is it for me? is it the expected length - no buffer overflow? are the values/commands valid? etc.)
There seems to be confusion about what the original poster means by "random transmission".
On interpretation is a transmission on 433 MHz by something other than his RH__ASK transmitter, that is, "random" in the sense that we don't know the origin of the transmission. This might more specifically referred to as "cochannel interference" and it will be received if it uses a protocol sufficiently close to RH__ASK to be recognized as a valid RH_ASK transmission.
A second interpretation is a transmission by his own transmitter that occurs at a "random" point in time, potentially while his Arduino is performing some other task. This will be received1 if the "some other task" doesn't disrupt the inherent background operation of the RH_ASK task. Potential sources of disruption include (at least) reallocating the timer used by RH, disabling interrupts, or by failing to service the RH task such that the receive buffer overflows.
1 The usual caveats apply, that is, the signal will be received if it is not corrupted by interference or low receive signal level. Sometimes you lose so the system should be designed to tolerate dropped messages.
MrMark: The second interpretation is correct. The system is simply a 433MHz Tx using the RH_ASK protocol randomly transmitting (approximately every 20 min) sensor data to a 433MHz Rx also using the RH_ASK protocol. I have used this system over a number of years and have found that the RadioHead protocols as used have been very reliable and cannot recall any interference, disruption or wrong data.
I wanted an added function to the above which I was concerned would cause a missed reception due to the Aduino processor doing this additional function when a transmission occurred. However, I am confident after getting such good feedback from this forum and also further examining the RH_ASK documentation that this concern is unlikely to occur.