gemu2015 / Sonoff-Tasmota

Tasmota Fork TCS34725,PN532_i2,ccc1101 Moritz support,m5stack 4,7 epaper, hotplug drivers
GNU General Public License v3.0
24 stars 19 forks source link

Support ESP-IR #40

Open TheChatty opened 1 year ago

TheChatty commented 1 year ago

SML works fine with some ESP8266 and D0 transceiver on hardware and software serial. image

Now I'd like to change to ESP-IR (integrated board with emitter and receiver): image

I guess there is an inverting Schmitt trigger in the D0 head. For obvious reasons that cannot be easily integrated into ESP-IR. Is there an easy solution to invert their behavior for SML? (e.g. change all lines in TasmotaSerial.cpp containg digitalRead and digitalWrite in a clever way)

gemu2015 commented 1 year ago

this took me 15 minutes to make a compile option to invert software serial, would be some more effort to make that configurable with a command

define TS_SWS_INVERT

see repo

TheChatty commented 1 year ago

You forgot one digitalWrite.

But even with this fixed the transmitter is always on and flashing when sending. What's happening?

gemu2015 commented 1 year ago

this is only working for software serial , hardware serial can not be inverted.

the pin i forgot should set the trx GPIO to the right level.

it should definitely work for sending.

for receiving i forgot the level change interrupt active transition, i will check that later

TheChatty commented 1 year ago

The problem was #defines from user_config_override.h are not incorporated into (all?) lib(s).

Now enforcing that #define TS_SWS_INVERT it works visually.

gemu2015 commented 1 year ago

yes i forgot that we are in a library. i fixed the irq , try receiving

TheChatty commented 1 year ago

Testing receiption with my EasyMeter (it sends telegrams every 2secs) does not work. Need to test later against my IR head in both directions.

TheChatty commented 1 year ago

Sending strings from ESP-IR with up to 14.400 baud works. Starting from 19.200 things get messy. The meter I have which requires sending is only at 1.200 baud thus ok.

Receiving strings with ESP-IR does not work even at 1.200 or 300 baud. My Kamstrup request (80 3f 10 07 00 3c 00 56 00 57 00 59 00 4a 00 44 00 7b 7c 97 0d) provokes every 10-15 time a single character to be received but mostly none. The character received is in 50% an @. When I undo inversion code for reading (define and interrupt) each Kamstrup request provokes almost steadily receiption of FF FF. Do you have any ideas how to analyze this?

gemu2015 commented 1 year ago

first check if the non inverse version works both for sending and receiving. ich checked the code again and can't find a reason why it should not work.

TheChatty commented 1 year ago

Using original Tasmota on both ends leads to this:

Both modules configured to IRsend/IRrecv

IRsend {"Protocol":"NEC","Bits":32,"Data":0x1248FEB7} is received as "IrReceived":{"Protocol":"UNKNOWN","Bits":32,"Hash":"0x1248FEB7"} in both directions. This library seems to handle inverted diodes transparently.

Both modules configured to TCP Tx/Rx with TCPBaudrate 1200

Data sent from D0 to ESP-IR is not received. Data sent from ESP-IR to D0 is kind of received. Long strings of the same character are "translated" into different characters (with some garbage).

0x65 -> 0x4D
0x67 -> 0x4C
0x6B -> 0x4A
0x79 -> 0x43
0x31 -> 0x67
0x33 -> 0x66
0x35 -> 0x65
0x3F -> 0x60
0x5F -> 0x50
TheChatty commented 1 year ago

@s-hadinger Are you able to to give some insight why a bit-inverted TasmotaSerial.cpp installed on ESP-IR is working for sending but not for receiving?Maybe you've got some idea where to continue investigation?

s-hadinger commented 1 year ago

This looks like a duplicate from https://github.com/arendst/Tasmota/discussions/16447

s-hadinger commented 1 year ago

If that's the same issue, it is possible to invert Hardware Serial, but it requires an additional parameter that is not present in TasmotaSerial (nor in Arduino if I remember well). The standard Tasmota has no plan to introduce this change.

Honestly this does not look as the good approach. IR is not meant to be used as On/Off, as this generates too much interference. It is typically sent with a carrier of 38KHz so that the receiver can filter out glitches and only retain what correpond to the carrier frequency. You can probably use higher frequency carriers, but this requires much more than just plugging serial to the IR diode.

TheChatty commented 1 year ago

The discussion at the main repo got stalled so sorry for the duplicate. Once solved I'll close it with a link to the solution.

The IR communication both threads are dealing with is about reading certain energy meters via standardized D0 interface. It's not about signals from TV remotes and so on.

As I said above the D0 IR head probably sports a Schmitt trigger (see linked schematics above) which inverts plain TTL signals thus the head is working as is on hardware and software serial from Tasmota or on a FTDI.

The factory-made ESP-IR has its diodes connected to GPIO 4 and 14 thus software serial. As try and error has shown switching HIGH and LOW did work for sending. This makes me wonder what is missing for receiving.

gemu2015 commented 1 year ago

@TheChatty sorry i did not realize what you are trying to do. i just thought you wanted an inverted serial driver to save a hardware inverter. but the esp-ir you are using is an ir-remote controller which operates with modulated ir light (38kHz). Thus the ir receiver is not just a photodiode but a receiver IC. it cannot operate with energy meters at all.

TheChatty commented 1 year ago

The receiving IC is a VS838. Thus it would need to be desoldered and replaced with a SFH309FA, for instance?

But still strange to me that using IRsend/IRrecv module from Tasmota I can exchange data between ESP-IR (VS838) and D0 head (SFH309FA).

gemu2015 commented 1 year ago

yes that would work. if you stay with inverted logic you should wire the photodiode so that the logic level is zero when no light is present.

TheChatty commented 1 year ago

I'd try to simply connect SFH309FA to the same pin where VS838 is connected at the moment. I assume it's directly hooked up to GPIO14 from ESP. Maybe no bit inversion is need for receiption.