I want to use a "listen-before-talk" approach to transmit data from sensors connected to a transmitter and receiver pair to a MCU connected to a transmitter and receiver, which means that the sensor will only transmit data once it has been asked to do so by the MCU, but the problem I'm having is that my receivers will have no way of knowing if the information it's receiving is from one of my transmitters or from some other 433 transmitter in the area.The receiver I want to use has a product description here which seems to suggest there may be a method of pairing up my transmitters and receivers but how? If I transmit transmitter ID information e.g if the transmitter is transmitting 4 bits, I make the first two bits always "11" so the receiver knows that the information is from one of the transmitters it should listen to would I then be able to filter data I don't want on the AVR?
The modules you are using are only 0dBm (1mW) which is quite low power. The RFM12s that you are used to are normally 8dBm (6mW) and have a ready made, robust protocol. They are surface mount as well, so I'll assume you are using them mounted to a PCB.
My first thoughts would be to isolate RF issues from protocol issues. Set up a transmitter doing 101010101010 at whatever rate is required to transmit the data in your application. You seem to have a rate of about 2400Hz which is good for long distance without being so slow as to confuse any AGC in the receiver. Either use a scope on the receiver or set up something to detect this preamble like pattern, and see how far you can go with your current setup. This should make it possible to work out if it is an RF issue or a protocol one.
I don't know the HRR30 receiver, but most of the basic AM receivers have a non adjustable AGC in them. This means that it can be hard to work out exactly how long a preamble you need to bias the gain correctly, and also hard to work out what data rates are supported. Too short a preamble and the receiver will still be gained up and responding to noise. Too slow data rate and the gain will be all over the place. Your setup sounds fine, but may be worth investigating.
Bread boarding these transmitters and receivers is fraught with problems. I don't think that you need to resort to anything more than a quarter wave dipole though. Get the module onto a simple PCB and you will likely see a big improvement.
Another big assumption, but with projects like this it is often not worth implementing error correction. Just transmit several times and assume you will miss some packets. If that isn't acceptable, a send /ack system will be better then error correction.
The suggestions about retries are good ones. With RF generally one can never count upon a clear channel free of noise so that there will always be a finite probability of a missed transmission at the receiver due to interference or noise.
Having the transmitter use of FEC (generally better probability of reception per bit sent) but more complex) and/or unconditional retransmissions (worse than a well designed FEC though good against RF interference that may overpower the channel for longer than a packet duration) allow a unidirectional link a high probability of success. You can also use some kind of unique spreading code such as FHSS DSSS or similar to create CDMA channels for your transmitters such that they will not interfere even if they all transmit at the same time. That can be done in the baseband or at RF carrier frequency.
Use of TDMA techniques is often a simple expedient whereby you assign time slots such as A = 0s...15s, B = 15s...30s, C=30s...45s, D = 45s...60s out of 1 minute (for instance, though of course you can scale the time slot frequency and duration arbitrarily) and use a clock within each transmitter to schedule its periodic transmission windows such that it'll never transmit at the same time as its peers. Going slower e.g. 0...15 minutes etc. out of the hour would work even better. The problem with half duplex scheduled transmissions is clock drift between the transmitters. 10 days is very approximately roundable to 1,000,000 seconds. So a 20ppm clock drift will equal about 20 seconds maximum error over 10 days, so if your devices are to transmit for months on a schedule, you can see that over time their clocks will become off by up to minutes magnitude. Applying first order compensation for measured crystal frequency offsets at the center of the expected operating temperature range will enable to get low single digit PPM clock accuracy in practice with a reasonably accurate and stable 32kHz crystal oscillator timebase. Applying a temperature compensation to the clock rate will help too if your operating temperature drift and range are large enough to warrant it.
Of course if you have bidirectional (RX as well as TX) capability at the nodes you can use packet acknowledgements as well as listen-before-talk synchronication and synchronization / time broadcasts to help the communication succeed.
If you use FDM you'll also be able to have unidirectional transmitters broadcast independently of each other, though some possibility for external interference / noise related errors will still exist.
If you can transmit audio bandwidth baseband you can just use FDM in the baseband by assigning different subcarrier frequencies like 697Hz, 770Hz, 852Hz, 1209Hz to the different transmitters and recovering the information by a DFT or Goertzel resonator bank at the receiver.
You can use common CDMA ICs like car lock / alarm transmitters or garage door openers or similar so that you get the benefit of the CDMA circuitry's interference suppression as well as the inexpensive hardware due to mass production.
If you use a protocol like Bluetooth Low Energy or Zigbee for the communications you'll get the "built in" layers of reliability, error detection/correction, transmission reliability, protocol implementation, modem integration, et. al. They're intended for low energy sensor networks and take all your stated needs into account, and though they're probably excessive for your needs, the benefits of an highly optimized, highly efficient, highly reliable, off the shelf, inexpensive solution sometimes make them attractive for the simplest of needs.
As for there being no easy way to get the transmitters to transmit in turns, well, a small RTC or $0.50 8/16 bit MCU could help a lot there to implement TDM or LBT (listen before talk) or a reliable transmission protocol, but that's up to your implementation. At the least if you're not using FDM you'll probably need to send unique IDs / node serial numbers or unique codes from each otherwise identical node so the receiver knows which 'identical' node the transmission came from. Typically for low power battery powered nodes you'd have to only activate their transmitters at a low duty cycle such that they're saving power most of the time and transmitting only so many times per minute / hour / day / week. If that is the case then coordinating the transmissions may be architecturally not that far removed from the existing scheduling algorithms/circuitry.
The final option I'll mention could involve using directional antennas at the receiver pointed to each node to make it less likely that other nodes or interfering fixed transmitters will cause problems in a given reception. Of course that adds complexity to the receiver setup but can be quite effective depending on one's system design and environment. I'd possibly do this in conjunction with other techniques, not usually instead of them.
- Using RF Link Transmitter/Receiver – ADC vs Microcontroller
- Protocol to be used to make microcontroller to work as mouse
- Two rf 433 transmiter and one receiver connection won’t work
- Changing the port values inside the loop (8051)
- Electronic – How to avoid interference in 433 MHZ RF transmission (in the case)
- Electrical – What do I need in order to make the arduino to transmit / recieve signals exactly at 433.68 MHZ
- Electronic – How do we separate source signals in spread spectrum