Extending IR range with RF

[Toastie]

Dear All,

since long I am toying around with ideas about IR range extension using radio frequency (RF) transmission. It is not necessary the line of sight range that bothers me – the LEGO IR remotes (both PF and the RCX/Scout/Spybot Mindstorms varieties) do bridge fairly long distances – the dead spots were making me nervous. My “robots” are often controlled to some extent by a host computer communicating with the remote PBricks in charge via the Mindstorms IR Towers. I was never that much interested in creating autonomous robots – which appears to be the main impetus of the hardcore robotics folks.

In this RailBricks article (Page 44, link opens full PDF document) is a short reference to my first reasonably well working IR/RF range extension solution; the devices are set-up for half duplex IR/RF communication so that the PBricks can report back (acknowledge) commands to host control. A number of my present LEGO trains are also equipped with RCX PBricks and IR/RF transceivers. This way the trains are capable of receiving and acknowledging commands in tunnels, behind large buildings and the like. In case there is no reply the command is simply resent by the host computer a couple of times before a warning is issued. More recent train additions such as a motorized version of Ben Beneke’s BR23 use PF equipment (receiver + LiPo + old school 9V mini motors) to roam around – so these need to be integrated as well.

Just recently I put one of my IR/RF transceivers in front of a LEGO PF receiver and it worked quite well. There is of course no reply from the PF receiver, so all that is really needed for PF is the RF to IR conversion part of the transceiver. I tried out a couple of integrated electronic RF circuits (no way that I could work with discrete RF stuff, TTL/CMOS logic is all I am capable to manage electronically) and came up with a fairly stable solution that I like to share here. Although this is not a train specific contribution, I post it here because the original idea was remotely controlling trains. Furthermore, there were also some hints from other forum members (e.g., JopieK) that RF communication is on their roster. I am very much interested in these solutions as well!

Before going into details, here is a short list of properties I judged to be essential for my project; bear in mind that this project is sort of across multiple themes, so the transceiver should be operating with virtually “all” IR controlled LEGO devices (as long as they run on the LEGO typical 38kHz IR carrier):

• Two-way half-duplex communication (-> not necessary for PF)
  
• About 20 m range in congested surroundings
  
• Up-to 5kBits/s communication rate
  
• Minimal foot print, preferably 4 studs wide
  
• No modification of existing LEGO hardware, i.e. the transceivers need to tie into the IR communication path
  
• Make it as cheap as possible, but within my limited e-skill range
  
• Wide input voltage range: 4.5 V DC to 20 V AC
  
• Operation voltage below 5V. 3.3V seems to be favorable
  
• Max. input current 10 mA
  

The last two properties result from the idea to run the transceivers off from “active” RCX sensor inputs. These are capable of a sustained delivery of about 5V/10mA to external sensors after rectification and voltage stabilization. In other words, I would not need any additional power source for the operation of the transceivers, such as RCX outputs; there are only three and they are used for motor and light operation. The wide input voltage range ensures that all other LEGO power supplies are compatible as well.

To begin with, here is the idea of the non-invasive realization of a half duplex IR/RF transceiver. The set-up would be: Local LEGO IR Mindstorms tower <–> local IR/RF transceiver <–> remote IR/RF transceiver <–> remote PBrick. The problem that readily arises when using two individual circuits for RF transmission (IR in + RF out) and RF reception (RF in + IR out) is a nasty loop that is created when not taking further care, as shown in Figure 1.

IR from the tower causes RF to be sent (1), the RF in channel is picking up the signal (2), mirrors that to IR out - and we create a loop (3); the on-board RF in sees its own signal and goes nuts. So there needs to be some sort of control logic, telling the IR out channel of the transceiver to simply shut-up when RF is being sent. That logic can either be hardware (e.g., in terms of a TTL solution, as shown before, see above referenced RailBricks article) or can be “programmed into” a little micro controller. I am using PICs from microchip (just ran into them, no preference at all here). The cheapest and smallest PIC I could find with 6 I/O ports is the 12F509 ($1.5/pc). The diagram in Figure 2 shows the simple electronic circuit I came up with.

