Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IR module (Infrared) #3094

Open
wants to merge 72 commits into
base: dev
Choose a base branch
from
Open

IR module (Infrared) #3094

wants to merge 72 commits into from

Conversation

ecrips
Copy link
Contributor

@ecrips ecrips commented May 8, 2020

  • This PR is for the dev branch rather than for master.
  • This PR is compliant with the other contributing guidelines as well (if not, please describe why).
  • I have thoroughly tested my contribution.
  • The code changes are reflected in the documentation at docs/*.

This adds a new module (with documentation) which can receive IR pulses from a suitably connected sensor (such as a TSOP382xx). It also can decode RC-5 codes.

TerryE and others added 30 commits July 23, 2019 19:16
Lua 5.1 to 5.3 realignement phase 1
The internal implementation already preferentially forwards to the
encoder module, so we should just remove these functions as they confuse
people into thinking that we don't have their inverses (see the feature
request nodemcu#2907).

Update the docs to refer to the encoder version and add deprecation
warnings to the runtime implementations.
* clean effects library
* Fix several issues in ws2812 and effects
* Implement working way of calling shift from callback
* Remove app/include/netif/wlan_lwip_if.h

This file appears to be unused in our tree.

* New `net.if.info` call to show LwIP information

This is a generalization of `wifi.sta`'s and `wifi.ap`'s `getip` and
`getmac` calls.  I don't propose to deprecate those, but perhaps we
should, in the documentation, point users at this function instead.

The direct motivation is to permit continued use of DHCP-provided NTP
servers in a future where
nodemcu#2819 has landed, now
that nodemcu#2709 is in the
tree.  But rather than exposing just that information, a more general
interface seems useful.
* Remove stale putative MD2 support

This hasn't worked in a while, presumably since one of our upstream
merges.  Don't bother making it work, since MD2 is generally considered
insecure.

* Land mbedtls 2.16.3-77-gf02988e57

* TLS: remove some dead code from espconn_mbedtls

There was some... frankly kind of scary buffer and data shuffling if
ESP8266_PLATFORM was defined.  Since we don't, in fact, define that
preprocessor symbol, just drop the code lest anyone (possibly future-me)
be scared.

* TLS: espconn_mbedtls: run through astyle

No functional changes

* TLS: espconn_mbedtls: put the file_params on the stack

There's no need to malloc a structure that's used only locally.

* TLS: Further minor tidying of mbedtls glue

What an absolute shitshow this is.  mbedtls should absolutely not
be mentioned inside sys/socket.h and app/mbedtls/app/lwIPSocket.c is not
so much glue as it as a complete copy of a random subset of lwIP; it
should go, but we aren't there yet.

Get rid of the mysterious "mbedlts_record" struct, which housed merely a
length of bytes sent solely for gating the "record sent" callback.

Remove spurious __attribute__((weak)) from symbols not otherwise
defined and rename them to emphasize that they are not actually part of
mbedtls proper.

* TLS: Rampage esp mbedtls glue and delete unused code

This at least makes the shitshow smaller

* TLS: lwip: fix some memp definitions

I presume these also need the new arguments

* TLS: Remove more non-NodeMCU code from our mbedtls

* TLS: drop support for 1.1

Depending on who you ask it's either EOL already or EOL soon, so
we may as well get rid of it now.
* Add missing globals from luacheck config

* Fix luacheck warnings in all lua files

* Re-enable luacheck in Travis

* Speed up Travis by using preinstalled LuaRocks

* Fix more luacheck warnings in httpserver lua module

* Fix DCC module and add appropriate definitions to luacheck config.

* Change inline comments from ignoring block to only ignore specific line

* Add Luacheck for Windows and enable it for both Windows and Linux

* Change luacheck exceptions and fix errors from 1st round of polishing

* Add retry and timeout params to wget
Also clean-up a nasty `ow` module example.
seregaxvm and others added 8 commits April 29, 2020 13:27
* fix build

* poor mans link which also works on docker under windows

* Delete espconn.h

* resurecting it as regular file

* Add missing newline

Co-authored-by: Marcel Stör <[email protected]>
@pjsg
Copy link
Member

pjsg commented May 8, 2020 via email

@ecrips ecrips changed the title IR module IR module (Infrared) May 11, 2020
@ecrips
Copy link
Contributor Author

ecrips commented May 11, 2020

Sorry, searching for TSOP38238 is probably best. The code should work with any of the sensors in that family, but the TSOP38238 is the common one. I've also noticed that it might be worth spelling out that IR=InfraRed - that's mentioned in the documentation but might not be obvious otherwise - I've updated the pull request title.

@pjsg
Copy link
Member

pjsg commented May 11, 2020 via email

@ecrips
Copy link
Contributor Author

ecrips commented May 13, 2020

I.e some like this ought to work: https://www.aliexpress.com/item/32975610831.html?

The IR receiver will probably work, but note that the remote uses the NEC protocol which I haven't written a decoder for (RC-5 is more common here).

I suspect that you ought to note that you need to pick an IR receiver module that matches the PCM frequency of the transmitter.... You could also include a link to 'Standard chinese sources: https://www.aliexpress.com/wholesale?SearchText=ir+receiver+module https://www.aliexpress.com/wholesale?SearchText=ir++receiver+module'

Yes, matching the frequency of the transmitter ensures a better signal. The TSOP38238 is available on the "standard Chinese sources": https://www.aliexpress.com/wholesale?SearchText=TSOP38238 and is what I've tested with. Other IR receiver modules are likely to work (almost all provide the same sort of signal), but I haven't tested so can't be sure.

app/modules/ir.c Outdated
uint8_t rawbuf_write;
uint8_t pin, pin_num;
uint8_t setup;
} data;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know I'm going to sound like a pest, but: is it possible to avoid globals like this and encapsulate everything needed within a Lua userdata? Could we even potentially allow for multiple IR rxers at once?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some global data is needed for the interrupt routine (so it can find the structure with the data in). But it would (in theory) be possible to move most of this into dynamically allocated data which would allow multiple IR receivers. I have to admit removing the need for the static rawbuf array would be a nice improvement (reduces RAM usage when not in use). I'll have a look at how difficult it would be to do.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ecrips Maybe it isn't the best suggestion, but you can have a look at softuart module where I was faced with similar problem. My solution is not ideal (as it cannot read more than one data frame simultaneously) but the method on implementing multiple receiving instances and selecting right one in ISR should be possible to apply in this code.

@tomsci
Copy link

tomsci commented May 17, 2020

Turns out I've been working on something similar, although for the esp32 so the code is conceptually similar but all the platform APIs are different. Do you think it's worth us trying to align the two, at least to the point of having the same Lua APIs in each? My attempt was more focussed on sending rather than receiving, so there's a chunk of code using the rmt logic block on the esp32 which I don't think the esp8266 has? Although using it for receiving I found to be more pain than it was worth, and I went with a simple GPIO ISR callback, like you.

uses the NEC protocol which I haven't written a decoder for (RC-5 is more common here).

Where I am it's the opposite, most things I have seem to use NEC or a variant thereof :) But there's sufficient variation I'd say it's not worth trying to include an NEC decoder in the C code. I ended up doing all the decoding Lua side to account for all the weirdnesses.

fwiw I haven't found an IR device yet that the TSOP38238 couldn't decode, the biggest pain for me has been working out what the high-level protocol is.

@tomsci tomsci mentioned this pull request May 17, 2020
4 tasks
@ecrips
Copy link
Contributor Author

ecrips commented May 19, 2020

Turns out I've been working on something similar, although for the esp32 so the code is conceptually similar but all the platform APIs are different. Do you think it's worth us trying to align the two, at least to the point of having the same Lua APIs in each? My attempt was more focussed on sending rather than receiving, so there's a chunk of code using the rmt logic block on the esp32 which I don't think the esp8266 has? Although using it for receiving I found to be more pain than it was worth, and I went with a simple GPIO ISR callback, like you.

It would make sense trying to align the interface if possible. The main difference I can see is you are using negative/positive values to encode high/low pulses whereas I used the bottom bit. Your approach is probably easier to handle in Lua.

uses the NEC protocol which I haven't written a decoder for (RC-5 is more common here).

Where I am it's the opposite, most things I have seem to use NEC or a variant thereof :) But there's sufficient variation I'd say it's not worth trying to include an NEC decoder in the C code. I ended up doing all the decoding Lua side to account for all the weirdnesses.

I initially tried doing all the IR decoding in Lua (i.e. used gpio.trig()) but couldn't get accurate timing, so moved all the code over to C. But having the Lua interface for decoding on Lua was actually very useful for debugging the C so I kept it knowing that it could be used for decoding other protocols in the future. NEC does seem to have more room for 'quirks' than RC-5.

fwiw I haven't found an IR device yet that the TSOP38238 couldn't decode, the biggest pain for me has been working out what the high-level protocol is.

Yes, the only issue I've had is sensitivity to noise. E.g. some pick up quite a bit of interference from CFL bulbs.

@marcelstoer
Copy link
Member

Pending:

  • rebase on dev
  • @tomsci and @ecrips to agree on an API to align ESP32 and ESP8266

@marcelstoer marcelstoer removed this from the Next release milestone Sep 1, 2020
@slorquet
Copy link

Hello

are there any plans to support IR signal transmission? for example to control a device, like an air conditioner... :p ?

thanks for any info

@tomsci
Copy link

tomsci commented Jul 4, 2021

are there any plans to support IR signal transmission

I ended up splitting my ir code into a separate external module here: https://github.com/tomsci/nodemcu-irpwm to avoid the problem that one-size-never-fits-all - my implementation was probably too specific to my requirements to suit anyone else out-of-the-box, the whole esp32 vs esp8266 API divergence doesn't seem to have gotten any better, we're all doing this in our spare time, etc.

That being said, you're welcome to look at my code for irpwm_send() in the above repo. However that only gets you the basics of sending IR pulses. To actually control a device you need to know its protocol and codes. I only have codes for a few specific devices I needed to support (and which I don't have any plans to publish), so I can't help you there. Not sure if ecrips's code might give you more help there or not. You may need to consult something like https://www.lirc.org/. There seem to be some promising links if you google "lirc nodemcu".

@stale
Copy link

stale bot commented Sep 21, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Sep 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.