RTL8723BE Again

According to This Posting, when my laptop ‘Klystron’ had an older kernel version, it was suffering from a number of WiFi problems.

These problems seemed to be related to the RTL8723BE kernel module, a Linux implementation of the device driver, for a chip-set that seemed to run fine under Windows. Linux issues with this chip-set are famous.

More recently I have read some follow-up information, that makes the problems I was experiencing more easily explained.

Apparently, the Realtek chip-set in this laptop has not one but two points, at which an antenna wire can be connected – i.e., the possibility of connecting two antennae. The device-driver is supposed to detect which antenna has the stronger signal, and is supposed to switch to whichever one that is.

Apparently, my laptop was not made so cheaply, as only to have one antenna in fact, as some models do. This is evidenced by the fact that when I was running Windows on it, I was able to close and reopen the laptop lid at any time, and not risk losing the signal.

But what can happen with earlier versions of this kernel module under Linux, is that it fails to switch to the antenna with the stronger signal in real-time, instead making a static decision to stay with one of the antenna wires, at least after a connection has been established. And this would explain why, when I closed my laptop lid before, the kernel module would choose to stay with an antenna it had chosen, and one with the now-weaker signal.

On the side, what I now find is that since I have been upgraded to kernel version ‘4.4.0-30-generic‘, the kernel module and its WiFi service seem to have become very stable, until I put the laptop into Suspend Mode. When I Resume from RAM after that, apparently the kernel module receives some amount of corruption, so that it becomes unstable again. But this is not the only problem that laptop runs in to with Suspend to RAM, as also noted Here. Further, I still have this laptop set To suspend to RAM, whenever I close its lid. So there are still no sessions on this machine, with the lid closed, with the WiFi active, and with the laptop plugged in to AC power, as some users leave theirs.

Such a test might be a good thing, to see if the WiFi signal still fades like that, with the new kernel module. That test has not happened yet.



Some Thoughts about Laptop WiFi Antennae

One fact which I had observed for some time, is that even many laptops today which have an LCD display, still use an Electroluminescent back-light, the latter of which needs to be activated with a kilovolt voltage, but the first of which only receives signals from the motherboard, that are too weak actually to emit a lot of light. And so, the circuitry has existed for some time, to take battery-level voltages, and to boost those into the kilovolt range, resulting in a very small number of microamperes of current. This is done with transistors, and with a special coil – which is also called “an inductive component”.

What the designers of laptops with EL backlights tend to do, is to feed the thin leads which carry this high voltage, through one of the hinges of the display / lid, in such a way that the leads make a gentle 90 degree bend on the side of the MB, and make a gentle 90 degree bend again on the side of the lid, while inside the hinge that connects the lid to the main body of the laptop, this set of leads only makes a 90 degree twist, or untwists, as the laptop lid is opened and closed. It is felt that this solution minimizes any wear and tear to the high voltage EL power leads, the insulation of which may be thin, even though that modern insulation effectively stops 1-2 kV.


But there is a report about those leads which some readers may already have encountered, according to which those form the WiFi antenna of the laptop. Well according to what I seem to have observed myself, Those leads fulfill both functions.

Because the low-current circuitry which puts the high voltage onto those leads feeds them through an inductor, a radio-frequency signal can also be fed onto the leads without interference from the LF high voltage, simply by looping them through another device, in series with the high voltage source. Even the fact that they have ‘a bit more insulation than an RF antenna should need’, will not interfere with their working as a WiFi antenna.

And I suppose that a question which users might ask could be, ‘Why would the Engineers go through the extra trouble, to allow the EL supply leads to double as the WiFi antenna, when low-voltage loops on the MB itself should also work?’

And as nearly as I can make out, the answer seems to be, that on most laptop designs, the display / lid is the only larger component, which goes from facing horizontally, to facing vertically, during normal use.


So, depending on what sort of troubleshooting one is doing, one might worry, that the same leads which feed the backlight, might also be starting to fail, in their function as the WiFi antenna. There is just one observation which needs to be added, to this statement of a hypothetical fear.

If those leads did become so frayed, that they no longer work as an RF antenna, then the user should also see some sort of negative effect, on how well the backlight maintains constant brightness. In fact, very shortly after the onset of trouble, the backlight should also fail completely.

