Infrared binary mode (AnalysIR, IRMAN)

mbrugman · January 16, 2025, 5:54pm

Here is some testing I did with my IR Toy board.

First, I have an IR sensor/board that I built many years ago for testing/debug when I worked at a machinery OEM:

This is the prototype sensor that was eventually used - an IR photo transistor on a small board with an RC filter. The board was put into a piece of 1/2" PVC, a cable soldered to the board, a cord grip put on the end of the PVC, and finally filled with optically clear potting compound. (The sensor with into a pretty hostile environment, lots of water, strong soaps, etc.).

The board is an ATMega 32u4 variant. The code is using input capture pin and timer/ISR to count the pulses and decode the IR signals.

I set that sensor next to the IR toy to try to capture signals from a few different remotes:

My test thingy just decoded the signals and spit out the results into a serial terminal. Here are the initial results:

The first remote I used was the ASIC-based custom remote that was part of the original project from long-long ago. Both my setup and the IR Toy decoded it at 38KHz. They came up with different results; maybe presentation?

For reference, on mine it decoded all 4 bytes:

address is the first two bytes as-is.
command are the last two bytes as they are
In practice, I used bytes 1 and 2 to be sure it was the “official” remote. (The remote was used to move a large machine, so I wanted to be sure!). I used byte 3 as the actual “command”. Byte 4 is the one’s compliment (minus 1), and was used to verify the command.

The other two addressed devices in my terminal are two more remotes, one an Insignia TV, the other a universal. The BP didn’t decode either of those.

Trying irrx binary stuffs:

I captured each remote using the same setup as above, but then turned my sensor to face the IR Toy and did a “retransmit”. The interesting thing is that the binary mode showed good looking data for all 3 remotes, and when retransmitting sent the correct stuff out so my sensor would ID it:

I see that the BP is saying 36KHz, but I was pretty sure everything I did was 38KHz, but it’s been 10+ years…

Please let me know what else I can do for testing
Matt

ian · January 16, 2025, 6:43pm

Wow! Thank you so much!

First, that remote looks so very similar to the one I used with the initial IR Toy project 15 years ago

Weird and informative about the NEC protocol. I didn’t write this PIO, it came from examples (in the SDK I think). It presents 8 bit address and 8 bits of data. I will need to look in to this further.

Today did some hardcore testing swapping in and out of protocols, and noticed NEC misses a lot. I’m not sure if this is new, as in something I did recently, or always been this way.

I did write the RC5 and RAW PIO programs, and I’m super glad to see RAW works for you. That’s really the one that matters to me. RC5 also seems solid as a rock.

36kHz - sorry about that, this is a current known issue. A dummy value is returned at the moment. Measuring the carrier frequency is a real challenge because of how the RP hardware is designed , but I think I figured out a reliable way to do it and will attempt tomorrow.

mbrugman · January 16, 2025, 6:49pm

Oh, I guess I did see that

I was just questioning my own memories. I haven’t played with IR in a long time; that’s why I wanted the IR Toy. Fun stuff!

ian · January 17, 2025, 11:35am

Here is my little logic analyzer for determining the modulation frequency. It is so very inconsistent, a setting must be off.

ian · January 17, 2025, 4:56pm

RC5

It was an all day fight, but I think it’s working This is an RC5 remote. Notice how the first two pulses are a bit irregular - the PIO program skips the first two because I saw this a lot experimenting.

Here’s the mini-logic analyzer output from the frequency measurement program. 8 * 32bits. The firmware grabs the 8 words and loops though counting 1 transition of 0->1->0.

Logic analyzer says: 27.79uS, 35.98kHz
PIO program says: 27.79us, 35.97kHz, 139 bit periods (difference due to float calculations I suspect)

NEC

NEC remote control.

Logic analyzer says: 26.29uS, 38.03kHz
PIO program says: 26.20uS, 38.16kHz, 131 bit periods

Give that our resolution is 0.2us, this seems pretty accurate. The floats can be changed to integer math and probably be just a tad more accurate.

