Receiver hardware for IR beam (red eye)?

[Tinue]

I was wondering if new hardware has shown up since this article has been written: https://www.mh-aerotools.de/hp/red-eye/H...rduino.pdf

The "HP C4103A IR Transceiver Unit" is increasingly difficult to get. In Switzerland, the cheapest one I found was about 50 US$, and there was only one available.

So far I tried a burst detector and an IR transistor. The burst detector VS/1838B works more or less (a few errors from time to time), but it stops after one second. It's built for remote controls, and apparently thinks someone is sitting on the remote and thus shuts off.

The photo transistor is just way too slow to detect a 32kHz signal.

So I was wondering if someone found another receiver in the meantime. Either a "raw" receiver detecting the individual 32kHz pulses, or a burst detector that signals the 6-8 pulse bursts. The software I am using can deal with both types of detectors.

[MeindertKuipers]

The project mentioned below uses a Vishay TSOP4133, according to its datasheet needs only 1 burst to recover. I think most photodiodes should be able to handle a 32 KHz signal

Link: https://hackaday.com/2021/12/28/diy-infr...r-printer/

Another receiver circuit is here: https://github.com/dankar/redeye, and possibly you might be able to get this working without the opamp.

I have not tested any of the circuits above myself, very happy with my C4103A unit.

[Tinue]

Thank you, the TSOP4133 looks very promising! The shortest pause in the Red Eye protocol is indeed one burst, so it might just about work.

Photodiodes are probably ok, but they need amplification. As a software engineer, I have no idea how to accomplish this. A phototransistor has the amplification built in, but it's built in a way to make it much too slow. I'm actually wondering how this works for the GitHub project that you linked. The ptogotransistor that I got can maybe handle 10kHz, but never 32kHz

I'm also happy with the C4103A that I already have, but now I need another one to test my RP2040 code to send/receive Red Eye. I'll try the TSOP4133 first, before I try to source another HP device.

[MeindertKuipers]

Are you planning to emulate Blinky with the RP2040? I have been able to send IR codes with my RP2040 setup emulating the HP82143 printer. Hope to make a video in the next few days about this.

[Tinue]

(11-28-2023 08:30 AM)MeindertKuipers Wrote:  I have been able to send IR codes with my RP2040 setup emulating the HP82143 printer.

Wow, impressive! Are you using the RP2040 PIOs to listen on the HP IL protocol? Looking forward to the video.

My project listens on the USB/Serial port, and then forwards every byte received through the IR LED in the Red Eye protocol. I'm using PIO state machines for the protocol handling, because that's what I wanted to learn.

The other part of the project listens on the IR receiver, and forwards every byte received through the USB/Serial connection.

[MeindertKuipers]

(11-28-2023 12:46 PM)Tinue Wrote:  

(11-28-2023 08:30 AM)MeindertKuipers Wrote:  I have been able to send IR codes with my RP2040 setup emulating the HP82143 printer.

Are you using the RP2040 PIOs to listen on the HP IL protocol?

There is no HP-IL involved, I am using the PIO to do the interfacing to the HP41 and C-code to emulate the PRINTER-1E ROM and the HP82143 printer. The bytes to be printed are sent over the IR-led. I do use a simple PIO state machine to send the RedEye IR frames, but still some C-code is used to construct the frame and the error correction bits. I simply do not have a lot of space in the PIO left because of the HP-41 interfacing so I needed to keep the IR output relatively simple. The PIO only sends out half-bits (a burst followed by a non-burst, or two non-bursts) with the correct timing. Only 7 PIO instructions, and the clock divider defines the carrier frequency. Happy to share my code if you want.

[Tinue]

Interesting; Emulating a module seems rather complex. I guess you need to emulate the ROM chip itself, and all of the I/O that is going on. I wonder how this fits into these tiny PIOs. Just emulating the ROM needs to read the address lines, send the address up to the C-code, read back the ROM value from C-Code, and then clock it out to the data bus. But then you said that you have little room left for the Red Eye handler.

As for my code: I did the Red Eye sender first, and was not yet comprehending the half bits. This is why my C-code sends 54 bits to the state machine, and the state machine simply loops through the bits, bursts on a one, pauses on a zero. Also, just because I started this way, I use two state machines: One does the actual burst, and gets triggered by the other one. In total they need 10 instructions.

My receiver came afterwards, and is more efficient. It can communicate an entire byte in 14 2-bit words up to the C-code. It needs 13 instructions if there is a burst detector attached, and 7 more if it needs to analyze the carrier frequency itself. I just about fill the capacity of one PIO with using 4 state machines and 30 instructions.

[MeindertKuipers]

