I am trying to do livestream with my rasberry pi. So I am using the USB webcam inbuilt microphone. I can see in alsamixer, capture volume level getting high automatic when I start talk. So how can I fix the capture volume to a specific value.
I have tried "alsactl store" command but it is not working.
To set the capture volume, first check capture is active:
amixer set Capture cap
Then set capture volume (for example 100%):
amixer set Capture 100%
It returns something like:
alpereira7#rasp:~$ amixer set Capture cap
Simple mixer control 'Capture',0
Capabilities: cvolume cswitch
Capture channels: Front Left - Front Right
Limits: Capture 0 - 63
Front Left: Capture 39 [62%] [12.00dB] [on]
Front Right: Capture 39 [62%] [12.00dB] [on]
alpereira7#rasp:~$ amixer set Capture 100%
Simple mixer control 'Capture',0
Capabilities: cvolume cswitch
Capture channels: Front Left - Front Right
Limits: Capture 0 - 63
Front Left: Capture 63 [100%] [30.00dB] [on]
Front Right: Capture 63 [100%] [30.00dB] [on]
Related
I wrote some code to activate a video when a motion sensor detects movement.
So far everything works while everything is wired to the breadboard.
When I connect my motion sensor to the Pi itself, it keeps triggering itself even when there is no motion.
Any idea what could be wrong?
The sensor is connected to GPIO4. When I wire the cables directly on the Raspberry on the corresponding pins the trouble starts.
Do I have to change something in my code when directly wiring to the Pi?
Thanks in advance for any kind of help.
Below my code and a picture of my breadboard setup and the setup when it's wired diretly to the Pi.
Also my config text is included below:
from gpiozero import MotionSensor, LED, Button
from time import sleep
import vlc
playing = set([1,2,3,4])
# creating Instance class object
vlc_instance = vlc.Instance()
player = vlc_instance.media_player_new()
player.set_fullscreen(True)
#Motion Sensor
pir = MotionSensor(4)
#Led
led = LED(26)
#Button
button= Button(18)
led.off()
print("Sensor wordt geladen.")
pir.wait_for_no_motion()
sleep(5)
while True:
print("Ready")
pir.wait_for_motion()
sleep(1)
print("Motion detected")
led.on()
sleep(1)
led.off()
player.set_mrl("/media/pi/GROT/MOSA25.mp4")
player.play()
sleep(120)
while player.get_state() in playing:
sleep(1)
continue
print("Finished")
sleep(600)
continue
# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16
# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720
# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
# Automatically load overlays for detected cameras
camera_auto_detect=1
# Automatically load overlays for detected DSI displays
display_auto_detect=1
# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2
# Disable compensation for displays with overscan
disable_overscan=0
[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1
[all]
[pi4]
# Run as fast as firmware / board allows
arm_boost=1
[all]
gpu_mem=156
I'm just creating an app(kivy) for a raspberry pi(3b) with 7 inch touchdisplay. In addition I implemented a light sensor (TSL2591), which can regulate the brightness of the backlight using following command:
os.system('sudo sh -c "echo '+str(brightness)+' > /sys/class/backlight/rpi_backlight/brightness"')
with values of brightness 0 to 255
Works fine so far, but I do update the brightness once a second. If I'm not wrong, the command overwrites a config file and I mind of write access to the SD Card that often. I think the SD card will be corrupt after a short period of time.
For sure I can try to get less write operations, but it also leads to less smoothness:
update slower than 1 sec
only write if brightness value really changes
don't use all of the 255 steps
So the main question is: is there any other way to control the brightness? Or any workaround? I could not find a "real" Datasheet or any other advice on the internet. So maybe there is another way.
That's not a conventional disk file; it's a "device special file" which the kernel artificially creates to look like a disk file. It allows you to "talk" to device drivers using standard read() and write() calls.
You need not worry about SD card wear.
Flashing a coral dev board per the getting started guide results in the the error Wrong image format for "source" command. This error is what is displayed in the serial console when the SD card is inserted in the board and the board is powered up - full output below. I didn't find any documentation for this problem so I am posting it here in case anyone else has this issue.
U-Boot SPL 2019.04.1 (Apr 29 2020 - 18:40:05 +0000)
power_bd71837_init
Board id: 2
DDRINFO: start DRAM init
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
Normal Boot
Trying to boot from MMC2
hdr read sector 300, count=1
U-Boot 2019.04.1 (Apr 29 2020 - 18:40:05 +0000), Build: jenkins-enterprise.uboot-imx-1
CPU: Freescale i.MX8MQ rev2.0 1500 MHz (running at 1000 MHz)
CPU: Commercial temperature grade (0C to 95C) at 33C
Reset cause: POR
Model: Freescale i.MX8MQ Phanbell
DRAM: 1 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
BuildInfo:
- ATF
- U-Boot 2019.04.1
flash target is MMC:0
Net:
Error: ethernet#30be0000 address not set.
Error: ethernet#30be0000 address not set.
eth-1: ethernet#30be0000
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot: 0
** No partition table - mmc 1 **
## Executing script at 40480000
Wrong image format for "source" command
## Starting auxiliary core at 0x00000000 ...
u-boot=>
This error results from a bad SD card, or perhaps one that has already been used (formatted) for other uses. I was able to bypass this error and successfully install the OS by burning the image per the the getting started guide on a brand new SD card (I used a Samsung 128GB Pro Endurance card). I used balenaEtcher on a mac, which burns the image in just a few minutes.
For work I've had to provision dozens of these and they are super finicky about sd cards. I've bought 4 brand new completely identical (same brand, size, etc.) sd cards and burn them all identically. 1 will work on one board but not another, another will work in the 2nd but not the first, etc. So the only advice I have is "keep trying".
Thanks for the answers from Oliver and j2abro. I just dug the Coral Dev Board out of my project drawer and started trying to get it running.
First of all, make sure you read the directions and set the DIP switches properly (this dip, me, didn't do that, at first). I finally got it to work, but Oliver's answer seems to match my experience (Dev Board is finicky about SD Cards). Here's the cards used and result. All flashed with BalenaEtcher on a MacBook Pro (M1 2020, Monterrey 12.6):
SanDisk UltraPlus 256GB (multiple FAILS: didn't set DIPs correctly. derp!)
SanDisk UltraPlus 32GB #1 (FAILED with DIPs correctly set: same result as OP)
SanDisk UltraPlus 32GB #2 (FAILED with DIPs correctly set: same result as OP)
SanDisk UltraPlus 256GB (SUCCESS: set DIPs correctly) same card as #1
All these cards were brand new, right out of the retail packaging; nothing else was written to them before the Coral Dev Board image.
Theory: I tried the 32GB cards thinking that this board might have a problem with exFAT (above 32GB) storage formatting, similar to the Raspberry Pi boot limitation. However, given my and j2abro's success with larger SD Cards, I'd recommend trying a larger SD Card (more than 32GB) rather than the typical 32GB or less you'd use for a Pi. Seems like the Dev Board likes exFAT formatting better?
Tip: I strongly recommend connecting to the board using the Serial Console while setting up the board (link below), otherwise you'll be doing a lot of guessing as to what's going on with the setup and waste your time:
https://coral.ai/docs/dev-board/serial-console/
Here's what I saw (finally) in the Serial Console after the second reboot after a successful flash with the 256GB card:
...
[ 8.788556] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
Mendel GNU/Linux (eagle) lime-jet ttymxc0
lime-jet login:
Hope this helps you get to a successful setup.
I have a Raspberry pi 3 with the 7" dsi touch screen. I'm loading an empty bundle factory image of Android Things 0.5.1 and I'm having two possibly related issues.
Firstly, the boot animation is incredibly slow. Something in the neighborhood of 2 frames a second.
Secondly, once it boots up to the dev preview connection screen the font is larger than it should be. When I load my app onto the device it is clear that there is something wrong with the resolution or pixel density.
I have tried this on versions 0.5.1 and 0.5.0 and get the same results on both.
Here is my config.txt file
kernel=u-boot-dtok.bin
framebuffer_depth=16
# Prevent the firmware from loading HAT overlays now that we handle pin muxing.
# ourselves. See:
# https://www.raspberrypi.org/documentation/configuration/device-tree.md#part3.4
dtoverlay=
dtparam=i2c_arm=on
dtparam=spi=on
dtparam=audio=on
# pwm and I2S are mutually-exclusive since they share hardware clocks.
dtoverlay=pwm-2chan-with-clk,pin=18,func=2,pin2=13,func2=4
dtoverlay=generic-i2s
start_x=1
# Tell U-boot to always use the "serial0" interface for the console, which is
# set to whichever uart (uart0 or uart1) is set to the header pins. This doesn't
# interfere with the uart selected for Bluetooth.
dtoverlay=chosen-serial0
# Enable skip-init on the UART interfaces, so U-Boot doesn't attempt to
# re-initialize them.
dtoverlay=rpi-uart-skip-init
# Add pin devices to the system for use by the runtime pin configuration driver.
dtoverlay=runtimepinconfig
dtoverlay=uart1
dtoverlay=bcm2710-rpi-3-b-spi0-pin-reorder
# Tell the I2S driver to use the cprman clock.
dtoverlay=bcm2710-rpi-3-b-i2s-use-cprman
# Uncomment to disable serial port on headers, use GPIO14 and GPIO15
# as gpios and to allow the core_freq to change at runtime.
enable_uart=1
core_freq=400
# Enable hardware graphics acceleration.
dtoverlay=vc4-kms-v3d,cma-256
mask_gpu_interrupt0=0x400
avoid_warnings=2
# Support official RPi display.
dtoverlay=i2c-rtc,ds3231
dtoverlay=rpi-ft5406
hdmi_force_hotplug=1
hdmi_drive=2
When I downgrade to 0.4.1 this issues goes away and I get a speedy animation and the screen resolution goes back to normal.
Here is the config.txt for 0.4.1
kernel=u-boot-dtok.bin
framebuffer_depth=16
dtparam=i2c_arm=on
dtparam=spi=on
dtparam=audio=on
# pwm and I2S are mutually-exclusive since they share hardware clocks. To
# enable I2S comment out the pwm line and uncomment the generic-i2s line.
dtoverlay=pwm-2chan-with-clk,pin=18,func=2,pin2=13,func2=4
# dtoverlay=generic-i2s
start_x=1
# Tell U-boot to always use the "serial0" interface for the console, which is
# set to whichever uart (uart0 or uart1) is set to the header pins. This doesn't
# interfere with the uart selected for Bluetooth.
dtoverlay=chosen-serial0
# Enable skip-init on the UART interfaces, so U-Boot doesn't attempt to
# re-initialize them.
dtoverlay=rpi-uart-skip-init
# Uncomment to disable serial port on headers, use GPIO14 and GPIO15
# as gpios and to allow the core_freq to change at runtime.
enable_uart=1
core_freq=400
I have tried applying the fix found in this question but it did not make a difference.
Thanks for the help.
I have the same issue with the screen density with 7" Waveshare 1024x600 display. Display's density isn't identified correctly for some reason. It may be the display's manufacturer issue though.
You can see display reported values with ADB command:
adb shell dumpsys display | grep DisplayInfo
My display reported 240dpi, though the correct value is 160dpi.
Anyway, I've managed to set the correct density through ADB:
adb shell wm density <correct_density_value>
Good news is that you only need to set it once per image.
I'm trying to configure a RaspberryPi2 to record video data from the camera module to a rosbag. To get the camera working with ROS, I used code I found here: https://github.com/fpasteau/raspicam_node.
This works fine, but I have a problem capturing the data to a rosbag. When capturing in raw mode at a high frame rate, it captures smoothly for a few seconds, then freezes for a few seconds, then captures smoothly for a few seconds, then freezes, ...
For instance, I tried capturing a file with 640x480#30FPS and this is what rosbag info yields:
duration: 2:51s (171s)
size: 2.9 GB
messages: 5049
compression: none [2504/2504 chunks]
types: rosgraph_msgs/Log [acffd30cd6b6de30f120938c17c593fb]
sensor_msgs/CameraInfo [c9a58c1b0b154e0e6da7578cb991d214]
sensor_msgs/Image [060021388200f6f0f447d0fcd9c64743]
topics: /camera/camera_info 2505 msgs : sensor_msgs/CameraInfo
/camera/image 2504 msgs : sensor_msgs/Image
/rosout 22 msgs : rosgraph_msgs/Log (2 connections)
/rosout_agg 18 msgs : rosgraph_msgs/Log
So if we have 171 seconds of video, at 90FPS, that should give 15390 messages, we only got 2504, which is about 14FPS. The file itself is 2.9GB in size. This means it had an average writing speed of ~17.5MB/s. Eventually I found a command to test the write speed of the SD card (dd if=/dev/zero of=~/test.tmp bs=500K count=1024), which says my writing speed is about ~19MB/s on average.
So my questions are:
If the SD writing speed is causing the problem, how come the RaspberryPi can't utilise the full 90MB/s?
Can I tune the RaspberryPi to write quicker to the SD card?
I thought about getting a BananaPi, which comes with SATA, so I could connect a SATA drive and shouldn't run into any write speed issues. Before making that investment, does anyone have experience with BananaPis? I saw a test here: http://314256.blogspot.co.uk/2014/11/banana-pi-sata-disk-throughput-test.html, which looks like the BananaPi should be able to handle it.
Any other ideas how to make it work on the RaspberryPi?
It looks like the raspicam_node publishes images with bgra8 encoding (raspicam_raw_node.cpp#L266), so we need to store 4*640*480*30 Bytes/second = 36.86 MB/s.
However ~18 MB/s seems to be pretty much the limit on a Raspberry 2 (microSD card performance comparison).
Instead of trying to save all the raw data, have rosbag store the sensor_msgs/CompressedImage from the /camera/image/compressed topic. You can tune the <base_topic>/compressed/jpeg_quality parameter (see compressed_image_transport's dynamic reconfigure parameters), but with the default of 80 you should get around 30:1 compression ratio, i.e. 1.23 MB/s.
The Raspberry should be able to handle this easily. Given the image quality of the tiny Raspberry camera, you will probably not even perceive any difference in quality.