acquire is not waiting for a burst

[siliconchris]

Hi,

I am trying to setup a Raspberry PI PiCo with an Iduino Infrared Receiver (http://www.mercateo.com/p/615-W632551/Iduino_1485322_IR_Empfaenger_Passend_fuer_Einplatinen_Computer_Arduino.html)

I have this setup

When I run the test procedure from acquire.py, I receive this error right after the start - without even pressing a button on my remote control:

`

from ir_rx.acquire import test test() Waiting for IR data... 000 8284

exception in decoding the burst data with length=1 duration=0 / [8284]

[8284] `

I don't really understand, why the program is NOT waiting for infrared signals but is immediately trying to decode something, that is probably not even there. I did a change to the acquire.py to print out way more debugging Information and this is what I get:

`

from ir_rx.my_acquire import test test() rp2 setting Pin to 16 initializing local IR_GET class with pin=Pin(16, mode=IN) nedges=100 twait=100 Waiting for IR data... local decode function called edge is 10 length of burst is 9 dt is 8798 dt is 11257 actual length of burst [8798] is 1 duration is 0 the burst is: [8798] x: 000 e: 8798 near called with 8798 / target 9000 near called with 8798 / target 2400 near called with 8798 / target 889 near called with 8798 / target 2666 near called with 8798 / target 2000 near called with 8798 / target 4500 near called with 8798 / target 3500 near called with 8798 / target 0 exception in decoding the burst data with length=1 duration=0 / [8798] [8798] `

Interesting note here, the valueSs keep changing from call to call.

Can you give me a hint what's going on here?

Kind regards,

Christian

[Vendelator]

I have not had time progressing with my own code yet but I do have a working application which is nice.

Anyway, from what I can tell by viewing from my phone right now, the program fails to recognise the protocol used. Do you know what protocol you are trying to receive?

I will look at it better later today.

I had more success with this: https://github.com/meloncookie/RemotePy

[siliconchris]

Hi, This is my issue, I think. The remote I am trying to receive a signal from is a custom remote from DeAgostini. So I am pretty sure it does not really make use of a "standard" protocol. So, I guess what I really want to have, is some way to simply print out the information the remote issues in a burst. If I can get that, I thought I could just store these in CONST and compare received inputs to these, to decide what to do when a button on the remote is pressed.

For reference, this is how the remote looks from the out and inside

[peterhinch]

Unfortunately I don't know German so I've no idea what hardware device you are using. The fact that acquire.py fails in the absence of a signal implies it is not compatible.

I would suggest using the Vishay TSOP4838 as recommended in the docs and run it off the Pico's 3.3V supply (Pico GPIO's are not 5V compliant).

[siliconchris]

Hi, I am now using the mentioned TSOP4838. Anyhow, regardless of which decode class I am trying to use, I only receive errors like bad block or invalid start pulse - even though I have not even pressed a button on my makeshift remote.

So I am wondering, is there a possibility to have your class simply print out the raw data it receives from an IR transmitter? Or is it only meant to be used with a standard remote control?

Kind regards and many thanks for your support, Christian

[peterhinch]

I don't understand why you're getting any response when you haven't pressed a button. If the remote is not transmitting the software should just wait quietly. I suggest you ensure that your remote is disabled and check that your setup works with a known good remote control. If this test passes, the fault implies that your remote is transmitting all the time.

is there a possibility to have your class simply print out the raw data it receives from an IR transmitter?

If you look at the docs for acquire you will see that

The test() function returns a list of the mark and space periods (in μs).

which is what you are looking for.

[EDIT] If your remote is continuously transmitting, it is possible that the receiver code will malfunction. It is designed on the basis that remotes will transmit a burst whenever a button is pressed, and it has never been tested under conditions of continuous reception.

[siliconchris]

I have to apologise. My issue was caused by malfunctioning receiver hardware. I added a resistor and a capacitor to my IR diode and now I receive signals just perfectly fine. Nonetheless, I want to thank you for your advise. Christian

[siliconchris]

Malfunctioning hardware caused this issue. so not a software problem.

[peterhinch]

OK, thanks for letting me know.