Threaded Mode | Linear Mode

Martin Hepperle · (This post was last modified: 06-27-2014 07:45 AM by Martin Hepperle.)

(06-26-2014 10:08 PM)everettr Wrote: I was confused about pulses and bursts, and how the IR detector interprets them. It is getting clearer to me now. I will probably go with the TSOP4133 part that Christoph suggested, though I am sure this is very similar to those that you listed.

5 Kb, what a whopper :-) If it fits the flash and meets the timing constraints, no problem. It sounds like you are using interrupts for both the serial and the burst timing. I would like to see how you did that, since I have been wondering if some sort of caching of data would be needed to separate IR operations from serial communications. That is an interesting idea about additional ESC sequences, but how would you persuade a calculator to emit the new sequence?

(06-26-2014 07:58 AM)Martin Hepperle Wrote: I just finished the first version of the code and can make it available if you are interested. I am just adding some comments so that the code is understandable.
I am definitely interested in seeing your project!
Thank you,

Yes, I used a pin-low interrupt to capture the start of a data frame and then a timer interrupt to capture the half-bits. Before that I had tried the quick&dirty approach (polling with while() loops) but that was unreliable, inelegant and dirty.
The other problem was that I first had the serial communication in the interrupt service routines (resp. in the polling loops) but I quickly learned that serial I/O is too slow so that I lost bits and sync. Therefore I implemented a ring buffer (mailslot) where the interrupt routine places the decoded and error checked byte and the main loop later emits these to the serial line. This works very well (i would even dare to say perfectly) and I noticed that I could make the buffer very small (1-2 bytes), but stuck with a voluptuous 8-16 byte buffer.
My error checking corrects one flipped bit and I think this could be improved, but I am not sure.

Emitting special escape sequences should be asy by sending e.g. an ESCape character (ASCII 27) and then a code which is not used by the printer and does not indicate a graphics sequence. For example "ESC 0" could initiate and terminate a different command mode and this could be filtered out of the IR stream so that the command is not sent to the printer. I have made provision for such a thing in the code, but it is more of a hook and not yet fully developed.
I think most of the better calculators can send individual characters/ASCII codes.
If the calculator can only emit simple thinkgs, one couls us a magic work (number or string) to switch modes, but that should be the last resort.

Code may be posted here when polishing is finished.

Martin

Martin Hepperle · (This post was last modified: 06-27-2014 08:33 AM by Martin Hepperle.)

(06-26-2014 06:27 PM)Marcus von Cube Wrote: [... deleted ...]

@Martin: The IR range depends on the type of IR LED. Katie has made some experiments. I don't recall the exact details, but I can send you one of mine.

So my question would be: what ranges do people get with their WP34S?
I obtain about 100 mm, which is o.k, but something like 500 mm would be nice. I do not need 10 meters and do not want to drain the batteries too fast.
I only was astonished about the power of the HP 48 - it seems to illuminate the whole room with his IR and can print even if not pointed at the printer.

I obtained my IR diode for the HP 20b from H. Pott together with his fabulous USB board, but am considering to make another WP34S from a HP 30b.

Martin

Marcus von Cube · 06-27-2014, 08:01 AM

Here is an old thread on IR printing. It contains info from me and Katie and covers most of the questions (LED part number, range, commands, etc.).

Martin Hepperle · 06-27-2014, 08:15 AM

(06-25-2014 07:27 PM)Christoph Giesselink Wrote: For sure the HP-95LX has also the necessary hardware. And with a little software help we can send data to the printer:

Code:

... [deleted] ... ; Equations IRFMAT equ 0e30ah ; IR Format Register IRCNT equ 0e30bh ; IR Transmit/Receive Register

Is there something like a technical reference manual for these machines where e.g. the I/O addresses and how to use them are described?

Christoph Giesselink · 06-27-2014, 03:47 PM

(06-27-2014 08:15 AM)Martin Hepperle Wrote:
(06-25-2014 07:27 PM)Christoph Giesselink Wrote: For sure the HP-95LX has also the necessary hardware. And with a little software help we can send data to the printer:

Code:

... [deleted] ... ; Equations IRFMAT equ 0e30ah ; IR Format Register IRCNT equ 0e30bh ; IR Transmit/Receive Register