This is not impossible. I have had separate monitors fail, due to the supply to the EL backlight failing. That monitor simply went blank, within a second of my powering it up eventually.

But there is something else which can resemble this situation, which is not as negative a prognosis for a laptop. After all, if those leads needed to be replaced, doing so would effectively amount to a mess.

In the modern world of Quantum Mechanics, we might not like to be reminded of this, but practical antenna geometry is still defined by waves and nodal lines. The advantages of having put an antenna into a laptop lid can disappear completely, when we just close the lid and have the laptop idling in standby.

The geometry with which such an antenna sends and receives radio waves, can effectively collapse, just as a function of the lid being made horizontal again, flush with the motherboard.


So there could be a number of reasons for which a WiFi connection can fail, and I have just searched for a software problem, in ways that seemed to take me four ways to hell and back, when in my case, simply moving the laptop to the other end of the table it rests on, facing in an opposite direction, may have solved the problem for me.

I know that as long as the WiFi works 90%, and as long as my display works 100%, I will not need to dig any deeper into the inner workings of this laptop for now.


(Edit 04/30/2016 : ) One result which does not occur easily in Electronics, is the perfect separation of signals. Thus, closing the laptop lid will not reduce the amplitude of the received WiFi-signal to zero, but will only attenuate it. Likewise, if the same wire is being used as WiFi-antenna as is being used as EL power supply, using it for the latter, also injects background noise into the weak WiFi signal received as the former.

I now suspect, that whenever a Windows laptop lid is closed, Windows settings make extra sure, to turn off the display as well, so that this issue is less of  a real problem.

Further, one of the many, many KDE power saving settings we can decide, is that Laptop Lid Closing Action is Turn the Screen Off.

But beyond that, KDE has more settings. Typically, I will tell my computers to Start displaying the Screen Saver / Locker after 10 minutes, and then to turn the Display Off after 30 minutes of inactivity total.

If the screen has been turned off as the Lid Close Action, this does not turn on the Screen Saver. Thus, with such settings, it can be that KDE next turns the Screen Saver, and thus the display, back On after 10 minutes, to display a Screen Saver which nobody ever sees. And then after another 20 minutes of that, these KDE settings should cause the display to turn off a second time.

In the meantime the WiFi antenna would receive no incoming signal for 20 minutes, starting from 10 minutes after I had closed the lid.

This might sound very strange to some Windows users, but simply follows mechanistically from such settings.

So I am now experimenting, with setting the laptop Lid Close Action to be Turn the Screen Off. But then I am setting the Display Power Saving Off Delay, to be equal to the number of minutes, within which the Screen Saver will Turn On.

Hence, my new settings should never allow for the display actually to be on, while the lid is closed. And then we will see, whether this laptop seems to disappear off my LAN again…


(Edit 04/30/2016 : ) The affected laptop has now been able to stay visible on my LAN, with its lid closed, for 12 hours overnight, while previously, it used to vanish off my LAN within a few minutes of my closing the lid, regardless of what my software settings were.

So I am declaring this experiment a success.

And for the same reason, that I am linking the current posting, as relevant to This Earlier Posting.


BTW, In order to test this visibility, I have been using a 3rd-party Android file manager app, which is also particularly efficient as a share / LAN browser. As it happens, my router has been enthusiastic enough, to continue to register the laptop ‘Klystron’ as connected, after its signal was lost, and after I could no longer get data to and from it.

But this 3rd-part LAN-browsing, Android app, will show me honestly, that the laptop has quit the LAN, within a few moments of the laptop doing so, which the laptop has not done for more than 12 hours now.

Further, this 3rd-party LAN-browsing app is also sophisticated enough, to display the computer I use as my server (‘Phoenix’) twice, once with its real IP address, and a second time with the IP address of its OpenVPN presence. That makes this app the only software I presently have, that can even detect my VPN, from elsewhere on my physical LAN.


(Edit 05/01/2016 : ) My laptop has now stayed connected to my WiFi for more than 24 hours, and without any glitches at all, with its lid in the closed position. So again, the simple fact that its display is off now, 100% of the time the lid is closed, seems to have helped.


The problem ‘Klystron’ has with WiFi, Must Be A Hardware Problem.

It would seem that the laptop I name ‘Klystron’, is befallen by not one but two WiFi problems, which made it hard to identify either of them.

