Librem 5 Wi-Fi performance


But then I think there is a potential for confusion because that command, although it shows the installed package version as you say, does not show which kernel is currently running?

I mean, in the situation right after I installed a new kernel package but while I have not yet rebooted, that command will show the new kernel version but I am still running the old version, until I reboot, I think. If everyone takes the habit of always rebooting directly after installing the new kernel package then there is no problem of course.

Then you can always report the whole output of uname -a, like:

Linux librem5 5.11.0-1-librem5 #1 SMP PREEMPT Mon Mar 22 14:21:27 PDT 2021 aarch64 GNU/Linux

This includes the build date, which can be mapped back to the package version.


Great, looking at the build date solves the problem for me. I had actually run uname -a before and after reboot but it didn’t occur to me to look at the date. Now I see the difference there.

Before reboot:

purism@pureos:~$ uname -a
Linux pureos 5.11.0-1-librem5 #1 SMP PREEMPT Wed Mar 17 02:15:51 PDT 2021 aarch64 GNU/Linux

After reboot:

purism@pureos:~$ uname -a
Linux pureos 5.11.0-1-librem5 #1 SMP PREEMPT Tue Mar 23 15:28:50 PDT 2021 aarch64 GNU/Linux

Thanks again for your help. I’m learning a lot on this forum today, as usual. :slight_smile:


While we are discussing this kind of issue, I notice that the notes for the update (that it invites me to read each time) are always content free:

Includes performance, stability and security improvements

(This is using the GUI to update.)

I understand that noone wants to devote Purism resources to writing actual release notes. That’s fine. So would it be possible instead to generate release notes automatically with just the updated package versions (although in this case it would seemingly have to specify the build date)?


I have no performance data to share but one thing I have noted is the following.

There is a place in the house where the charger is.

When I first received the Librem 5 it was possible to put the phone on charge but still work away remotely on it (sshed in).

In the last few weeks that is no longer possible. In the same place in the house the Librem 5 will lose WiFi signal. (This is 5 GHz only. The 2.4 GHz SSID is not even configured in the phone. There is only one WAP.)

Coincidence? Maybe. Of course I will claim that nothing else has changed. :wink:

Apart from this, I don’t have any WiFi reliability problems. When the phone is closer to the WAP, the connection is stable.

Are there any settings here that might be relevant? Some trade-off that has been made in the settings?

Anything that I should be looking at?

1 Like

That would be an issue with the Store’s GUI then, since the packages have their changelogs properly filled in:

purism@librem5:~$ apt changelog linux-image-5.11.0-1-librem5 
linux-librem5 (5.11.8pureos1) byzantium; urgency=medium

  [ Sebastian Krzyszkowiak ]
  * [9fcc84f] Revert "redpine: Clean up loop in the interrupt handler"
  * [1108550] Revert "redpine: Move card interrupt handling to RX thread"

  [ Martin Kepplinger ]
  * [c0865eb] Revert "mx6s_capture: switch base addr atomically by DMA completed"
  * [ca2fe5f] hi846: cleanup
  * [0ef20b3] hi846: move reg definitions from header to source file
  * [034c507] hi846: add dorotas debug regs interface
  * [85d44f0] hi846: document raw8 setting bit
  * [a96b6f7] hi846: improve exposure / integration time comment
  * [f875daf] hi846: disable 3264 mode for now
  * [dc166c3] arm64: dts: imx8mq-librem5: enable two-8bit-sensor-mode for csi1
  * [689d241] arm64: dts: imx8mq: set csi1 phy clk to 200mhz
  * [a157d9b] Merge tag 'v5.11.8' into stable/5.11.8

  [ Dorota Czaplejewicz ]
  * [042b4b7] s5k3l6xx: Respect lane count
  * [4cb8c66] librem5: use only 2 lanes for CSI2 camera.
  * [4fee411] s5k3l6xx: Add gain control
  * [b6c2831] Librem 5: Boost clocks for CSI2
  * [341e727] mx6s_capture: Fix size setting
  * [be37083] s5k3l6xx: Preserve controls across power ups and downs
  * [0974db0] s5k3l6xx: Introduce an empty debug frame
  * [1f20b7c] s5k3l6xx: Allow accepting whatever size the userspace requests
  * [788b16a] s5k3l6xx: Add debugfs register override interface
  * [ecaf256] mx6s_capture: Add debug switch for selecting baseaddr_switch
  * [f4ddd5f] s5k3l6xx: Add 1:4 scaled mode
  * [5efdacd] s5k3l6xx: Use actual 1:2 mode
  * [0b77889] s5k3l6xx: Use actual 1:1 mode
  * [e71bdc7] s5k3l6xx: Remove separate PLL register setting

  [ Angus Ainslie ]
  * [786ca43] mx6s_capture.c: export all of the controls

 -- Martin Kepplinger <>  Mon, 22 Mar 2021 16:34:49 +0100

linux-librem5 (5.11.6pureos1) byzantium; urgency=medium

  [ Elias Rudberg ]
  * [51877d8] Remove vdo part of tps6598x_rx_identity_reg struct

  [ Martin Kepplinger ]

I don’t think that it is (directly) related to power saving mode.

I can walk to the charging station, pinging continuously, and watch the RSSI icon at the top of the screen reduce and die, and watch the pings go from working to “Destination Host Unreachable” to “Network is unreachable”.

I can walk to the charging station, scanning the actual RSSI number continuously, and watch it progressively lower until, apparently, the signal is no longer viable.

Doing either of those things should keep the WiFi card and other relevant components from power saving.

I can accept that perhaps the signal at the charging station was always marginal but it does seem as if it has become weaker.

