Yes, this is pretty strange and we are investigating this. For some reason diversity seems to be switched off regardless of the module parameters. I am currently digging through the driver source to find all possible constraints on enabling diversity - there are quite a lot, EEPROM settings, quirks for specific models etc.
I am pretty sure that this can be enhanced!
We “just” have to find how
By the way, I’m delighted to see someone with RF/EM experience/knowledge is active in Purism. I still think of how all the effort of the OpenMoko project resulted in so much less than planned due to inadequate attention to EM/RF details.
My Librem 15 also has poor wifi performance compared with other laptops/phones in the same environment. It is very sensitive to the position of the laptop screen but I am not able to turn the screen around to the optimal point at my desk in the office.
I haven’t tried opening up the case or fiddling with drivers yet.
Like @Thomas_Habets I will probably use a USB wifi dongle for now (unless I can see any obvious problems with the cables), but I look forward to @nicole.faerber’s updates as to how we can improve performance of the built-in wifi cards.
I am happy to forgo bluetooth functionality if that would result in better wifi performance.
It would be great to know if they learn something about the problem, since I am experiencing similar issues with mine here. Opened and checked antenna cables already, loosened them up a bit, but this didn’t help. I have a hard time believing that the aluminum cover truly is shielding the antennas and the only area where they can receive properly is in the small space of the plastic hinge of the screen lid, since this would be such an obvious design flaw that someone must have noticed it earlier, right?
As a brief update, I rebuilt the driver with debugging enabled and I can verify that diversity is not enabled. I just have no idea yet why. The driver is pretty big and complex and for a bunch of chips. I will need to add debugging code to find the spot where it gets decided that diversity is not going to be used and subsequently find why it is not enabled.
What seems to be pretty clear to me already is that WiFi antenna diversity and Bluetooth coexistence are mutually exclusive. As soon as BT coex is enabled then WiFi diversity gets disabled. This is driver code and I wonder why this is. Other combined modules, e.g. Intel, can do this. But since we do not support Bluetooth right now anyway it is not a real concern.
Can you also check if antenna diversity is an issue for the Librem 13v1? Does the 13v1 have two antennas internally also? If so, is antenna diversity enabled for it? My 13v1 has always had weak WiFi abilities, much weaker than my other devices.
I do not have a 13v1 at hand to verify but I am pretty sure that the basic design is very similar. The 13v1 also has working Bluetooth once you install the non free firmware and Bluetooth is exclusively using the second antenna - if it is in use. So there must be two antennas inside the case. And since it is basically the same WiFi/BT NGFF module it is very likely that it suffers from the problem.
How would I diagnose if I had the problem on my Librem 13v1?
I’m running Qubes 3.2. It runs the Xen hypervisor (not sure which version). In the dom0 VM it has an old version of Fedora running a modified Linux 4.4.67. Both USB controllers (PCI devices) are assigned to the sys-usb VM running Fedora 25 (but running a modified Linux 4.4.67 which is provided to it by dom0). The Atheros AR3012 Bluetooth shows up as a USB device in sys-usb. The Atheros AR9462 (PCI device) is assigned to the sys-net VM which is running the same versions of Fedora and Linux as sys-usb. Note that the two different parts of the Wireless/Bluetooth chip are accessed via two different PCI devices which are assigned to two different VMs.
I don’t need or use Bluetooth so I hope no antenna is devoted to Bluetooth, or if one is then I hope it can be switched to supporting antenna diversity.
We did a little further analysis of possible problems. To put it up front, we still do not know how to really improve the situation, sorry.
By some hardware analysis (which involved taking apart devices etc.) we found that at least the antennas (yes, L13v2 and L15v3 do have two) are not the issue. The antennas are placed in the display hinge bar where the kill switches are located also. Replacing these with other antennas or changing their position did not improve the situation.
We also have the suspicion that the reception quality is fine but that the problem might be related rather to the sending path.
A little further down the road at least I have the impression that the situation has improved with more recent kernel version (4.13+). Can someone else confirm this? Now I can successfully associate with 5GHz access points which did not work at all before. There is still room for improvement but it is somewhat better.
I still uphold my theory that the TX signal strength is the problem and I suspect that the ATH9k driver is very conservative on choose the TX power. I just have not yet found a way to force it to higher TX power, the driver’s algorithm will always reset it if I manually increase it…
I also have the feeling that it got better with recent updates on my machine (using Solus here) although I’m on the LTS branch (4.9.66). This aside, it is still a big problem in everyday use and oftentimes I just use a mobile internet hotspot because it is very slow or doesn’t work at all. Like someone wrote aove, quality is degrading really fast when moving away from the router, so sometimes, when I need to download or upload something, I have to walk to the room with the router
I love using my Librem so much and use it very often, so proper WiFi would be a relief. I will just stay tuned and thanks for investigating this issue!
If the wifi card is AR9462, then antenna diversity is irrelevant since AR9462 is a 2-stream card. Diversity is used only for 1-stream cards (like AR9565 etc.) and with such cards the HW will switch reception between the main and aux antennas based on various factors to improve RX performance.
BT coexistence and antenna diversity can’t be enabled at the same time - but this limitation doesn’t apply to AR9462 since diversity is not used at all with this chip.
It’s been sometime since the last post here, so I wonder if anyone has any news on this? I am also experiencing relatively poor wifi performance on my Librem 13 v2 compared to my other devices.
If I’m not close enough, I see frequent loss of connection to APs when other devices have no problem, and when connected often considerably poorer performance than other devices. For example, my phone gets better than 100Mbit/s compared to 5 on the Librem in the same location.
I’m running pureOS with latest updates (kernel version 14.17).
I’ve seen @mladen suggest using a non-free driver from Debian buster here, but especially with a Librem I’d prefer not to use non-free. That said, I’d be interested if anyone can comment on the performance with the non-free driver - sometimes I really need working wifi in places not super close to an AP…
Thanks for the link to the other driver. I’d not seen that. Although it’s about librem15, not 13.
For me (OP) I got my librem back and it’s better, but still I’d say it’s the device I have with the worst wifi range, including raspberry pi’s with built-in on-PCB antennas.
Can confirm that the wifi performance on my Librem 13v3 running PureOS is also subpar and weaker than all my other devices. Hopefully new iterations of the Librem 13 swap out the Atheros card for a better one (using free drivers)!
Terrible wifi performance here as well, I have a librem 13 v 3 with latest updates. For the price you would expect at least a working wifi card, people should be warned!