Search the Community

exquisitus, I don't see how jhpadjustable's reply was patronizing, prejudiced, or full of attitude. He politely said that if you want to know the history of the module (and why it's not well supported) there are other threads talking about it. I really don't see how his reply is "less useful than no reply at all" since he told you where you can find more information (something you can also do with the forum's search feature). When people here provide information to users, and then get replies like yours, it's no wonder the driver situation doesn't improve. Anyone who is working to make it better just gets people coming and being offended by their answers. If you're unhappy with the state of the XR819 driver, I have the perfect place for you to go to solve your problems: https://github.com/fifteenhex/xradio/pulls I hate to say it, I really do, but I think you need to see this: https://www.youtube.com/watch?v=F-mju_gW3c8

Why? If both Ethernet magnetics and XR819 are saved the additional DRAM chip and RTL8211E might fit. Anyway: only position of the 4 mounting holes and the one prepopulated 13 pin header on the left need to be considered while PCB can grow to the right or even both sides (would love to throw the ugly GbE dongle away and now shutting up to not hijack the poll any more)

Thanks, I did read it as mentioned. 1. I just want to "confirm" (get opinions) re: software problems before I jump to @davedsbca recos. 2. What does it mean to directly connect the 13 pin connector on OPi0 to GND and TVout (= Video?) ? What cable/leads? Is there a link for the 13 pin connector pinout description for GND and one/several TVout (s)? The RCA cable is between the TRRS port on the expansion board and the Yellow/Red/White composite ports on the TV. 3. Has anyone tried the R359 resistor removal hack? My plan is to nip it from one side. Attempting complete removal might damage the expansion board ! BTW, I agree with @zador.blood-stained that the impedance match here should be 75 ohms as for cable TV, as opposed to 50 ohms which is standard for coax antennas. So maybe disabling R359 is the right thing to do. 4. Also, any latest fix for the known WiFi Internet speed issue? My $speedtest-cli shows 3.6 / 4.65 Mbps up/down. Our Xunlong friends here have created a mess here... how come they haven't swapped the XR819 for an already used Realtek WiFi chip and fixed the expansion board issue in a new Orange Pi Zero edition? Xunlong has been churning a lot of models anyway. These issues render the OPi0 price/performance potential to humdrum.

Wireless connection? Yes, it's normal - all initiatives that this is fixed to some normal state were failed, documentation does not exits and investing more time solo into this problem is long gone. New Zero comes with AP6212 which is working O.K. This is written at download page: Onboard wireless chip (XR819) has poor software support so wireless connection issues are expected And if you do some forum search, you will get even more information about this problem.

The driver is still there (and ready for 4.11) but not included any more for reasons explained above: https://github.com/armbian/build/issues/663#issuecomment-299268016 BTW: part of the problem IMO is amount/lack of feedback. Some very loud voices constantly blame Armbian and those volunteers who tried hard to improve the driver (see links above) for being incompetent/reluctant/whatever and XR819 not working at all while we received almost zero feedback stating the opposite (as your 'driver worked perfectly for me') In other words: Dealing with XR819 is not only frustrating based on technical details (low performance, crappy driver code drop, lack of documentation) but also due to end user feedback and expectations.

Then you shouldn't have updated the kernel. The driver is disabled in 4.11 and it will not be readded unless all major issues (that we consider major) are fixed (and it doesn't depend on us since we don't have resources or documentation to do this) You may be able to find and compile out of tree driver for the XR819 chip, but not the one you have linked - that one AFAIK is for the 3.10.x kernel.

See the "Orange Pi Zero wireless module status" pinned thread and other XR819-related threads in this H2/H3 subforum. Shorter: Are you volunteering? If not, then probably not: too many users with too little patience having too high expectations of too weak a wireless chip with too little and too poor public documentation/drivers You could fall back to the ill-reputed legacy kernel, obtain a supported USB wireless adapter, or configure and build your own kernel with xradio_wlan enabled https://github.com/armbian/build/. Whatever you choose, good luck.

Effectively, the WiFi XR819 driver is defective under 4.11, so we leave it disabled for now ...

Hi All, On new revision of Orange Pi Zero (512M) board, chinsee engineers changed the PCB by removed the R66/R69 resistors (PA20 / Wifi power logical pull up). As I measured on board the PA20 line can be accessed on pin of XR819 power supply LDO (5V/1.8V). The U58 IC pin3 (marked on photo) should be elevate from PCB and should pull up to 3.3V logical "1" level. The PA20 line for I2S data out is accessed from pcb pin. Good luck!

I know and that's why I'm asking a NanoPi Air owner for help Unfortunately I can't help with Air right now since I don't find those little guys (too small ). But I remembered that we could convince FriendlyELEC to drop partially Allwinner's BSP stuff so maybe we find the necessary bits over there: https://github.com/friendlyarm/linux/commits/sunxi-4.11.y (funnily the redesigned NanoPi NEO Plus 2 to avoid XR819 there and replace it with AP6212A)

Talking back then about NanoPi NEO Plus 2. Not so surprisingly FriendlyELEC discovered what a shit show XR819 is and did what? Replaced it with AP6212A instead: https://github.com/friendlyarm/linux/commits/sunxi-4.11.y On the bright side: We could convince them to focus on mainline kernel and for a certain amount of boards they're already at it

Ok, so we can see probe requests going out from the xr819 (as long as this is not captured on the orange pi zero) and no probe response. I think you said this works with the legacy kernel driver. Can you capture the packets there so we can compare?

The amount of retries needed to get a frame in/out of the wifi interface affects more than just throughput. It can break association, DHCP etc. Of course you know all of this because you know better than everyone else right? It works for me from what I remember. I actually broke WPA/WPA2 support at some point trying to get the chip to pass encrypted frames directly to the kernel and connecting to open aps was the only thing that worked. As far as I can tell you haven't actually posted anything to show what happens when you try to connect to an open AP let alone anything that shows your issue is an issue with the xradio driver. And... it could be an issue that is unsolvable without more details on the firmware running on the chip. The xr819 doesn't just take frames off of the air and pass them to the host. Maybe it thinks it should be decrypting frames it shouldn't? Who knows. Maybe it is easy to fix but where are the logs and packet dumps? I'm not sure what your idea of reporting a bug is but it's not "This doesn't work for me, fix it now!". I don't think you have ever said where it fails to connect.. not associating outright is different to no passing any IP traffic etc.

Same with the non anachronistic way (using nmtui as recommended). BTW: http://www.cnx-software.com/2016/11/10/allwinner-h2-linux-android-sdk-and-allwinner-xr819-wifi-driver-released/#comment-541282

You're saying that mainline is recommended in any case but with legacy kernel i can connect to my open AP .Also in this thread you mentioned it as best driver but this problem only occurs on mainline.. If its lack of hw it cant be connected with legacy am i wrong? I appreciate your effort and i thank you for it but developers just given up with this xr819 driver and cant accept any discussion. I even tried to compile driver from sources and changed some flags but cant get it worked. I found a xradio to cw1200 port in git but cant compile it https://github.com/plaes/xradio. little help ? thanks again

Hi everyone, I was doing speed tests on the XR819 and started looking at the driver code. My this looks very similar to the cw1200 driver already in mainline Linux. I started modifying the cw1200 driver to try and get it to work with the XR819. Apart from someone renaming functions and adding a bunch of important junk for XR819, the drivers are quite similar. I've modified the cw1200 driver up to the point that it's loading the boot_cw1x60.bin ( boot_xr819.bin ) file, but for some reason the bootloader is returning an error instead of success. I don't think it's possible to diagnose this without the datasheet from ST. Clearly this exists, because people were able to write the cw1200 driver for mainline. Does anyone have a clue where I might find the datasheet for the CW1100? I also haven't been able to find the firmware files from ST for this chip. They don't exist in the linux-firmware tree! Here's my progress thus far: Try to load cw1200_wlan_sdio first time. Timeout waiting for bootloader to respond (I think XR819 has the same bug, no?) Unload the module and load it again: Here's my diff to the mainline driver.

H2+/H3/H5 boards overview (2017/03 update) Since it has been a while since this topic has been updated and a lot of new boards have been released in the meantime it's time for a new overview. I'll add also H2+ and H5 based boards since in the meantime we learned that those SoCs are pin-to-pin compatible and recently vendors started to simply exchange H3 with H5 on some PCB (and vice versa in at least one occurence). From a software point of view H5 is quite different (using 64-bit Cortex-A53 CPU cores and ARMv8 instruction set, some early boot stages are also totally different compared to Cortex-A7/ARMv7 used in H3 and H2+) and it should also be noted that Armbian currently only provides OS images based on mainline kernel for H5 boards (so please forget about HW accelerated video decoding or 3D for now or maybe ever since none of the developers is in the mood to deal with Allwinner's BSP/legacy kernel for H5 (regarding 'BSP' just look above in post #2). While software support for H5 is currently somewhat different hardware features are pretty much the same as with H3 (still 3 to 4 real USB2 host ports and one USB2 OTG port: a simple register setting can switch the Micro USB port's PHY between the so called 'musb' controller used for OTG and a real EHCI/OHCI controller pair: with mainline kernel it will soon be possible to switch OTG to a real 4th USB2 host port with full feature set that still has not to share bandwidth with any of the other USB ports). CPU performance with H5 compared to H3 is slightly higher at the same clockspeed but some workloads that benefit from either 64-bit or ARMv8 instruction set are significantly faster (eg. software making use of NEON instructions might perform almost twice as fast and the best example is the stupid 'sysbench' CPU pseudo benchmark which shows over 10 times better scores on the same hardware when compiled with ARMv8 settings). In the following list I will also introduce some subjective 'categories' to deal better with the huge amount of boards we can use in the meantime: NAS category: these are the H3/H5 boards with Gigabit Ethernet IoT category: these are the small and cheap boards best suited for low consumption 'General purpose' category: all the other H3 devices, these are also those you should look for if you want a cheap device to run with X11, OpenELEC, RetrOrangePi or Lakka since they all feature HDMI and full legacy kernel support As already said the differentiation is subjective and partially misleading since new boards like NanoPi NEO 2 featuring Gigabit Ethernet are also that inexpensive, small and energy efficient that they could serve both as NAS and IoT nodes (actually you can somewhat control behaviour since GbE vs. Fast Ethernet makes a pretty huge difference in consumption so it's up to you). Boards that might fit in multiple categories are listed more than once to make comparisons more simple if you're only interested in a specific device category: NAS category (only due to Gigabit Ethernet available): Banana Pi M2+: H3, 1GB DRAM, 8GB slow eMMC, 1+2 USB ports useable, Wi-Fi/BT Banana Pi M2+ EDU: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable NanoPi M1 Plus: H3, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi M1 Plus 2: H5, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+2+2 USB ports useable, Wi-Fi OrangePi PC 2: H5, 1GB DRAM, no eMMC, 1+3 USB ports useable OrangePi PC Prime: H5, 2GB DRAM, 1+3 USB ports useable, Wi-Fi/BT OrangePi Plus: H3, 1GB DRAM, 8GB eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2: H3, 2GB DRAM, 16GB fast eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2E: H3, 2GB DRAM, 16GB fast eMMC, 1+3 USB ports useable, Wi-Fi IoT category (cheap, small, energy efficient, most of them headless): NanoPi Air: H3, 512MB DRAM, 8GB slow eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet NanoPi NEO: H3, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Fast Ethernet NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Gigabit Ethernet NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Gigabit Ethernet OrangePi Zero: H2+, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI OrangePi Zero Plus 2: H5, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI General purpose (HDMI and full legacy kernel support: video/3D HW accelerated): Beelink X2: H3, 1GB DRAM, 8GB slow eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet NanoPi M1: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi Lite: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable, Wi-Fi, no Ethernet OrangePi One: H3, 512MB DRAM, no eMMC, 1+1 USB ports useable, Fast Ethernet OrangePi PC: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi PC Plus: H3, 1GB DRAM, 8GB fast eMMC, 1+3 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet pcDuino Nano 4: See above, it's just an OEM version of NanoPi M1 done for Linksprite Some important notes: The following boards are listed in more than 1 category due to advanced feature mix: NanoPi NEO 2, NanoPi NEO Plus 2 and OrangePi Zero Plus 2 H3/H5 CE/FCC certifications: Please check individually and don't trust in logos silkscreened on the PCB, even if it looks like 'CE' it might mean 'China Export' instead IO bandwidth: H2+/H3/H5 SoC features 3+1 USB2 ports but on a few boards an internal USB hub is used so while these expose more USB receptacles some ports have to share bandwidth. Also on these boards a buggy/slow GL830 USB-to-SATA bridge is used. Search for 'hub' above to identify them. eMMC: shows most of the times higher random IO performance compared to 'the average SD card', but some vendors use pretty slow eMMC on their boards (Xunlong being the exception with OPi PC Plus, Plus, Plus 2, Plus 2E and Zero Plus 2). Please do not overestimate eMMC -- there's no need to choose crappy/slow SD cards and if you follow the usual recommendations difference in performance varies not that much (for example eMMC on most boards shows pretty low sequential write speeds that will be easily outperformed by any good SD card and differences in random IO don't have to be that huge, simply watch out for SD cards showing A1 or even A2 logo) USB ports: Some of the IoT devices have two of the SoC's USB host ports available on a pin header to be used with soldering or combined with various Docks, HATs or 'Expansion boards' (search for '1+1+2' above). On OPi One/Lite the unexposed USB host ports are available at pretty tiny solder pads so only usable with a lot of soldering experience Wi-Fi/BT: all boards providing both Wi-Fi and BT rely on Ampak's AP6212 so performance is identical, the Wi-Fi only boards either rely on RTL8189ETV/8189FTV (slightly better Wi-Fi performance than AP6212) or Allwinner's XR819 (so expect low Wi-Fi performance with OPi Zero or NEO Plus 2 since implementation is low-end and currently driver sucks) Yeah, each vendor's naming scheme totally sucks. Partially there are rules involved (the 'Plus' then means eMMC with Xunlong or GBit Ethernet with FriendlyELEC... mostly) but please don't trust in and check always individually! And now another few words on a different technical detail affecting both performance and thermal behaviour of the various boards: Voltage regulation / DVFS. TL;DR: the SoC can be fed with a variable voltage (VDD_CPUX), the lower the voltage the lower the temperature (less problems with heat/overheating), the higher the voltage the higher the maximum CPU clockspeed. So the best idea is to adjust this dynamically (low voltage/clockspeed when idle and only increasing both when needed). There are 3 variants to implement this: not at all, primitive or advanced (using a voltage regulator that's able to adjust VDD_CPUX in 20mV steps) Only 3 devices implement no voltage regulation at all: Banana Pi M2+/EDU (frying the SoC constantly at 1.3V therefore prone to overheating), Beelink X2 (no idea) and NEO 2 (only 1.1V therefore limited to 1008MHz cpufreq max since above instabilities might occur). Some boards use SY8106A I2C accessible voltage regulator where we can use fine grained voltage settings (Armbian fine-tuned these for every board so far to achieve max performance). This applies only to the following Xunlong boards: OPi PC, PC Plus, PC 2, PC 3, Plus, Plus 2 and Plus 2E. All other boards implement a simple two voltage scheme and are able to switch between 1.1V (up to 912MHz possible with H2+/H3 or 1008MHz with H5) or 1.3V (1.2GHz max with H2+/H3 and 1.25GHz with H5) And finally to add some stupid rankings: the cheapest board is from Xunlong (Orange Pi Zero: $7), the fastest is from Xunlong (Orange Pi PC 2 for $20) and the one with best feature set and onboard peripherals is also from Xunlong (Orange Pi Plus 2E: $35). And that's only due to OrangePi PC 3 Prime still not being released at the time of this writing (since otherwise regarding both performance and features this specific Xunlong board... ) Hope that helps Edit: OPi 3 is now known as OPi Prime and (almost) nothing has changed compared to the leaked pictures back from last August.

And the next mutation is just around the corner: NEO Plus 2: H5, camera connector for OV5640, voltage regulation is back (1.1V and 1.3V as usual but FriendlyELEC admits that it does not work software-wise yet -- obviously this is about Allwinner's BSP kernel since with mainline it should just work), and surprisingly XR819 Wi-Fi as known from OPi Zero. Open question: How does FriendlyELEC deal with the 2nd USB receptacle on the board (since USB data lines might be also available on the 12 pin header). Don't ask about availability please -- we don't know.

Well, I'll started with what we have already in Xunlong's repo: https://github.com/igorpecovnik/lib/commit/2f9e9e6feae3cc3037a52ba0be8295761cb1f586 BTW: I detected a potential collision: PA10 is routed to pin 26 of the GPIO header on normal Zero but according to Xunlong's sys_config.fex now used for BT. We'll see. @Igordo you know whether Steven ships out dev samples? I would accept one as the last board adding to my collection for the next 3 months. Doing some test with the NAS Expansion board and regular Zero (XR819) would be great too. So maybe if you're talking to him next time you can ask whether he would ship out the three items?

Pulpstone OrangePiZero OpenWrt Chaos Calmer 15.05.1 ============================ Orange Pi Zero Hardware specification CPU H2 Quad-core Cortex-A7 H.265/HEVC 1080P. GPU Mali400MP2 GPU @600MHz Memory 512MB DDR3 TF card (Max. 64GB)/ NOR Flash(2MB Default not posted) 10/100M Ethernet WIFI XR819, IEEE 802.11 b/g/n [http://www.orangepi.org/orangepizero/] . . Pulpstone OrangePiZero Added : All Modem Packages Support 4G Modem Support HiLink Modem Support USB Tethering Android Support SFTP Server Pulpstone Mikodemos v5 (fix restart OpenVPN) Pulpstone MJPG Streamer (gigi webcam-uvc) Pulpstone Tramsmission Pulpstone miniDLNA LuCI-App-SQM LuCI-App-Access-Control LuCI-App-HD-Idle LuCI-Theme-DarkMatter 3G/4G Info by eko.one.pl Samba Network Shares (NTFS/EXT4) MPD (soundcard internal + fix volume button n sound) ping_loop v3 Mikodemos - Design by Andriawan Simple Network Interface Profile Fix Bridging Lan and Wireless Support USB WiFi . . Basic Information : LAN = LAN LuCI '192.168.1' Username/Password 'root / root' SSID Wifi 'OrangePiZero' SSID Password 'internet' Default Modem Device '/dev/tty/USB0' Service Type 'UMTS Only' APN 'internet' 3G/4G Info '192.168.1.1:81' ping_loop GUI '192.168.1.1/cgi-bin/pingloop' Pulpstone Mikodemos v5 '192.168.1.1/pulpstone' Pulpstone MJPG Streamer '192.168.1.1:8291' ** Pulpstone Tramsmission '192.168.1.1:9091' ** **username/password = pulpstone/pulpstone . . How to flash OpenWrt to MicroSD card ------------------------------------------------------- On a Linux desktop and Windows desktop insert your MicroSD Extract image use Etcher software to write the img file to your MicroSD card's. [https://etcher.io/#downloads] . . Regrads, FuadSalim [https://www.facebook.com/fuad.salim.drg] . .

Which is nothing that applies to any of the devices Armbian runs on except maybe early OPi Zero boards with unpopulated SPI flash pads where people want to solder such small amounts of NOR flash to? Anyway: this thread started with a simple claim: Replace Armbian userland with OpenWRT's and magically XR819 Wi-Fi is fixed (see page 1 and @hyphop's posts). While those people looking into the driver came to different conclusions: https://forum.armbian.com/index.php/topic/2808-orange-pi-zero-went-to-the-market/page-5 (interrupt handling and TX retransmits for whatever reasons, at least the latter doesn't look like fixable by exchanging the userland) I believe a lot of people believe in OpenWRT making their Wi-Fi on OPi Zero working and that's all based on ping roundtrip times published by one single individual. I haven't seen any iperf3 numbers comparing the OpenWRT approach with Armbian in an identical environment and also know nothing about how those pings were generated (we know that H2+ legacy kernel has its own ideas about which interface to choose for packets, so in case OPi Zero was connected with both Ethernet and Wi-Fi packets might came back through Ethernet instead). And if I would really want crappy Wi-Fi I would at least go for "Antenna diversity", search for my 'La fonera' somewhere lying around here and do this 'hardware hack' and then run OpenWRT on it. But since 2.4GHz band here is unusable in the meantime 5GHz are mandatory anyway.

Hi, I'm planning on buying Orange Pi Zero and before I do that, I want to make sure I won't regret anything after buying it. I'm planning on using the pi zero as a wireless router with its built-in wifi, but I read on some posts that the driver XR819 itself has some issues, like heating up the board or high ping. So please suggest me which distro I should use for the pi zero that has no wifi issues. Thank you.

To add some information to your experiences. OPi Zero Wi-Fi is single antenna low power/performance Wi-Fi in 2.4 GHz band. In crowded areas most of the 'performance possible' depends on the environment around (how many neighbours running also 2.4 GHz networks, which channels/bands used, interference with eg. microwave ovens, how many users/devices are actively consuming bandwidth). I let NetSpot Pro (the free version is already ok for this purpose) run at my location for 48 hours: 139 Wi-Fi networks in total detected, just 14 in 5 GHz band (that was with a MacBook Pro making use of multiple good antennas, with the better of those cheap SBC Wi-Fi implementations only ~40 nets are detected). It started 2-3 years ago that the laptop we use in the kitchen wasn't able to play 'normal' Youtube videos in the evening hours. It's running OS X but is a 'PC laptop' (read as: usually low performance Wi-Fi) and I had to discover that's due to 2.4 GHz band becoming pretty unusable especially in the evening when everyone around uses also Wi-Fi extensively. At my location 2.4 GHz with somewhat reasonable throughput/latency only works during the night and somewhat during the day but not in the evening (any more). That's important to keep in mind since if you're not the only one using the available Wi-Fi channels performance in 2.4 GHz band might depend more on everything around you than your own equipment (it's shared media and not a dedicated cable of known quality). Adding to that XR819 Wi-Fi in OPi Zero might just be the new definition of low end (for some technical insights look in this thread and search forum for @dgp comments) and currently there is one issue with the driver used: High rate of TX retransmissions that affect performance/latency negatively of packets sent by OPi Zero (RX is the other direction). No one ever will touch the legacy kernel variant of this driver, for the mainline version we'll see probably a fix sometimes in the future that addresses the TX retransmits. Then Wi-Fi 'performance' with this device will improve from 'total crap' to 'just crap' So regarding your above scenario you mostly use RX (loading media files from the NAS, indexing) -- in TX direction just some HTTP requests happen. Also it depends on your media files. If you use MP3 files with 128 kbps bitrate then of course a Wi-Fi connection providing somewhat stable 200 Kbits/sec (that's not 200 kbps) will suffice since every media streaming/playing software uses buffering, analyzes throughput/latency when starting to stream and the better ones increase buffer sizes automagically (leading to a longer delay before you can hear something) if they measure drops or very low bandwidth available. So when you use 'audio streaming' as test case everything depends on the file formats (and media codecs) you use. If you would choose lossless formats like AIFF and WAV for example instead of MP3 then poor Wi-Fi performance can become a showstopper since bitrates are way too high. Regarding 'indexing new music' it matters also which format you use: AIFF for example supports the same ID3v2 tags as MP3 does so indexing when it's only about metadata might be as fast as with MP3 even if the files need way more space on disk (and available bandwidth to be transmitted over the network). @aliceander: Since you're one of the few people trying to use the OPi Zero as intended ('small IoT projects') Wi-Fi should suffice. Just don't expect wonders regarding bandwidth and distance though the latter can be somewhat fixed using a better antenna -- that might cost multiple times more than the Zero -- and of course by using an appropriate AP. But for 'small IoT projects' it should be already fine and 'performance' in TX direction might improve over time with the mainline kernel once a kind soul took the time to start a wireless sniffer, analyzes the problem in TX direction and codes the necessary fix.

