wscott@EN.ECN.PURDUE.EDU (Wayne H Scott) (01/16/90)
I have one of those Radio-Shack IR dectectors and am tring to get the
program posted recently to work on a macintosh. What I need to know
is the timing information for the HP.
Where can I get this information?
Can someone send it to me?
_______________________________________________________________________________
Wayne Scott | INTERNET: wscott@en.ecn.purdue.edu
Electrical Engineering | BITNET: wscott%ea.ecn.purdue.edu@purccvm
Purdue University | UUCP: {purdue, pur-ee}!en.ecn.purdue.edu!wscottmadler@tybalt.caltech.edu (Mark Adler) (01/17/90)
>> I have one of those Radio-Shack IR dectectors and am tring to get the >> program posted recently to work on a macintosh. What I need to know >> is the timing information for the HP. >> >> Where can I get this information? >> Can someone send it to me? Sure. Here's what comes out of the HP IR port (this information is from the November 1987 HP Journal and my own experimentation): The HP-28S (and I presume all other HP's that use the IR printer) has a 32768 Hz crystal used to time the output of the IR port. It is used in two ways. First, to generate a carrier of IR pulses at a rate of 32768 Hz. These pulses have a 50% duty cycle, so the IR LED is turned on for about 15 uS and these pulses are spaced 30.52 uS apart. The second use of the 32768 Hz is to time the byte frame, which consists of 27 (what I will call) half-bit cells. Each half-bit cell is 14 periods of the 32768 Hz which is 30.52 uS * 14 = 0.4272 mS. The total length of each byte frame is then 0.4272 mS * 27 = 11.54 mS. The HP Journal documentation guarantees at least three more half-bit times (about 1.28 mS) between byte frames, but I have observed on my HP-28S that there is always at least 4 mS between byte frames. Perhaps it takes a little while for the calculator to assemble the frame before sending it. This results in a data rate of about 64 characters per second. This does not include the very long delay the calculator inserts after new line characters to let the printer catch up. Each half-bit cell contains either nothing (the IR LED is left off), or it is about half filled with a carrier burst, which ends up being 6 to 9 pulses at the 32768 Hz rate. I will call a half-bit cell "lit" if it has a carrier burst in it, and "unlit" if it does not. A lit cell then looks like (with eight pulses in this example): _ _ _ _ _ _ _ _ _| |_| |_| |_| |_| |_| |_| |_| |________________________ where the entire line represents a single half-bit cell. Each byte frame of 27 half-bit cells is broken down as follows: the first three cells are lit and indicate the start of a frame, hence they are called start bits (though they should be called start half-bits). The remaining 24 cells represent 12 actual data bits, each bit taking up two half-bit cells (hence the name "half-bit cell"). The first four bits (eight cells) are parity bits used to check and correct the following eight bits (16 cells) which are the actual bits of the byte being sent. The bits are encoded by lighting exactly one of the two cells making up each bit. If the first cell is lit, then the bit is a 1, if the second cell is lit, then the bit is a 0. The four parity bits (called H1, H2, H3, and H4) are sent first, and then the eight bits of the byte are sent most significant bit first. The patterns used for the parity are (most significant bit first): H1 - 01111000 H2 - 11100110 H3 - 11010101 H4 - 10001011 Each parity bit is the parity of the data byte and'ed with that parity bit's pattern from the table above. For example, if we are sending an "a", it has the binary representation: 01100001. And'ed with the pattern for H1, we get 01100000, which has an even number of one's, so its parity is 0. And'ed with the pattern for H4, we get 00000001, which has odd parity, so the H4 parity bit is 1. H2 and H3 give zero, so the entire 12 bits that are sent are, in order: 000101100001. For this example, the 27 cells look like (L=lit, U=unlit): |L L L|U L|U L|U L|L U|U L|L U|L U|U L|U L|U L|U L|L U| S 0 0 0 1 0 1 1 0 0 0 0 1 where I have split the start "bits" and the data bits with vertical bars and put the corresponding interpretation below each group (S = start bits). There are two kinds of errors that are treated. First is a missing carrier burst in a half-bit cell, and second is an inserted carrier burst. In the first case, both half-bit cells are unlit, and in the second are both lit. If we ignore the start bits for a moment, these possibilities are not allowed by the encoding of 0 and 1. When either case is detected (UU or LL), the bit is marked as missing, and then the error correction attempts to use the parity structure of the twelve bits to fill in the missing bits. The parity structure above allows up to two missing bits in the eight data bits to be filled in in this way. The probability of changing a 1 into a 0 or a 0 into a 1 is much lower than the probability of the missing bit error, since it requires an insertion and a deletion in the same pair of half-bit cells. For this reason, that case is not treated by the error-correction. This all assumes that the start bits were picked up correctly. You will note that the start bit structure (three consecutive lit cells) is not allowed in the data part of the frame, which is what makes the start bits distinctive in a stream of cells. One more detail: the HP-28S converts line feed characters (hex 0A) that it sends into the printer's newline character (hex 04). I presume it turns off this translation when it sends graphics data. It will also insert newline characters automatically in long strings to make them print on separate lines. Now I'll tell you what comes out of the Radio Shack IR detector when this stuff goes into it. The detector rectifies and filters out the 32768 Hz carrier, so ideally it would give the envelope of the carrier bursts that are sent in lit half-bit cells. This would mean that the detector either would or would not (for lit and unlit cells) put out an approximately 200 uS signal every 427 uS wide half-bit cell. However, the detector does not do this. It actually puts out a signal that is from 250 to 500 uS for a carrier burst. The problem is that if there are two consecutive lit cells, the signal runs over if it's longer than 427 uS, which it often is, especially in the first few bytes sent. In a transmission with no errors, up to four consecutive lit cells are possible (the start cells followed by a one), and two consecutive lit cells are common (a 0 followed by a 1). The solution is to interpret signals that are 430 uS, 850 uS, 1280 uS, and 1710 uS as 1, 2, 3, or 4 consecutive lit cells. Which is what they must be. This is what HPREAD does, and it works quite well. To measure these times in HPREAD, I use the high byte of the high resolution timer in the PC, which decrements every 0.107276 mS. This happens to be (rather conveniently) almost exactly one-fourth of a half- bit cell time. The macro WAIT waits until that high byte changes, so if the code between WAIT's is not too time consuming (and there are no interrupts), then that code is executed four times every half-bit cell. I don't know what you have in the Mac hardware to replace this, but if there is an accessible timer, the Mac should easily be fast enough to to the work in HPREAD between use of WAIT. I should point out that I coded WAIT in such a way so that the Turbo C compiler would produce the same code I would have written in assembler to do that. This is so that the change in the high byte of the timer is caught as soon after it happens as possible to maximize the accuracy of the times the IR port bit is sampled. I think this should answer your questions. Mark Adler madler@hamlet.caltech.edu
madler@tybalt.caltech.edu (Mark Adler) (01/18/90)
Oops. It's not the November 1987 HP Journal, it's the OCTOBER 1987 HP Journal that describes the timing and content of the IR printer port output. Mark Adler madler@hamlet.caltech.edu