Frequency	20kHz	36kHz	38kHz	40kHz	56kHz	60kHz
Bits @ 0.2us	250	139	131	125	89	83

The bit counts are very very similar to what I calculated yesterday.

What a huge pain, but at least it’s done. I will integrate this into the mode, the commands, and the AnalysIR binmode next.

PIO program

; program for measuring modulation frequency
; mini logic analyzer
; preload X with the number of bits to sample
.program measure_mod_freq
.define NOTICE_IRQ 0
public entry_point:
.wrap_target
    mov y, x          ;save counter value in y
    wait 0 pin 0      ;stall and wait for IR mark (low from learner)
    wait 1 pin 0      ;stall and wait for IR space (high from learner)
    wait 0 pin 0      ;stall and wait for IR mark (low from learner)
    wait 1 pin 0      ;stall and wait for IR space (high from learner)
    wait 0 pin 0      ;stall and wait for IR mark (low from learner)
loop:
    in pins, 1           ;take one bit sample
    jmp y-- loop        ;loop until counter hits 0
    irq wait NOTICE_IRQ ;notify the end of the measurement
.wrap

Kind of ugly, but it works. The waits are to filter out those first few wonky periods and get a cleaner signal.

henrygab · January 18, 2025, 2:30am

Wanted to provide some validation.

Console recording of RX of signal

HiZ> m

Mode selection
 1. HiZ
 2. 1-WIRE
 3. UART
 4. HDUART
 5. I2C
 6. SPI
 7. 2WIRE
 8. 3WIRE
 9. DIO
 10. LED
 11. INFRARED
 x. Exit
Mode > 11
Protocol
 1. RAW (aIR format)*
 2. NEC
 3. RC5
 x. Exit
Protocol (1) > 1
TX modulation
 20kHz to 60kHz
 x. Exit
kHz (38kHz*) >
RX sensor
 1. 38kHz barrier
 2. 36-40kHz demodulator*
 3. 56kHz demodulator
 x. Exit
RX sensor (2) >
Mode: INFRARED

INFRARED-(RAW)> irrx

Error: No voltage detected on VOUT/VREF pin
Hint: Use W to enable power, or attach an external supply
No file specified, packets cannot be saved
RX sensor: 36-40kHz demodulator

Listening for IR packets (x to exit)...
Exiting...

INFRARED-(RAW)> W
Power supply
Volts (0.80V-5.00V)
x to exit (3.30) >
Maximum current (0mA-500mA), <enter> for none
x to exit (none) >
3.30V requested, closest value: 3.30V
Current limit:Disabled

Power supply:Enabled
Vreg output: 3.3V, Vref/Vout pin: 3.3V, Current: 3.7mA

INFRARED-(RAW)> irrx
No file specified, packets cannot be saved
RX sensor: 36-40kHz demodulator

Listening for IR packets (x to exit)...

$36:9007,4534,577,562,576,563,576,562,577,562,577,562,577,563,576,563,576,563,576,1674,552,1700,552,1701,552,1699,552,1699,553,1698,554,1672,580,1672,580,1672,580,1672,580,1672,581,559,579,560,579,561,578,560,579,561,551,586,553,587,552,585,554,1696,555,1697,555,1696,556,1697,555,1671,581,39910,9009,2306,524,65535,;

Modulation frequency 36kHz, 36 MARK/SPACE pairs

'r' or 't' to re-transmit, space for next, 'x' to exit >

Listening for IR packets (x to exit)...

$36:9042,4498,585,557,581,557,582,583,556,558,581,583,556,583,556,557,582,583,556,1668,583,1668,557,1695,557,1695,557,1694,557,1695,557,1695,557,1668,583,583,556,583,556,583,555,583,556,583,556,582,556,1669,583,583,556,1668,584,1669,556,1695,557,1694,558,1695,556,1695,557,584,554,1696,557,39907,9042,2273,557,65535,;

Modulation frequency 36kHz, 36 MARK/SPACE pairs

'r' or 't' to re-transmit, space for next, 'x' to exit >

