pa1409@sdcc13.ucsd.edu (Steven Haehnichen) (01/05/90)
It has taken me a while to overcome some serious moral compunctions
in recommending anything sold by Radio Shack/Tandy, but...
I recently ran across a gadget at Radio Shack that seemed too easy
to be true, and still might be. It's their "GP1U52X Infrared
Receiver/Demodulator" (Catalog # 276-137). It sounded interesting
so I bought one for about $3.50 and checked it out. I was slightly
comforted by the name "Sharp" stamped into the tiny (1/2 inch)
tin box. Anyway, it has a whopping three pins to it, and some
relatively useless "technical data" with it.
Ok.. The three pins are GND, Vcc, and Vout... simple, eh?
I connected the Vout to the Error line of my PC's parallel port
and put an LED on it just for looks. I stole the +/- 5 VDC from
the key-board port and that was it.
Now my error line goes high whenever the Receiver picks up a pulse
of infra-red. All of the support circuitry is right on the little
board. It has an IR phototransistor, amp, limiter, band-pass
filter, demodulator, integrator, and comparator built in.
BUT... Does it pick up HP-IR? Yup. Along with every IR remote
control I own. The hardest part seems to be the software. I'm not
real big on 8088 assembly, but it looks like it might be the only way
to make sense of the signals. (I would assume they're pretty
fast, but it seems to send a lot of data (several seconds) just for
a screen dump.)
If you set it up so that the input is fed into the Error line of the
parallel port (like mine), the fourth bit of port 0x379 will be 0 on an IR
pulse. (first bit being the LSB) so something like this works to
read it: (Turbo C)
IR = !(inportb(0x379) & 8)
Where IR is true on a IR pulse.
Anyway... to make a long story longer.. I hope someone can take it
a little further than this, ideally reading in HP text
(graphics?!?!)
I used the Error line because it lets me leave my printer on and
on-line without confusing the system, and if I mistakingly leave the
IR receiver engaged and try to print, I get a friendy printer error.
Oh, one other thing... It tends to pick up a few stray signals
(especially in bright light) but they are very few compared to the
HP data pulses. I haven't seen it pick up any interference at all
in dim light. (One of those dark-red plastic sheilds might be nice.)
There you have it. If anyone makes anything out of the signals,
PLEASE send me some code. Good luck!
Steve
----------------
shaehnichen@ucsd.edu
shaehnic@ucsd.bitnet, and wherever else UCSD can get mail from.
>>> The sooner I fall behind, the more time I have to catch up!! <<<madler@tybalt.caltech.edu (Mark Adler) (01/06/90)
Yep, I bought one (actually two) of those IR detectors from Radio Shack. I have written code and and have been able to read stuff from the HP. However, there is a problem that I have not overcome. The filter in the detector that picks out the pulses produces a duty cycle that is rather a lot larger than the actual envelope of the signal from the calculator. The result is that for the first few bytes sent, the start bits and one or two bits after that are all run together in a single pulse. This problem clears up after the first few bytes, as the automatic gain built into the detector settles down. From then on, I can receive the bytes with no problem. That is, until the calculator decides to pause to the let the printer catch up. Then the first few bytes that follow are screwed up, since the detector has cranked up its gain since it didn't get any signal that whole time. One hacked up solution to the problem would be to have a special program on the calculator that sends stuff in a continuous stream and sends a few garbage bytes to start with. Do do this, someone would have to tell me what SYSEVAL address sends an encoded byte out the IR port. One possible cause of the problem, is that the IR detector has built in a 40 KHz filter for typical remote controllers which output IR pulses at a 40 KHz rate. The HP-28S, however, uses 32.768 KHz pulses. This doesn't keep the detector from working, since according to the specs, the response is only down by 6 dB at 32 KHz, so this effectively means that the detector has only half the range it would if it were tuned to 32 KHz. No big deal, since you can always put the calculator near the detector. (Though, while experimenting, I put the calculator fifteen feet away, and it still worked fine.) Another side effect is that this makes the detector much more sensitive to "noise" from normal remote controls, so you would not be able to use those in the same room, or even near by rooms while using the link. A solution might be to change one of the external components in the detector, of which there are three: two capacitors and a resistor, all surface mount. I am going to put a variable resistor in place of the one that is there to see what effect it has on the problem. It is also possible that the resistor might control the gain, which could also potentially solve the run-together-bits problem. Another possible solution, which I tried and it didn't work, was to ignore the run together bits (which include the parity bits for error correction), and just extract the data bits. Even had this worked, it would not have been a very good solution since there is no error detection or correction. But it didn't work anyway because sometimes the run together bits preclude deducing what following bits are, since the encoding method uses the last bit to send the next bit. And every once in a while, the run together bits include the data bits. I too was very excited when I hooked this thing up and it looked like it was going to work. I will post notes about progress, or the lack of it, on the detector. Just by the way, I got the IR information from an issue of the HP Journal that I got by calling the technical support number in my calculator manual. Also, I am writing the program in Turbo C 2.0, using __emit__ to produce assembler code without an assembler. I have an assembler, but this way, others without one will be able to modify the program. Wish me luck. Mark Adler madler@hamlet.caltech.edu The opinions expressed here are not, in fact, mine, but rather belong a small worm that lives on the fourth planet out from Betelgeuse.
alonzo@microsoft.UUCP (Alonzo GARIEPY) (01/06/90)
In article <5916@sdcc6.ucsd.edu> pa1409@sdcc13.ucsd.edu (Steven Haehnichen) writes: | I recently ran across a gadget at Radio Shack that seemed too easy | to be true, and still might be. It's their "GP1U52X Infrared | Receiver/Demodulator" (Catalog # 276-137). | | Ok.. The three pins are GND, Vcc, and Vout... simple, eh? | I connected the Vout to the Error line of my PC's parallel port | and put an LED on it just for looks. I stole the +/- 5 VDC from | the key-board port and that was it. | | BUT... Does it pick up HP-IR? Yup. Along with every IR remote | control I own. | | If you set it up so that the input is fed into the Error line of the | parallel port (like mine), the fourth bit of port 0x379 will be 0 on an IR | pulse. (first bit being the LSB) so something like this works to | read it: (Turbo C) | | IR = !(inportb(0x379) & 8) | | Where IR is true on a IR pulse. Chances are that this device will not work with the HP-28. Modulation involves transmission of information on top of a carrier frequency. The frequency of the carrier used by the HP-28 is different than that used by remote controls. Unless this device is smart enough to detect the carrier and switch (very unlikely), it won't properly detect the signal (although I am sure a great deal of noise will be generated). The other problem is that the signal from the HP-28 is very dependent on timing. You need more than just pulse detection, and you need very accurate timing information. Alonzo Gariepy alonzo@microsoft
pa1409@sdcc13.ucsd.edu (Steven Haehnichen) (01/06/90)
OK, it looks like the Radio-Shack IR detector has some "features" that make it impossible to read HP printer signals. <sniff> I received some informative mail bringing to my attention the built-in low-pass filter that effectively filters out anything useful from the HP28S. The papers state that the receiver detects and filters out a Bandpass Center Frequency of 40 kHz. I wish I knew the exact frequencies used by the HP-IR, but someone said that an oscilloscope shows that the carrier was detected but the data was NOT demodulated correctly. (I accidentally wiped the mail with all this info, address included, so I apollogize for not giving credit to whom it is due.) BUT, I'm not done dreaming yet... Would it be possible to write a program (IMC?) that would pulse the LED at a lower frequency, making it readable by the Radio Shack gizmo? Apparently, there is no problem with the 40 kHz carrier, just the data on it. Really, it doesn't need to be the same HP protocol at all, just readable signals. I have a feeling that anything would be faster, more accurate, and more convenient than entering code by hand. (helluva lot more fun, too!) How accessable is the IR-LED to software? (sorry if I'm resurecting a past well-beaten topic; I've only been on this newsgroup for a month or so.) One other thing... I'm no electronics buff, but how hard would it be to kill the low-pass filter on the receiver. (Would it solve the problem?) The only pieces on the board are the phototransistor, IC, a couple of resistors, and a 47uF capacitor (can barely read it). Would that be part of the low-pass filter? (i.e. a chageable part) How far off-base am I here??? Steve Haehnichen shaehnichen@ucsd.edu and probably any other general UCSD path. --- "May your dreams be longer than the night." - Vangelis
madler@tybalt.caltech.edu (Mark Adler) (01/07/90)
Some more notes on the IR detector from Radio Shack: First off, like I said in the last note, the 40 KHz bandpass filter is not a problem, since it is only down 6 dB (a factor of four in power) at 32 KHz. Since the power of an evenly radiated source goes down as the square of the distance, this is the same as moving the source twice as far from the detector. Experimentally, the range of this link is at least fifteen feet, so the real effect of having the correct (32 KHz) bandpass filter in there would be to increase the range to over 30 feet. But who really needs that? As far as accurate timing information is concerned, IBM PC's and clones (and most other computers for that matter) have a high resolution timer that can be used to measure the time between these pulses accurately enough to decode the data. In fact, I have used the timer in the PC to measure the pulses far more accurately than needed, effectively using the PC as an oscilloscope to figure out why I was having the problem with just the first few bytes. Other than that problem, I have been able to read bytes from the calculator with no error whatsoever (the error correction code in my program has never been activated---if the start bits of the byte are detected, then the entire byte and the four correction bits are decoded with no error). The timing for decoding is not all that stringent. You only have to be able to distinguish a time of 427 uS from 854 uS from 1282 uS. In 427 uS, my machine (an 8 MHz 286) can execute around 100 to 400 instructions, depending on their complexity and how much branching and looping there is. And that's more than enough instructions to do the task at hand. The only problem I have is when the stream first starts, and the detector is a little too anxious to produce pulses from the signal. Then the first few bits, especially the start bits which are pulses that are only one half bit time apart, get run together into a single long pulse. There is no software cure for this, aside from sending garbage bytes to start with. Alonzo, perhaps you know what SYSEVAL address in the HP-28S sends a single byte (with all the framing and parity bits) out the port? If so, then I can use that to write a program to send data from the HP as packets: with a few garbage lead-in bytes, a header, and some overall packet error detection (besides the byte error detection), all in one continuous stream, and have my PC-end program receive those packets. This would work with the Radio Shack detector unmodified. As far as receiving data from the calculator when it is using its normal print functions, that will require modification to the detector, if it is possible at all. I'm working on that. It is possible that changing one of the external components would change either the automatic gain control, or the bandpass frequency, either of which has a chance of curing the run-together-bits problem. (Just by the way Steve, the 4.7 uF (not 47 uF) cap is just there to smooth out the power source, to reduce noise. Changing it wouldn't help. However, I'm hoping that changing the surface mount resistor or one of the surface mount capacitors might.) Also, for others playing with the part, I found that external noise is killed almost entirely by connecting the metal case that the detector is in to the detector's ground. Apparently, the metal case is there for a reason. And also, Steve, you're right not to let the naysayers deter you. Mark Adler madler@hamlet.caltech.edu The opinions expressed here are not, in fact, mine, but rather belong a small worm that lives on the fourth planet out from Betelgeuse.
george@wombat.UUCP (George Scolaro) (01/08/90)
In article <10169@microsoft.UUCP> alonzo@microsoft.UUCP (Alonzo GARIEPY) writes: >In article <5916@sdcc6.ucsd.edu> pa1409@sdcc13.ucsd.edu (Steven Haehnichen) writes: >| I recently ran across a gadget at Radio Shack that seemed too easy >| to be true, and still might be. It's their "GP1U52X Infrared >| Receiver/Demodulator" (Catalog # 276-137). >| > >Chances are that this device will not work with the HP-28. Modulation >involves transmission of information on top of a carrier frequency. >The frequency of the carrier used by the HP-28 is different than that >used by remote controls. Unless this device is smart enough to detect >the carrier and switch (very unlikely), it won't properly detect the >signal (although I am sure a great deal of noise will be generated). >The other problem is that the signal from the HP-28 is very dependent >on timing. You need more than just pulse detection, and you need very >accurate timing information. Is the HP28(s) similar to the HP42S? I think it must be since the same printer can be used with both? Anyhow, a friend and I have just put together a trivial little circuit based on the Motorola MC3373, and 8 pin minidip IR receiver. We wrote a small (hundred or so line assembler program) and have it decoding the IR coming from the HP42S. At his stage the code is 68000 on a homebrew system (the handiest hardware platform we had), but it should be real easy to convert to any other platform. The output of the circuit is a single bit signal, 1 for IR on, 0 for IR off. The signal timing looks pretty easy to decode on any system which can do a timed software loop with +-30% accuracy. Of course the deluxe method is to use a micro to turn the stuff into real RS232. The unit as it stands decodes the IR and the software re-converts the data into 8 bit binary, which for the 42S is pretty well ascii, except for some special characters which we handle via a conversion table. The circuit came pretty well straight out of the motorola master selection guide in the remote control circuits section. Its basically a few dollars worth of bits. Thanks for the decoding of the IR data to Eric Toonen, who posted it via gmuvax2.gne.edu. In fact the info that he posted was for the 28S and I used it for the 42S, hence my idea that the two are compatible. regards, -- George Scolaro george@wombat (try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]
ge@kunivv1.sci.kun.nl (Ge' Weijers) (01/15/90)
george@wombat.UUCP (George Scolaro) writes: >Is the HP28(s) similar to the HP42S? I think it must be since the same >printer can be used with both? Anyhow, a friend and I have just put >together a trivial little circuit based on the Motorola MC3373, and >8 pin minidip IR receiver. We wrote a small (hundred or so line >assembler program) and have it decoding the IR coming from the HP42S. >The circuit came pretty well straight out of the motorola master >selection guide in the remote control circuits section. Its basically >a few dollars worth of bits. A bit more information on this would be welcome. The circuit sounds simple. The problem with the Radio Shack thing seems to be the automatic gain control. Not a problem with a TV remote control, but a pain with a calculator. What IR receiver did you use? (If it's a minidip receiver, what's the MC3373 for? I haven't used one of those) Ge' Weijers Ge' Weijers Internet/UUCP: ge@cs.kun.nl Faculty of Mathematics and Computer Science, (uunet.uu.net!cs.kun.nl!ge) University of Nijmegen, Toernooiveld 1 6525 ED Nijmegen, the Netherlands tel. +3180612483 (UTC-2)
george@wombat.UUCP (George Scolaro) (01/16/90)
In article <692@kunivv1.sci.kun.nl> ge@kunivv1.sci.kun.nl (Ge' Weijers) writes: >george@wombat.UUCP (George Scolaro) writes: >A bit more information on this would be welcome. The circuit sounds simple. >The problem with the Radio Shack thing seems to be the automatic gain control. >Not a problem with a TV remote control, but a pain with a calculator. >What IR receiver did you use? (If it's a minidip receiver, what's the MC3373 >for? I haven't used one of those) The MC3373 is an IR receiver, and is in an 8 pin minidip. All it takes is three IN914 diodes a few caps a few resistors and an npn transistor + IR photodiode to make it all work. The IR photodiode was bought at a surplus place (I just bought one of each and chose the one that worked best). The receiver works with the calculator up to a metre or two away, beyond that it is very flakey (I assume because the printer outputs a fairly low level output to conserve the batteries). The setup seems insensitive to external lighting, either fluorescent or reflected outdoor light (sol). The major drawback is that it runs on +12v. regards, -- George Scolaro george@wombat (try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]