The Museum of HP Calculators

HP Forum Archive 08

[ Return to Index | Top of Index ]

converting HP41 cx IR data to 8 bit serial
Message #1 Posted by Ron Meek on 29 June 2002, 3:24 p.m.

I am trying to construct a stepper motor driver for a rotary table. I have a HP 41cx with an 82242A infrared converter. I want to convert the output of the infrared converter to serial ascii at 2400 baud, 1 start bit, 8 data bits, 1 stop bit, no parity. I want to do this in hardware, as a PC will be too bulky for the job. Unfortunately, I sold my HPIL serial interface, and only have a parallel and a HPIB interface left. The output of the hardware will be fed to a Ferret Tronics stepper driver chip (FT609) that will drive the stepper. Can anyone help?

Re: converting HP41 cx IR data to 8 bit serial
Message #2 Posted by Tony Duell (UK) on 29 June 2002, 4:05 p.m.,
in response to message #1 by Ron Meek

Without really thinking about it, it would appear to be easier to convert the output of the GPIO parallel box to serial than to use the IR printer output. Converting (essentially) Centronics parallel to serial is a problem for which there are many solutions.... Years ago I did make a parallel/serial coverter for the IR printer interface. I have no idea where I put the schematics (but I will still have them somewhere), but I remember it as being about 20 TTL chips and a UART. It was not simple. These days I'd probably program a microcontroller to do it. Any of the modern single-chip microcontrollers should be able to do it, I think.

Re: converting HP41 cx IR data to 8 bit serial
Message #3 Posted by Andrés C. Rodríguez (Argentina) on 29 June 2002, 4:36 p.m.,
in response to message #1 by Ron Meek

The main issue here is that the IR protocol used by the calculators has very little similarity with a UART or serial port (I mean the RS 232 kind). On equipment designed after 1990, the IRDA "standard" provided functionality very similar to the serial ports, making adapters relatively easy to build. Since the calculator IR that HP designed was pre-IRDA, it lacks such virtue. There was an article in the Hewlett Packard Journal around mid-1987 which described the timing and "parities" used by the IR port of the HP 28, 42, etc. The start and stop signalling and other features were not directly mapable to the typical asynchronous signalling of a serial port.

If you look in the Museum Archived Forum Messages, and look for some messages from Steve (Australia), he explained how to decode the IR signals using not a serial port, but the audio input of a PC sound board.

Re: converting HP41 cx IR data to 8 bit serial
Message #4 Posted by Ellis Easley on 29 June 2002, 6:32 p.m.,
in response to message #3 by Andrés C. Rodríguez (Argentina)

While I don't know whether the 41C IR module or any of the calculators used the same method, I do know that IRDA used as its physical layer an HP standard (I think it was called "HP-SIR") which was implemented in some HP palmtop or notebook computers (HP100/200LX? OmniBook?). The main thing IRDA added was a network-style protocol for reliable transmission.

Re: converting HP41 cx IR data to 8 bit serial
Message #5 Posted by Ellis Easley on 29 June 2002, 6:49 p.m.,
in response to message #3 by Andrés C. Rodríguez (Argentina)

I searched as you suggested, this thread: discusses the protocol in much detail. It sure is "something else".

Re: converting HP41 cx IR data to 8 bit serial
Message #6 Posted by Ellis Easley on 29 June 2002, 5:43 p.m.,
in response to message #1 by Ron Meek

I think the HP41 IR module lets the 41 print to the 82240A/B printers (what else?). I also think the other calculators with IR, including the 48, 38, and 39 will also print to the 82240. Since those graphing calculators can communicate with each other through either the IR or the cable, and since the cable connection also connects to a standard RS-232 port (three wire, anyway), it seems logical to assume that the IR interface of the 82240 (and the 41 IR module) is a similar protocol to RS-232.

There is a standard called IRDA used by laptops and now incorporated into the multi-I/O chips in PCs as an optional mode of operation of the serial ports. IRDA was based on a protocol HP developed for their first palmtop PCs (or was there another level between "laptop" and "palmtop"?) like the 100 and 200 IIRC, small clam-shell units with full keyboards - the first things I saw with PCMCIA hard drives.

Anyway, IRDA physically is basically RS-232 modulating a narrow pulse at the beginning of the bit cell. It seems like one objective was to save power in a battery powered device. Where the RS-232 bit stream has a "one" (or whatever a start bit is), the narrow pulse is transmitted by an IR LED. Where the bitstream has the opposite sense, no IR is transmitted. I think the original name of HP's standard was "HPIR" or "HPSIR".