A theory about this: it could be that the signal in that place is weak for certain frequency band(s) but not for others. Then, it could be that the change you have noticed is due to a change in the frequency band(s) being used, for whatever reason that may happen. Anyway, in that case it does not necessarily indicate any new bug or so, if it just selects a different band/channel now. This command can be used to show which channel is currently used:

iw dev

You could check that when doing tests, then maybe you could find that performance is bad at a certain location when a certain band is used, but not when another band is used. Maybe. Just speculating.

It would be great if there was some way to get some kind of diagnostics info about how the wifi is working.

The WAP is configured to use a specific channel. It is not set to “Auto” for the channel. The channel has not changed.

Still investigating …

The only diagnostic that I have at the moment is iw wlan0 scan which shows a mass of information, including the signal strength.

1 Like

OK. Another theory then: maybe your next door neighbors turned on a new gadget they have that interferes with your wifi in certain locations?

For the sake of troubleshooting it would probably be best to live alone far away from civilization, with no other radio waves than those from the WAP and the L5. :upside_down_face:

1 Like

Fair theory. For sure no spurious SSIDs show up (e.g. with the above scan or with the same scan on any other WiFi-capable device) but I probably can’t rule out a gadget that nukes the 5 GHz band with non-WiFi traffic, whether that’s one of my gadgets or a neighbour’s gadget with a high-gain antenna. :wink:

I don’t know exactly what the sources of interference in the 5 GHz band are. In the 2.4 GHz band, it’s for example leaky microwave ovens and cordless phones that are using that band.

Another awkward fact: The Librem 5 is back working again for access via WiFi while at the charging station. (This kind of intermittency is consistent with noise, rather than a signal problem. It remains to be seen whether intermittency occurs again.)

I did apply some updates this morning. Did it make a difference? Anyone’s guess … The investigation continues …

1 Like

There are so many parameters affecting Wifi. Maby we should specify one or more standard test scenarios and put together a script that collects information by running some tools and log them with date and time. This would give us a systematic procedure and comparable results. At least more than with unsystematic modus operandi.


Why too many troubles with Librem 5 Wlan? I using my Evergreen everyday and i do not having any troubles with wifi 5Ghz or 2.4Ghz. Librem 5 just support 802.11n-5-2.4Ghz so maybe you need to config your router to run only with 802.11n to prevent conflicts.

1 Like

? I’d start “my” investigation (most probably only indirectly related to the Librem 5 Wi-Fi performance) here: “MLCCs do not always sit quietly on the board and do their job.” Or here:

Actually only thing that I want to point out here is to try not to experiment further with low quality chargers (if so) that might easily interfere (this or that way) with …

@irvinewade, just another “thought” of mine (that might help? or not).


@Quarnero good point! Noise coming from USB 3 peripherals is also a thing to consider:


irvinewade mentioned 5 Ghz. Personally, I run 2.4 Ghz for better coverage through walls. Some say that using 2.4 only saves on power. I use automatic channel selection on my AP, but I guess setting to the upper channel would be best for avoiding USB 3 interference. I was reminded of this:

I wonder if the Librem 5’s internal display has any impact on WiFi as well, and would some resolutions on an external display have an effect.

It would be nice to have a phone friendly SDR app (maybe a RTL-SDR can run from the Librem 5?) to help hunt down WiFi problems. A directional antenna would probably be more effective for locating.

As usual, the right way to do this is to file an issue in the bug tracker. Otherwise you can be fairly sure the right person won’t notice.


Certainly a good suggestion (@Quarnero) but that can’t be the case. Merely walking the phone to the charging station and putting the phone on the table in the general vicinity of the chargers has the effect of causing WiFi to drop out - long before I get to switch on the Purism-supplied USB-C charger and/or connect the charger to the Librem 5. To be clear: all of the chargers are switched off (at the wall). Nothing is connected to anything.

If it hadn’t been working previously, I would just put it down to “too far away from the WAP”.

I may eventually have to do that. (Or get my dock working so that I can charge and use GbE at the same time.)

That would be harder to test as I am walking-and-pinging in order to test, and looking at the screen to see when it fails.

I did look at doing that at one time (about something else) but the process seemed too intimidating e.g. I don’t know what component I should be filing against. In some respects it would be better to have a front end system where rank amateurs get to file problems (described to the best of their ability), problems get triaged, and then only things that pass muster get properly categorised and filed in the real issue tracking system.

I also figured that you already have more than enough things to work on that you do know about - without nitpicking from me about the message that the GUI updater gives.


Strange. What I know about radio signals is that they do strange and unintuitive things. Like sound, signals can travel through things and bounce off of things. While the access point might be somewhat good at being unidirectional, the smartphone antenna probably is not. A slight difference in orientation could put a signal above or below the noise floor when the signal is weak. Although less likely to the be case, it could be that before, the signal bounced off of something, like an object in the room, and now that object is in a different position. Or instead of reflecting signal, something is reflecting noise into the location. Also, another appliance could be putting out noise, and it does not necessary have to be close by or in the same room, depending on how much noise it is putting off and how narrow of a focus it has in that direction. Also, your access point might be changing channels based on what it senses as a clear channel. But the clarity of that frequency near where the phone is could be very different. That is where a SDR near the phone’s location could come in handy, or just experiment. You could try logging into the AP and selecting a different channel, especially if it is on automatic. The frequency might also affect where the signal’s peaks and troughs are located in the building, although that might only be a practical concern for the longer frequencies. Changing the orientation of the AP, or its antennas (if they are not fixed), might also do something. It will be small effect, but when the signal is at the threshold, it could make a difference.