Calculators with Support of the 82240 IR-Printer

[Martin Hepperle]

Oh my! My journey into HP-IR land has been extended.

Some Numbers
The frequency of the IR signal is f = 32768 Hz so that one pulse of 50% duty cycle has a duration of t_pulse = 1/32768 / 2 = 15.3 us (microseconds)).
The HP docs specify a burst length of 6 to 8 pulses = 183 to 244 us as valid range. All my test calculators output 8 pulses per burst.
One complete bit takes 854.5 us, one half-bit time is therefore 427.25 us

• A logic one starts with 8 pulses
  8 pulses = 8 / 32768 = 244 us followed by a pause of 854.5 - 244 = 610.5 us
• A logic zero starts with a half bit pause of 854.5/2 = 427.25 us followed by 8 pulses = 8 / 32768 = 244 us followed by a pause of 427.25 – 244 = 183.25 us. The same interval occurs between the bursts of the three start half-bits. This pause corresponds to 183.25/10^6 * 32768 = 6 cycles. This is a critical value as this pause of 6 cycles should be detectable.
  

Reading the Docs
TSOP 11XX, 18XX, 21XX, 23XX, 41XX, 43XX, 25XX, 45XX Datasheets
The burst length should be 6 or more pulses, so that the time of at least 6/f = 6/32768 = 183 us is recommended. This is within the HP specs.
The output pulse of the TSOP 11XX has a length of
t_burst – 4/f < t_out < t_burst + 6/f0
which means that it may be 4 cycles shorter or 6 cycles longer than the actual burst. If the output is at the upper limit of this range, it will close the gap between two bursts.
The TSOP 18XX datasheet explicitly states that it requires a gap of at least 9 cycles after each burst.. In time this means
t_gap > 9 / 32768 = 274.7 ms
This is longer than the time between the start-halfbits, so that a TSOP 18XX may be unable to detect the gap between these and output them together as one continuous long signal.

Now after procuring me an oscilloscope (I wanted one for a long time anyway and this gave me a good reason) I observe that all bursts are detected but often bursts following in a short interval (start-half-bits, zeros followed by ones) are output as one pulse. Sometimes all individual bursts come through. In general it seems to be unreliable to detect the individual bursts with these TSOP XXXX receivers (I played with TSOP 1133 and VS1833). This is also the reason why my first implementation (I only detected the start of the first burst and then sampled at regular intervals) worked well, as long as the timing of the sender was accurate.
However with inaccurate senders (say HP 28S) and not being able to detect the individual bursts this does not work, as Christoph Gießelink already pointed out.
The attached picture shows the result of printing the same character twice. the first time the pulses are clearly visible, the second time some are connected.

Now what to do?
While I was looking for a small enclosure with an IR-window I found the IrDA receivers C4103A are used to connect HP LaserJet printers. While I was interested in the casing only, I also tested the receiver part of it and learned that it produces the IR signal, i.e. the output is the raw nicely amplified 32.678 kHz pulses without integration. So I now see two ways to proceed:
a) try to find another integrating IR receiver which can handle the short gaps between the bursts,
b) build my own discrete receiver unit using R/C integrator and an OP-Amp,
c) use the raw signal and do the decoding in software.

My thoughts about these approaches are:
a) This option would be the most desirable, but I am not sure whether such a solution exists.
b) This might be a good solution, and I came up with a design (using the LTSpice simulation tool) that could work. However I fear that in the real world this would require a lot of tweaking to work properly and be reliable. I am not an electronics engineer, just an aerospace engineer. While I can think digital and know how to fly to the moon, I have only a faint understanding of non-digital technology like R/C circuits and the like.
c) This solution seems to put a rather high load on the CPU as it must time and the 32 kHz pulses to detect the bursts. On the other hand this might be the most flexible solution.
Maybe some of you electronics experts can give me some ideas or point me into the “right” direction? If this discussion becomes too long and specific, you can also send me PM and I will summarize the end result here. Maybe there a hardware design published somewhere for this purpose which I have not found yet?

Thank you, Martin