Listening for IR packets (x to exit)...

$36:9014,4526,558,585,553,611,528,585,554,611,528,584,555,584,554,611,528,584,554,1670,582,1670,582,1670,582,1670,582,1669,583,1669,583,1669,556,1695,557,1695,556,585,554,584,554,1696,556,584,554,585,554,586,553,584,555,585,554,1696,556,1670,582,559,580,1669,582,1670,582,1670,582,1669,582,39910,9036,2252,579,65535,;

Modulation frequency 36kHz, 36 MARK/SPACE pairs

'r' or 't' to re-transmit, space for next, 'x' to exit >

Listening for IR packets (x to exit)...

$36:9010,4529,581,562,578,560,579,560,578,561,578,588,551,559,553,587,551,588,552,1697,555,1698,554,1697,555,1670,582,1670,582,1670,581,1671,582,1670,555,1696,555,587,552,586,553,1696,556,1696,556,585,554,558,580,561,578,559,580,1669,582,1670,556,585,554,584,555,1696,556,1696,556,1669,583,39882,9043,2246,586,65535,;

Modulation frequency 36kHz, 36 MARK/SPACE pairs

'r' or 't' to re-transmit, space for next, 'x' to exit >

Listening for IR packets (x to exit)...
Exiting...

INFRARED-(RAW)> $36:8976,4565,517,648,491,648,514,624,491,648,491,647,492,648,491,647,491,649,490,1735,517,1736,516,1709,542,1710,542,1709,544,1709,540,1709,544,1711,541,1709,517,1735,517,1736,516,648,491,648,489,649,490,649,491,625,514,648,490,648,491,648,491,1708,543,1709,543,1708,543,1711,540,1711,542,39947,9004,2287,544,65535;
$36:9003,2311,542,65535;
x
Invalid command: x. Type ? for help.
INFRARED-(RAW)> $36:9016,4524,586,556,582,556,583,556,583,582,557,582,557,556,583,581,557,582,557,1667,558,1695,557,1694,559,1693,558,1695,557,1667,585,1667,585,1667,585,1667,585,1667,585,1666,585,582,557,556,583,557,556,608,531,608,530,584,555,608,531,608,531,1693,558,1694,559,1693,559,1667,584,1667,585,39906,9044,2271,559,65535;
$36:9043,2245,586,65535;

Comparison in AnalysIR

Channel one (green on top) is imported from the first signal in the above console log by copy/pasting the text from the terminal.
Channel two (yellow on bottom) is what was received by the LearnIRv2 USB dongle.

As can be seen, the results are substantially identical.

Minor Issue Found

After using irrx, and using ‘x’ to exit, the BP continues to show received IR signals. Reboot resolves this, of course, as does disabling power.

ian · January 18, 2025, 12:25pm

Thank you so much for the test and comparison in AnalysIR!

This is expected. In RC5/NEC/RAW when packets are detected they arrive in the terminal asynchronously. In RAW mode it outputs the AIR format timing packets.

henrygab · January 18, 2025, 9:43pm

Ah, OK. No control over when they arrive; OK, that makes sense.

In which case, how does one turn it off? I ask because the prompt included x for exit, and I thought that would stop the receiving?

ian · January 18, 2025, 9:50pm

