There is a demo which comes with UV4L demo OS for Raspberry PI, https://raspberry:8080/stream/webrtc. When i run it on a macOS computer (Firefox browser), and select that a screen is to be shared, it always says 'no suitable video device found!' and apparently doesn't connect anywhere. Same happens when i go there on a Chromium browser on a Raspberry PI itself. There doesn't seem to be any error messages anywhere - some deprecation warnings but no more than that:
onopen() webrtc:197:25
navigator.mozGetUserMedia has been replaced by navigator.mediaDevices.getUserMedia webrtc:251:32
WebRTC interfaces with the “moz” prefix (mozRTCPeerConnection, mozRTCSessionDescription, mozRTCIceCandidate) have been deprecated. webrtc:105:25
{"iceServers":[{"urls":["stun:stun.l.google.com:19302","stun:192.168.0.101:3478"]}]} webrtc:104:21
onaddstream is deprecated! Use peerConnection.ontrack instead. webrtc:107
peer connection successfully created! webrtc:110:21
URL.createObjectURL(MediaStream) is deprecated and will be removed soon. webrtc:255:60
call(), request={"what":"call","options":{"force_hw_vcodec":false,"vformat":"60"}} webrtc:193:25
message =message webrtc:281:25
Where shall i look into?
Clarification: i can see my desktop in a 'local' box, so sharing has been successful, same on Raspberry PI. But it never goes to the other side, i can't even use the data channel - it is greyed out - so apparently no connection happens, at all.
The following command runs an instance of UV4L that allows to mirror your desktop or window to the Raspberry Pi HDMI display. Note that you must pass the SSL certificates .key and .crt (see the UV4L installation instructions to know how to generate them):
uv4l --enable-server --driver dummy --server-option '--use-ssl=yes' --server-option '--ssl-private-key-file=/home/pi/selfsign.key' --server-option '--ssl-certificate-file=/home/pi/selfsign.crt' --verbosity=7 --server-option '--enable-webrtc-video=no' --server-option '--enable-webrtc-audio=no' --server-option '--webrtc-receive-video=yes' --server-option '--webrtc-renderer-fullscreen=yes' --server-option=--webrtc-renderer-window=0 0 1920 1080 --server-option '--webrtc-receive-datachannels=yes' --server-option '--webrtc-receive-audio=yes' --auto-video_nr --server-option '--webrtc-receive-audio=yes --server-option '--port=9000'
You can then access the WebRTC streaming page at:
https://raspberry:9000/stream/webrtc
You must explicitly enable screen sharing in firefox or chrome according to the instructions written in the the same page.
I would check if the camera module on the pi itself is attached correctly. Did you try to capture a test image using something likeraspistill -o test.jpg yet? I've seen the 'No Suitable devices found' problem come up when I either didn't enable the camera on raspi-config or I didn't insert the camera's ribbon cable correctly. You can also check if you've connected the GPIO corresponding pins right.
Related
I installed this module and have the corresponding RaspberryPi HAT(Waveshare Rpi 35A) attached to my Raspberry Pi.
After running modprobe ili9486 in the terminal:
In /sys/module, I see the device.
In /dev/ and /dev/spi/, I don't see anything with ili9486 in it's name.
How do I send a command to the device?
In specific how do I send the command to ili9486_probe, which will in turn, send the command to waveshare_command? My goal is to get the command to reach waveshare_command?
I didn't install the dtoverlay on the Waveshare github because I do not want touch screen features. I just want to write to the screen.
I am trying to use VNC in a headless install on my Raspberry Pi 4, running Raspberry Pi OS, installed via Raspberry Imager. The install is more or less vanilla, as the only changes I have made are for connecting (seting up SSH, wireless and VNC as noted in this guide: https://www.tomshardware.com/reviews/raspberry-pi-headless-setup-how-to,6028.html).
When I log in via VNC I get the "Cannot Currently Show the Desktop"-error. It should be possible to fix by changing the screen resolution via raspi-config, but that makes the pi unresponsive. Setting the pi to use "G3 legacy" should fix that issue either after a reboot or without (answers vary on that), but it doesn't seem to make a difference in either case.
Does anyone know how I can get to connect via VNC to my pi?
Thanks :)
According to the documentation:
If your Raspberry Pi is headless (i.e. not plugged into a monitor) or
controlling a robot, it is unlikely to be running a graphical desktop.
So the idea is to create a new virtual desktop via vncserver command and use the display number in VNC.
Basically should be sufficient to specify a HDMI mode. I have a Raspberry Pi4 headless, this is my configuration in /boot/config.txt
# 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 this if your display has a black border of unused pixels visible
# and your display can output without overscan
disable_overscan=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=2
hdmi_mode=82
# 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
[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
#dtoverlay=vc4-fkms-v3d
gpu_mem=128
start_x=1
enable_uart=1
#hdmi_enable_4kp60=1
Then I disabled encryption and set a VNC password. In addition, if you to see the raspistill/raspivid preview through VNC you have to enable this: RealVNC Viewer > Menu > Options > Troubleshooting > Optimize screen capture - select 'Enable direct capture mode'
Raspbian Buster:
Launch command line and run:
sudo raspi-config
Display options -> Resolution. Then select a resolution mode, I recommend select 1280x720 but you can also choose the higher resolution (1920x1080). Save and finish.
Reboot and connect to raspberry again through VNC client.
Raspbian Bullseye:
Launch command line and run:
sudo raspi-config
Display options -> VNC Resolution. Then select a resolution mode, I recommend select 1280x720 but you can also choose the higher resolution (1920x1080). Save and finish.
Reboot and connect to raspberry again through VNC client.
This solved the problem for me: https://www.shellhacks.com/raspberry-pi-force-hdmi-hotplug/.
TL;DR
Setting the resolution of VNC in Raspberry Pi (RPi):
/usr/bin/xrandr --fb 1920x1080
Long answer
One can examine the code of raspi-config bash script, here
Look for the do_vnc_resolution function.
My Rpi4 Bullseye machine had set itself into safe mode … in /boot/config.txt the line
hdmi_safe=1
Was uncommented.
Commenting it out fixed my lo-resolution VNC display problem
Then had to reboot, then logout, and login for everything to be set ok
I'm running into a very strange issue attempting to run CodeSys on a 4GB RasPi-4. Long story short, the Pi works fine right up until I start running the CodeSys project. When I do, within 60sec, eth0 goes down and cannot be brought back up. Even rebooting the Pi has no effect. The only way I've found to recover eth0 is to re-burn RasPiOS from the source image from Raspberrypi.org (which I've done about 30 times over the past few days, trying to trial-and-error my way out of this).
Linux raspberrypi 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT 2020 armv7l GNU/Linux
I have eth0 set to a static IP using /etc/dhcpcd.conf. Whatever is causing this issue is not altering my settings there. Attempts to use ifconfig eth0 up/down have no effect -- no errors, no feedback, just nothing. Checking eth0's state shows "waiting for carrier," despite being connected to an active switch (I've also swapped out all the cables and the switch to eliminate them as the source of the problem).
When I re-burn the Pi and install CodeSys, eth0 stays up indefinitely (24hrs+ in my longest test). It's starting the CodeSys project that kills eth0. A reboot after etho "dies" gives a series of bcmgenet messages that appear to be related:
pi#raspberrypi:~ $ dmesg | grep bcmg
[ 1.033665] bcmgenet fd580000.ethernet: failed to get enet clock
[ 1.033685] bcmgenet fd580000.ethernet: GENET 5.0 EPHY: 0x0000
[ 1.033709] bcmgenet fd580000.ethernet: failed to get enet-wol clock
[ 1.033730] bcmgenet fd580000.ethernet: failed to get enet-eee clock
[ 1.044648] libphy: bcmgenet MII bus: probed
[ 9.528502] bcmgenet fd580000.ethernet: configuring instance for external RGMII
[ 9.535175] bcmgenet fd580000.ethernet eth0: Link is Down
I also tried creating a new CodeSys project from scratch that had no eth0 drivers (ModBus, Ethernet/IP) installed, only the GPIO driver. That didn't help either -- eth0 dies within 60sec.
The strangest part is, only eth0 seems to be affected. The GPIO pins keep cycling as controlled by the CodeSys project (I have a simple LED-blinking program running), and I can still SSH into the Pi using wifi. But since my main reason for setting this Pi up is to use Ethernet/IP and ModBus....
This thread: at GitHub is the only place I've found anyone describing anything similar to what I'm experiencing, but in that case CodeSys is not installed. I did try adding genet.skip_umac_reset=n to my cmdline.txt as suggested in the thread, but it had no effect.
So, it turned out this was an issue configuring the GPIO pins.
CodeSys has two difference "device" files for adding the GPIO pins to the project device tree. The default selection is for older Pi models, and the alternate choice (labelled only for B+ and Pi2) is the correct one for the Pi4.
As it turns out, the outdated GPIO device file will work on a Pi4, mostly. But using the wrong device file allows CodeSys to try configuring GPIO pins that shouldn't be tampered with. In this case, GPIO 28 and 29. Setting either of them to Output mode killed eth0.
Using the correct device file removes 28&29 from the list of configurable GPIO pins. It also gives the correct list of available GPIO pins for the newer Pi models, hopefully avoiding other potential config issues that I didn't trip over.
In CodeSys, right-clicking on the GPIOs element in the device tree offers the option to "Update the Device." Select this option to get the list of available device files, and select the correct one before using the "Update Device" button in the bottom of the window.
I have been trying to locate a working library for the MSR605X magnetic card reader/writer. At time of writing, I have tried five separate libraries. Only two of these were explicitly for the 605X the other three were for the older 605. All the libraries I have tried either did nothing at all or errored before completing a command (can't figure out the errors either).
I am running Raspberry Pi OS 32 bit on a Raspberry Pi 3 B+ the MSR605X communicates via a USB connection.
So far the library that seems to be most complete is: https://pypi.org/project/msrx/
However, I can not get this library to read or write (either nothing happens or I get a Serial exception "cannot reconfig port).
Any help or links to documentation for this reader is welcome.
EDIT: Adding the commands ran with the above library
msrx -D /dev/input/event4 read
msrx -D /dev/input/jso0 read
The -D is to specify the device path (default is /dev/ttyUSB0 which doesn't exist on my system). I obtained the above two paths by searching for USB serial devices then matching the search result to the device ID which I obtained from lsusb.
Running these commands results in a serial exception (could not reconfig port) which I assume means that I have the wrong device path. I have also checked for any tty* device paths that are changed when I plug in the reader. I consistently get a permission denied error whenever trying to run the above commands with a tty* device path (I am root on this system).
msrx author here — MSR605 requires an external 9V power injected into its cable (via the barrel jack port), otherwise it won't power up properly.
I'm using a Raspberry PI compute module 3 in a custom motherboard connected to an ESP32 using HCI over UART to connect to a mobile phone over bluetooth. It partially works: The phone is able to pair with the device, the device can see the phone in the bluetoothctl UI, SDPtool can see the services (RFCOMM) exposed by the device.
However, when I use pybluez, certain functionality does not work:
First I tried using the device as the bluetooth slave. This is my preferred configuration. btmon showed the phone trying to connect, but pybluez never gets past sock.accept(). The code is pretty much exactly what you see in the example on pybluez github, and I've used the same code successfully with a stock Raspberry Pi Zero W (with the integrated bluetooth) successfully.
The phone shows the following error in the socket.connect() command:
W/System.err: java.io.IOException: read failed, socket might closed or timeout, read ret: -1
W/System.err: at android.bluetooth.BluetoothSocket.readAll(BluetoothSocket.java:698)
W/System.err: at android.bluetooth.BluetoothSocket.readInt(BluetoothSocket.java:710)
W/System.err: at android.bluetooth.BluetoothSocket.connect(BluetoothSocket.java:387)
Hard to find anything of value in the Pi device's logs, but I did see this in btmon:
ACL Data RX: Handle 128 flags 0x02 dlen 14 [hci0] 75.711662
L2CAP: Command Reject (0x01) ident 5 len 6
Reason: Invalid CID in request (0x0002)
Destination CID: 0
Source CID: 0
I also tried using the Android hack for connecting directly using a channel ID rather than a UUID (essentially skipping the SDP lookup) - I got the channel ID using sdptool browse local, and this resulted in the same error.
After exhaustively trying different things I switched gears to trying to use the phone as the bluetooth slave instead of the device. Here I see more success, but still things aren't working as expected:
discover_devices from pybluez doesn't report any devices, although the phone and bluetoothctl both show the devices as paired. However, if I hardcode in the device address I see in bluetoothctl, I am actually able to connect.
I'm convinced that something is screwed up with the bluetooth configuration, perhaps the versions of bluez or pybluez, but I can't find anyone else who has reported these sorts of issues. I'd note that I'm using the compatibility mode switch on the bluetoothd service (otherwise it doesn't work at all). Bluez version is 5.43 I believe.
Has anyone seen anything like this? Any suggestions for troubleshooting these issues (different versions of bluez, etc)?
I ultimately did solve this, but I'm not sure which change did it:
I reduced the baud rate to 115200.
I switched it to classic bluetooth in the firmware flash.
I disabled bluetooth sleep.
One of these three changes must have done the trick
ret = esp_bt_controller_enable(ESP_BT_MODE_CLASSIC_BT);
if (ret != ESP_OK) {
ESP_LOGE(tag, "Bluetooth Controller initialize failed: %s", esp_err_to_name(ret));
return;
}
ret = esp_bt_sleep_disable();
if (ret != ESP_OK) {
ESP_LOGE(tag, "Bluetooth Sleep Disable Failed: %s", esp_err_to_name(ret));
return;
}