Decoding signals from IR remote controls with LabVIEW

[Max_67]

Thanks Dave!

I did a quick read test yesterday, something's moving on the read side...

In the next days I should have some free time in the evening so I will be back with my findings.

Max

[Henrik_Volkers]

Your Sensor already has a build in demodulation for a fixed carrier frequency.

Good: you don't have to care about the higher carrier frequency.

Bad:  you are limited to devices using that carrier frequency.  

If you want to reseach all IR remotes, you would need a fast IR receiver without demodulator ...

hint: SFP-moduls start at 5 bugs (or ask someone in a IT department ( the sneaker guys, that run the network 😄 )) 

and have a really fast IR receiver and a LVDS digital output . You should use  the 850nm SFPs (most common in building network)  

[Max_67]

First success.
This is the reading of the "volume up" button on a Nikkei TV remote control, which uses the NEC IR remote protocol.

Two words are transmitted:

I have other remotes using other protocols, so that's just a starting point.

Encouraging, though.

Max

[DavidBoyd]

Wow, you move fast!  This looks like exactly what you wanted to achieve.

[DavidBoyd]

Looks like Manchester encoding, or a CDI (conditioned diphase) encoding?  Always a transition at the bit edge, and a second transition in between is a zero bit?

Edit: Nah, that can't be true.  Byte lengths vary depending on content.

[mcduff]

---

@DavidBoyd wrote:

Looks like Manchester encoding, or a CDI (conditioned diphase) encoding?  Always a transition at the bit edge, and a second transition in between is a zero bit?

Edit: Nah, that can't be true.  Byte lengths vary depending on content.

---

No idea here, just guessing, but each byte here is 8 bits. One bit is a "short" or "long" pulse; there a 4 pulses per byte. How the message starts or stops, is a bit more mysterious.

EDIT: Forget about it. 🙂 

[Max_67]

Yesterdat I was reading about the receiver.

This is from AI:

The TSOP38238 is a 38 kHz infrared (IR) receiver module that typically rests in a HIGH (1) state when no signal is detected, transitioning to LOW (0) when a modulated 38 kHz signal is received. A long HIGH state followed by signal pulses is the standard idle condition before the receiver decodes data frames, such as NEC or RC5 protocols.

The chart in the image doesn't start with the idle HIGH state because I placed a loop that simply waits for the digital line to go LOW.

After that there is the execution of the Digital Wfm 1Chan NSamp which get the samples on the chart.

The long HIGH state before the 02h seems to be what AI described for the NEC protocol:

The NEC IR remote protocol is a widely used infrared communication standard that sends 32-bit data packets using a 38 kHz carrier frequency. It features a unique 9ms leading pulse followed by a 4.5ms gap, 16-bit address (device ID), and 16-bit command (button function), using pulse distance modulation for encoding bits.

So the NEC IR remote protocol always transmit 32 bits.

First two bytes are the address (always the same for any button on the remote) while the second two bytes are the command, which is of course different for each button.

Funny thing is that the second byte is always the revers of the first, the fourth the reverse of the third.

This NEC protocol seems very easy to be acquired, I can also allow a loop before the real reading.

Just tried a remote of a Sony HiFi... completely different.

I have to play with the number of samples, and also it seems that it doesn't switch from the first loop to the samples acquisition fast enough.

It won't be easy to cover all the differences...

[DavidBoyd]

Oh boy, you've got a lot going on here already, and a couple of armchair enthusiasts following you!

I did find this Renasas/NEC app note, perhaps you found it already?  Looks like the bit times are unequal for 0 vs 1, but since they repeat everything with the values inverted, they end up with all messages being equal duration.

What's unclear to me is how much your smart little Vishay device is doing for you.  Are your decoded values actually acquired LSB first?

Yeah, if my boss needed an IR decoder (unlikely assignment in my current medical device employment), I'd get a RedRat and write code around their .NET library.  If I were doing this for funsies with a handy paid-for PXI chassis and multi-IO module, I'd be following your path.

Enjoy!

Dave

[Max_67]

To be honest I did nothing about the "LSB first" thing...

I have an app on my mobile (which has IR transmitter) with all the buttons for that Nikkei TV coming from a database.

The app lets me see the code for each button, so I just compared the digital waveform acquired through LabVIEW with the hex code from the app.

And they match.

Max

[DavidBoyd]

Interesting.  If the signaling matches what your database of codes shows, and it's already MSB first, then I might conclude that the Vishay part does some internal processing?  In any event, your example waveform and the decoding you overlaid on it does demonstrate that the NEC protocol does repeat each byte with logical inversion - hence the adjacent byte pairs should sum to 0xFF, as those do.