Programming the PICs is rather straight forward, after some readjustments to assembler code (loved to program Zilog’s Z80 on the machine level in the olden days) it worked fine for me. The nice thing about virtually all small baseline micro controllers is their reduced instruction set. The cheapest programmer for PICs is the PicKit1, which sells for about $35. The PicKit1 is compatible with microchip’s mighty MPLab IDE, which ships for free. I did all the programming with this suite and I am impressed with debugging, simulation capabilities and what not.

What does the PIC do? When idling, it simply loops between the IR in and RF in channel of the transceiver and listens for signals. The moment a signal is received it jumps to the respective code (either IR or RF is handled, but not both) and deals with the signal: Is it just noise or a qualified signal (see code)? In case of a “real” signal it generates the corresponding RF out or IR out signal by mirroring what is coming in to the output: RF out is simply the on/off keyed (OOK) bit stream from the IR detector. IR out is somewhat more sophisticated; here we need to convert the incoming OOK RF signal into corresponding 38 kHz IR light bursts (I could not get hold of an IR LED with built-in 38kHz generator, they must exist). This is what the PIC does as well. For the time of transmission and some additional delay time after transmission it does simply not look at the other channel, this way we for sure don’t create a locked loop. Mindstorms PBricks need about 5 - 10 ms for sending out their reply, so this is ample of delay time. If you are interested in the PIC code, PM me and I’m happy to send you the assembler listing or the entire MPLab project file. But beware – the code is sub-amateur level!

As IR parts I used the pieces shown on the left in Figure 3. The more commonly used pieces on the right were a little bulky – also I wanted to go with 3.3V so that took me to the TSOP 34838 IR receiver and a miniature side emitting SHARP GL 480 IR LED. The RF parts are shown in Figure 4. I used 433 MHz LINX modules just because they were relatively cheap (and ready to go and can manage up-to 5 kBits/s). These receivers are very stable, reliable, and virtually don’t pick up RF noise, even in completely messy circuits, see Figure 5. (On a side note, LINX phased out the LC series receivers in 2007. The follow-up LR series receivers are much more sensitive, have a higher transmission rate (10 kBit/s) but also do see a lot more noise. In fact, with no “real” RF signal present, the internal amplification goes way up and picks up noise like crazy. There are ways to pull the receiver out of noise, including software solutions (see code), but I found a much more convenient way: East Dragon Electronics (no joke, and the guy's name handling the order was Oscar ...) in China has still tons of LINX LC receivers in stock and they sell them for $5 + sh&h each!)

Figure 5 shows the prototype on a solderless breadboard; if RF works in such a messy environment, then it for sure works on a rookie-made printed circuit board as well. All I can say is that the LINX people do a good job on their RF stuff ...

RFM has also a nice suite of integrated RF stuff. Their integrated transceivers (RF in and out all under one tiny hood!) are also working fine, even in my messy environment. It is just that the LINX LC receivers appear to be less prone to noise pickup ... and they are a little cheaper.

Now on to the foot print. To really go small we need a) a printed circuit board (PCB) and b) some SMD parts. The PCB board was made by a German company called “PCBPool”. They give you quite powerful software (called “Target V14” and up) to draw the circuit and automatically route the board – but you have to use their service. Which is $60 for a 160x100 mm2 double sided board. That fits at least 15 individual transceiver boards as shown in Figure 6 – I have already used 7 from this board shown. Everything works on-line; you just have to wait for the board to show up in your real mailbox.

Figure 7 shows all the parts going onto the board – I certainly overdid it with the resistors ...

The assembled transceiver is shown in Figure 8; In Figure 9 it is comfortably sitting in a case made by 3 hollowed out 4x2 bricks and a 2x4 plate.

The cost (very rough estimate) for such a transceiver is still considerable, I guess:

• PCB $60/15 = $4
  