The main problem I was trying to get a handle on as late as This Posting, could be described as having a WiFi status that seems active to programs running on the affected laptop, but which causes that laptop to seem to lose its connectivity with the rest of my LAN, as seen from the LAN. I can verify that within seconds. It seems to take place, whenever I just close the lid.

The previous posting combined this observation, with the fact that I had set the Lid Close Behavior to Lock the Screen, to suggest that maybe the Screen Locking function built-in to KDE, was triggering this situation somehow.

But what I have now done, is to change the Lid Close Behavior to Turn the Screen Off, which simply causes the backlight of the screen to go dark. And just as before, closing the lid causes the same condition. What this rules out, is that the problem was caused by the KDE Lock Screen function per se. Further, KDE can be told to lock its screen, just with <Ctrl>+<Alt>+L. If I enter that key-combination and keep the lid open, ‘Klystron’ stays visible to the rest of my LAN, and its WiFi appears unfettered.

Now, what can sidetrack this, is the fact that a second type of malfunction will sometimes set in, which actually causes its WiFi to seem to log off, and which requires that I reconnect. One reason for which I need to reconnect, is the fact that my WiFi passphrase is stored on the laptop in a user directory, but as part of the KDE-Wallet system, that keeps such information encrypted with another password.

Hence, whenever I want the WiFi to reconnect for any reason, I must first unlock my KDE-Wallet, so that the Network Manager can be given my WiFi passphrase, to reconnect.

It is not clear what causes the initial disconnection though. A part of me thinks this could be due to misuse of my laptop on my LAN, of IPv6 addresses. But another part of me thinks this could be due to dodgy support of 802.11n within Linux drivers.

What I do know is that this second problem sets in much less often than the first.

Also, it is possible that closing the lid does not physically sever any type of antenna-connection, but may rather change the geometry of the antenna wave patterns, so that the signal strength may just go way down. This may be confirmed at some later point in time, when I try moving the laptop to a different location, relative to my router. I just find the thought sad, that there might be some sort of more-serious, hardware issue with the WiFi, since hardware issues are finally harder to solve than software issues.



Understanding The Intricacies Of KDE Logic

In This Posting, I was describing a problem with my Linux laptop named ‘Klystron’, in which the laptop would take itself off my WiFi, apparently every time I closed the lid.

In the short term, there was a solution to this problem. I was able to go into my KDE Power Management Settings, where I had set the action on closing the lid to “Lock Screen”, and I was able to change this setting to “Do Nothing”. The suspicion had never occurred to me, that there could be two distinct behaviors:

1) After (x) minutes, the screensaver can come on, and if the attempt is made to interrupt the screensaver after (y) additional seconds, that screensaver can ask the user for his password.

2) The user can ask KDE to “Lock The Screen”.

According to the way KDE works, (1) and (2) are as different as Night and Day. So apparently, Locking The Screen is also supposed to mean, Disconnect From WiFi. But the screensaver asking the user for his password to stop, does not mean Disconnecting The WiFi.

Live and Learn.

And actually, one main reason for which I do close the lid usually, is the fact that the laptop is more protected from dust etc., with the lid closed.


(Edit : ) This laptop setup uses Network Manager. So just this afternoon I left-clicked on the Network Manager icon while connected to my home WiFi, and then drilled deeper into its GUI, to adjust which settings would be displayed as additional information about the network I am connected to. Network Manager is somewhat flexible in this GUI layout adjustment, but does not really allow settings to be fine-tuned in the same way.

Some KDE setups use ‘WICD‘ instead of ‘Network manager‘.

What I saw, was that there was no specific parameter to display, for whether a WiFi network should disconnect, on locking the desktop.

The only relevant WiFi-related detail I was able to add to the display, was “WiFi Band”, which could plausibly have complemented “WiFi Security”, which was already included. For my home access point, WiFi Band now displays “b/g“, as a result of further troubleshooting steps of mine.

I have since disabled 802.11n from the kernel module…

This means in practice, according to my logic, that the behavior I described in this posting, of cutting out when I close the laptop lid, cannot be deliberate. If it was deliberate, it would also be something which can be configured differently. And thus, this can also not be due to any translation error.

Therefore, this is a bug, and one I can now reproduce any time I want to.