I need to read the IR from a TV remote. I have a grove pi board now. Wondering how I can add IR capability. I have seen IR shields for PI but not clear how to integrate with my grove pi board.
We have an example on the Github repo for this: https://github.com/DexterInd/GrovePi/tree/master/Software/Python/grove_ir_receiver for this sensor: http://www.seeedstudio.com/depot/Grove-Infrared-Receiver-p-994.html.
This pretty much works out of the box for the Keyes Remote(http://yourduino.com/sunshop2/images/products/large_369_KeyesRobotRemote1.jpg).
If you are using some other remote then you’ll have to set it up manually by follwing step 8 here: http://www.instructables.com/id/How-To-Useemulate-remotes-with-Arduino-and-Raspber/?ALLSTEPS. These might be useful too: http://alexba.in/blog/2013/01/06/setting-up-lirc-on-the-raspberrypi/ and http://www.etcwiki.org/wiki/LIRC_-_Raspberry_Pi .
How this works is that we use the RPISER port on the raspberry pi to connect the IR receiver pin directly to the Serial pin on the Raspberry Pi (The pin might be TX or RX depending on the version of the IR receiver). Then we use LIRC to read to signals from the remote and a python library to interpret them.
IR on GrovePi + RaspberryPi [Python]
Do these same instructions work for the GoPiGo? In other words, do I connect my IR sensor to the serial port on the GoPiGo board and then use the Python library to receive the IR signals? I understand that this port uses the UART pins on the RasPi (GPIO 14 and GPIO 15), right?
I think you would be better if you use this library from here. This one has been revised not long ago. You can use it to control the GrovePi just fine:
Thanks for your response, Robert. This was very helpful.
I now have lirc installed on my GoPiGo and can receive key presses using the standard command line approaches. The main issue I have now is that I would like to use my own IR remote rather than purchase a Keyes remote. Specifically, I get no response when I run the Python programs located here:
Is it not possible to configure the system to work with my own remote?
With respect to where I am now, despite the fact that I cannot run the sample Python programs, I can in fact get response when I stop the lirc daemon on the GoPiGo using:
sudo /etc/init.d/lircd stop
Then, when I press keys on my remote using mode2, I DO get responses using the command mode2 like this:
sudo mode2 -d /dev/lirc0
I of course get the same sort of responses there that I get running the program, ir_debug_logger.py. (I just noticed that this program uses mode2! )
I can also restart the lirc daemon using this:
sudo /etc/init.d/lircd start
Then, when I use
the values of the keys on my remote are displayed on my terminal. This of course required that I first install my remote on the lirc system by storing the key values in lircd.conf.
So, in looking at your code, it seems that your system imports ir_receiver, which I assumed uses the data for the Keyes remote from somewhere. I found raw IR data in the Python file, di_ir_reader.py. I also found the line the comment “Drivers and examples for using the ir_receiver in Python with the GoPiGo without LIRC” in the setup.py software for the server.
Does all this mean that I will have to get the raw data for my remote and put it in in di_ir_reader.py?
Many thanks for your help!
Okay, I went with the assumption that I needed to substitute the remote I would like to use for the raw IR data in di_ir_reader.py. I did the substitution, which code you can see in the file I have uploaded here: NemoRawCodes.py (12.3 KB) I copied that file to the server directory and renamed it to di_ir_reader.py before running sudo bash install.sh again.
Here is the error that I get when I start the ir-server.service and check the status:
>pi@dex:~ $ sudo systemctl start ir-server.service >pi@dex:~ $ sudo systemctl status ir-server.service >● ir-server.service - IR Server App > Loaded: loaded (/etc/systemd/system/ir-server.service; enabled) > Active: activating (auto-restart) (Result: exit-code) since Thu 2019-02-07 18:47:10 UTC; 1s ago > Process: 1508 ExecStart=/usr/bin/python /home/pi/Dexter/GoPiGo/Software/Python/ir_remote_control/server/di_ir_reader.py (code=exited, status=1/FAILURE) > Main PID: 1508 (code=exited, status=1/FAILURE)
Can you try and see the logs of the service? Do a
sudo journalctl -u ir-server.service and see what went wrong in there.
[quote=“RobertLucian, post:7, topic:1039”]
sudo journalctl -u ir-server.service
Okay, this technology stuff continues to do what I tell it to do rather than what I want it to do! Checking the log, I found a simple syntax error in the Key_Map (commas missing at the end of the lines…) I corrected those errors, and here is the latest report:
pi@dex:~ $ sudo systemctl status ir-server.service ● ir-server.service - IR Server App Loaded: loaded (/etc/systemd/system/ir-server.service; enabled) Active: active (running) since Tue 2019-02-12 18:10:12 UTC; 10s ago Main PID: 2534 (python) CGroup: /system.slice/ir-server.service ├─2534 /usr/bin/python /home/pi/Dexter/GoPiGo/Software/Python/ir_remote_control/server/di_ir_reader.py ├─2552 /bin/sh -c mode2 -d /dev/lirc0 └─2553 mode2 -d /dev/lirc0 Feb 12 18:10:12 dex systemd: Started IR Server App. Feb 12 18:10:12 dex sudo: root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/etc/init.d/lirc stop Feb 12 18:10:12 dex sudo: pam_unix(sudo:session): session opened for user root by (uid=0) Feb 12 18:10:12 dex python: Stopping lirc (via systemctl): lirc.service. Feb 12 18:10:12 dex sudo: pam_unix(sudo:session): session closed for user root pi@dex:~ $
I will try more this afternoon.
Thanks for your help!
That’s great news, I think. Can you also show me in the source code where that syntax issue is? I can’t seem to be able to find that missing comma in the code.
I had forgotten to add the commas at the end of each line in the key_map data:
I have started to test out the changes running the Python example code provided, but so far without success.
I ran install.sh again with the results that I posted previously. I get pulse and space data on my terminal when I run this:
sudo systemctl stop ir-server.service sudo /etc/init.d/lirc stop sudo mode2 -d /dev/lirc0
Here is the version of di_ir_reader.py that has my raw IR data:
di_ir_reader.py (12.3 KB)
In studying the Dexter code a little more, I have found this comment:
The ir signals are 65 bytes long
After looking at the raw data from the remote I am using (obtained using irscrutinizer) as well as studying the Dexter code a bit more, I can see that header data is being stripped out. My first reaction was that none of the signals on my remote are exactly 65 bytes. Subtracting the header data, however, I arrived at 65 bytes! I can also see how the values for 1 and 0 relate to the Keyes codes. I am going to try stripping out the header codes from the actual data.
Although I am thinking it was a good idea for me to order a Keyes remote, which should arrive in the next couple of days, I guess I am willing to keep trying a bit longer to get the Dexter code to work with my remote.
Well, I tried a bit more and am now able to successfully receive a code from my remote and use that data to control the GoPiGo! Things are working reasonably well. The main problem I am having now is that data (noise?) seems to creep even when no button is pressed on the remote.
The more significant issue is that the remote I am using sends some signals in two parts as you can see from the wave forms I am including below. IR data structured this way seems to make the signals incompatible with the
di_ir_reader.py which is not able to recognize the data .
So you can perhaps see what is going on, here are the two chunks of raw data for one that works fine (KEY_UP) and one that does not (KEY_OK).
begin raw_codes name IrScrutinizer_captured_signal for UP 8967 4470 552 552 552 1683 552 552 552 552 552 1683 552 1683 552 552 552 552 552 1683 552 552 552 1683 552 1683 552 552 552 552 552 1683 552 1683 552 1683 552 552 552 552 552 552 552 1683 552 552 552 552 552 552 552 552 552 1683 552 1683 552 1683 552 552 552 1683 552 1683 552 1683 552 end raw_codes
Here is one that does not work:
begin raw_codes name IrScrutinizer_captured_signal for OK 8967 4470 552 552 552 1683 552 552 552 552 552 1683 552 1683 552 552 552 552 552 1683 552 552 552 1683 552 1683 552 552 552 552 552 1683 552 1683 552 1683 552 1683 552 1683 552 1683 552 552 552 552 552 552 552 552 552 552 552 552 552 552 552 552 552 1683 552 1683 552 1683 552 1683 552 39864 8967 2235 552 end raw_codes
I am also including below screen shots of the two wave forms, one that works fine (KEY_UP) and one that does not (KEY_OK).
This one works just fine. You can see that the protocol it uses is NEC2, which seems to be more compatible with the Keyes data that was already present in your program:
This one does not work. You can see that the protocol it uses is NEC1:
The main problem I am having now is that data (noise?) seems to creep even when no button is pressed on the remote.
Can you show us how that stream would look like? This is so I can compare it to what I’ve already experienced. I’m mainly interested in seeing how often the noise creeps in.
Also, I wonder which remote you’ve got. The “old remote” we used for coding this program, is not perfectly compatible with what was released last year (more specifically, during the last summer). And apparently, there’s no easy way to separate one from another other than by testing it on the GrovePi. Released is a big word - I might actually have to say “changed suppliers”.
The remote I was using (the one for which I sent you the codes for comparison) is the remote from the Optima projector in our home theater. I just receivedthis remote from Amazon. As you can see from the photo, it is labeled “Keyes.” The one I received has the arrow keys on the bottom and the number keys at the top. I paid $5.58 via Amazon Prime.
Here is a match for the one I have that I found from AliExpress in China (They are selling it 0.82 with the 29 day shipping time from China! Shipping is .11, which is about right for a slow boat from China. Given the margin, how about that for a great markup!?!
Anyway, running it with Dexter’s
di_ir_reader.py, I can see that the codes are different. For example, are are the results from key presses (The results BTW, are not always consistent…):
|1, 2, or 3||KEY_UP|
|7, 8 and 9||KEY_DOWN|
Looking with irscrutinizer at the signals transmitted. I can see where some codes are recognized as NEC and some as NEC1. Some signals will come up as NEC with one press and with NEC1 with another press.