• RF receiver = $10 (LR type from digikey) or $5 (LC type from East Dragon)
  
• RF transmitter = $5
  
• IR receiver = $1
  
• SMD capacitors = $5
  
• all remaining parts about $5
  

That totals to roughly $30 which is considerable. Prices go down when you order ship loads but that was not what I was looking for. I just want my trains and stuff run around happily.

Figure 10 shows how to “connect” to LEGO devices without breaking into them. So far this IR/RF transceiver worked with PF receivers, RCX, Scout, and Spybot PBricks. PF is only one way, so the back channel is not needed.

In this clip

three trains are remotely controlled via RF (with back channel).

The IR tower or control unit (remote) is hooked up in exactly the same way with another transceiver. As already said, if you go one-way only (PF) then a 433 MHz remote control extender works very well as transmitter.

Here are some more or less useful pictures once moderated.

There is more to come; RF base stations with distributed IR in/out satellites (reducing the cost significantly for multiple stationary LEGO devices such as switch point controllers, lighting, etc.) is one option that works also quite well, just installed some stuff. Furthermore, when not using the back channel, the host transmitter can be a plain vanilla 433 MHz remote control extender blowing out considerably more RF signal than my tiny transceivers. That will ensure some real remote distance control.

Will hopefully be back soon with some more applications.

Best regards,

Thorsten

Edited November 22, 2011 by Toastie

[lightningtiger]

Now this is what I wasn't expecting in a Lego forum....an electronics article !

Simple enough, but man do I miss the days of discrete component electronics they were fun !

Great engineering there 'Toastie', question...in your power supply are you using standard electrolytics or tantalum capacitors....plus what's their working voltages...the one on the load side is easy 5 Volt, but the source side ?

Again great work !

[Toastie]

Now this is what I wasn't expecting in a Lego forum....an electronics article !

Simple enough, but man do I miss the days of discrete component electronics they were fun !

Great engineering there 'Toastie', question...in your power supply are you using standard electrolytics or tantalum capacitors....plus what's their working voltages...the one on the load side is easy 5 Volt, but the source side ?

Again great work !

Hi LT,

yeah - discrete WAS better, but then: No RF for me I guess ...

With respect to your question: The circuit diagram indeed needs an update. I used Tatalum SMD capacitors - some T491 series, whatever that means, 35 V DC on the source side (47 uF) and 6.3 V on the 3.3 V side (220 uF). These were apparently "new" in 2009 ...

Best regards,

Thorsten

[Kisvakond]

Hello Thorsten!

Nice work! Well done!

I think an RF-transciever is the one most wanted thing we wanted for ages for our PF-system!

There is more to come; RF base stations with distributed IR in/out satellites (reducing the cost significantly for multiple stationary LEGO devices such as switch point controllers, lighting, etc.) is one option that works also quite well, just installed some stuff. Furthermore, when not using the back channel, the host transmitter can be a plain vanilla 433 MHz remote control extender blowing out considerably more RF signal than my tiny transceivers. That will ensure some real remote distance control.

"Dear SANTA.. "

I'm looking forward your further stuff..

Edited November 21, 2011 by Kisvakond

[kyphur]

I am by no means an electronics guy but I like this.

Something I would be very interested in seeing (and contributing $$$ towards development) that I believe would also be marketable:

Addressable IR/RF - RF/IR system

By this I mean that the Receivers would each have a unique address (simple number say 1 - 16) and the transmitter would have a way to select which receiver we are addressing (and include the option for ALL).

For this we could set up to 16 IR Receivers to use the same "frequency" so now 4 "Frequencies" * 2 "Channels" which used to give us control of 8 receivers would actually give us control of up to 128 receivers!

Of course since this would be a PF only adaptation it wouldn't need Transceivers just a single Transmitter and multiple Receivers.

Then I would be able to run all of me trains on "Frequency" 1 and motorize my switches using "Frequencies" 2 & 3.

Anyone interested in working on this?

[clcwong]

I am by no means an electronics guy but I like this.

