One would think the purest way is to use a photodiode to drive a transistor, which in turn drives an infrared LED. Let's call it the three parts solution (actually you also need a small series transistor for the LED). This can be done, but it has the disadvantage that everything the photodiode detects gets amplified, including noise it picks up. You don't want that.
OTOH, IR receiver modules are usually tuned to a specific protocol and frequency, but if the used frequencies are close a single receiver may be used. The module includes a filter around the center frequency, which eliminates noise, together with an AGC (Automatic Gain Control) stage, which also helps eliminating unwanted (low level) signals, like the radiation from HF fluorescent lamps. But if no real signal is present the AGC will amplify the incoming noise to a normal signal level. And this noise will be retransmitted. When a real signal is received the AGC's amplification will be adjusted, and the noise will be suppressed, so a real signal will come through properly, despite high noise levels when not transmitting.
So while there will also be a lot of noise picked up and retransmitted by an IR receiver module, just like the three parts solution. The disadvantage of the latter is that it won't suppress the noise if a proper signal is detected. Its advantage is that it's protocol-independent.
As for power, this is a tall order. The three component solution will transmit noise all of the time, and will drain the battery fast. The receiver module contains more electronics, and will draw around 0.5 to 1 mA. Which is also too much to let the battery last six months.
edit
If the power is really premium you may have to stick to a specific protocol and decode the received commands before retransmitting. The \$\mu\$C will consume some power too, but will cause the LED to remain off for most of the time, like up to 99.99%, since it won't transmit noise, just valid commands. It's possible to program the \$\mu\$C to decode multiple protocols, but like I said earlier, they'll have to have close characteristics, like pulse-pause ratio and carrier frequency.
"I suspect this protocol has been used for a while and may have a name." (highlighting by me)
Possibly, but I doubt it. There's a huge chance that this is a proprietary protocol which is only internally documented. Main reasons for a proprietary protocol:
- Design freedom. The designer checked a number of existing protocols and dismissed all of them because of some technical reason or other. It may have too little throughput, or be too complex to code in a 2kB microcontroller.
- Commercial protection. Use a proprietary protocol and competitors can't make products which can be used with yours, so the customer has to come back to you. Simple protocols can be reverse engineered, though, so they may want IP protection (to the extent possible, I'm not a lawyer.)
There is a zillion of those proprietary protocols around, often by small businesses who are doing their own thing and don't have to comply with anything as far as standard protocols are concerned.
You may have a chance with reverse engineering. You don't say what kind of data the transceivers take, but maybe you could find a pattern in how a given input is coded.
Best Answer
The MICRF112 uses relatively low frequency crystals (9.84 and 13.56MHz), so it should be possible to switch between two crystals using an analog multiplexer or even a mechanical switch. However you also need something to switch the RF output between two separate antenna circuits, so you won't be saving much (if anything) in BOM.
Considering the low cost and small size of the MICRF112, it might be better to just use two of them - each hard-wired to its own crystal and antenna matching circuit. You could tie the data inputs together and disable the unused IC via its EN input.