I'm trying to use Linux Infrared Remote Control LIRC library to record a custom signal from remote control and save it in a file. Then I will use these signals to send it back again through ir tx using raspberry pi
when I run test ir rx mode2 -d /dev/lirc1 the output seems good .
Using driver default on device /dev/lirc1
Trying device: /dev/lirc1
Using device: /dev/lirc1
space 16777215
pulse 9044
space 4463
pulse 601
space 1641
pulse 628
space 532
pulse 575
space 558
pulse 577
space 530
pulse 603
But when I open the /etc/lirc/lircd.conf file, this happens:
# Type of device controlled
# (TV, VCR, Audio, DVD, Satellite, Cable, HTPC, ...) :
# Device(s) controlled by this remote:
begin remote
name fan
bits 0
flags CONST_LENGTH
eps 0
aeps 0
one 0 0
zero 0 0
gap 50000
toggle_bit_mask 0x0
frequency 38000
begin codes
KEY_POWER 0x0
KEY_0 0x0
KEY_1 0x0
end codes
end remote
All saved keys are zeroes, so how do I solve this problem?
Your LIRC driver is configured and seems ok from this side. However it is worth double checking the driver has been set up correctly as I think this is the problem.
Assuming you are using T95m/T95N remote:
0x140 KEY_POWER
0x155 KEY_POWER
0x101 KEY_0
0x14e KEY_1
Try editing your etc/lirc/lircd.conf with the above values running it(blast some IR commands) and seeing if it turns the values back to 0x0 after.
I would suggest that you declare the transmitter GPIO pin first then the receiver
like this :
dtoverlay=gpio-ir-tx,gpio_pin=17
dtoverlay=gpio-ir,gpio_pin=18
and i would double check /etc/lirc/lirc_options.conf as TeeJay suggested
this fixed my problem on raspberrypi 3+
Related
I'm trying to add a new the gpio controller driver in u-boot. I've actually added and enabled the driver but it needs a small fix and I'm not able to figure out how to handle this. I'm somewhat new to the u-boot and gpio frameworks.
My problem is, there are two gpio controllers i.e My dts file looks like the below
gpio1:gpio#505050505 {
/* this bank has hw pins 0 - 29 */
ngpio = 30;
};
gpio0:gpio#a0a0a0a0 {
/* this bank has hw pins 0 - 19*/
ngpio = 20;
};
In the driver probe function, i see that gpio1 is probed first and then the gpio0 is probed. Due to this probe(dt parsing) order, the pin mapping created is as shown below
pin 0 - 29 mapped to gpio1 hw pins 0 - 29 and
Pin 30 - 49 mapped to gpio0 hw pins 0 - 19
but my requirement is to have it reversed, i.e
pin 0 - 19 mapped to gpio0 hw pins 0 - 19 and
pin 20 - 49 mapped to gpio1 hw pins 0 - 29
and i can't change the dt node entry order(req from client).
I've already looked into aliases section where the bus nos. are assigned. I wanted to know if there is any field in dt node which determines the order or anything in uboot gpio framework which can determine the pin mapping.
I am using a Raspberry Pi (linux kernel 4.4) and "libusb" to read the steering angle of a Logitech G29 HID Device (PS3 mode). I get only one byte of data for the angle and that is far to little for the steering range of +-450° deg. The HID Device Descriptor shows the problem.
Item(Global): Physical Maximum, data= [ 0xff 0x00 ] 255
How could I change the Physical Maximum to 65535?
Why do you think that a number from 0 to 255 cannot be used to represent angles between -450 and +450? Isn't it possible that a value of 0 corresponds to -450 degrees and a value of 255 corresponds to 455 degrees? It's very unlikely that Logitech made a fatal design flaw in the HID interface of their device.
If you really want to change the HID interface, then, at a minimum, you would have to reprogram the firmware of your G29 device in order to change that descriptor and change the HID report it describes. It is very likely that the device is closed source and that there are no instructions for reprogramming the firmware, so you are probably out of luck. Adding more resolution to that measurement might also require hardware changes, which could be difficult.
I followed a tutorial to illuminate an LED on a Raspberry Pi so that when an iBeacon detected an LED is turned on using the GPIO pins but I need to alter the script so that the LED goes off again when the iBeacon is no longer detected.
The script at the moment is:
#!/bin/bash
gpio mode 1 out
trap "gpio write 1 0" exit
while read line
do
if [[ `echo $line | grep "2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 1 1" ` ]]; then
gpio write 1 1
fi
done
Which is being called by:
$ beacon scan -b | ./scriptName
The out put of beacon scan is:
pi#pibeacon ~ $ sudo beacon scan
BLE Beacon Scan ...
iBeacon UUID: 92AB49BE-4127-42F4-B532-90FAF1E26491 MAJOR: 1 MINOR: 1 POWER: -59 RSSI: -62
iBeacon UUID: 92AB49BE-4127-42F4-B532-90FAF1E26491 MAJOR: 1 MINOR: 1 POWER: -59 RSSI: -65
iBeacon UUID: 92AB49BE-4127-42F4-B532-90FAF1E26491 MAJOR: 1 MINOR: 1 POWER: -59 RSSI: -65
Continuously updating all the time the iBeacon is detected and just stops when the iBeacon is undetected.
The aim is to have a script run all the time and use the output of the beacon scan command to determine if the LED should be on or off - if the iBeacon is detected the LED should be on and if the iBeacon is then moved out of range the LED turn off again. The existing strip turns the LED on once and then the only way to reset the situation is to stop the script and start it again.
Thanks
One way you could accomplish it with your existing code is to set a variable to a timestamp inside your if statement. Then, outside your if statement (but inside the while), you can compare the current time to the timestamp. If enough time has passed since the beacon was detected (say 5 seconds), you code can turn off the LED.
The disadvantage of this approach is that if no beacons are detected at all, your code will block on the read line statement. So this is only workable if you know for sure at least one beacon will always be around to keep your program running. This sort of programming is not ideally suited to a simple bash script, because you really need two threads to handle this. But if you want to keep your same basic toolset, this is a decent option.
I worked out a (bad?) solution and thought I'd share it here. It has the effect of when the beacon is detected the light flashes and then when the beacon goes out of range the light stops flashing. I set this code to run on startup of the Pi and has fulfilled the function I needed (a very rough proof of concept prototype!).
I used the very good Radius Networks Development Kit (which is where the original script is from) and would highly recommend that if anyone else is interested in messing about with iBeacons.
#!/bin/bash
gpio mode 1 out
trap "gpio write 1 0" exit
while read line
do
if [[ $line = *"2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 1 1"* ]]; then
gpio write 1 1
fi
gpio write 1 0
done
I'm new to embedded devices and am trying to understand how to use i2cget (or the entire I2C protocol really).
I'm using an accelerometer MMA8452, and the datasheet says the Slave Address is 0x1D (if my SAO=1, which I believe is referring to the I2C bus being on channel 1 on my raspberrypi v2).
From the command line, I enter
sudo i2cget -y 1 0X1d
It returns
0X00
I think that means I'm attached to the correct device.
So now, I'm trying to figure out how do I get actual data back from the accelerometer?
The i2c spec says
i2cget [-y] i2cbus chip-address [data-address [mode]]
So I have tried
sudo i2cget -y 1 0x1D 0x01
where 0x01 is the OUT_X_MSB. I'm not sure entirely what I'm expecting to get back, but I figured if I saw some data other than 0x00, I might be able to figure that out.
Am I using ic2get wrong? Is there a better way to learn and get data from i2c?
The datasheet for my accelerometer chip is at
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Accelerometers/MMA8452Q.pdf
I am way too late but this might help other people. You might be getting the 0x00 output every time you use i2cget is because you might have forgotten to set some mode. For instance, I was working on pcf8583 which is a clock and calendar chip and can also be use as a counter.
My goal was to use this chip as a counter. It was connected to i2cbus1 with device address 0x51. So reading the data sheet, I found out that, the chip would work as a counter when the mode is set to 0x20 in the control register 0x00. The command I used for doing this:
i2cset 1 0x51 0x00 0x20
Now, I could read the counter pulses from a wind sensor with the command:
watch i2cget -y 1 0x51
watch is just a linux command that runs the specified command (i2cget) repeatedly every 2 seconds and displays the results on standard output.
From the datasheet its clear that the default value of Status Register Address 0x00 is 0x00, so you are doing fine I guess. See Table 11 Register Map Address in the datasheet.
You may try reading the device ID at Register Address 0x0D. You should get value 0x2A when you read this register(0x0D).
I am using beaglebone to access digital input from specific pin using sysfs interface. And I can change the output states but not the input :(. What I did is, I have two pins pinA and pinB. pinA I made it output and pinB I made input. Connected pinA to pinB. Configured pinA as output pin by sending out to direction attribute in sysfs and pinB as input by passing in. And I changed value of PinA to 1 and it is giving 1 as output (I tested using LED). But when I read the value of PinB it is giving 0 only, even I pass 0 to value of pinA. what may be the reason ?
Thank you :)
As I understood, the steps you followed:
echo 7 > /sys/kernel/debug/omap_mux/gpmc_ad6
echo 38 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio38/direction
cat /sys/class/gpio/gpio38/value
I also did the same mistake and it took me hours, but the answer was simple: The first line starting with "echo 7" is the problem. Look at the muxing bits:
Bit 5: 1 - Input, 0 - Output
Bit 4: 1 - Pull up, 0 - Pull down
Bit 3: 1 - Pull disabled, 0 - Pull enabled
Bit 2 \
Bit 1 |- Mode
Bit 0 /
You were entering echo 7 which is --> 0 0 0111 and it means: bit 0,1 and 2 is 1, so the mode is set. No problem. However you just forgot to set whether it's an input or output. And it should be like this:
echo 0x27 > /sys/kernel/debug/omap_mux/gpmc_ad6
your bits are now: 1 0 0111 binary which is 0x27 (hex).
When you write "cat /sys/class/gpio/gpio38/value" while giving input, you can see a wonderful 1 :) I’m sure you will be very happy as much as I was :)
Also, one more thing, you are right for Analog input about 1.8V, but GPIO operates with 3.3v.
Several possible causes:
1) Did you set the IO direction of the input pin?
eg. echo "in" > /sys/class/gpio/gpioN/direction
2) (less likely) Is the GPIO pin you're using as an input multiplexed as a GPIO line and in the right direction? Most of the GPIO pins on the OMAP SoCs are multi-function. You're kernel might have set it for an alternate function.
You can check it with:
cat /sys/kernel/debug/omap_mux/board/core
Which dumps the configurations of all IO pins. The output looks like this:
OMAP4_MUX(CSI22_DY1, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
/* gpio_81 */
OMAP4_MUX(CAM_SHUTTER, OMAP_PIN_OUTPUT | OMAP_MUX_MODE3),
OMAP4_MUX(CAM_STROBE, OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
/* gpio_83 */
In this case, CAM_SHUTTER is set an output, and routed as to the GPIO module (OMAP_MUX_MODE3)
[Caveat: this is from my OMAP4 board - without having the OMAP3 data sheet to hand - there will be a fair amount of similarity]
You can't change this through sysfs - instead you'll need to modify either your kernel (or possibly boot-loader if the kernel uses the configuration it set up).
In the board-file for your system - which I think in your case will be in <linux_source_root>/arch/arm/mach-omap2/board-omap3beagle.c - you'll find a initialiser for the MUX table. You will need the board's schematics, the kernel source tree and the SoC data sheet to get between the primary function name of the pin (in my example above CAM_SHUTTER) and a GPIO number.
3) I was a bit confused by even I pass 0 to value of pinA - I wonder whether you meant that? This does however point to another thing to watch for - there is the programmable pull-up or -down on each IO pin. These are set with the MUX settings. There may conceivably be an external one as well - again you'll need the schematics to be sure.
Yes. The internal pull up and down is configured in the same register as the mux-mode - so it might be that you can configure this in the same way you're setting the mux-mode. Get the AM335x TRM (for OMAP4 the chapter is called Control Module).
In terns of the kernel, look in <linux_source_root>/arch/arm/mach-omap2/mux.h where a bunch of macros are defined
As an example for use I have in my board file:
/* PIC -> OMAP4 interrupt line 2 - GPIO81 */
OMAP4_MUX(CAM_SHUTTER, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
and
OMAP4_MUX(GPMC_AD11, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
From memory you get a choice of either a pull-up or pull-down but can't select neither.