A handheld remote can make an interactive display, an audio object or a classroom prototype easier to use. Someone can start a demonstration without reaching behind the enclosure or opening an app. The first engineering question is simple: when they press the button, does the device do what they expect?
A stream of numbers in a terminal is a good beginning. To turn it into a usable control, you also need to know which button those numbers represent, what happens when it is held down, and whether the receiver still works where it will be mounted. On our bench we had two infrared modules exchange a known command, with the wiring and output recorded.
This matters in real projects. In a February 2022 forum discussion, a builder wanted two USB media players to respond to one remote. Reception depended on finding a narrow pointing position, and the players fell out of sync. Detecting a command on one board was only part of making that installation work.
What the bench experiment connects
We used a GraftPort carrier with a Raspberry Pi Pico, a GraftSense IR333C transmitter module and a GraftSense TSOP34138 receiver module, running MicroPython 1.23. The transmitter emits bursts of infrared light; the receiver turns a suitable signal into electrical pulses; software interprets the pulse timing as a command. The receiver does not know that a button means "play" or "next."
The modules connected through four-wire cables at the carrier's DIO0 and DIO1 connectors. The transmitter's signal went to GP6 as an output and the receiver's signal to GP14 as an input; the neighboring GP7 and GP15 positions were unused. Those are GPIO numbers, not header positions. The receiver's connector label DIN names the signal going into the controller.
Before copying those connections to another board, check the supply and output voltage. The receiver module's schematic pulls its output up to its VCC rail through a 10 kΩ resistor and shows no level translator. A module described as "5 V" does not have an output suited to a 3.3 V controller just because the connector fits. Confirm the actual rail and signal levels, and power or translate as required. We did not record those measurements.
For the first run we held the transmitter and receiver facing each other. That removes one variable while bringing up the software, but it leaves enclosure materials, viewing angle and working distance for a later test.
Send a known command before adding product behavior
Our receive and transmit code builds on Peter Hinch's MIT-licensed micropython_ir library. The program created a 38 kHz NEC transmitter on GP6 and an NEC 16-bit receiver on GP14. NEC is the message format. The transmission itself is short:
ir_tx = NEC(Pin(6, Pin.OUT), freq=38000)
ir_tx.transmit(0x10, 0x20) # address 0x10, command 0x20
The program repeated that transmission every two seconds. A fixed message keeps the first test easy to read: if the received values change unexpectedly, investigate the connection, timing or decoding before adding a menu, motor or audio player. Keep the driver version with your prototype files so a later update does not quietly change the experiment.
Our terminal printed Address=0x0020, Cmd=0x10, which looks wrong. The cause was in our callback: it named its first argument addr and its second cmd, but the receiver passes the command first and the address second. With the labels corrected, the output matched the transmitted address 0x10 and command 0x20.
The third callback argument was not a repeat flag either. For NEC it is zero, and a repeat is signaled by a command value of -1. The receiver documentation explains the data, address and control convention.
What this supports is modest but useful: a fixed message was transmitted and produced receiver callbacks. It is not a handheld remote test, a measured success rate or a completed product action.
Decide what a press and a hold should mean
Once the known message is understood, write down the intended action before extending the code. For an exhibit, a press might start an animation once. For an audio prototype, holding a button might keep adjusting volume. Applying one repeat policy to both gives confusing results: an animation restarts continuously, or volume moves only one step.
Define and test these cases:
- One short press: perform the selected action once and show feedback.
- A held button: repeat an adjustment, or ignore repeats for a one-shot action.
- A button from another remote: leave the prototype unchanged unless you deliberately support it.
- A missed reception followed by another press: give a predictable result, with no unexpected toggle.
Start with one accepted address and command, then add only the actions your demonstration needs. Keep lengthy work out of the receiver callback so that playing a sequence or updating a screen does not land in the time-sensitive reception path. Use a flag or queue to hand work to the main application.
Check the receiver choice before committing the enclosure
"38 kHz" is only part of compatibility. The receiver must also accept the signal's burst pattern. Vishay describes the TSOP341 family as a short-burst receiver; its datasheet gives the data-format constraints and points long-burst designs to other families. Our bench result is evidence for that setup, not a guarantee for every NEC remote or environment. Check the chosen remote, receiver variant and driver together.
Next, place the receiver where it will sit in the product and repeat the interaction test through the real cover. Try the intended seating or standing positions, the expected room lighting and the weakest remote battery you plan to support. Record presses attempted, actions completed, missed actions and unintended repeats. A dark plastic panel that looks right to the eye still needs an infrared transmission test.
Manufacturer distance and directivity figures describe reference conditions, not this assembled prototype. An older datasheet's 45 m typical distance is not a claim that the module works across a 45 m room; the emitter, optical path and test conditions all matter. Set a working distance from the intended use and verify it on the assembled device.
For a two-device installation, add a separate check that both devices reach the required state. Sending one message to both does not show synchronized playback or prove neither missed it; that is a larger system requirement than this bench test covers.
A useful next prototype test
You do not need a full remote-control system to learn something useful. Choose one command, define its press-and-hold behavior, and demonstrate the resulting action through the intended enclosure. Keep the bench setup available so you can separate reception problems from application problems when something stops working.