Is there something like a technical reference manual for these machines where e.g. the I/O addresses and how to use them are described?

Not at the moment. I send a copy of the "HP 95LX Developer's Guide" to Dave, so it will be part of the next Museum DVD set.

Christoph Giesselink · 06-27-2014, 03:54 PM

(06-27-2014 07:25 AM)Martin Hepperle Wrote: Yes, I used a pin-low interrupt to capture the start of a data frame and then a timer interrupt to capture the half-bits. Before that I had tried the quick&dirty approach (polling with while() loops) but that was unreliable, inelegant and dirty.
The other problem was that I first had the serial communication in the interrupt service routines (resp. in the polling loops) but I quickly learned that serial I/O is too slow so that I lost bits and sync. Therefore I implemented a ring buffer (mailslot) where the interrupt routine places the decoded and error checked byte and the main loop later emits these to the serial line. This works very well (i would even dare to say perfectly) and I noticed that I could make the buffer very small (1-2 bytes), but stuck with a voluptuous 8-16 byte buffer.
My error checking corrects one flipped bit and I think this could be improved, but I am not sure.

I wrote the REDEYE receiver code three times. The 1st version in 8086 assember for a Messdos PC. The signal from a IR-receiver was connected to the CTS line of a RS232C interface. The input of the program was interrupt driven by the CTS line interrupt. The last version used the PC timer chip to decode the input signal.

The 2nd version I wrote more a less parallel in 8051 assembler for a company. IR input interrupt driven, internal timer to decode the framing and a timer interrupt for the case the frame was incomplete with less than 2 bis missing.

The 3rd version is implemented in C and published under the GPL v2 inside Emu28 and Emu42 (file REDEYE.C). The implementation is also "interrupt driven". At every rising edge of the IR output pin the decoder is called. The timing is generated over the elapsed CPU cycles which is in reality the elaped time since the last IR signal rising edge. The implementation of the error correction is complete, in fact it can restore two missed bits. Read the originally HP documentation (HP 82240B Technical Interfacing Guide and Hewlett Packard Journal October 1987 page 16) carefully please, especially the concept about "missed bits" at IR bursts and drop outs in the Hewlett Packard Journal article. This is very important for the error correction. IMHO the Journal article gives more practical hints for a software implementation then the Technical Interfacing Guide.

I agree with the ring buffer solution for the captured character. The IR input interrupt had highest priority in my 8051 implementation. On another thing I recognized that we now have 2014, the original 8051 program design was made in 1993, the latest version was from 2002 and the firmware binary for the 8051 had a size of 676 bytes! Sorry, I'm not able to publish this firmware.

Martin Hepperle · 06-30-2014, 11:39 AM

(06-27-2014 03:54 PM)Christoph Giesselink Wrote: [... deleted ...]

The 3rd version is implemented in C and published under the GPL v2 inside Emu28 and Emu42 (file REDEYE.C). The implementation is also "interrupt driven". At every rising edge of the IR output pin the decoder is called. The timing is generated over the elapsed CPU cycles which is in reality the elaped time since the last IR signal rising edge. The implementation of the error correction is complete, in fact it can restore two missed bits.

[... deleted ...]

Ah, thank you, I had not seen these sources and I followed a different way than proposed in the HP docs (measuring the time between bursts) by sampling at regular intervals. Both strategies seem to work well. I hope to test my receiver also with an HP 28S soon and then put it into a nice casing. I am also looking for a cheap thermoprinter understanding ESC/POS (cash register) codes which would allow building a low cost HP 82240 replacement for hobby use (just for fun, no commercial background).

rwiker · 07-01-2014, 04:58 AM

(06-30-2014 11:39 AM)Martin Hepperle Wrote: I am also looking for a cheap thermoprinter understanding ESC/POS (cash register) codes which would allow building a low cost HP 82240 replacement for hobby use (just for fun, no commercial background).

Sparkfun has this which may or may not have the functionality you want (and may or may not count as "cheap").

Martin Hepperle · 07-09-2014, 12:51 PM

In the meantime I have tested my code with a HP 48G and the WP 34S and the results are as expected. For further tests I used a HP 28S and found the IR-transmission relatively buggy (incomplete data frames, bit errors).

