Hi. I had perhaps the same type problem that Katie Wasserman had, in that the yellow colored printer gear was damaged and missing some teeth. I took the thermal printer assembly out of a HP-82143A that is used for the HP-41C series. It seemed that the HP-97 and HP82143A printers were very similar, and the unit fit right into the HP-97. These printers are also alot more plentiful than parts HP-97's, but they do not use the drive gears, but instead use a rubber band to move the print mechanism. After I installed the HP-82143A printer into the HP-97, everything seemed to work except that it did not print. It tried to print however(print arm moved etc..).I am not sure why it didn't print, but suspected that perhaps the print head is slightly different, or the chip drivers were different. I never tried exchanging the HP-97 print head with the HP-82143A print head, because my HP-97 head was damaged. Has anyone out there ever tried this swap before and had any success?
HP-97 and HP-82143A printers
|
07-26-2000, 10:42 AM
07-26-2000, 11:15 PM
I had the same idea as Erik but didn't have a HP82143A around to try. I did think about using the printing mechanism from a 82240A (or B) which takes the same size paper as the 97 but would need to be adapted to mount in the space on the 97, also the interface is entirely different. I'm considering using a small microprocessor (a PIC most likely) to read the print head driver output (and motor drive output) and translate these into the needed codes that would then be sent via IR to a 82240A/B. My guess is that this would not be too hard to do, since the 82240A/B can accept bit-column graphics (what the 97 send to the print head). The same idea would work for the other 9x machines and the 19C and 10. The one piece of information that I need, however, is the bit stream format of the IR commands that the 82240A/B need. (I'm not wild about trying to reverse engineer these.) Does anyone have these specs?
07-27-2000, 03:40 PM
The HP 82440 IR protocol is documented in a 1986 HP Journal issue. It's either the same issue with the HP-18C articles, A specification document was reportedly available from HP Corvallis years ago, but I've never seen it. Several people have reverse-engineered it, apparently without realizing that it was documented in HP Journal. However both of the reverse-engineering efforts I've seen (including one published in Circuit Cellar Ink) got details wrong, and in fact made it out to be more complex than it really is. I've been considering designing PIC microcontroller based hacks to add printing output to HP calculators that didn't have it, such as the HP-67. It never occurred to me that this might be useful to people with broken HP-97s.
07-27-2000, 03:50 PM
I looked it up, the issue of the HP Journal with the 82440 printer protocol information is October 1987.
07-28-2000, 12:55 AM
I had it all the time and didn't realise it. Thanks.
07-29-2000, 01:24 AM
Does anyone have the IR printer article readily available for email or fax. I don't have the 10/87 issue of HPJ around. (Of course, I could order it from one of those services that the HP Journal site points you too, but...)
07-29-2000, 07:45 PM
What information do you need? I can transacribe the essential bits for you if you like.
07-30-2000, 01:46 AM
I need to know enough about the bit patterns to generate them and control the IR LED hooked into the PIC. I also need to know the carrier frequency that the IR receiver uses (probably 40KHz). Steve, I appreciate your offer to transcribe the info, but it's going to be a lot. If you have a scanned copy of the article that you could email, that would be great, if not I can get it from one of the journal reprint services. Perhaps a scan of this info could be added to the other HPJ articles on the CD ROM set so that it would be available to everyone.
07-30-2000, 05:04 AM
Ahhh, it's simple enough!
BasicsThe carrier frequency is 32.768Khz. (for the HP-18C) The carrier has an even mark and space of approximately 15.26uS The carrier is modulated by a square wave with a fixed mark, but variable space. Thus the information is carried by the gaps between pulses, not the pulses themselves!
Data EncodingThe data is encoded bit by bit. Bit times are fixed (28 pulses of the carrier, or approx 854.5uS). This bit time is broken into two halves.
* A 1 bit is defined as a burst in the first half of the bit time, and no pulse in the second half Note that this makes a start bit 50% longer than a normal bit.
An ExampleIf I were drawing things, it would look like this: (this is a start bit followed by a 1 and a 0.) Note that you don't start counting until you see the first rising edge. To make things easier, I only show 4 pulses per 1/4 bit time, rather than the 6 to 8 that you may see in practice. Also note that while HP talks of 1/2 bit times, you can usefully think in terms of 1/4 bit times with the even 1/4's ALWAYS in a space, and the mark only ever occuring in one of the odd 1/4's.
___||||____||||____||||____||||________________________||||____ To break that up:
___is some amount of space between characters
||||____||||____||||____is three half bit times with pulses in their first half. (and is thus a start bit)
||||____________is two half bit times with pulses in the first half bit time (a 1)
________||||____is two half bit times with pulses in the second half bit time (a 0) Data is sent in frames. Each frame consists of a start bit, 4 ECC bits, and 8 data bits. If you look at the output of one of these IR devices on a storage scope, or via some other method, you'll notice immediatly that the frames stand out like islands of data in the sea of noise. As you look closer you'll see the groups of pulses and the spacing between them. You'll notice the three different size gaps. These are 1 unit, 3 units, and 5 units. Coding these gaps is actually one way of coding the data.
A Table to Cheat By :-)Here is a table that some of my software uses to decode these gaps. Note that it was devises BEFORE I knew anything about how te data was decoded.
const This table encodes the GAPS between modulation pulses for each character. 1 indicates a short gap, 2 the middle size gap, and 3 the long gap. Knowing that the pulses fit around each gap, that the gaps are in the proportion 1:3:5, and that you should send 7 carrier pulses at 32767Hz, this is probably enough info.
How To CheatSo, character A is 65 and is '11123131322221'
You would send: |_|_|_|___|_____|_|_____|_|_____|___|___|___|___|_| Where each | is 7 carrier pulses, and each _ is a gap of equivalent size. If you're further interested...
|_|_|_|___|_____|_|_____|_|_____|___|___|___|___|_|And yes the 1's do extend out beyond the end! This is becasue the last set of pulses occur in the first quarter of the last bit time (first half of the first half of the last bit time!!!). So even though we're encoding information in the gaps, the last gap does not need to be terminated.
SSSSSS = start bit So it was S110101000001
1101 is the ECC
Calculating the ECCHow do we get the ECC? well it's like this... The 4 bits (call them H1, H2, H3, and H4) are calculated individually Firstly for each bit you apply a mask (AND) to the data the masks are:
H1 01111000 So for the code 01000001 the resulting data for these is
H1 01000000 Then you calculate the EVEN parity bit required for these (i.e. the bit required so that there are an EVEN number of bits. Since H1, H2, and H4 have an odd number of bits, the parity bit for these would be 1, bit for H3 it is 0. Then you string them together (the parity bits) this gives you: 1101 which is what we found above! These parity bits can be used to detect and correct up to two missed bits (though how you do that is well beyond what I'm prepared to go into!) But, my software DOES decode these without resorting to calculating the ECC bits (although I may add that some time) But you're trying to SEND this data right? So the lookup table I've given you should be all you need, unless you want to do all the hard work yourself :-)
P.S.An easy way to play with this is to capture it with your sound card... (Oh damn, I've let out my secret). It has the advantage of handling all the timing for you, so software speed is no longer an issue. This is especially important when using an operating system that multi-tasks.
An observation about formatingYou can really stuff up the formatting (especially with the pre: tag if you include a ']' in your text. Our esteemed host has allowed things like '\]' for ']' (and thus '\[' for '[') to escape the special processing as I've just discovered. Thanks :-D I may even write an editor to make this process somewhat faster. Formatting really takes a while to do... Anyone interested?
07-30-2000, 05:16 AM
Since you're using a PIC, it's probably far better to calculate the ECC bits. Probably more fun too. Are you going to impliment a bidirectional interface (or even better a bidirectional interface for the HP41!)
07-30-2000, 05:26 AM
This table indicates what you should do when you receive a bit (i.e. a rising edge) after x timer ticks (a timer tick is 1/32768 sec) Ticks Bit Comment You can use the ECC to determine what the bits are, as long as you know which are missing (which you probably will). What I do is to decode the gaps, then use some heuristics to determine what the gap is likely to be, then do pattern matching to determine which is the most likely. This is probably too code intensive for a PIC, bit the calculation of bits using the ECC should be OK. Reply if you need an explanation of how to do it.
07-31-2000, 12:01 AM
Thanks very much for all that Steve! I think that it should be enough infomation for me, especailly since I'm going the other way with this. It's going to be a uni-directional interface. The idea is to read the 7-bit print head pulses from a 97 (19C or 10C) and send off a column of dots to an HP 82240 via IR. Reading the print head pulses should be relatively easy if I can sync to the clock line on the print head driver and the motor forward start line. In think that you supplied enough info to generate the IR signals and the manual for the 82240 shows the escape sequence needed to send out to print a single column of dots.
07-31-2000, 06:10 AM
Because the IR interface is one-way, there is no way to detect that the buffer is full. Thus the sender needs to send data in such a way that the buffer never overflows. With new batteries, the IR printer can print about 2 lines per second. When the batteries are almost exhauseted, this drops as far as 1 second per line. The buffer in the printer can contain 200 characters. Becasue you're sending graphics, you will not be able to take advantage of the sort of buffering that calculators sending whole characters do. The easiest algorithm is to send a line, then wait 1 second before sending another. However if you can determine how long it takes to print a line (worst case) then you may be able to take advantage of the buffer by sending several short lines at once, and then waiting until you're sure the buffer can accept more characters. If you're sending to another device (say a PC with the IR interface) then you can go as fast as you desire :-)
07-31-2000, 05:58 PM
(a timer tick is 1/32768 sec) Actually, in that table the described timer tick is for the timer in the 8050 microcontroller in the 82440A printer, and is longer longer than 1/32768 sec. I don't know the value offhand. The table values are for a nominal 5 ticks per half bit time. Since a half bit time is nominally about 427 microseconds, the tick must be about 2.1 ms.
The table values are based on the sender's clock being within a certain tolerance. This is why the larger entries However, for *sending* the IR data, you don't need this sort of table.
08-02-2000, 09:20 AM
I still have a thermal printer for sale..... Menno |
« Next Oldest | Next Newest »
|
Possibly Related Threads… | |||||
Thread | Author | Replies | Views | Last Post | |
HP-97 Printer Malfunction | Dan Lewis | 17 | 5,181 |
11-25-2013, 10:18 AM Last Post: Thomas Chrapkiewicz |
|
request M.E. pac for HP-67/97 wallet cover scan | Ignacio Sánchez | 0 | 1,046 |
11-06-2013, 09:36 AM Last Post: Ignacio Sánchez Reig |
|
HP-67/97 Mechanical engineering PAC cover | Ignacio Sánchez | 0 | 999 |
10-30-2013, 04:35 AM Last Post: Ignacio Sánchez Reig |
|
HP-97 Printer Troubleshooting | aj04062 | 6 | 2,476 |
10-15-2013, 08:45 PM Last Post: Eric Smith |
|
HP-97 Service Manual, newer model | davorin | 6 | 2,440 |
09-16-2013, 10:45 AM Last Post: davorin |
|
HP-97 card reader pinch roller axle | davorin | 2 | 1,578 |
09-15-2013, 08:47 AM Last Post: aj04062 |
|
HP-97 Card Reader | davorin | 3 | 1,859 |
09-13-2013, 04:21 PM Last Post: Stephan Matthys |
|
HP-97 Printer Head | aj04062 | 1 | 1,148 |
09-11-2013, 09:18 PM Last Post: Randy |
|
HP-97 Printer Head | aj04062 | 0 | 919 |
09-10-2013, 09:19 PM Last Post: aj04062 |
|
HP-97 thermal head movement | davorin | 6 | 2,229 |
09-08-2013, 03:09 AM Last Post: davorin |