Jump to content

ygoe

Members
  • Posts

    22
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Alright, I've retried with the Debian instead of Ubuntu image. Same steps as before. I can indeed hear something now. Very loud. And very noisy. Nothing but noise actually. I've prepared a very quiet mp3 file (scaled down by -20 dB) because I knew 100% volume would be way too loud. And it just comes out of my speakers as loud noise. Seems like the device was actually found this time but the data it generates is completely unusable, near random. The noise stops as soon as I terminate mpg123. I'm afraid my speakers might get damaged by this. Totally unusable. If this is all we get, I'll have to find a solution with Raspberry Pi really. I don't want that because these boards are much bigger, more expensive and need 3x the power. I haven't tried with a Raspberry Pi Zero (non-W), might need to get one of them. But their hardware is really old now. And I need an ugly external USB Ethernet adapter for it. I wish Raspberry Pi OS supported other hardware, too. But I really need the software volume control as well because my amplifier or speakers have no control, they just do what they get. It's those tiny 3 W boards but I found they're totally enough for my ears (and also my neighbours'). BTW, is it normal that the second 'dtc' command to compile the device tree writes out 223 warnings?
  2. Well, I cannot reproduce your configuration. It just doesn't work on my copy of the device. Are you sure the kernel already knows what to do without recompiling? Can I verify this somewhere? Should I find a log entry somewhere? Or how else can I see why aplay lists a device that noone else can find? Are we talking about a current version of "Armbian 21.08.2 Focal with Linux 5.10.60-sunxi" on a NanoPi NEO? I'm using a fresh installation, latest download image as of yesterday, nothing else installed or modified so far. BTW, in the meantime I've also tried out FriendlyElec's own Ubuntu Linux image. It already comes with all sorts of audio devices but none of them works either. I can't remember the details, I've posted it to their forum. But that looks pretty dead to me, my post as a new user wasn't moderation-approved within 3 days and I cannot see my post anymore/yet. Here's the current output of speaker-test -DI2Smaster -c2 speaker-test 1.2.2 Playback device is I2Smaster Stream parameters are 48000Hz, S16_LE, 2 channels Using 16 octaves of pink noise ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM I2Smaster Playback open error: -2,No such file or directory
  3. Here's the asound.conf file I used successfully on a Raspberry Pi 3B+, including volume control. But I can't make any sense of its content. Would there be something in it that is useful for a NanoPi?
  4. Okay, thank you, that looks much more like my skillset. I followed all the steps and gathered the mentioned files from the rest of the thread. I can see an I2S device but volume control and MP3 playback don't work yet. aplay -l **** List of PLAYBACK Hardware Devices **** card 0: I2Smaster [I2S-master], device 0: 1c22000.i2s-pcm5102a-hifi pcm5102a-hifi-0 [1c22000.i2s-pcm5102a-hifi pcm5102a-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 aplay -L null Discard all samples (playback) or generate zero samples (capture) sysdefault:CARD=I2Smaster I2S-master, 1c22000.i2s-pcm5102a-hifi pcm5102a-hifi-0 Default Audio Device dmix:CARD=I2Smaster,DEV=0 I2S-master, 1c22000.i2s-pcm5102a-hifi pcm5102a-hifi-0 Direct sample mixing device dsnoop:CARD=I2Smaster,DEV=0 I2S-master, 1c22000.i2s-pcm5102a-hifi pcm5102a-hifi-0 Direct sample snooping device hw:CARD=I2Smaster,DEV=0 I2S-master, 1c22000.i2s-pcm5102a-hifi pcm5102a-hifi-0 Direct hardware device without any conversions plughw:CARD=I2Smaster,DEV=0 I2S-master, 1c22000.i2s-pcm5102a-hifi pcm5102a-hifi-0 Hardware device with all software conversions alsamixer cannot open mixer: No such file or directory alsamixer -c 0 This sound device does not have any controls. mpg123 some.mp3 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3 version 1.25.13; written and copyright by Michael Hipp and others free software (LGPL) without any warranty but with best wishes Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock Segmentation fault speaker-test speaker-test 1.2.2 Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise Playback open error: -2,No such file or directory Something seems to be different today than when you showed your log.
  5. Oh dear, that is complicated. I don't have such an Armbian build system. I guess that needs to be a powerful Linux computer. What exactly is the trouble if this was enabled right in the distribution kernel? Is it unstable? Could it cause random noise or data loss? Does it eat kittens at night? I'm actually looking towards a Raspberry Pi Zero with a USB Ethernet adapter for my project instead of the nice little NanoPi.
  6. Hello, I've been playing on my Raspberry Pi 3B+ with an I2S audio amplifier and could play music from it. Now I want to add more devices to experiment with multi-room systems. The only other system with I2S support I have here is a NanoPi NEO. It has dedicated I2S pins so that shouldn't be too complicated. I thought. But it doesn't work. 'aplay -l' says "no soundcards found" and 'speaker-test -c2' essentially says the same. 'armbian-config' doesn't have a switch to enable I2S, only SPDIF, which sounds plausible considering that the SPDIF pin is multipurpose while the I2S pins are not. A web search for several terms didn't bring up something useful. Searching this forum for "i2s" gives me even no result at all, which I consider an error because I've seen this topic discussed here from the web results already. So I have no clue how to make I2S work on a NanoPi NEO with Armbian (all updated). The pins are connected correctly (I believe) but the software doesn't seem to know that these pins exist. On the RasPi I had to create the file /etc/asound.conf. I also tried that on Armbian but it has no effect. Maybe its contents does not apply here? What do I have to configure or install to make this work? Shouldn't it work on its own already as the other tools are also pre-installed?
  7. Not sure about the bridge. I have none, says "brctl". armbian-config didn't use a bridge either. The "bridge=br0" line was commented out from the start. At least I'd expect to connect to the device itself, even if I won't get anywhere else. That'd be fine if I want to configure the IoT device via an AP WLAN interface. It doesn't need to provide a WLAN gateway to the internet for me. Update: I've attached the dual-band adapter again. This time, after a reboot, the channel 5 was actually applied. I have no idea why it worked now when it didn't yesterday. And I still have no bridge but can connect to the internet via this AP. traceroute confirms this extra hop. So a bridge certainly isn't required here. Very confusing. Or maybe just unreliable. Still, the 2.4-GHz-only adapter doesn't work at all. And it's one with known good Linux support from Edimax, recommended for RasPi.
  8. Maybe my description was a bit confusing. I'll try to clarify. I don't want to have an access point on both bands at the same time. I just want it on one (configurable) band. That's already enough. At first the armbian-config tool chose the 5 GHz band for me and everything was fine. But it didn't offer me to change that (or it did and failed, I can't remember). I wanted to use the same dual-band adapter and have the network on 2.4 GHz now. That is part one. Doesn't work because the SSID isn't visible in 2.4 GHz, only in 5 GHz channel 40. Part two is that I tried with a different WLAN adapter that can only handle 2.4 GHz. This time, the SSID appeared on channel 5 (which also certainly isn't blocked anywhere in the world) but dnsmasq failed to start, probably because the WLAN adapter doesn't have the static IP address that's configured for it. Can a WLAN adapter driver bug cause the static IP address assignment to fail? Without any entry in dmesg? Recently I've learned that Linux drivers can contain any bugs anyone could or could not imagine, including bugs that haven't been invented yet. But this sounds pretty simple to me. WLAN access point configuration looks very complicated to me, with lots of settings no user of a regular access point consumer device would ever see. I'm wondering if all of this is necessary. The more settings there are, the more mistakes one can make setting them. Can I just leave some of them out? Is there a minimal working config set described anywhere? Each WLAN AP tutorial on the web shows completely different settings and values.
  9. Not at the same time. Only one WLAN adapter is attached at any time. First I tried one, then I tried the other that only has 2.4 GHz to see if I can force the AP onto that band this way. I could but got other problems.
  10. Hello, I'd like to set up a WLAN access point with WLAN adapters attached to USB on my Orange Pi Zero. First I started with a dualband adapter and used the armbian-config tool. It took forever (like minutes with a black screen) but eventually completed and gave me a working access point on channel 40. That's fine but I also need to be able to change this to a 2.4 GHz channel. That's where things got problematic. I edited /etc/hostapd.conf and changed the channel number from 40 to 5, then restarted hostapd. That didn't work. The service restarted but there was no access point anywhere to be found on the air. Also, the WLAN adapter's LED didn't blink regularly as before, but only occasionally. I couldn't find anything in the logs. Can't I just change the channel number? Do I also need to change other settings? Next I tried with another WLAN adapter that only supports 2.4 GHz. I rebooted the device with the other adapter attached. It was also recognised. I updated these files to use the new network interface accordingly: /etc/network/interfaces.d/armbian.ap.nat /etc/hostapd.conf /etc/dnsmasq.conf The access point comes up on the desired channel this time. But I can't connect because dnsmasq isn't running. It wants to bind to the WLAN's IP address but that isn't assigned. I'm not sure how a statically assigned IP address can't be assigned. Maybe I need another magic spell for that one as well. So for now, nothing except 5 Ghz works. That's not enough. Here are my current config files: /etc/network/interfaces.d/armbian.ap.nat #allow-hotplug wlx0013eff45e2e # dual-band adapter allow-hotplug wlx801f02e695a0 # 2.4 GHz adapter #iface wlx0013eff45e2e inet static iface wlx801f02e695a0 inet static address 10.0.0.1 netmask 255.255.255.0 network 10.0.0.0 broadcast 10.0.0.255 /etc/hostapd.conf ssid=ARMBIAN #interface=wlx0013eff45e2e # dual-band adapter interface=wlx801f02e695a0 # 2.4 GHz adapter hw_mode=g channel=5 #bridge=br0 driver=nl80211 logger_syslog=0 logger_syslog_level=0 wmm_enabled=1 wpa=2 preamble=1 #wpa_psk=34ed41c482f2bb8ffbbf589952245121ee70c666d1186ebefa51a86b17829990 wpa_passphrase=12345678 wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP rsn_pairwise=CCMP auth_algs=1 macaddr_acl=0 ## IEEE 802.11n ieee80211n=1 ht_capab=[HT40-][SHORT-GI-40][SHORT-GI-40][DSSS_CCK-40] country_code=DE ieee80211d=1 ## IEEE 802.11n ## IEEE 802.11a #hw_mode=a # disabled for the 2.4 GHz adapter ## IEEE 802.11a ## IEEE 802.11ac #ieee80211ac=1 # disabled for the 2.4 GHz adapter vht_capab=[MAX-MPDU-11454][SHORT-GI-80][TX-STBC-2BY1][RX-STBC-1][MAX-A-MPDU-LEN-EXP3] vht_oper_chwidth=1 vht_oper_centr_freq_seg0_idx=42 ## IEEE 802.11ac # controlling enabled ctrl_interface=/var/run/hostapd ctrl_interface_group=0 /etc/dnsmasq.conf #interface=wlx0013eff45e2e # dual-band adapter interface=wlx801f02e695a0 # 2.4 GHz adapter listen-address=10.0.0.1 bind-interfaces server=8.8.8.8 domain-needed bogus-priv dhcp-range=10.0.0.10,10.0.0.199,12h This is the output of ip a: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 (...) 3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 12:42:35:f1:2d:fe brd ff:ff:ff:ff:ff:ff 4: wlx801f02e695a0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 80:1f:02:e6:95:a0 brd ff:ff:ff:ff:ff:ff eth0 is my wired network, wlan0 is the on-board WLAN I'm not using (no antenna attached). The other wlx... interfaces are the USB WLAN adapters. And this is my general system info: http://ix.io/3xLF What do I need to do to make this WLAN access point work with both adapters, and on any channel I want (supported by the hardware)?
  11. I have found the solution. The bus number must be 1, not 0 as explained everywhere. This will create the device /dev/spidev1.0 instead of spidev0.0 and applications must be adapted. But with this modification I can access the SPI device. So here's the relevant overlay configuration in /boot/armbianEnv.txt: overlays=spi-spidev param_spidev_spi_bus=1 And the SPI interface can be used only under this path: /dev/spidev1.0 Who knows where that bus number 0 leads to...
  12. I guess you mean the param_spidev_spi_bus parameter? Sorry, I've pasted the complete file in the other response that never made it to the forum. Here is the file /boot/armbianEnv.txt: verbosity=1 logo=disabled console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=spi-spidev usbhost2 usbhost3 param_spidev_spi_bus=0 rootdev=UUID=4a65461e-d8ac-4d8f-94c0-05ecd12f6d58 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u I used armbian-config to enable SPI and also read that I need to manually add this parameter to the file. That's where I am now. I followed the pinout from this image (and many others which look the same): I have now also verified that the pins work correctly as GPIO with the spi overlay disabled. So it's not a hardware failure. The software just isn't sending any SPI signal. SCLK, MOSI and CS0 remain low at all times when sending to SPI.
  13. (Finally this forum lets me enter a new topic. It's failing most of the time, making it really hard to solve my actual problem if the infrastructure also fails.) I'm using an Orange Pi Zero board and try to make it talk to a radio module via SPI. The whole thing already works on a Raspberry Pi so the module and cabling is correct. But the module doesn't respond to requests on the Orange Pi. Since this doesn't do anything, I searched for issues like this and along the way found an SPI loopback tool. I tried it and it returned all zeros. The tool readme suggests that the MOSI and MISO pins are not connected, but they are. I checked and resoldered those pins and connected both with a jumper. The hardware is 100% correct. It must be the software that doesn't understand the SPI interface here. The same tool shows a correct echo on the RasPi. I also found another topic here about the Allwinnder H6 chip where a patch in Armbian was necessary to resolve the same issue. I couldn't respond there due to a permanent forum outage and then lost the link. So I believe that the same error is in the Orange Pi Zero image. I didn't understand what was changed there, something deep within the system. The armbianmonitor -u command failed with an internal server error response, so I uploaded the logs elsewhere. The Google form in front of this bug report recommended paste.debian.net but that service is unsuitable because its length limit of 150 kB is not sufficient.
  14. Hello, I've bought a USB Bluetooth adaptor on Amazon and wanted to try it on my Armbian device, an Orange Pi Zero. The installed system is Armbian Focal (Ubuntu). That adaptor seems to have the Realtek rtl8761a chip, according to the error message in syslog. The firmware could not be found. It should be included in the "firmware-realtek" package but that doesn't exist. I couldn't find anything else that provides that firmware. That USB adaptor has an average rating, a second one I've also ordered has a better rating. Both have the same chip inside. Both don't work on a current Windows 10 because the unsigned driver from Realtek (to be downloaded from two different Chinese websites) crashes my computer (I really do mean crash, I had to unpower it). Both product descriptions only mention Windows compatibility, no Linux. But that doesn't say anything. So I thought I'd give them a last try on Linux before returning them. Does anybody know where that firmware can be found? If there's nothing available, what would be the recommended method to bring Bluetooth connectivity to a small Linux device? A different USB adaptor? A custom chip with an SPI interface? Nothing at all because Bluetooth doesn't work?
  15. Hello, Today I found that the "serial-getty@ttyS0.service" service restarts every minute. It says "serial-getty@ttyS0.service: Succeeded." in the syslog/journal and then starts again, so it exited with code 0. The restart counter is already at 3085, so it's been like that for 2 days. No output is logged from the service itself. So I looked up its start command and ran it interactively. Again, with no output, after a minute, it returned with code 0. So I straced that thing and saw that it did lots of things, then print "Password:" somewhere, wait a while and then print "Login timed out after 60 second" and exit with code 0. strace /sbin/agetty -o '-p -- \u' --keep-baud 115200,38400,9600 ttyS0 linux >agetty.trace 2>&1 Looking further up the trace, it seems that it prints "login:" somewhere several times, and once it reads single characters as input, assembling to the string: "Armbian 20.05.2 Focal ttyS0 \r" It echos every single character, then proceeds to the password prompt. But no further input is read, so it gives up. Here's the full trace output: https://ygoe.de/s/JSCkKnW7Th90xghl I'm wondering where that ghost input comes from and who is sending this string, character per character, every time? There's a USB to serial adapter connected to the serial port, but GND is currently left open (or the adapter's LED would light from the TX line voltage) and the USB is not attached anywhere. And that certainly won't generate such a string. When I had last used that USB to serial adapter, I could log in with user name and password just fine. The device is an Orange Pi Zero with (I think) Armbian_20.05.2_Orangepizero_focal_current_5.4.43. Support log: http://ix.io/2wbG
×
×
  • Create New...