This is weird. I've got brand new batteries in the 27S and the 82240B, but I'm getting strange intermittent black squares in place of characters when printing. The 27S is set for battery-powered printing. I'm also seeing the same thing printing from my 17BII. My 48GX is printing fine. I tried going down in the basement, thinking maybe there was interference from sunlight. Any ideas? Interference from the power LED on the printer?
[
attachment=4895]
Try increasing the distance between the receiver and transmitter.
(06-04-2017 11:37 PM)Geoff Quickfall Wrote: [ -> ]Try increasing the distance between the receiver and transmitter.
Well I'll be damned, that seemed to work. I printed out my whole solver library, and I didn't see any error boxes, though occasionally it would omit the first character of the formula. Strange. I might have to try the same thing with my 82240A and see how that one behaves.
I have about five of those, you always need a back up! They all do the squares when the two units are too close.
100 percent reproducible but that is a small sample size. Occurs with my wp34s IR , all my Panamatik ACT IR woodstocks, 41, 42, 48 series...
it will probably happen with the DM42 but that will have to wait until a software update in the beta units.
Geoff
Ha, just got back from Asia and Europe so not paying attention. In your photo they are WAY to close. Probably got away with it due to the reduced voltage stale batteries. Over time you got closer and closer, then new batteries and bam!
Seems like my 82240A is a lot more forgiving than the B. I just printed my solver library (at least a foot of printout) from a distance of about 3 inches, and don't see any obvious signs of missing characters. Whether this is something specific to the two units I happen to have, or which applies to the A and B models in general, I can't say. I'm suspicious that the power LED behind the filter on the B is causing some kind of interference (e.g. backscatter into the receptor). I might look at desoldering it and replacing it with a roughly equivalent resistor. Or maybe just wrap it with some electrical tape.
Try about a foot away, then work back if you have to, and see what happens. Three inches may still be a little close.
If that doesn't help, try printing from your 48 and see if the problem persists. If so, try the printer self-test a couple of times to see if it may be an issue internal to the printer. (Hold down the paper feed button while turning it on to start the self-test).
You should see a character in the first column of every line of the self test printout, EXCEPT line five.
Good luck!
Bob
Could the problem be that the IR LED in your 27S is too LOW, rather than too close, relative to the printer's IR receiver? Try raising the calculator a tiny bit (e.g. by resting it on a thin booklet), until its IR LED is at the same height as an HP 48's IR LED. I vaguely remember HP recommending that.
Hmm, no dice yet. The printer self-test comes out just fine, as far as I can tell. I printed a lengthy program from my 48GX, only a few inches from the printer, and it didn't have any trouble. I still can't get the Pioneers to print reliably, though. I tried setting the 27S on a coaster, which didn't seem to have any effect. I also opened up the printer and realigned the receiver (it looked like it was pointed too far downward). Same results; if the 27S is too close, I get black squares, and if it's far enough to eliminate the errors, it will occasionally skip the first character of a line. My A model printer has no trouble at all with my 27S. I didn't see any sign of bulging caps inside the B model printer, and everything looked relatively normal.
That is puzzling. Dropping the first character sounds like possibly a timing issue, like the head isn't returning quickly enough to keep up with the data?
Long shots, but maybe worth checking:
- Double check the Battery / AC Adapter setting; maybe change it to AC and then change it back to Battery, just to make sure it's being read properly by the 27S.
- Try running the printer on an AC adapter if you have one or, if not, try another set of fresh batteries just to make sure it's operating at full speed.
I considered that, but if it's a timing issue, I don't think it's a mechanical one. Sometimes when the only character on a line is a line-feed (e.g. printing a blank line between amort groups), it will skip that character and not advance the print head/paper at all.
I just did a test with the two printers side-by-side: the A on the left, running on batteries, and the B on the right, running on the external power supply (an original 82241A). Both have relatively new batteries. The A produced flawless output, but the B had four initial character skips (and a misreceived character, because I was holding the calculator a bit too close at first). I never see any of the little broken box characters that would indicate a buffer overrun. It never skips a character in the middle of lines, and I can't find any problem with output from a 48SX or 48GX. So weird.
[
attachment=4908]
[
attachment=4909]
It is beginning to sound like a noise problem. Either to much data (black square) or to little data (missing print or space command)
So the noise is being interpreted two ways, ignored (missing) or printed (black square). Internally the oil filled caps filter noise and would be my first suspect in the hardware. Especially since the self test functions. Of course the self test prints code directly from the rom therefore no IR test is involved so my second thought would be the IR diode or a cap in that circuit.
Diodes have a shelf life, but up in the 'I won't see it in my lifetime' age.
So now that you have ruled out positional error (too close, too far, receiver and transmitter angles) it would seem that its receive range has narrowed considerably. Again capacitors come to mind as an aging component.
Geoff
(06-07-2017 12:22 PM)Dave Britten Wrote: [ -> ]Sometimes when the only character on a line is a line-feed (e.g. printing a blank line between amort groups), it will skip that character and not advance the print head/paper at all.
Just to make sure I'm understanding that, is the printer at rest when that comes in, and it doesn't respond to a single <LF>? Or did it get a <LF><LF> at the end of the preceding print line and didn't execute the second one?
(06-07-2017 12:22 PM)Dave Britten Wrote: [ -> ]... I still can't get the Pioneers to print reliably, though....
Did you try a second Pioneer? If so, which model?
What would be perfect is if you could pick up another 82240B *and* another HP-27S then do some comparisons :-)
(06-07-2017 05:16 PM)Geoff Quickfall Wrote: [ -> ]It is beginning to sound like a noise problem. Either to much data (black square) or to little data (missing print or space command)
So the noise is being interpreted two ways, ignored (missing) or printed (black square). Internally the oil filled caps filter noise and would be my first suspect in the hardware. Especially since the self test functions. Of course the self test prints code directly from the rom therefore no IR test is involved so my second thought would be the IR diode or a cap in that circuit.
Diodes have a shelf life, but up in the 'I won't see it in my lifetime' age.
So now that you have ruled out positional error (too close, too far, receiver and transmitter angles) it would seem that its receive range has narrowed considerably. Again capacitors come to mind as an aging component.
Geoff
Noise (or a faulty cap) might explain the black squares (i.e. mis-received characters) at close range, but the omitted characters are consistently at the beginning of lines. And I don't see the problem with my 48s. Is there a big difference in transmitter power between the Pioneers and 48? Maybe a slight clock difference, and the Pioneers are just a bit outside of what this particular printer can handle?
(06-07-2017 05:35 PM)BobVA Wrote: [ -> ]Just to make sure I'm understanding that, is the printer at rest when that comes in, and it doesn't respond to a single <LF>? Or did it get a <LF><LF> at the end of the preceding print line and didn't execute the second one?
Right. The sequence is like this example:
Code:
BALANCE= 4,715.68120945<LF>
<LF>
PMTS:13-18
The line feed between the two lines to add an intervening blank line gets skipped. The printer just sits there waiting for the next line to be sent from the calculator (which pauses between lines so as not to overrun the buffer). So far, I've yet to detect it skipping characters anywhere
within a line, only the first one.
(06-07-2017 05:35 PM)BobVA Wrote: [ -> ]Did you try a second Pioneer? If so, which model?
What would be perfect is if you could pick up another 82240B *and* another HP-27S then do some comparisons :-)
I tried it with my 17BII a little bit, and was getting similar results, at least as far as the black boxes. I'll have to test again to see if it's dropping initial characters too. What I do know is that the 27S is printing flawlessly to the 82240A, and the B is having no trouble with a 48SX and 48GX.
(06-07-2017 08:34 PM)Dave Britten Wrote: [ -> ]...I tried it with my 17BII a little bit, and was getting similar results, at least as far as the black boxes. I'll have to test again to see if it's dropping initial characters too.
*That* will be interesting!
I think you're right that it could be some subtle timing problem, with your printer and 27S at opposite ends of tolerance, but still it's puzzling it's only the first character.
Maybe the time base for the calculator and the printer are far enough out from each other that getting initial bit sync is taking too long, and if the calculator pauses in sending data (as it might between lines), sync drops and then you get the missed first character while it regains sync?
One way to test that would be to send a long (but less than the 200 character printer buffer length) string of characters that would print several lines, in one burst.
The print stack function would probably do that, or maybe you can do it with the MSG function? If you don't get any dropped first characters with a single buffer full of characters, that's a clue.
Or it could be it's only dropping the first character if it's sent when a <LF> is occurring, which could be some electrical noise problem, as Geoff mentioned. That may be coupled with either a timing problem or a weaker signal from the 27 compared to the 48. The 17BII results will be helpful in ruling that out.
Or you could just use the "A" printer :-) But keep us posted if you press on!
Yeah, my main solution is to just stick with the A printer for Pioneers.
I'm going to do some more tests with my 17BII and 19BII and see if those are dropping the initial characters. I should probably read up on the red-eye printing protocol to see if any obvious explanation jumps out at me. One-way digital communication is a tricky animal.
Alright, did some more tests. The 27S is the only one exhibiting the character dropping, and only with the B.
Some dates inferred from serial numbers:
27S - 1988
17BII - 1992
19BII - 1993
82240A - 1989
82240B - 2002 (Am I reading that right? It's ID25200071.)
That's some big enough gaps that I could conceivably see the timings and tolerances having changed since the 1st-gen Pioneers.
It could be the 27S and 82240B have components with a stack-up of tolerances/drift/aging that just makes the pair incompatible.
As far as component aging is concerned, culprits usually are capacitors (especially polarised type) and diodes (emitting diodes suffer reduced output with age & use).
.
(06-08-2017 01:21 AM)Dave Britten Wrote: [ -> ]Alright, did some more tests. The 27S is the only one exhibiting the character dropping, and only with the B.
It does sound like borderline issue with the those two devices. If you really want to dig into it, it would be interesting to compare an oscilloscope capture of the LED drive signal from the 17BII and the 27S to see if there's some timing difference.
(06-09-2017 11:23 PM)BobVA Wrote: [ -> ]It does sound like borderline issue with the those two devices. If you really want to dig into it, it would be interesting to compare an oscilloscope capture of the LED drive signal from the 17BII and the 27S to see if there's some timing difference.
Exactly what I was thinking. It's a shame I don't have a scope.