New SIRC capturing routine, code repetition problem

[fenyvesi]

Dear Robert,

Because of Amazon Echo problems I postponed the usage of your program. I got a new Echo and I managed to implement a LOCAL Wemo switch emulator in NodeRed running on RasPi without the need of opening a port. So I started the ESP part again.

1. Since I have a Sony AV I captured the IR codes. In this process I modified the SIRC capturing module to adapt to the situation that the code length is not fixed (it alternates between 15 and 20 bits). In the meantime I realized that there was a problem in the get_nec() routine also: bad data signal names were used. I modified it also. It is in the file called .zip, it is really a .rar file.

2. In the process of capturing I realized also that the code repetition doesn't work in the ESP program. The problem is in the BitTx.cpp, line 69. The names are vice versa. I suggest that the correct form is: tx_bitCounter = tx_bitCount;

BR. George rxir.zip

[roberttidey]

Thanks.

I have updated BitTX for the repeat handling. I normally handle any repeat handling at the higher level so hadn't noticed that.

I have checked out further the rxir.py changes, particularly the nec ones. I hadn't had a problem with the previous version. I use the inverted data signals where high is ON but even when I set it that way in your update I couldn't get nec to capture.

For nec start detection is looking for an long on pulse followed by a long off pulse, so it exits this with the signal in an on state. The nec data pulses are a fixed period on pulse followed by a variable period off pulse, so the code that enters the data bit follows the detection of a off to on transition. This is the line if pin == RX_DATA_OFF and pulse < maxhigh: in the original version.

The Sony support was put in just from the spec as I don't have a sony remote and looking at it again the variable width is the on period followed by a fixed off. This is why it should be if pin == RX_DATA_ON and pulse < maxhigh: in the Sony version unlike the nec version.

The quiet period should be using RX_DATA_OFF and I have changed that.

The merged version is updated. Note that I restored the queries for input data and the signal level definitions.

[fenyvesi]

Dear Bob,

I’ve forgotten to write but you realized that I had added a quick and dirty Raw capturing to have an idea about timings.

I used the original signals without inverting them with hw and changed the signal levels: RX_DATA_OFF = GPIO.HIGH

RX_DATA_ON = GPIO.LOW.

I wouldn’t dare to take statements about the NEC routine, because I don’t know it. My proposal of change based on the fact that I used it as a template for Sony and the logic seems to be the same.

As far as the Sony: When it didn’t work in the original form I had been scrutinizing it for a while till I realized that the pin variable stores the PREVIOUS status before status change. This is the reason I modified the proposed way and it does work.

Küldte a Windows 10 Posta