Does anyone have experience with the HP 28S and IR-printing and knows whether there is a known timing problem with the HP 28S? Is the 28 known to be more finicky w.r.t. printing? I have not looked at the signal with an oscilloscope yet.

Maybe the reason may also be that I still use a 38 kHz IR-receiver - I will replace it with a 33 kHz one soon to see whether this makes a difference.

In the end I would like to dump the ROM of the 28S via IR so that I can use it in EMU28.

Martin

Christoph Giesselink · (This post was last modified: 07-09-2014 11:53 PM by Christoph Giesselink.)

(07-09-2014 12:51 PM)Martin Hepperle Wrote: In the meantime I have tested my code with a HP 48G and the WP 34S and the results are as expected. For further tests I used a HP 28S and found the IR-transmission relatively buggy (incomplete data frames, bit errors).

Does anyone have experience with the HP 28S and IR-printing and knows whether there is a known timing problem with the HP 28S? Is the 28 known to be more finicky w.r.t. printing? I have not looked at the signal with an oscilloscope yet.

The HP-28S works successful in connection with a HP-82240A/B printer and with my Redeye-Serial converter.

The main difference between a HP48 and a HP28 is the IR burst and half-bit timing generation.

The HP48 chip Clarke or Yorke has a hardware register called LBR (Led Buffer Register). This register is responsible for sending a half-bit in the REDEYE protocol. The timing of this register is done by hardware and derived from the 32768Hz crystal, so the timing of the IR burst and the half-bit length is very exactly.

In opposite the HP28 and all other calculators using the Lewis chip (2nd Clamshell generation 19B/19BII/28S and High End Pioneer 17B/17BII/27S/42S) or the combination of 1LK7 Saturn and 1LP2 Centipede chip (1st Clamshell generation 18C/28C) don't have this hardware driven register. Here the timing of the half-bit length is completely done by the CPU. Only the generation of the 32kHz IR signal is done in hardware. So on software side you have to open a gate for the exact time of 7 IR burst cycles. Overall the CPU has to control the IR burst length time and the half-bit length time. To make this more difficult the CPU has no constant speed. On the 1LK7 Saturn CPU the CPU strobe frequency (~620kHz) is generated by a LC oscillator, on the 1LR2 Lewis over a PLL from the 32768Hz base frequency to get a CPU strobe frequency of nominal 1MHz. To get a more or less exact timing, the actual CPU speed is measured over the internal timer driven by the 32768Hz crystal. So from time to time the CPU speed is measured to eliminate the CPU speed drift over temperature, humidity, ...

To make it short, the timing accuracy of the REDEYE protocol made my CPU is much less than the one generated by the hardware LBR register inside the HP48 series.

So your method checking the IR state on each half-bit position is less timing tolerant than the solution suggested in HP Journal article (used by my hardware solution and inside the Emu28 and Emu42 simulation). In the suggested solution you are synchronizing your timing at every received bit and not at the beginning of the 12 bit frame.

(07-09-2014 12:51 PM)Martin Hepperle Wrote: In the end I would like to dump the ROM of the 28S via IR so that I can use it in EMU28.

To stay correct, the 28S can be emulated by Emu42 (with simulation of the 1LR2 Lewis and 1LR3 Sacajawea chip) and the 28C with Emu28 (a simulation of the 1LK7 Saturn in connection with the 1LP2 Centipede chip).

Martin Hepperle · 07-10-2014, 09:31 AM

Christoph,

thank you for the excellent technical explanation. I'll think it over and might implement the "self calibrating" approach to decode the redeye protocol in a more robust way.

And, yes, yesterday evening after stumbling across some rom images in the woods I also leared that for the 28S emulation I'd better use the EMU42 software...

Thank you for sharing your knowledge, Martin

Marcus von Cube · 07-10-2014, 11:32 AM

(07-09-2014 12:51 PM)Martin Hepperle Wrote: In the meantime I have tested my code with a HP 48G and the WP 34S and the results are as expected...

There was a reason to implement the printer software on the 34S the way it is:

