Issue on sending Yamama-NEC codes

[PicoCodeHappens]

Hi @peterhinch

first of: THANK YOU for your awesome library, which made my life so much easier :-)

Buuuuuuuuuuut: I've got a problem and my troubleshooting capabilities are an an end ;-)

I built the following circuit

Raspberry Pi Pico IR in TSOP 4838 @GPIO28 IR out TSAL 6100 VIS (10 Ohm resistor in place) @GPIO16 IR out amplified by BC547B on 3.3V

and imported your awesome library. After some trial and error and patching code for my particular pin setup I got it all working, I can now receive IR codes and send them out. For example my Sony TV now turns off and on using your software.

Problem is: My Yamaha AVR won't do the same. Yamaha uses NEC codes. I can properly receive the codes from my Yamaha remote (i.e. "Data 2a Addr 007e Ctrl 00" for toggling the power). Thing is, when I send these codes using nec.transmit(0x7e,0x2a) my AVR just does nothing :(

Since the Sony portion is working, I think, the circuit itself is working flawlessly.

Anyhow, I:

• checked that my circuit is working
• checked that the IR LED is working (by using my smartphone camera)
• switched the IR LED with another type, which has a lower range but a broader output angle (TSAL 6200)
• checked, that the codes I receive are indeed valid codes for Yamaha AVR operation
• tried other Yamaha/NEC codes i received off my remote
• tried fiddling with timings by sending the codes 3 times, 62ms apart (less time freezes the Pico)
• tried the repeat code
• gave up for now :(

Do you have any idea, which tree I should bark up next?

[peterhinch]

NEC is usually easy. I wonder if Yamaha are using a nonstandard carrier frequency? I've found that capturing codes with a TS4838 works even if the carrier is 40KHz or 36KHz. But possibly the receiver in the Yamaha AVR is more selective. You could try overriding the default in the transmitter.

It is possible to measure the carrier frequency of the remote, but it requires building a simple circuit and using a scope, logic analyser or frequency counter.

[PicoCodeHappens]

I can confirm, the 4838 is quite forgiving about the carrier signals since the Sony signals - which it caught flawlessly - are modulated at 40 kHz. Internet (tm) says, Yahama uses the NEC default carrier frequency of 38 kHz - no word of duty cycle so far.

I think, you've got a point, tomorrow I'm going to code a little loop around line 17 of your nec.py and try to drive the carrier frequency from 34 kHz up to 42 kHz - in 50 Hz increments and send the data. If that doesn't work, I'll try the same at fixed 38 kHz but try to tune the duty cycle in the same manner.

About frequency measurement, I sadly don't own any of these tools, just an old DMM from the 1990ies :(

Anyway, thanks for your help, I'll keep you posted.

[peterhinch]

I doubt that duty cycle will have an effect. I'd start out trying 34, 36 and 40KHz as these are known values, then try your 50Hz increments.

[PicoCodeHappens]

Well, I tried and I failed :-) From 34 to 50kHz, nothing worked.

In addition I found out, that one of my outdoor LED strips' remote sends NEC codes, too. But I'm encountering the same problem: Reading the remote codes works fine, sending them won't work. So now I've got two NEC-devices that won't work. I'm quite sure, that the problem is on my side, not on your or Yamaha or anybody elses'.

I'll keep digging.

[PicoCodeHappens]

Peter, you won't believe it, I think, I found the error - but I am not fluent enough in Python to fix it. Long story short: The very last pulse, the end-of-message-pulse is not generated - although it is in your nec.py.

Long story long: I bought an Oscilloscope :-D and measured the output of the pin on the Pico I use for sending the pulses. I am sending nec.transmit(0x7e,0x2a) and I can clearly see, that almost everything is in order, the 9ms/4.5ms header, the address, the inverted address, the command and the inverted command (all four LSB first). I've attached the measurement.

But then, there is no EOM-pulse and I am truly not sure, why. Found it in your nec.py self.append(_TBURST), but to no avail :(

I hope you can help me :-)

All the best!

[peterhinch]

OK, I will investigate. There may be a bug in my PIO code.

[peterhinch]

I've pushed an update.

Thank you for the excellent report, it was indeed missing the last pulse owing to a bug in rp2_rmt.py. Please let me know if this works for you.

[PicoCodeHappens]

Thanks for the update. It works! I just turned off my wife's AVR :) I'm gonna sleep on the couch tonight, worth it :-D

Thanks for your help!!!

[peterhinch]

Thank you for identifying this nasty bug.