Raspberry Pi3, bluealsa - connected but no sound output on bluetooth speaker? - bluetooth

Summary: Everything is connected, and appears to work, but no sound comes out of the speaker - how to diagnose or fix?
I am trying to play sound from my Raspberry Pi 3 to a bluetooth speaker, but it is not working.
The pi connects to the bluetooth speaker (confirmed by automated audio on the speaker when it connects, "raspberrypi connected", and checking echo "info 04:52:C7:5A:3B:A1" | bluetoothctl on the pi also shows it is connected).
The speaker volume is not muted and other devices can connect to it and play through it. Checking alsamixer verifies that audio is not muted.
But using aplay to play sound through the bluetooth speaker leads only to a deafening silence. Although it looks like it works:
$ aplay -D bluealsa:HCI=hci0,DEV=04:52:C7:5A:3B:A1,PROFILE=a2dp /usr/share/sounds/alsa/Front_Center.wav
Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
I have looked for log files that might have information in them, but haven't found anything.
bluealsa configuration
I set this up following the instructions here. The details of this set up are:
Raspbian Stretch, 2018-10-09 image (bluealsa v5.43 installed out of box)
bluez v5.49 downloaded, built and installed (no errors)
/etc/dbus-1/system.d/bluetooth.conf edited, following lines added to root element:
<allow send_interface="org.bluez.ThermometerWatcher1"/>
<allow send_interface="org.bluez.HeartRateWatcher1"/>
<allow send_interface="org.bluez.CyclingSpeedWatcher1"/>
And following also added to the top level busconfig element:
<policy group="bluetooth"><allow send_destination="org.bluez"/></policy>
pi user added to bluetooth group
I have tried moving the HCI, device and profile details into .asoundrc and /etc/asound.conf files but these produce the same results (console output suggests successful, but no sound comes from the speaker when I use aplay).
Other things (probably not relevant but including for completeness)
pi access is via SSH (it's headless)
on booting the pi, sudo systemctl status blueto* shows an error message on the bluetooth service: Failed to set privacy: Rejected (0x0b), apparently a boot-related issue (link) which is fixed by manually restarting the bluetooth service after boot using systemctl (ugly, but fine as a workaround for now)
no suspicious looking messages in dmesg, user.log or boot.log
but the following was in daemon.log, it correlates with an execution of the aplay command above (but I have tried that command several times with the same console output, it generates them sometimes only):
.
Nov 10 21:02:16 rpi_3e5ccf bluealsa[789]: /usr/bin/bluealsa: Unsupported AT message: SET: command:+CLIP, value:1
Nov 10 21:02:16 rpi_3e5ccf bluealsa[789]: /usr/bin/bluealsa: Unsupported AT message: CMD: command:+CLCC, value:(null)
Nov 10 21:02:16 rpi_3e5ccf bluealsa[789]: /usr/bin/bluealsa: Unsupported AT message: SET: command:+CSRSF, value:0,0,0,1,0,0,0

Ultimately I was unable to debug this and got impatient, so just wiped the SD and started from scratch. The detailed steps I followed are below, these mean I can now play audio using aplay without having to specify the device, e.g.:
aplay /usr/share/sound/alsa/Front_Center.wav
1) Set up SD card image
use etcher to burn 2018-10-09-raspbian-stretch.img
touch /boot/ssh
add a suitable /boot/wpa_supplicant.conf file
edit /rootfs/etc/hostname
2) ssh-copy-id from host to pi, for convenient SSH
3) Set up software on the pi:
passwd
sudo apt update; sudo apt dist-upgrade
sudo apt install vim git screen htop rpi-update
sudo apt autoremove
sudo systemctl set-default multi-user.target # don't start X windows on boot
sudo BRANCH=next rpi-update
sudo reboot
4) Update bluez
sudo apt install libdbus-1-dev libglib2.0-dev libudev-dev libical-dev libreadline-dev
wget http://www.kernel.org/pub/linux/bluetooth/bluez-5.50.tar.xz
tar -xf bluez-5.50.tar.xz`
cd bluez-5.50/
./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --localstatedir=/var --enable-experimental
make -j4
sudo make install
sudo cp /etc/dbus-1/system.d/bluetooth.conf /etc/dbus-1/system.d/bluetooth.conf.bak, then edit:
add to root: <allow send_interface="org.bluez.ThermometerWatcher1"/><allow send_interface="org.bluez.HeartRateWatcher1"/><allow send_interface="org.bluez.CyclingSpeedWatcher1"/>
add new child of busconfig: <policy group="bluetooth"><allow send_destination="org.bluez"/></policy>
5) Get bluetooth working
sudo adduser pi bluetooth
sudo reboot
bluetoothctl: scan on
bluetoothctl: trust 04:52:C7:5A:3B:A1
bluetoothctl: connect 04:52:C7:5A:3B:A1
aplay -D bluealsa:HCI=hci0,DEV=04:52:C7:5A:3B:A1,PROFILE=a2dp /usr/share/sounds/alsa/Front_Center.wav # test it works at all
6) Get bluetooth working without specifying the device by creating the following /etc/asound.conf file:
pcm.bose {
type plug
slave {
pcm {
type bluealsa
interface hci0
device 04:52:C7:5A:3B:A1
profile "a2dp"
}
}
hint {
show on
description "Bose speaker"
}
}
pcm.!default {
type plug
slave.pcm "bose"
}
ctl.!default {
type hw
card 0
}
For reference and credit, this is based on information from the following three sources:
link
link
link
And in reply to #Parthiban's comment above, here is the dbus-monitor output from the now-working system:
signal time=1541964336.104905 sender=org.freedesktop.DBus -> destination=:1.1 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
string ":1.1"
signal time=1541964336.105032 sender=org.freedesktop.DBus -> destination=:1.1 serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost
string ":1.1"
method call time=1541964336.106756 sender=:1.0 -> destination=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RequestName
string "org.freedesktop.systemd1"
uint32 7
signal time=1541964336.106880 sender=org.freedesktop.DBus -> destination=(null destination) serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
string "org.freedesktop.systemd1"
string ""
string ":1.0"
signal time=1541964336.107024 sender=org.freedesktop.DBus -> destination=:1.0 serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
string "org.freedesktop.systemd1"
method return time=1541964336.107096 sender=org.freedesktop.DBus -> destination=:1.0 serial=5 reply_serial=3
uint32 1
method call time=1541964336.108116 sender=:1.0 -> destination=org.freedesktop.DBus serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=ListNames
method return time=1541964336.108179 sender=org.freedesktop.DBus -> destination=:1.0 serial=6 reply_serial=4
array [
string "org.freedesktop.DBus"
string "org.freedesktop.systemd1"
string ":1.0"
]

Related

Trouble initializing SDK node using USB-TTL M210 v2

I am trying to connect M210 v2 RTK to a desktop computer with Ubuntu 18.04, ROS Melodic and parallel installation of Opencv 3.3.1 and 4.5.3 using a USB-TTL RS232 to make UART connection and an USB-USB connecting drone and desktop to be able to run Advanced Sensing.
When I call ls -l /dev/ttyACM* && ls -l /dev/ttyUSB* it returns that it is indentified the USB and ACM connection.
crw-rw---- 1 root dialout 166, 0 out 4 13:18 /dev/ttyACM0
crw-rw---- 1 root dialout 188, 0 out 4 13:18 /dev/ttyUSB0
I also set the transfer rate of TTL-USB to 921600 using minicom, and gave persmission to device to read and write with sudo usermod -a -G dialout $USER && sudo chmod 666 /dev/ttyUSB0
Unfortunatelly when I launch roslaunch dji_osdk_ros dji_sdk_node.launch it appears some connection problem presented below and I am not being able to fix it. I have been trying to turn on/off drone and RC several times ass described here, but the problem still stand.
started roslaunch server http://V3D06:43613/
SUMMARY
========
PARAMETERS
* /dji_sdk/acm_name: /dev/ttyACM0
* /dji_sdk/align_time: False
* /dji_sdk/app_id: 1076017
* /dji_sdk/app_version: 1
* /dji_sdk/baud_rate: 921600
* /dji_sdk/dxc: False
* /dji_sdk/enc_key: 6bd1d26f8dd897e4b...
* /dji_sdk/serial_name: /dev/ttyUSB0
* /dji_sdk/use_broadcast: False
* /rosdistro: melodic
* /rosversion: 1.14.12
NODES
/
dji_sdk (dji_osdk_ros/dji_sdk_node)
auto-starting new master
process[master]: started with pid [2436]
ROS_MASTER_URI=http://localhost:11311
setting /run_id to bde7b4d2-252e-11ec-8a59-1831bfb3e154
process[rosout-1]: started with pid [2458]
started core service [/rosout]
process[dji_sdk-2]: started with pid [2464]
[ INFO] [1633364323.534426789]: Advanced Sensing is Enabled on M210.
Read App ID
User Configuration read successfully.
[1276751.089]STATUS/1 # getDroneVersion, L1702: ret = 0
[1276751.089]STATUS/1 # parseDroneVersionInfo, L1122: Device Serial No. = 1DADG3E00100U4
[1276751.089]STATUS/1 # parseDroneVersionInfo, L1124: Firmware = 3.4.3.44
[1276751.089]STATUS/1 # functionalSetUp, L279: Shake hand with drone successfully by getting drone version.
[1276751.089]STATUS/1 # legacyX5SEnableTask, L56: Legacy X5S Enable task created.
[1276752.089]STATUS/1 # sendHeartbeatToFCTask, L1576: OSDK send heart beat to fc task created.
[1276752.289]STATUS/1 # Control, L40: The control class is going to be deprecated.It will be better to use the FlightController class instead!
[1276752.290]STATUS/1 # FileMgrImpl, L253: register download file callback handler successfully.
[1276753.557]STATUS/1 # PSDKModule, L98: MOP only support M300, so mop client will not be initialized here.
[1276753.557]STATUS/1 # PSDKModule, L98: MOP only support M300, so mop client will not be initialized here.
[1276753.557]STATUS/1 # PSDKModule, L98: MOP only support M300, so mop client will not be initialized here.
[1276753.557]STATUS/1 # initDJIHms, L900: DJI HMS is not supported on this platform!
[1276753.567]STATUS/1 # getDroneVersion, L1702: ret = 0
[1276753.567]STATUS/1 # parseDroneVersionInfo, L1122: Device Serial No. = 1DADG3E00100U4
[1276753.567]STATUS/1 # parseDroneVersionInfo, L1124: Firmware = 3.4.3.44
[1276753.567]STATUS/1 # AdvancedSensing, L145: Advanced Sensing init for the M210 drone
[1276753.567]STATUS/1 # init, L49: Looking for USB device...
[1276753.572]STATUS/1 # init, L65: Found 8 USB devices, identifying DJI device...
[1276753.572]STATUS/1 # init, L83: Found a DJI device...
[1276753.572]STATUS/1 # init, L96: Attempting to open DJI USB device...
[1276753.572]ERRORLOG/1 # init, L101: Failed to open DJI USB device...
[1276753.572]ERRORLOG/1 # init, L102: Error code: -3
[1276753.572]ERRORLOG/1 # init, L105: Please make sure you provide a udev file for your system and reboot the computer
[1276753.573]STATUS/1 # LiveViewImpl, L89: Finding if liveview stream is available now.
[1276754.076]STATUS/1 # init, L254: Start advanced sensing initalization
[1276754.076]STATUS/1 # activate, L1329: version 0x304032C
[1276754.076]STATUS/1 # adv_pthread, L46: adv pthread created !!!!!!!!!!!!!!!!!!!!!!!
[1276754.076]STATUS/1 # adv_pthread, L48: adv pthread running !!!!!!!!!!!!!!!!!!!!!!!
[dji_sdk-2] process has died [pid 2464, exit code -11, cmd /home/vant3d/catkin_ws/devel/lib/dji_osdk_ros/dji_sdk_node __name:=dji_sdk __log:=/home/vant3d/.ros/log/bde7b4d2-252e-11ec-8a59-1831bfb3e154/dji_sdk-2.log].
log file: /home/vant3d/.ros/log/bde7b4d2-252e-11ec-8a59-1831bfb3e154/dji_sdk-2*.log
It appears it has some problem providing a udev file, but I don't know how to fix it. Does anyone have some idea to help on this problems?
Thank you!
That's my post. Firstly turn off advanced sensing to try whether a basic FTDI works.
The second which DJI OSDK version are you using? does the OSDK version match the version in OSDK-ROS? I saw you have M300 in. that is usually in OSDK 4+. For M210, I only use 3.8 and 3.9
If basic FTDI works, and you can get all the feedback. there is a higher chance that you have the wrong ACM config. DJI RNDIS thing is nasty and may not be config properly. You need to manually set static IP of 192.168.43.1 (or I remember something like this 42 or 43, you need to check on this static IP) and set it manually

Sink to the virtual v4l2 device

I have tried an example on Ubuntu 19.04
gst-launch-1.0 videotestsrc ! v4l2sink device=/dev/video10
But gstreamer fails
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
ERROR: from element /GstPipeline:pipeline0/GstV4l2Sink:v4l2sink0: Cannot identify device '/dev/video10'.
Additional debug info:
v4l2_calls.c(609): gst_v4l2_open (): /GstPipeline:pipeline0/GstV4l2Sink:v4l2sink0:
system error: No such file or directory
Setting pipeline to NULL ...
Freeing pipeline ...
Why it doesn't work? I haven't found this in the documentation, do I need to create /dev/video10 somehow?
I did the same for the default device /dev/video1, but it is an input camera device on my laptop:
sudo gst-launch-1.0 videotestsrc ! v4l2sink
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
ERROR: from element /GstPipeline:pipeline0/GstV4l2Sink:v4l2sink0: Device '/dev/video1' is not a output device.
Additional debug info:
v4l2_calls.c(639): gst_v4l2_open (): /GstPipeline:pipeline0/GstV4l2Sink:v4l2sink0:
Capabilities: 0x4a00000
Setting pipeline to NULL ...
Freeing pipeline ...
Thank in advance.
The title of your questions suggests you would like to write to a virtual video device. v4l2 devices can be both input and output video devices. Your camera is a video input (capture) device. Directing a v4l2sink (so an endpoint of the pipeline) in gstreamer will likely fail.
You can however generate a virtual output device. What you are looking for is something like the v4l2-loopback device. It allows you to generate a virtual /dev/video10 device like this:
modprobe v4l2loopback video_nr=10
Another possible solution for the same error message: recreate the v4l2loopback interface:
sudo rmmod -f v4l2loopback
sudo modprobe v4l2loopback
This might apply to others experiencing the error message from the original question, but who are already aware they need a v4l2loopback device as gstreamer sink.
When trying to stream a video to the existing v4l2loopback device I streamed to using ffmpeg before, I got the same error message
Device '/dev/video0' is not a output device.
Investigation
When comparing the state of a working loopback video device and a non-working one (i.e. after writing to it with ffmpeg) with v4l2-ctl --all -d 0 using diff, I found the following difference :
--- working 2020-11-19 18:03:52.499440518 +0100
+++ non-working 2020-11-19 18:03:57.472802868 +0100
## -3,21 +3,18 ##
Card type : GPhoto2 Webcam
Bus info : platform:v4l2loopback-000
Driver version : 5.9.8
- Capabilities : 0x85208002
- Video Output
+ Capabilities : 0x85208000
Video Memory-to-Memory
Read/Write
Streaming
Extended Pix Format
Device Capabilities
- Device Caps : 0x05208002
- Video Output
+ Device Caps : 0x05208000
Video Memory-to-Memory
Read/Write
Streaming
Extended Pix Format
Priority: 0
-Video output: 0 (loopback in)
Format Video Output:
Width/Height : 960/640
Pixel Format : 'YU12' (Planar YUV 4:2:0)
Somehow that "Video Output" capability is required for gstreamer to work successfully and taken away by my previous ffmpeg call.
The behaviour only occured when I loaded the v4l2loopback module with the exclusive_caps=1 option, see 1.
The solution was to unload / load the v4l2loopback kernel commands, forcefully removing the v4l2loopback kernel module and adding it again using rmmod / modprobe (see above).

Modbus cant read data from epever tracer 1210a to raspberry

i want to make a monitoring program for tracer
i use rs485 usb converter to connect epever tracer1210a to raspberry pi 3 model b
from pymodbus.client.sync import ModbusSerialClient as ModbusClient
client = ModbusClient(method = 'rtu', port = '/dev/ttyACM0', baudrate = 115200)
client.connect()
print( client)
result = client.read_input_registers(0x3100,6,unit=1)
print (result)
solarVoltage = float(result.registers[0] /100.0)
solarCurrent = float(result.registers[1] /100.0)
batteryVoltage = float(result.registers[4] /100.0)
chargeCurrent = float(result.registers[5] /100.0)
print("solar voltage : ",solarVoltage)
print("solar current : ",solarCurrent)
print("battery volatage : ",batteryVoltage)
print("charge current : ",chargeCurrent)
client.close()
and i get error like this:
ModbusSerialClient(rtu baud[115200])
Modbus Error: [Input/Output] Modbus Error: [Invalid Message] Incomplete message received, expected at least 2 bytes (0 received)
Traceback (most recent call last):
File "yutub.py", line 9, in
solarVoltage = float(result.registers[0] /100.0)
AttributeError: 'ModbusIOException' object has no attribute 'registers'
please help me to fix this problem
I had faced the same problem.
Follow the below steps to fix the issue:
git clone https://github.com/kasbert/epsolar-tracer/tree/master/xr_usb_serial_common-1a
Follow the installation steps from Readme.
You might face problem when you execute make. In such case do sudo apt-get install linux-headers.
Check that the USB UART is detected by the system
lsusb
Check that the CDC-ACM driver was not installed for the Exar USB UART
ls /dev/tty*
To remove the CDC-ACM driver and install the driver:
sudo rmmod cdc-acm
sudo modprobe -r usbserial
sudo modprobe usbserial
sudo insmod ./xr_usb_serial_common.ko
After this when you do ls /dev/tty* you will see /dev/ttyXRUSB0. This means the driver is installed and you are in good shape.
Change the port in your code to '/dev/ttyXRUSB0'.
See the output image
After you restart the PI you might not see the ttyXRUSB0 instead you will see ttyACM0. In such case execute sudo echo blacklist cdc-acm > /etc/modprobe.d/blacklist-cdc-acm.conf. If PI does not allow you to execute then create the file in the path and write blacklist cdc-acm.
Reboot and verify if ttyACM0 is still displayed in ls /dev/tty*.

Raspberry Pi: IR LED works, but irsend does not transmit any IR code

I installed the current lirc package (0.9.0~pre1-1.2) on a Raspian jessie (no pixel) (everything updated and upgraded) and connected to the (lirc default) GPIO ports:
to gpio port 17 - an IR LED via transistor etc
to gpio port 18 - an IR receiver nodule
The receiver part works perfectly:
mode2 command receiving raw data from transmitter
the IR code recognition of previously recorded keys works
However, the IR LED only works only while lirc is not involved:
a shell script can switch the IR LED on and off with no problem
The only thing that doesn't work:
irsend does not make the IR transmitter emit anything, however no error message is shown
So the hardware, especially the IR LED is definitely working, while lirc cannot make the LED emit any configured IR code.
Please note that this seems to be a duplicate of
stackoverflow: irsend is not giving errors, but does not send signal on Raspbian
Unfortunately it is not. The "solution" provided there was placing the data for /etc/modules into the file /etc/modules-load.d/lirc_rpi.conf. I tried that as well, but it makes no difference.
Any help is greatly appreciated!
Configuration data follows - if any other data is required, I'd be happy to add it! TIA!
System and lirc Configuration
Extract fom: /boot/config.txt
dtoverlay=lirc-rpi,gpio_in_pin=18,gpio_out_pin=17,debug=on
Extract of: /etc/modules
lirc_dev
lirc_rpi gpio_in_pin=18 gpio_out_pin=17
(not sure if that is necessary at all, does not make a difference if this is not configured!? Any hint apppreciated)
All active entries in: /etc/lirc/hardware.conf
LIRCD_ARGS="--uinput"
DRIVER="default"
DEVICE="/dev/lirc0"
MODULES="lirc_rpi"
LIRCD_CONF=""
LIRCMD_CONF=""
Some system output
1) The driver is loaded, output of following command right after boot, output of: dmesg | grep lirc
lirc_dev: IR Remote Control driver registered, major 245
lirc_rpi: module is from the staging directory, the quality is unknown, you have been warned.
lirc_rpi: to_irq 178
lirc_rpi: auto-detected active low receiver on GPIO pin 18
lirc_rpi lirc_rpi: lirc_dev: driver lirc_rpi registered at minor = 0
lirc_rpi: driver registered!
input: lircd as /devices/virtual/input/input0
lirc_rpi: Interrupt 178 obtained
2) the service is started and running, output of: systemctl status lirc
? lirc.service - LSB: Starts LIRC daemon.
Loaded: loaded (/etc/init.d/lirc)
Active: active (running) since Mo 2017-06-12 20:04:03 CEST; 2h 58min ago
Process: 377 ExecStart=/etc/init.d/lirc start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/lirc.service
+-437 /usr/sbin/lircd --driver=default --device=/dev/lirc0 --uinput
3) the modules are loaded, output of: lsmod | grep Module;lsmod | grep lirc
Module Size Used by
lirc_rpi 8453 3
lirc_dev 10211 1 lirc_rpi
rc_core 23776 1 lirc_dev
I followed the troubleshooting steps in the (outdated) manual at http://aron.ws/projects/lirc_rpi/
to get some more information.
Output of: cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 0-53, parent: platform/20200000.gpio, pinctrl-bcm2835:
gpio-35 ( |? ) in hi
gpio-47 ( |? ) out lo
I have seen that output also in this case:
raspberrypi.stcakexchange: LIRC won't transmit (irsend: hardware does not support sending)
This user is as irritated by that output as I am - can somebody please tell why gpio-35 and gpio-47 are listed here? shouldn't it be gpio-17 and gpio-18?
Output of: cat /proc/interrupts | grep lirc
178: 875 pinctrl-bcm2835 18 Edge lirc_rpi
This matches the dmesg output on having obtained interrupt 178
Any other dmesg output of lircd, no matter what action, is repeatedly (most likely due to the debug option set) only
lirc_rpi: SET_SEND_CARRIER
lirc_rpi: in init_timing_params, freq=38000 pulse=13157, space=13158
lirc_rpi: SET_SEND_DUTY_CYCLE
lirc_rpi: in init_timing_params, freq=38000 pulse=13157, space=13158
Having restarted testing again after some time for to build up a test copy of the circuit, the problem occurred again. And now, after some more month of much testing, having asked lots of people for help (no one could help), even having purchased and built up a cheap mini USB oscilloscope kit for to examine the hardware further, I finally found the solution.
Long story short: everything in the configuration was correct, and all of the attached hardware was fine. The problem was the testing script - see my remark on
"a shell script can switch the IR LED on and off with no problem"
and as I did not put it in the above description, nobody could have found the solution myself....
The script uses the pseudo files in /sys/class/gpio, see an example here:
raspberry-projects.com: IO pin control from the command line
At the end of the script a command writes to /sys/class/gpio/unexport for cleanup purposes, and this step seems to reset a GPIO port to always end up in the state of being configured for input. As a result LIRC is not longer able to control this GPIO port, since it seems to configure the GPIO port for output only during system boot, and after that always expecting the port to be in that state.
I tracked the problem down to this point by using the gpio utility from the wirinpi package (install with sudo apt-get wiringpi), executing gpio readall and checking for differences.
The time when everything suddenly worked again, I simply may have fogotten about to run my testscript before testing LIRC, which I otherwise always did...
Luckily the problem with the port configuration can easily be fixed without having to reboot the system. Again I use the gpio utility to reset reset the used port for output, where in the below example
the default output port 17 for LIRC is used and
the parameter -g lets the utility use the ordinary GPIO port numbering and not that very different one of the wiringpi package and library
Here is the command, after having executed this last in my test script, LIRC can properly send IR codes again:
gpio -g mode 17 out

There is unexpected error, when open GPIO pin on Raspberry Pi on Java ME 8

I'm working on Raspberry Pi with Java ME 8.0 and I want to use GPIO pin 7
try {
pin = (GPIOPin) DeviceManager.open(7);
} catch (IOException ex) {
Logger.getLogger(PiGPIOled.class.getName()).log(Level.SEVERE, null, ex);
return false;
}
also tried with below code:
pin = (GPIOPin) DeviceManager.open(new GPIOPinConfig(
0, 7, GPIOPinConfig.DIR_OUTPUT_ONLY, GPIOPinConfig.MODE_OUTPUT_PUSH_PULL,
GPIOPinConfig.TRIGGER_BOTH_EDGES, false));
I have give all API permissions, But When I run midlet I see error:
[ERROR] [DAAPI] iso=-1:There is unexpected error, when open GPIO pin 7
Currently I have not connected anything to GPIO 7 pin, is this is the problem?
Some of the links suggested to run usertest.sh, when i tried that I see java running and few people mentioned it worked for them wonder how ?
here is more information
pi#raspberrypi ~/javame8 $ ls /sys/class/gpio
export gpio17 gpio18 gpio3 gpio7 gpiochip0 unexport
Thanks,
Ashok
The Problem here is I have installed midlet without #sudo and trying to run with #sudo. Installed and run midlet #sudo and it worked.

Resources