peterhinch / micropython_ir

Nonblocking device drivers to receive from IR remotes and for IR "blaster" apps.
MIT License
240 stars 51 forks source link

Capture RAW IR signal and replay #3

Closed DartLazer closed 2 years ago

DartLazer commented 3 years ago

Dear Peter, first thanks of all for all your hard work getting this to work in mPython.

Is there any way I could capture an infrared key and save the pulses. And later on replay this IR key?

I'm building a device where you can simply scan the IR key so it will be usuable with all kinds of remotes.

Kind regards, Rik

DartLazer commented 3 years ago

I found your code in transmitter.md explaining how to get RAW Signals.

Using the following code I can captured and write to file, and try to send. My television however doesnt respond to the signal. When I try to read the code with my raspberry pi (other device) I can see it coming through and it looks similar to the IR code from the remote.

Am I missing something?

`from ir_rx.acquire import test import ujson from ir_tx import Player from sys import platform from machine import Pin, Timer from time import sleep

led = Pin(25, Pin.OUT) scan_button = Pin(14, Pin.IN, Pin.PULL_DOWN) transmit_button = Pin(13, Pin.IN, Pin.PULL_DOWN) print('Waiting for button') led.high() while True: if scan_button.value(): lst = test() # May report unsupported or unknown protocol with open('burst.py', 'w') as f: ujson.dump(lst, f) print('Scanned')

if transmit_button.value():
    print("Transmitting?")
    from ir_tx.nec import NEC
    with open('burst.py', 'r') as f:
        lst = ujson.load(f)
    pin = Pin(15, Pin.OUT, value = 0)
    ir = Player(pin)
    ir.play(lst)   
    sleep(1)

`

DartLazer commented 3 years ago

When I scan both codes on another device I get this for the original remote: +4434 -4485 +572 -1682 +566 -1685 +567 -1688 +565 -546 +566 -571 +542 -597 +542 -571 +566 -572 +540 -1713 +540 -1687 +567 -1686 +568 -601 +523 -574 +562 -573 +566 -547 +565 -573 +844 -288 +739 -1492 +534 -599 +587 -592 +494 -578 +570 -565 +534 -581 +557 -570 +540 -1712 +563 -555 +566 -1715 +534 -1700 +525 -1712 +541 -1712 +515 -1712 +564

and this for the remote send with the raspberry pico: +4403 -4512 +512 -1715 +535 -1723 +534 -1661 +590 -575 +539 -574 +538 -601 +537 -576 +513 -625 +537 -1739 +522 -1720 +510 -1213 +351 -136 +520 -634 +507 -619 +514 -603 +514 -597 +631 -458 +581 -582 +526 -1714 +566 -547 +512 -626 +512 -600 +512 -626 +539 -581 +534 -603 +539 -1723 +525 -572 +513 -1740 +539 -1715 +511 -1736 +519 -1740 +541 -1686 +537

It seems like somehow the timings on the PICO are always a bit shorter.

peterhinch commented 3 years ago

That looks like a Samsung protocol which is not one I'm familiar with. Record and replay is, as stated in the docs, rather experimental. However I would have thought that those slight discrepancies in the receive timings should be insignificant. Have you tried transmitting both sets of timings to see if that is the case?

Your transmit code looks wrong: you import NEC. I'd expect to see

from ir_tx import Player

I guess this is a typo because as quoted it would throw an exception.

Aside from this it is difficult for me to support capture mode as I can't replicate your conditions. As stated in the docs, it is for experimenters and the issue with repeat codes is a bit of a killer.