The PIO only does HP41 interfacing, syncing and deserializing. It decodes ISA (using SYNC) and sends address to the C code, which takes, care of reading the printer ROM (and send the instruction out to ISA) Also the ISA instruction is deserialised by the PIO, and C software identifies the instruction and recognises, the printer commands. The printer status register is sent when requested by C code to another PIO state machine to send it on the DATA line. PIO takes care of timing and serializing. And of course send a carry bit on some instructions, but instruction decoding and execution is done in C.

I do not plan a Redeye receiver, I can imagine it is a bit more complex than sending. By sending half bits the state machine is quite efficient (also uses nops an delays) and only 27 bits need to be constructed in C, plus automatically 3 zero half bits for the interframe delay. This state machine runs at twice the required carrier frequency, and uses a sideset to drive the LED. Will post the PIO source tomorrow.

I really like the RP2040 and especially the PIO. The limited PIO codespace forces you to be creative and consider every single byte, just like mcode programming in the past. There are limitations of course but many tricks are possible. I actually do use the forced instructions a few times from C code to send new instructions or a jump to a state machine. Lots of fun!

[Tinue]

(11-28-2023 07:38 PM)MeindertKuipers Wrote:  Lots of fun!

;-) I agree. Detecting the length of a pause, when you can only count down and not up, gives interesting PIO code.

Yes, I realized that I only need half the bits when I did the receiver. There can never be a "burst-burst" or "pause-burst" pattern, so one can send the other two possibilities with just one bit. Maybe I'll optimize the sender once my receiver is fully working. I also think I might be able to save an instruction or two by using a side set for the LED, instead of the explicit "SET" instruction.

[MeindertKuipers]

Below is my PIO code for the RedEye transmitter:

Code:

.side_set 1                                     ; just one sideset for the IR output

lolo:                                           ; send out the first lo cycle
        nop                     side 0  [13]    ; delay to be timed at 14* 15,2588 usec

.wrap_target         
        nop                     side 0  [11]    ; always the 2nd lo cycle, 
                                                ; delay to be timed at 14* 15,2588 usec

public ir_start:  
        out x,1                 side 0          ; read from TX FIFO into x
        jmp !x, lolo            side 0          ; when X = 0, a lolo sequence is done
                                                ; when x <> 0, a hilo sequence is done
hilo:                                           ; hilo sends out 7 IR pulses, and 7 pulse times low
        set x,6                 side 0          ; set X to send out 7 bits
hilo_loop: 
        nop                     side 1          ; send out high IR pulse of 15,2588 usecs
        jmp x--, hilo_loop      side 0          ; send out low IR pulse of 15,2588 usecs

        .wrap                                   ; free jump to .wrap_target for lo cycle

Sideset pin is the IR output LED and make certain that the TX FIFO is set to autopull at 30 bits (24 half bits, 3 start bursts and 3 inter frame delays) and use Shift-to-Left. The clock divider should be set such that the state machine runs at 2 * 32768 Hz. in my case the main CPU clock is 125 MHz, and the divider is 1964 (I used a small correction, after measuring the carrier frequency I had to make a small adjustment). The state machine start is at the label ir_start! That is the instruction where it will stall if no data is available.
To send data, use a 1 to send a Hi-Lo burst and 0 for a Lo-Lo burst, and construct the start bits with '111'.

To send an A for example:

Code:


    // 0000.0111.1010.0110.0110.0101.0101.0110 :   0x07A66556
    //       ^^^ start bits
    //           ^^^........................^^  payload 24 bits
    // and left align on the start bits, the final frame to send to the TX FIFO is then
    //  1111.0100.1100.1100.1010.1010.1100.0000 : 0xF4CCAAC0

[Tinue]

Very interesting, thanks! I learned two things: .wrap_target does not have to be at the top, and one can start into the PIO directly on a label, and not only at the top.

These are my two state machines:

Code:


.program redeye_carrier_burst

.define NUM_CYCLES 7                ; how many carrier cycles to generate
.define BURST_IRQ 7                 ; which IRQ should trigger a carrier burst
.side_set 1                         ; Side set is the LED pin

.wrap_target
        set X, (NUM_CYCLES - 1) side 0  ; use X to count the number of pulses
        wait 1 irq BURST_IRQ side 0     ; wait for the IRQ, and clear it
cycle_loop:
        nop side 1                      ; Turn LED on
        jmp X-- cycle_loop side 0       ; Turn LED off and loop back
.wrap

Code:


.program redeye_clockout_bursts

.define BURST_IRQ 7                     ; the IRQ used to trigger a carrier burst

.wrap_target
clock_out:
        out X, 1                            ; get the first bit on the left (msb)
        jmp !X burst                        ; bits are inverted, so for a zero, burst
        jmp clock_out                       ; for a one, jump back