Something I would be very interested in seeing (and contributing $$$ towards development) that I believe would also be marketable:

Addressable IR/RF - RF/IR system

By this I mean that the Receivers would each have a unique address (simple number say 1 - 16) and the transmitter would have a way to select which receiver we are addressing (and include the option for ALL).

For this we could set up to 16 IR Receivers to use the same "frequency" so now 4 "Frequencies" * 2 "Channels" which used to give us control of 8 receivers would actually give us control of up to 128 receivers!

Of course since this would be a PF only adaptation it wouldn't need Transceivers just a single Transmitter and multiple Receivers.

Then I would be able to run all of me trains on "Frequency" 1 and motorize my switches using "Frequencies" 2 & 3.

Anyone interested in working on this?

I can try on some electronic stuff with micro controller.

But as doing with my PhD course together, this may take some time.

Also, didn't think of a good system/control method yet...

Hope you guys give some ideas =]

[Toastie]

Addressable IR/RF - RF/IR system

Hi kyphur,

I believe this is entirely possible - it depends a little on details though. First, you'd need to decide whether or not you want to replace the entire PF stuff by new stuff - I guess not, at least not on the receiver side with all the nifty connectors and so on, right?

If that is so then a little thingy needs to go in front of the PF receivers. On the transmitter side you could go all custom but then the PF remote dials and switches are also gone. So lets presume you want to tie into the IR bit stream.

In this case, I'd wrap simply an "address frame" around the PF "message content". On the receiver side, some intelligence (PIC, Arduino, etc.) decodes first the address (e.g., 0 ... 255) and then decides if the message content goes through or not. For this to work, the respective receiver should only see IR light from the little thingy positioned in front. On the transmitter side - (using the LEGO PF remotes), each remote needs a dedicated IR pickup (at virtually no cost, will post some stuff in this regard soon) which goes to the transmitter intelligence (again PIC, Arduino, etc.). That one temporarily stores the remote bit stream, puts an address in front and sends the whole package out via RF, 4 times, as the original remotes do as well. I believe that there is ample of ucontroller code out there dealing with bit stream handling and things like address decoding. This would be again entirely non-fancy OOK protocol basically replicating what comes from the PF remotes ...

This way you would not need several RF frequencies. Also, the address range could be much larger. The entire transmission will be somewhat longer, but that may be tolerable.

Again, just ideas, I am no e-expert at all. ucontroller gurus might have a much more elegant way of realizing what you are looking for.

Best regards,

Thorsten

[ZueriHB]

Something like that would be great.

But what I would like is a version to build into the IR Receiver. It would negate the use of unmodified remotes, but allows a low profile addressable system for many trains, where space is sacred.

[JopieK]

My students are working on a system with the nRF24L01(+) RF adapters. They are transreceivers so they can include feedback. Is vey handy if you really want to automate your trains (like they want to do and I want to do for myself).

[kyphur]

I believe this is entirely possible - it depends a little on details though. First, you'd need to decide whether or not you want to replace the entire PF stuff by new stuff - I guess not, at least not on the receiver side with all the nifty connectors and so on, right?

If that is so then a little thingy needs to go in front of the PF receivers. On the transmitter side you could go all custom but then the PF remote dials and switches are also gone. So lets presume you want to tie into the IR bit stream.

>>Snipped for brevity<<

This way you would not need several RF frequencies. Also, the address range could be much larger. The entire transmission will be somewhat longer, but that may be tolerable.

Again, just ideas, I am no e-expert at all. ucontroller gurus might have a much more elegant way of realizing what you are looking for.

Yes, yes and finally YES...

Ideally the RF would simply be a go between as in your original design. The 1x4x2 receiver can be added to almost any existing PF design.

If everything would use the RF then we shouldn't need to shield the IR Receivers if we shield the IR Transmitter (like a capture hood that had the RF Transmitter's IR Receiver in it so only the RF Transmitter gets the signal.

I understand that the addresses could be much higher than the 16 I suggested. I used 16 for a few reasons:

• Simplicity: We'd need to set the address on the transmitter before sending commands and each receiver should be user configurable address.
  
• For Sending commands to Groups of receivers we could set the address on the RF to "ALL" and then your one of the four PF Frequencies on the LEGO Transmitter so I could stop all trains on Freq 1 (for example).
  
• For the Transmitter, if we keep the address count low then we can have a bank of on/off toggles along the top front edge that would allow us to select multiple addresses for a command. The "Address Frame" could contain a bit for each of the 16 addresses, if the receiver's address bit is 1/on/true then the receiver passes the command through. This would allow us to throw switches in groups or start/stop/slow/accelerate trains (or multiple engines in the same train) together.
  

Since the stop button on TLG's remote sends the BRAKE Command it would be nice to have a "FLOAT" button on the RF Transmitter so if I have 2 Locos on a train I can Float one of the engines instead of having to run it if I don't need the power.

Is vey handy if you really want to automate your trains (like they want to do and I want to do for myself).

I wouldn't mind automating my trains (especially for my big layout) but without on the fly trickle charging that would be useless and I don't want to get stuck with he limitations of 9v track for power.

Edited November 22, 2011 by kyphur

[Toastie]

My students are working on a system with the nRF24L01(+) RF adapters. They are transreceivers so they can include feedback. Is vey handy if you really want to automate your trains (like they want to do and I want to do for myself).

Hi JopieK,

this is breathtakingly beautiful RF stuff. I just checked the Nordic website and then some follow-up links to e.g. RF Semiconductor (link opens PDF).

Are your students using the 8051 (oh my, very good memories come to mind - an 8051 was doing my gas phase concentration measurements in the lab by taking pressure drops from known volumes ... I still have that module in my office ...) equipped version? Or do you plug the RF modules into your Arduinos?

Fantastic! Any idea when the hardware rolls? Or does it already?

This is going to be very, very exciting.

Best regards,

Thorsten

P.S. The back channel is naturally also very handy for protocol safety; instead of issuing 4 repetitive bit streams as the PF remotes do, usually 1 transmission is sufficient. Only if that did not get acknowledged, further transmissions are going out.

Edited November 22, 2011 by Toastie

[JopieK]

<br>Hi JopieK,<br><br>this is breathtakingly beautiful RF stuff. I just checked the Nordic website and then some follow-up links to e.g. <a href="http://www.semiconductorstore.com/pages/asp/DownloadAttachment.asp?d=68295&e=i" class="bbc_url" title="Link" rel="nofollow external">RF Semiconductor (link opens PDF)</a>. <br><br>Are your students using the 8051 (oh my, very good memories come to mind - an 8051 was doing my gas phase concentration measurements in the lab by taking pressure drops from known volumes ... I still have that module in my office ...) equipped version? Or do you plug the RF modules into your Arduinos?<br><br>Fantastic! Any idea when the hardware rolls? Or does it already?<br><br>This is going to be very, very exciting.<br><br>Best regards,<br>Thorsten<br><br><br>P.S. The back channel is naturally also very handy for protocol safety; instead of issuing 4 repetitive bit streams as the PF remotes do, usually 1 transmission is sufficient. Only if that did not get acknowledged, further transmissions are going out.<br>

<br><br><br><br>They use Arduino pro mini's. Though I preferred them to make an RF -> IR link, they insisted on making their own way of steering the engine (using a non-LEGO motor driver).<br><br>It should work in january. They have until april (that is when they start for their exams) so if they finish in january they can do testing (in primary schools) and do some final adjustments.<br><br>

[kyphur]

I'm just wondering, what's the battery draw of the RF to IR component?

[Toastie]

I'm just wondering, what's the battery draw of the RF to IR component?

Hi kyphur,

next to nothing - 10 mA peak when sending RF, about 3 mA max. when listening for RF (most of the time). I wanted the transceivers to run from "active" RCX sensor ports - they can only deliver that much.

Regards,

Thorsten