The right answer is probably the default behavior of UART mode, [ or { enable reads with writes, opening the UART etc. I just wanted it to be immediately usable.

ian · January 20, 2025, 11:30am

Modulation frequency is now detected. Time to close this up and push the final IR stuff.

ian · January 20, 2025, 2:47pm

Frequency modulation measurement is implemented and pushed in the latest auto build.

There seems to be a small bug where the first measurement in normal terminal mode (async receive) is 0 or very wrong (33 vs 38khz). After that it is fine. This bug is not present in the irrx app because it uses a different method of output. I was not able to identify this issue, but in the name of moving on I’m going to leave it for now.

Next I’ll add the AnalysIR binmode. It is already written, it just needs to be connected to the new functions for IR IO.

I feel like it would be wise to do some documentation while it is all fresh in my mind, but I also really want to move onto JTAG.

ian · January 20, 2025, 3:55pm

@henrygab - you just pasted the terminal output into the import box and everything was ok? Did you have to specify the source type?

I am able to export an example signal to the A.IR format, and it looks ok. But when I paste that same export in the import it doesn’t recognize it.

henrygab · January 20, 2025, 5:12pm

I don’t recall if it was mandatory, but yes, I believe I specified the type (maybe as A.IR Shield ?)

From there, I just clicked Import into Channel 1 . Nothing fancy.

Note: I’ve not tried any difficult IR signals (e.g., Lego Power Functions).

ian · January 20, 2025, 6:43pm

R’dTFM: I see there’s a dev version. I’m not using that, are you perhaps on the dev version?

henrygab · January 20, 2025, 9:32pm

Yes, I am on the latest dev version.

henrygab · January 20, 2025, 9:35pm

OK, here’s the full steps I took:

Open AnalysIR
File->Import IR Signal (Ctrl-I)
In import UI, pasted the following line:
$36:9007,4534,577,562,576,563,576,562,577,562,577,562,577,563,576,563,576,563,576,1674,552,1700,552,1701,552,1699,552,1699,553,1698,554,1672,580,1672,580,1672,580,1672,580,1672,581,559,579,560,579,561,578,560,579,561,551,586,553,587,552,585,554,1696,555,1697,555,1696,556,1697,555,1671,581,39910,9009,2306,524,65535,;
Click the button between the two halves, >>>>
Click the “Import into Channel 1”

I am able to leave it at auto-detect. However, I missed step 4 … which is where it interprets the text and converts it to pulses.

Note: hovering over the “bulk import” button gives two neat hints for importing multiple signals:

Separate signals with $$$.
Separate signals with $$$aaa$$$, changing aaa into whatever friendly name you like for the button, and it will populate that name into the Button column of the history. Neat!

ian · January 21, 2025, 10:07am

Thank you so much. I needed the updated “dev” version, now it’s working great.

ian · January 21, 2025, 1:49pm

Receive isn’t working yet, but transmit from AnalysIR seems to be in order.

ian · January 21, 2025, 3:54pm

\n!BP V5310!\n

I added an ID string that will be supported in future releases of AnalysIR. Version number is coded as BP HW version, IR Toy HW version, Interface version major, interface version minor. The actual version string is (will be) ignored by Analysis.

After talking with AnalysIR, I removed the final timeout “space” at the end and modified RAW mode and AIR mode to accept unevenly packed AIR packets. Unfortunately receive is still having some issues.

Teraterm reading the AIR mode packets over CDC. It grabs the whole packet in one go in the correct byte order.

Here is a freshly started AnalysIR. It reads a single byte per packet. The beginning of frame is where it should be ($36:…).

It repeated the button press twice, here’s the end of first frame (,; ) and beginning of the second ($36:…).

Here is where AnalysIR stops grabbing data, the frame is incomplete (doesn’t end with “,;” ).

Here’s a second mash on the button. The missing “7,;” are now grabbed, then the next frame ($36…).

The end of this frame is also incomplete(,93). This is exactly what I see in the AnalysIR debug logs as well.

If I close and re-open AnalysIR the first packet is correct, but after that it is out of sync again. This suggests to me that the issue is probably not directly caused by my AIR printing code - otherwise we might expect the incomplete buffer to persist between restarts.

Windows 11, AnalysIR 1.19.200.9445.

Here is a test firmware if you happen to have AnalysIR and a demodulator of some sort. Does capture work for you (and what is your OS)?

Start in HiZ mode (only)
Type binmode and choose option 7. The AIR protocol will be on the binmode COM port.

bus_pirate5_rev10-analysir.zip (261.0 KB)

mbrugman · January 21, 2025, 4:53pm

I don’t have AnalysisIR or a widows box to run it on. I can try spinning up a VM and downloading to try.

Is there an eval version of the software? I’ve never used it before.

Give me a bit to sort some things first and I’ll give it a whirl.