If this is correct, and the 41C IR module is based on something like HP-SIR or IRDA, you will need to receive the IR signal, translate it to RS-232 by stretching the pulses, then feed them into a UART. There used to be UARTs that could be completely programmed through pins, I don't know if you will find anything other than an 8250 or 16450 derivative today, and they need a microprocessor to program them. The main thing a UART does for you (on the receive side) is detecting the start bit including distinguishing a false start bit. If you are able to use a slow enough rate of sending bytes (allowing more than a full byte time between bytes) and don't have to worry about noise (stray IR pulses in this case), you could just use a one-shot as a start bit detector to start your receive clock (by RS-232 rules, you latch the data in the middle of the bit cell), then shift the data into a shift register. When the start bit gets to bit 9 or 10 or 11 (depending on whether the protocol has 7 or 8 data bits and 1 or 2 stop bits), it can enable the shift register contents to be transferred to another latch to be the next phase for the stepper motor (I don't know if the chip you name is a driver or an intelligent controller), this accomplishes the same purpose as the double buffering done in a UART. After the data is transferred you could clear the shift register to prepare it for the next byte's start bit to trigger the latching of the data. With the crude one-shot start bit detector, which will time out more than one byte time after the last data bit which has the same sense as the start bit, you can use its trailing edge to re-arm the data transfer circuit as well as the receive clock synchronizer.

Come to think of it, if you don't have to worry about noise, why bother stretching the IR pulses? You will still need to synchronize your receive clock and you will have to do it with more precision with a narrow data pulse.

Also, if you make the one-shot non-retriggerable (gate the trigger with the inverted output) you can set it to time out just after the last stop bit.

You could even use the trailing edge of the start bit detector, or perhaps more properly the "byte gate", to transfer the data from the shift register to the storage register, meaning you could forget about "arming" the shift register and detecting the arrival of the start bit in the last cell of the shift register. This would be trading some noise immunity for a simplification of the circuit.

Of course, all this assumes that what comes out of the 41 IR module is something like IRDA. You need to start by building a simple IR receiver and using an oscilloscope to see what the output looks like. A photodiode alone is sufficient for this. Applying some reverse bias to the photodiode speeds up its response by reducing its capacitance. There are two general wavelenghts of IR LEDs and some photodiodes are built with filters to make them respond better to one or the other. Some of these come in opaque (to visible light) packages. I think the photodiodes in clear packages will respond to either IR wavelength as well as to visible light.

Another possible issue is whether the protocol of the 41 IR module contains any overhead bytes around the data bytes. If this is the case you will need to filter them out. If you didn't want to use a microprocessor to do this, you could use a longer shift register and then transfer just those bits you want to the storage latch.

In this same vein, is it possible to send just one character from the 41 to the printer? I assume to control a stepper motor, you want to send a series of phases at a variable rate. The 41 might not be able to send characters - or blocks containing one relevant character - fast enough to allow you to drive the motor as fast as you are hoping to.

Also, the signalling rate you want - 2400 baud - might not be what the 41 IR module is doing. It seems like the default rate for the graphing calculators is 9600 baud (on the cable, anyway).

If your chip is intelligent, it might be able to buffer data and work with higher level commands than just individual motor phases. If this is the case, and if it will only work at 2400 baud, and if the 41 IR module sends more than just your data, you should consider using a microprocessor to receive the IR data, filter out the overhead, and retransmit the data bytes at 2400 baud to your chip. If the microprocessor only had one UART, I would use the UART to receive and use a general purpose output pin to "bit-bang" the 2400 baud output.

If any of this works, it will mean that there has been an HP41C RS-232 interface around all this time (even if it is transmit-only). On the other hand, it might be that none of this will work, in which case you will have to become expert in HP41C machine language to do what you want to do. Either that or figure out just what the IR module's protocol is and use a microprocessor to translate it.

BTW, there is the UART (Universal Asynchronous Receiver - Transmitter) and the USART (Universal Synchronous / Asynchronous Receiver - Transmitter) but did you know that in the National Semiconductor 1981 CMOS catalog they list a Universal Fully Asynchronous Receiver Transmitter?

Re: converting HP41 cx IR data to 8 bit serial
Message #7 Posted by Ellis Easley on 30 June 2002, 6:14 a.m.,
in response to message #6 by Ellis Easley

After reading Tony Duell's description ( of the IR printer protocol in the Archives thread I see that the printer protocol isn't like IRDA - if I am remembering IRDA correctly regarding the modulation - and I'm sure IRDA doesn't have the four additional bits because it can be implemented with a standard UART. IRDA is inherently two way and reliability was implemented in the upper layers through re-transmission. The printer protocol is one way, and I guess they wanted to give the printer its best shot at getting the data right the first time. However, I think my earlier ideas could be adapted to the actual printer protocol and improved with the new information. While the protocol is somewhat complicated by 4 bits per character of error checking/error correction information, as Tony points out, if you are trying to receive the data, you can ignore those bits if you're not worried about noise. You can always add support for them to make the system better.

The biggest difference from my earlier post is that instead of a narrow IR pulse at the beginning of only the "one" bits (or whichever have the same sense as the start bit), there is a 1/4 bit time IR pulse starting at the beginning of the bit cell for a "one", and a 1/4 bit time pulse starting at the middle of the bit cell for a "zero". You could still just look for a pulse at the beginning of the bit cell and if you find one, call it a "one", if you don't find one, call it a "zero". But clearly, you would be throwing away some reliability so it would be better to definitively identify a "zero" - although if you aren't going to implement the error checking and correction, I don't know what you would do with a bit that was neither "one" nor "zero", or one that was both!

The other difference has to do with the start bit. I thought it was a regular bit that happened to be of the polarity that required an IR pulse, to allow you to synchronize your receive clock to the beginning of a character. RS-232 asynchronous communication always depends on a certain amount of "dead time" (at least the 1 or 2 stop bits time) between characters to make sure you are receiving on a character boundary. The IR printer protocol uses a unique "code violation" - IR pulses in three consecutive 1/2 bit times - to identify the start of the character. It could be detected very nicely with a three bit shift register and an "and" gate. Detection of a valid start-of-character could trigger a state machine to clock another shift register for just the next 8 (or 12) bits. Or you could have just one shift register of [8 (or 12)] X 2 + 3 (+ 3 more for the three stop 1/2 bits, if you want to be very sure!) bits, clocked every 1/2 bit time, re-synchronizing the receive clock every time there is an IR pulse. Then every time three "IR pulse" bits arrive in the three cells at the far end of the shift register, transfer the bits you want to the storage register.

The signaling rate is 32768/28 or about 1170 bits per second. If you do need to re-transmit the data to your chip at 2400 baud, at least you don't need to worry about an overrun!

Re: converting HP41 cx IR data to 8 bit serial
Message #8 Posted by James M. Prange on 30 June 2002, 1:02 a.m.,
in response to message #1 by Ron Meek

For information on the format used by the HP 82240B printer, see; I suppose that the format would be basically the same for the 82240A. I don't know whether it was possible to transmit in "Serial InfraRed" ("SIR") mode with your combination of hardware, but if so, then I imagine it would be similar to the 48 series; see or


When there is no light, sound still remains...
Message #9 Posted by Andrés C. Rodríguez (Argentina) on 30 June 2002, 9:26 a.m.,
in response to message #1 by Ron Meek

I suppose the bit rate will not be enough for your purposes, but a nice way to output information from an HP41 calculator is by counting the pulses going to the buzzer, and varying the number of pulses by means of TONE instructions. Synthetic programming will give you a larger set of tones, and you can easily opto-couple the pulses if that is required for your project. Of course, your data rate will be only some tens of bits per second, but in some cases it may be enough.

The electronics to make this "interface" are very straighforward.

Some photos about this matter illustrate my article "Computer Memories from Argentina" here at the MoHPC, in the Memories Forum

Re: When there is no light, sound still remains...
Message #10 Posted by Tony Duell (UK) on 30 June 2002, 2:32 p.m.,
in response to message #9 by Andrés C. Rodríguez (Argentina)

I've seen mention of a device called a 'bender coupler' in old PPC journals and/or the PPC ROM manual. It appears this was a device that (capacitively?) coupled to the HP41's speaker ('bender') and let you feed the signal to something else. Now, I certainly don't _need_ one (I have a fairly complete HPIL system), but I would be interested in seeing what it consisted of. Does anyone know where I might find the scheamtic?

Rush Systems converter
Message #11 Posted by Ron Meek on 16 July 2002, 2:00 p.m.,
in response to message #1 by Ron Meek

I understand that a company called Rush Systems of P.O. Box 723, Bethel, CT made a converter, and was advertised in Educalc's catalog. I wrote to them, but the letter was returned "not known". Does anyone know where I can get one of these converters?

[ Return to Index | Top of Index ]

Go back to the main exhibit hall