An infrared receiver prints a message when something happens. That is useful evidence, but it does not yet tell you which command arrived, whether your own transmitter caused it, or whether any audio information crossed the link.
For a team exploring a contactless interaction, keeping those apart keeps the next experiment focused. A forum discussion about sensing human presence for an art piece is a typical starting point: a desired effect, and a sensing requirement that still needs to be pinned down. On our bench we ran two infrared experiments on Graft modules with a Raspberry Pi Pico, programmed in BIPES blocks that generate MicroPython, to separate a detected event from the more ambitious names attached to such projects.
Read the simplest event chain first
The first experiment uses one infrared transmitter module and one receiver module. Their optical alignment is part of the setup.
The receiver program configures GPIO6 for falling-edge interrupts and prints an "infrared triggered" message from the handler. The transmitter program sets GPIO21 true, waits 0.1 seconds and sets it true again. Note what that code does not do: it never drives the pin low, so it does not alternate high and low as a modulated signal would.
The receiver printed its trigger message during the session. That establishes a received event. It does not establish a decoded remote command or a verified transmitter waveform.
The distinction matters because the receiver is a TSOP34138, a carrier-selective infrared receiver. The Vishay TSOP341 family datasheet identifies the 38 kHz variant: the part is built to respond to infrared modulated near that frequency and to reject steady light. We did not establish whether this particular transmitter module generates its own carrier. A GPIO sequence alone cannot answer that hardware question, so the next step is to look at the emitter drive with a scope or check the module's circuit, not to assume it either way.
A larger assembly still responds to events
The second experiment combined an analog input, the transmitter, the receiver and a speaker output in one case. It was built as an "infrared voice" demonstration, and the name is worth examining against the code.
The receiver callback watches GPIO7 for a falling edge, increments a counter guarded against concurrent access, and sets an event flag. The main loop reads ADC26 and, when the value exceeds 40000, runs a transmitter sequence on GPIO9. That sequence again writes true twice, with 50 ms delays.
When an event has been flagged, the speaker plays at a fixed 1 kHz while its PWM duty changes according to the counter. The loop sounds for three seconds, stays silent for three seconds, then clears the flag. The analog values printed to the console are threshold readings, not a sampled speech signal.
Changing duty is not changing pitch, and nothing in this program encodes, transmits or reconstructs a speech waveform. What the assembly does demonstrate is a combined event-response program: an analog threshold starts a transmit sequence, a receiver event updates state, and a speaker responds. The transmitter behavior is still unresolved, and there is no claim here that voice crossed any measured distance.
Choose the next proof you actually need
Three different products hide behind "infrared", and each needs its own test:
- A simple trigger. Verify that a known transmitter action produces a distinguishable receiver event, and that ambient light and stray reflections do not, under the intended alignment, distance and lighting. Count false and missed events over many repetitions.
- Remote commands. Identify the carrier and the message format, then verify that the receiver side decodes the commands you send, including at the edges of the intended angle and range.
- Audio. Define a signal path that can actually carry and reconstruct audio. That is a different project from changing a fixed tone after an event, with its own bandwidth, modulation and noise questions.
We have not run these follow-up tests on this hardware. They are the experiments we would run next, depending on which of the three the product needs.
Write the requirement in those terms before choosing parts. "The user waves a card and the exhibit responds within half a second, from up to one meter, in a bright room" leads to a different design, and a different test, from "the toy sends a voice message across the room".