Accurate timing increases the range, exspecially for a low power device as used by the 34S.
Accurate timing is only available with a crystal. Hence the printer firmware is not available without the XTAL modification.
The timing is mostly done with the help of hardware timers and interrupts. This is accurate and energy efficient because the CPU is not involved in timing.

The efforts obviously pay off in other applications, too, as your experiments show.

Martin Hepperle · (This post was last modified: 08-06-2014 08:18 AM by 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

Michael Lopez · 08-06-2014, 11:09 AM

Thanks for the comprehensive information.

I recently purchased a NOS HP82240B printer out of curiosity & whilst it seems to work well with the 48 series (48SX & 48GX), it is rather unreliable with my HP50G calculators. Noticed in the original post that there is a reference to these being switchable to 82240B mode - would you please explain how this is performed?

Thanks,

Michael

Christoph Giesselink · 08-06-2014, 07:18 PM

(08-06-2014 08:15 AM)Martin Hepperle Wrote:

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.

I confirm. So it's luck that REDEYE receivers work with the TSOP1833 or TSOP4133.

I made a test equipment for a REDEYE compatible printer many years ago. This printer used the TSOP1833 as receiver. The REDEYE transmitter in the test equipment was crystal driven and always send exactly 7 IR pulses in the half bit frame. I cannot remember any problems with the receiver chip in the printer batch production during the lifetime of this product. So we had luck that we always get batches of TSOP1833 that worked with 7 or less pause pulses.

Martin Hepperle · 08-07-2014, 06:22 PM

(08-06-2014 11:09 AM)Michael Lopez Wrote: Thanks for the comprehensive information.

I recently purchased a NOS HP82240B printer out of curiosity & whilst it seems to work well with the 48 series (48SX & 48GX), it is rather unreliable with my HP50G calculators. Noticed in the original post that there is a reference to these being switchable to 82240B mode - would you please explain how this is performed?

Thanks,

Michael

Michael,

I had written my first post without having Access to an HP 40g. In the meantime I acquired one and found that for manual printing you only have to select "Infrared" in the print Dialog (Options are Infrared, USB, Serial). This should set the appropriate flags. For Output from a program you have to set the appropriate flags.

System flags of interest:
I/O Device (–33),
Printing Device (–34), << defines IrDA or Redeye protocol
Double-spaced Printing (–37),
Linefeed (–38),
I/O Device for Wire (–78)

See the description of system flags in the "Advanced Users Reference Manual", Appendix C.

–33 I/O Device.
Clear: I/O directed to USB/serial port.
Set: I/O directed to IrDA port.

–34 Printing Device.
Clear: Prints via IR to the HP 82240 printer. Flag –33 is ignored.
Set (default): Printer output directed to USB/serial port if flag –33 is clear, or to
IrDA compatible printer otherwise.

Please also note that the range of the HP 50g's IR Signal is very small, compared to the HP 48 - just about 50-100 mm ( 2-4 inches). I guess this is your problem.

Hope this helps.

Martin Hepperle · 08-07-2014, 06:33 PM

(08-06-2014 07:18 PM)Christoph Giesselink Wrote:
(08-06-2014 08:15 AM)Martin Hepperle Wrote:

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.

I confirm. So it's luck that REDEYE receivers work with the TSOP1833 or TSOP4133.

I made a test equipment for a REDEYE compatible printer many years ago. This printer used the TSOP1833 as receiver. The REDEYE transmitter in the test equipment was crystal driven and always send exactly 7 IR pulses in the half bit frame. I cannot remember any problems with the receiver chip in the printer batch production during the lifetime of this product. So we had luck that we always get batches of TSOP1833 that worked with 7 or less pause pulses.

Christoph,

thank you for your reply. I had hoped that you had used some alternative Hardware which I could copy. I think someone mentioned a commercial US product - I would be interested in learning about the innards of this hardware.

If you only sent 7 pulses (which is perfectly within the HP specs of 6-8 pulses) you gained some time for the pause (one 32kHz cycle), which may have helped the TSOP to detect the pause. The HP 48 and 28 seem to send 8 pulses for each burst, resulting in a shorter pause.
Currently I am playing with the 1133, maybe I should try some 1833 instead, if I can get some (I have one 1838, but thought it would be better to move closer to 33 kHz).

Martin

Christoph Giesselink · 08-07-2014, 10:11 PM

(08-07-2014 06:33 PM)Martin Hepperle Wrote: If you only sent 7 pulses (which is perfectly within the HP specs of 6-8 pulses) you gained some time for the pause (one 32kHz cycle), which may have helped the TSOP to detect the pause. The HP 48 and 28 seem to send 8 pulses for each burst, resulting in a shorter pause.
Currently I am playing with the 1133, maybe I should try some 1833 instead, if I can get some (I have one 1838, but thought it would be better to move closer to 33 kHz).

I had a look at the CLARKE External Reference Specification and I can confirm that the 1LT8 Clarke chip inside the HP48SX use 8 pulses. The situation at the 1LR2 Lewis chip inside the HP28S and the 1LP2 Centipede chip inside the HP28C is a little bit different, here you're enable a channel sending 16us pulses to the IR transmitter LED. The number of pulses depends on the time the STL pin is set to high by the CPU. This is inaccurate.

For more information you may have a look at the HP48 I/O Technical Interfacing Guide PDF. There's also a schematic of the HP48 IR receiver.

The TSOP1833 is out of production for many years now. I had a look at my personal REDEYE receivers, they all use the TSOP1833 chip. None of them use the later TSOP4133 chip which need one more pulse pause time than the TSOP1833. So I have no long time experience with the TSOP4133 in connection with the HP48 or HP28S.

The attached file show my smallest REDEYE receiver with a RS232C interface.

Michael Lopez · 08-08-2014, 07:17 AM

(08-07-2014 06:22 PM)Martin Hepperle Wrote:
(08-06-2014 11:09 AM)Michael Lopez Wrote: Thanks for the comprehensive information.

I recently purchased a NOS HP82240B printer out of curiosity & whilst it seems to work well with the 48 series (48SX & 48GX), it is rather unreliable with my HP50G calculators. Noticed in the original post that there is a reference to these being switchable to 82240B mode - would you please explain how this is performed?

Thanks,

Michael

Michael,

I had written my first post without having Access to an HP 40g. In the meantime I acquired one and found that for manual printing you only have to select "Infrared" in the print Dialog (Options are Infrared, USB, Serial). This should set the appropriate flags. For Output from a program you have to set the appropriate flags.

System flags of interest:
I/O Device (–33),
Printing Device (–34), << defines IrDA or Redeye protocol
Double-spaced Printing (–37),
Linefeed (–38),
I/O Device for Wire (–78)

See the description of system flags in the "Advanced Users Reference Manual", Appendix C.

–33 I/O Device.
Clear: I/O directed to USB/serial port.
Set: I/O directed to IrDA port.

–34 Printing Device.
Clear: Prints via IR to the HP 82240 printer. Flag –33 is ignored.
Set (default): Printer output directed to USB/serial port if flag –33 is clear, or to
IrDA compatible printer otherwise.

Please also note that the range of the HP 50g's IR Signal is very small, compared to the HP 48 - just about 50-100 mm ( 2-4 inches). I guess this is your problem.

Hope this helps.

Hi Martin,

Thanks for the explanation on the effect of the Flag -33 & -34 settings on IR communication via the HP50G.

Based on this, I've been using the correct settings to print to the HP 82240B but it is still rather "flaky" with the HP50G. Through my own trials, I realised that the transmission distance needed to be extremely short & now typically place the calculator almost right up against the IR receiver on the printer.

Have also played with the HP50G's height relative to the printer & it does seem to perform better if I raise the calculator ~ 3-5 mm. I think this may be due to the positioning of the IR transmitter on the calculator versus the earlier HP48 models the printer may have been designed for.

Whilst it is ok as a "play thing", I am not sure I would recommend extensive printing to a HP 82240B from a HP 50G.

Cheers,

Michael

Marcus von Cube · 08-09-2014, 11:22 AM

(08-06-2014 08:15 AM)Martin Hepperle Wrote: 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.

If I understand my code correctly, WP 34S outputs bursts of seven pulses. The generator is just the AND of two square wave clocks: 32768Hz and (32768/14)Hz. If you want to check the code, it's in trunk/main.c, routine put_ir().