Hi everyone, First of all I'd like to express my appreciation for the folks working on Armbian. I recently discovered the OPI0 and see many applications that could use an inexpensive yet full fledged embedded linux system. I'm not too concerned about the wireless throughput of the OPI0 but I do need stability, which I have not been able to achieve so far. I'm using the OPI0 as an AP with it's wireless interface bridged to the LAN interface. DHCP, DNS, gateway etc all provided for by another node on the network. A wireless device associates successfully, get's a bit of network access but as soon as I play a Youtube video it all starts failing. Here are some parts of dmesg and syslog although I guess most of you have already seen the message related to XRADIO (I've removed the bits that are likely not relevant). Has anyone been able to get the wireless to work reliably? [ 6.601429] [XRADIO] Driver Label:L34M.01.08.0002 Nov 14 2016 08:41:12 [ 6.601543] [XRADIO] Allocated hw_priv @ d5bf1240 [ 6.602314] [sBUS] XRadio Device:sdio clk=50000000 [ 6.602643] xradio wlan power on [ 6.754844] [XRADIO] Detect SDIO card 1 [ 7.101435] [XRADIO_ERR] xradio_load_firmware: can't read config register, err=-110. [ 7.101473] [XRADIO_ERR] xradio_load_firmware failed(-110). [ 7.437706] xradio wlan power off [ 7.437753] gpio wl_reg_on set val 0, act val 0 [ 7.487840] [XRADIO] Remove SDIO card 1 [ 7.488148] mmc1: card 0001 removed [ 7.488590] [mmc]: sdc1 power_supply is null [ 7.500494] systemd[1]: Started Journal Service. [ 7.540998] [XRADIO_ERR] xradio_host_dbg_init failed=2599 [ 7.541040] [XRADIO] Driver Label:L34M.01.08.0002 Nov 14 2016 08:41:12 [ 7.541148] [XRADIO] Allocated hw_priv @ d5bf1240 [ 7.541741] xradio wlan power on [ 7.541774] gpio wl_reg_on set val 1, act val 1 [ 7.591834] gpio wl_reg_on set val 0, act val 0 [ 7.593888] gpio wl_reg_on set val 1, act val 1 [ 7.694070] [XRADIO] Detect SDIO card 1 [ 7.695583] [mmc]: sdc1 power_supply is null [ 7.749447] mmc1: new high speed SDIO card at address 0001 [ 7.750272] [sBUS] XRadio Device:sdio clk=50000000 [ 7.751341] [XRADIO] XRADIO_HW_REV 1.0 detected. [ 7.947908] [XRADIO] Bootloader complete [ 8.185099] [XRADIO] Firmware completed. [ 8.187818] [WSM] Firmware Label:XR_C01.08.0043 Jun 6 2016 20:41:04 [ 8.196411] [XRADIO] Firmware Startup Done. [ 8.198911] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht' [ 8.313819] sunxi_i2c_do_xfer()985 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x48) [ 8.315067] sunxi_i2c_do_xfer()985 - [i2c0] incomplete xfer (status: 0x48, dev addr: 0x48) [ 8.318255] sunxi_i2c_do_xfer()985 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x77) [ 8.318316] bmp085: probe of 0-0077 failed with error -70 [ 8.966173] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro [ 9.344995] Adding 131068k swap on /var/swap. Priority:-1 extents:1 across:131068k SS [ 10.927838] systemd-journald[173]: Received request to flush runtime journal from PID 1 [ 11.372011] Bridge firewalling registered [ 14.440409] PHY: gmac0-0:00 - Link is Up - 100/Full [ 14.441407] br0: port 1(eth0) entered forwarding state [ 77.913076] device wlan0 entered promiscuous mode [ 77.913240] br0: port 2(wlan0) entered forwarding state [ 78.040468] [AP_WRN] ap restarting! [ 78.092772] [AP_WRN] vif0, AP/GO mode THROTTLE=35 [ 92.960132] br0: port 2(wlan0) entered forwarding state root@opi55:/lib/firmware/xr819# tail -f /var/log/syslog Feb 1 18:18:14 localhost systemd[1]: Started Session 3 of user root. Feb 1 18:18:18 localhost kernel: [ 92.960132] br0: port 2(wlan0) entered forwarding state Feb 1 18:21:06 localhost kernel: [ 261.050133] [AP_WRN] Multicast delivery timeout. ...snap... Feb 1 18:21:39 localhost kernel: [ 293.860293] [WSM_ERR] wsm_flush_tx:No pengding, but hw_bufs_used=1 ...snap... Feb 1 18:21:59 localhost kernel: [ 314.740116] [AP_WRN] Multicast delivery timeout. Feb 1 18:22:30 localhost kernel: [ 345.220307] [bH_WRN] miss interrupt! Feb 1 18:22:42 localhost kernel: [ 357.570241] [AP_WRN] Multicast delivery timeout. Feb 1 18:23:35 localhost kernel: [ 409.991567] [WSM_WRN] Too many attempts to requeue a frame. Frame is dropped, fctl=0x4208. Feb 1 18:23:35 localhost kernel: [ 410.350102] [AP_WRN] Multicast delivery timeout. Feb 1 18:23:41 localhost kernel: [ 415.997716] [WSM_WRN] Too many attempts to requeue a frame. Frame is dropped, fctl=0x4208. Feb 1 18:24:56 localhost kernel: [ 491.690269] [bH_WRN] miss interrupt! Feb 1 18:24:57 localhost kernel: [ 491.850202] [AP_WRN] Multicast delivery timeout. Feb 1 18:25:12 localhost kernel: [ 507.073815] [WSM_WRN] Too many attempts to requeue a frame. Frame is dropped, fctl=0x4208. Feb 1 18:25:38 localhost kernel: [ 533.210214] [AP_WRN] Multicast delivery timeout. Feb 1 18:25:54 localhost kernel: [ 549.137943] [WSM_ERR] wsm_flush_tx:No pengding, but hw_bufs_used=1 Feb 1 18:26:14 localhost kernel: [ 569.650088] [AP_WRN] Multicast delivery timeout. Feb 1 18:26:15 localhost kernel: [ 570.162082] [WSM_WRN] Too many attempts to requeue a frame. Frame is dropped, fctl=0x4208. Feb 1 18:26:23 localhost kernel: [ 578.290174] [AP_WRN] Multicast delivery timeout. ^C root@opi55:/lib/firmware/xr819# ls -al total 144 drwxr-xr-x 2 root root 4096 Nov 14 21:14 . drwxr-xr-x 12 root root 4096 Nov 14 21:14 .. -rw-r--r-- 1 root root 2308 Nov 11 00:14 boot_xr819.bin -rw-r--r-- 1 root root 975 Nov 11 00:14 device-xradio.mk -rw-r--r-- 1 root root 126416 Nov 11 00:14 fw_xr819.bin -rw-r--r-- 1 root root 744 Nov 11 00:14 sdd_xr819.bin root@opi55:/lib/firmware/xr819# uname -a Linux opi55 3.4.113-sun8i #50 SMP PREEMPT Mon Nov 14 08:41:55 CET 2016 armv7l GNU/Linux [ENDS]

Unfortunately you're hoping like a lot of OPi Zero customers for wonders. Even if the driver will be fixed once XR819 won't be great.