burst:
        irq BURST_IRQ                       ; trigger the burst. Jump back is "free" due to wrap.
.wrap

[MeindertKuipers]

Looks like an interesting state machine. I have not used IRQ's so far for syncing between state machines. Since it goes through the NVIC I had the idea that there may be an extra delay.
I use 2 extra GPIO's for this type of syncing, but then I have one source, and multiple state machines that need to sync to that one.

[Tinue]

(11-29-2023 02:35 PM)MeindertKuipers Wrote:  Since it goes through the NVIC...

I actually didn't think about this. It looks like I got lucky, because the documentation says "IRQ flags 4-7 are visible only to the state machines; IRQ flags 0-3 can be routed out to system level interrupts...".

Unless they are mapped to real interrupts, I think they are just as quick as GPIO pins.
Also, when I check the generated burst with a Saleae logic analyzer, I can see no delay at all.

[Tinue]

FYI: The TSOP4133 does not work, unfortunately. While it works fine with a perfect RedEye signal as generated with the Pico, it loses pauses with an HP 50g as the sender. Ultimately it doesn't recover quickly enough after a burst.

[MeindertKuipers]

(12-07-2023 09:18 AM)Tinue Wrote:  FYI: The TSOP4133 does not work, unfortunately. While it works fine with a perfect RedEye signal as generated with the Pico, it loses pauses with an HP 50g as the sender. Ultimately it doesn't recover quickly enough after a burst.

That is too bad. I will do a quick test with an IR transistor I have lying around here, see if that can keep up the speed.

[Tinue]

(12-07-2023 09:21 AM)MeindertKuipers Wrote:  I will do a quick test with an IR transistor I have lying around here, see if that can keep up the speed.

Two or three pins? The two pin ones are usually way too slow, because they drain the charge too slowly.

[MeindertKuipers]

(12-07-2023 09:50 AM)Tinue Wrote:  

(12-07-2023 09:21 AM)MeindertKuipers Wrote:  I will do a quick test with an IR transistor I have lying around here, see if that can keep up the speed.

Two or three pins? The two pin ones are usually way too slow, because they drain the charge too slowly.

I just did a test with a 2-pin IR transistor, and indeed it is way too slow. I also have some 3-pin receivers, tested those earlier. But these are complete receivers that filter the carrier out, and these also saturate after a few frames.
I found some references to photo-diodes which seem to be ,much faster, but these need a small opamp circuit to interface with

[MeindertKuipers]

(12-07-2023 09:50 AM)Tinue Wrote:  

(12-07-2023 09:21 AM)MeindertKuipers Wrote:  I will do a quick test with an IR transistor I have lying around here, see if that can keep up the speed.

Two or three pins? The two pin ones are usually way too slow, because they drain the charge too slowly.

I just did a test with a 2-pin IR transistor, and indeed it is way too slow. I also have some 3-pin receivers, tested those earlier. But these are complete receivers that filter the carrier out, and these also saturate after a few frames.
I found some references to photo-diodes which seem to be ,much faster, but these need a small opamp circuit to interface with

[Tinue]

(12-07-2023 12:49 PM)MeindertKuipers Wrote:  

(12-07-2023 09:50 AM)Tinue Wrote:  Two or three pins? The two pin ones are usually way too slow, because they drain the charge too slowly.

I just did a test with a 2-pin IR transistor, and indeed it is way too slow. I also have some 3-pin receivers, tested those earlier. But these are complete receivers that filter the carrier out, and these also saturate after a few frames.
I found some references to photo-diodes which seem to be ,much faster, but these need a small opamp circuit to interface with

Thanks! Ideally, one would clone the circuitry that is inside of the C4103A, and make it work for 3.3V. My main problem at the moment is the fact that the C4103A is a 5V device. For receiving, I could build a simple circuit with a transistor, and it seemed to work fine.

For sending, I noticed that the IR emitter never gets totally dark with 3.3V (high = dark, low = lit). It must get at least a bit dimmer, because it somewhat worked on the 82240 printer. It only gets fully dark when applying 5V.

I got myself some simple converters (similar to those: https://www.sparkfun.com/products/12009), but they are again way too slow. Apparently, even the converters need to have the "right" specifications.

[Martin Hepperle]

There are plenty of IrDA Transceiver modules should probably work for this purpose.
One of these modules is what you find inside the HP C4103.

At the time, I simply used the C4190 because it came with a nice small case with HP logo and it was not necessary to design a PCB or any other interface circuitry, and no need to look for a decent case.

If you want to design a completely new device, I would study the datasheets of these IrDA transceivers. For a selection see e.g. Digikey.

Like in the HP part, these are bi-directional, and have two separate lenses, so one could also use them for a combined printer receiver/sender module.

Martin