Introduction
I recently got a Roomba (model 966). It's a "small" robot vacuum cleaner that drives around your house and does the day-to-day vacuuming.
In order to be able to limit its working area, you can set up some "light towers" that send out a thin infrared beam, which the Roomba will not cross.
Yes, I am aware that I can connect my model via WiFi and set up no-go zones via a mobile app. But I don't really feel like granting a moving robot with a camera access to Internet. Not that much on the IoT bandwagon.
Light Tower
The included light tower looks nice, but it is sort of in the way, will probably get kicked around, and runs on batteries.
Full view of the area:
I'd like for the beam to originate from the crack between the door and the trim. As the picture hints, there is around 5mm to use. It would make the setup invisible in practice.
I could take the tower apart and in the process convert it to 5-12V use via some small DC-DC buck converter, but I decided to try to build my own tower. Also to keep the original tower for later.
While I was researching and thinking about this, MKme posted his take on the subject. He uses an MCU to generate the beam encoding. I'd like to try to get a 556 timer to do it. If possible.
Working out the beam encoding
My research showed that there were much disagreement on how the beam should be encoded. This is probably because people were using different versions of the towers and robots.
So: I am using the tower that come with a Roomba 966.
I decided to take a look at the encoding that my tower uses. But I did not have any IR receivers. I did however find a QRD1114 IR reflection detector in an old failed project. I hacked up a quick crappy amplifier using the QRD1114, a BC547, a 10k resistor and a 1k resistor. This is of course an inverting amplifier, thus the scope grabs below are inverted.
Overview of the signal:
Zoomed in:
So we have three ~500µs (~8.0ms — ~7.5ms) bursts with two ~7.5ms pauses
in between.
And a zoom on the short bursts:
Note that my crappy amplifier has limited bandwidth and thus distorts the
signal, and the "triangle
signal" is in reality a square wave signal that has been low-pass filtered.
But never mind. We can still see that 15 periods take ~394µs, thus one
is ~26.27µs. Giving a frequency of ~38kHz for the bursts.
(This could also have been found as 2.54kHz*15.)
Zoomed further out:
The bursts have ~135ms between starts.
This fits nicely with what (some) others have found: A carrier wave of 38kHz. 500µs on and 7.5ms off repeated 3 times
Assumptions on requirements for the tower
- I assume that iRobot use a decoder chip for the IR signals.
This will probably mean that it will have a fairly narrow bandpass filter around 38kHz for noise reduction.
- I assume that the demodulated IR signal is processed by a microcontroller doing other work too.
This means that the 500µs and 7.5ms timings are way less critical.
- I assume that the 135ms spacing between 3×pulses is only for power saving
This means that this spacing can be ignored. And since I plan to not have my tower run on batteries, this not a real problem.
Testing assumptions
I built a tower prototype using two 555 timers and the QRD1114 on a breadboard:
I tuned the 38kHz carrier frequency pretty closely, but for the 500µs and 7.5ms timings I just used a 555 calculator and tried to get close, using standard component values.
The beam from the IR diode is very weak and very wide, but the Roomba does run away from it.
Thus it looks promising.
The setup draws around 15mA. Which is fine.
Future work
I plan to do the "brains" of each tower using a 556 timer (which is essentially two 555 timers in one chip).
I'm currently waiting for 556 timers and IR diodes to arrive via the 'slow boat from China' before I can continue to do the setup on stripboard.
Also experiments in shaping of the beam will be easier once I have some cheap IR diodes to experiment with.
This will be detailed in part 2. Hopefully as a success story 
Thanks
Big thanks to Paul for talking a lot about 555 timers, and thus pushing me to finally start looking into them.
Thanks to MKme for documenting his version and getting me past the "when I get some time" stage.