Feladó: roberttidey Elküldve: 2018. június 1., péntek 11:04 Címzett: roberttidey/IRBlasterWeb Másolatot kap: George Fenyvesi; Author Tárgy: Re: [roberttidey/IRBlasterWeb] New SIRC capturing routine, coderepetition problem (#2)

Thanks. I have updated BitTX for the repeat handling. I normally handle any repeat handling at the higher level so hadn't noticed that. I have checked out further the rxir.py changes, particularly the nec ones. I hadn't had a problem with the previous version. I use the inverted data signals where high is ON but even when I set it that way in your update I couldn't get nec to capture. For nec start detection is looking for an long on pulse followed by a long off pulse, so it exits this with the signal in an on state. The nec data pulses are a fixed period on pulse followed by a variable period off pulse, so the code that enters the data bit follows the detection of a off to on transition. This is the line if pin == RX_DATA_OFF and pulse < maxhigh: in the original version. The Sony support was put in just from the spec as I don't have a sony remote and looking at it again the variable width is the on period followed by a fixed off. This is why it should be if pin == RX_DATA_ON and pulse < maxhigh: in the Sony version unlike the nec version. The quiet period should be using RX_DATA_OFF and I have changed that. The merged version is updated. Note that I restored the queries for input data and the signal level definitions. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[fenyvesi]

Bob,

I use a NodeMcu (ESP12) device and it seems to me that the output signal level is only 500 mV on the scope. Is it a hardware problem or something else?

Thanks.

George

Küldte a Windows 10 Posta

Feladó: roberttidey Elküldve: 2018. június 1., péntek 11:04 Címzett: roberttidey/IRBlasterWeb Másolatot kap: George Fenyvesi; Author Tárgy: Re: [roberttidey/IRBlasterWeb] New SIRC capturing routine, coderepetition problem (#2)

Thanks. I have updated BitTX for the repeat handling. I normally handle any repeat handling at the higher level so hadn't noticed that. I have checked out further the rxir.py changes, particularly the nec ones. I hadn't had a problem with the previous version. I use the inverted data signals where high is ON but even when I set it that way in your update I couldn't get nec to capture. For nec start detection is looking for an long on pulse followed by a long off pulse, so it exits this with the signal in an on state. The nec data pulses are a fixed period on pulse followed by a variable period off pulse, so the code that enters the data bit follows the detection of a off to on transition. This is the line if pin == RX_DATA_OFF and pulse < maxhigh: in the original version. The Sony support was put in just from the spec as I don't have a sony remote and looking at it again the variable width is the on period followed by a fixed off. This is why it should be if pin == RX_DATA_ON and pulse < maxhigh: in the Sony version unlike the nec version. The quiet period should be using RX_DATA_OFF and I have changed that. The merged version is updated. Note that I restored the queries for input data and the signal level definitions. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[roberttidey]

By output level I assume you mean the pin (e.g. GPIO14) driving the IR LED.

How are you connecting that? Are you connecting LED direct to pin?

Details on how I hook mine up are on the instructable https://www.instructables.com/id/ESP-12-Infra-Red-Blaster/

Here I drive the IR LED from the 5V line via a MOSFET buffer with a load resistor to give about 70mA through the LED which gives good range. Reason for using the 5V line is just to reduce load on the 3.3V regulator. One could replace the MOSFET by a npn transistor with a base resistor of about 1K. With either of these the GPIO pin should be switching between 0 and 3.3V

It is possible to drive the LED direct from the GPIO pin via say a 220Ohm resistor but the LED current will then be about 8mA and the range will be reduced.

[fenyvesi]

No, through a 4.7k resistor to a BC639 NPN transistor.

But if I measure the output of GPIO14 without connecting to anything the signal level is around 500mV and unable to drive the transistors (min. is 0.7V).

It is another strange pfenomenon is that when I drive the ESP through a web browser command after generating the required IR signals it irregularly remains HIGH. Maybe is it a side effect of loosing WIFI connection often and reconnecting?

_Thanks. George

Küldte a Windows 10 Posta

Feladó: roberttidey Elküldve: 2018. június 15., péntek 9:38 Címzett: roberttidey/IRBlasterWeb Másolatot kap: George Fenyvesi; Author Tárgy: Re: [roberttidey/IRBlasterWeb] New SIRC capturing routine, coderepetition problem (#2)

By output level I assume you mean the pin (e.g. GPIO14) driving the IR LED. How are you connecting that? Are you connecting LED direct to pin? Details on how I hook mine up are on the instructable https://www.instructables.com/id/ESP-12-Infra-Red-Blaster/ Here I drive the IR LED from the 5V line via a MOSFET buffer with a load resistor to give about 70mA through the LED which gives good range. Reason for using the 5V line is just to reduce load on the 3.3V regulator. One could replace the MOSFET by a npn transistor with a base resistor of about 1K. With either of these the GPIO pin should be switching between 0 and 3.3V It is possible to drive the LED direct from the GPIO pin via say a 220Ohm resistor but the LED current will then be about 8mA and the range will be reduced. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[roberttidey]

That definitely sounds wrong. GPIO14 should swing close to 3.3V when driven high.

Obviously with the modulated on/off output, the average voltage measured with a voltmeter will be very low but you say you have checked it with a scope so you should see the pulses with that. Can you see the modulated pulse on the scope even if they are of wrong level. If so then that would almost certainly point to a hardware issue.

I think I'd write a simple test sketch that sets GPIO14 mode to output and then toggles it high and low in the loop with maybe a 2 second gap so you can check the levels with that.

The IRBlaster software needs the pin to support I2C output and this can be GPIO14 or GPIO2 so you could try GPIO02 instead., although I think it somewhat unlikely that just one GPIO is faulty.

Maybe also double check your wiring from the GPIO pin to make sure that nothing else is connected that could affect things.

Output staying at a logic 1 after a sequence doesn't sound right either. The bitTx library will obey whatever the message codes are but these will should always end in IR Off.

[fenyvesi]

I was stupid. There were 2 independents problems.

1. The transistor was unable to drive the LED becuase the 4.7k resistor before it was to large and produced too large voltage drop.
2. When the LED didn’t go and I checked the input signal of the transistor I didn’t realise that the oscilloscope measurement cable was set to x10, so the input was 3.3V but I see only 330mV.

Sorry and thanks. George

Küldte a Windows 10 Posta

Feladó: roberttidey Elküldve: 2018. június 15., péntek 23:56 Címzett: roberttidey/IRBlasterWeb Másolatot kap: George Fenyvesi; Author Tárgy: Re: [roberttidey/IRBlasterWeb] New SIRC capturing routine, coderepetition problem (#2)

That definitely sounds wrong. GPIO14 should swing close to 3.3V when driven high. Obviously with the modulated on/off output, the average voltage measured with a voltmeter will be very low but you say you have checked it with a scope so you should see the pulses with that. Can you see the modulated pulse on the scope even if they are of wrong level. If so then that would almost certainly point to a hardware issue. I think I'd write a simple test sketch that sets GPIO14 mode to output and then toggles it high and low in the loop with maybe a 2 second gap so you can check the levels with that. The IRBlaster software needs the pin to support I2C output and this can be GPIO14 or GPIO2 so you could try GPIO02 instead., although I think it somewhat unlikely that just one GPIO is faulty. Maybe also double check your wiring from the GPIO pin to make sure that nothing else is connected that could affect things. Output staying at a logic 1 after a sequence doesn't sound right either. The bitTx library will obey whatever the message codes are but these will should always end in IR Off. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.