Atmosphere-NX
After connecting to Wi-Fi, the power consumption becomes abnormal.
Once Wi-Fi is turned on, abnormal power consumption occurs — even in sleep mode, it consumes about 8% per hour. Currently, the Switch firmware version is 20.0.1, and the Atmosphère version is 1.9.0. No other plugins are used; it is a completely clean Atmosphère environment. If I enable Airplane Mode, the abnormal power consumption issue disappears.
There have been some reports of this, yes. I don't really know what it could be, besides some interaction with dns.mitm, but people have said that even disabling dns.mitm doesn't reduce drain. It would be helpful for you to confirm that.
I did a test my self, putting on stand by on Emu, no game open, even though it doesn't work to wake it, in the last 14 1/2 hrs (est 12am to 7:20PM) from 100% to 28.9%. and this is with the wifi left on.
In the last 10mins on Display Hekate v6.2.2 boot screen, -226mA to 274mA, at a loss 1.0% drain, 27.9%. Surely this is not normal, I don't remember it going past 234Am from the last version.
- Oled Zelda Switch Edition - 18.0.1|AMS 1.9.0|E
Incase this helps. I accidentally upgraded my software so its up to date. 20.0.1
@91ajames Every indication so far is that this affects OFW as well as CFW, and isn't actually related to Atmosphere per-se.
@91ajames Every indication so far is that this affects OFW as well as CFW, and isn't actually related to Atmosphere per-se.
Actually, I also tested the official stock system without loading Atmosphère, and the official 20.0.1 version of the system showed no abnormal power consumption — even when connected to Wi-Fi, there was no excessive drain. The power drain issue only occurs when running Atmosphère in emuMMC.
@do-kiss this is inconsistent across setups and has to do with various wireless settings. Some people see it with atmosphere and don't without, because of various settings differences/wireless usage. Some people see it on completely unhacked consoles. Some people see it depending on 2.4 vs 5ghz network. It's complicated.
Piracy is not supported, have to block you from the repo, sorry.
Anyway, yes, it's known that the issue is "Nintendo wireless code wakes up the console too often, causing battery drain" since 18.0.0, but it's not well understood what exactly triggers this. Again, it's likely unrelated to atmosphere/hekate/etc. It occurs without atmosphere for many people. It is likely just a byproduct of your different emummc environment.
There have been some reports of this, yes. I don't really know what it could be, besides some interaction with dns.mitm, but people have said that even disabling dns.mitm doesn't reduce drain. It would be helpful for you to confirm that.
I suspect that the NEWs in the HOS needs to be sync with Nintendo server to keep updating, so it will be sending request to server real time if the console were online mode. but the 90dns block the response from server and cause the request repeated once and once again. that could be make sleeping standby invalid even screen off. this issue occured in emunand. only disconnet internet or turn on airplane mode can stop the sending request. you can test it in offical HOS online mode, the power consumption is normal or just a little higher than offline mode.
I did a test my self, putting on stand by on Emu, no game open, even though it doesn't work to wake it, in the last 14 1/2 hrs (est 12am to 7:20PM) from 100% to 28.9%. and this is with the wifi left on.
In the last 10mins on Display Hekate v6.2.2 boot screen, -226mA to 274mA, at a loss 1.0% drain, 27.9%. Surely this is not normal, I don't remember it going past 234Am from the last version.
- Oled Zelda Switch Edition - 18.0.1|AMS 1.9.0|E
Incase this helps. I accidentally upgraded my software so its up to date. 20.0.1
you can make a test with two emunands in one console and compare the power consumption.
- the first emunand SD00, update from 19.0.1 or lower to 20.0.1 by daybreak. still old news in channel.
- the second emunand SD01, new create from offical system 20.0.1. the latest news in channel.
I have so far rebuilt two consoles (Erista on sysNand 20.0.1 and OLED on sysNand 18.0.1) with a partition emuMMC. In the end, both consoles were on emuMMC 20.0.1, whereby I first had to update the OLED emuMMC to the latest version via Daybreak. Both installations solved the problem with the rapid battery drain in standby! However, another test with an Erista on sysNand 1.0.0 did not work. I am currently testing this under a Switch Lite on sysNand 18.0.0.
I always test with the network activated and dns_mitm!
On Sys (20.0.1) Stock with internet access (wifi) and no DNS blocking, I don't have the issue. On Sys (20.0.1) CFW with internet access (wifi) and DNS blocking, I don't have the issue. On Emu (20.0.1, upgraded via daybreak from 19.0.0) with internet access (wifi) and DNS blocking, I have the issue. On Emu (20.0.1, made from sys 20.0.1 after this sys had access to internet without DNS blocking) with internet access (wifi) and DNS blocking, I don't have the issue.
This is on a D1 Erista. Wifi access point is the same each time (and it is a 5ghz one).
It is pure speculation because I don't know at all how to check this, but I am starting to think, maybe after a firmware update, if internet is connected, the console tries to "acquit" something from N servers. Obviously it can't if you upgraded an EmuNand and have internet access BUT DNS blocking. So maybe it would explain the battery drain because of infinites tries ?
So now I don't know if this is a new thing or if you already know it and someone tried it. I did it on V1 RCM. I did this test. I had emuNAND and sysNAND version fw 13.0.1. First I updated OFW sysNAND to 20.0.1. Then I removed everything "unclean" from the card and uploaded only clean AMS 1.9.0. and Hekate 6.3.0. So no patches, no sig or sys, no exosphere.ini, no default.txt in hosts, as I write, only clean AMS, just to be sure. When emuNAND started up to fw 13.0.1 I connected to wifi and updated the fw officially from N servers to 20.0.1. After the reboot, Hekate autostarted to emuNAND, then the AMS logo, then the N logo and then the swich did not boot into the system but rebooted itself again. I have the impression that it does this now after all the OFW updates to 20.0.1 (I had not tried 20.0.0 before). Then everything booted normally to emumNAND 20.0.1 AMS 1.9.0E. I turned off the console and added everything that is used and recommended for a safe emuNAND to the mSD, so sys_p, default.txt to host and exosphere.ini. Everything according to the recommendations of "Setup Exosphere / DNS MITM". Both the new Goldleaf 1.1.0 and TegraExplorer 4.2.0 made the same fw dump from emuNAND but be careful, there are no longer 235 files like you do from OFW sysNAND but only 231 files! Maybe after that mysterious console reboot after updating emuNAND, four files were deleted. I don't understand the reason, I'm not an expert. The dump with 231 files is not valid according to Goldleaf 1.1.0 and will not allow it to be installed. But the console works. I updated the fw emuNAND via Daybreak but with a valid dump of 235 files and the console also works after the update. I tried to update emuNAND again with the invalid dump with 231 files via Daybreak. This warning popped up but it allowed me to update. The console works. Update is valid! exFAT Validation failed with result: 0x00000202 Missing content: -Program id: 010000000000081c -Version: 20.0.0 -Content id 00000000000000000000000000000000
mSD is formatted as FAT32, so maybe it's just related to that, I don't know... I'll go test the consumption with the update with 231 files and write it here.... Google translate...
EDIT: My conclusion: The battery consumption with WiFi on is not affected by the update method. Updating via Daybreak or via wifi via N servers makes no difference on the V1 RCM console in terms of battery consumption. The only difference is that via N servers not all 235 files are saved to the system, but only 231. This does not affect the functionality of the console if FAT32 is used on the mSD. During the update via N servers, exFAT support files are damaged or not saved. It is questionable how the update would turn out if the mSD card was formatted to exFAT, maybe all 235 update files would be saved to the system. But I can't find out, I don't use exFAT...
People in gbatemp's Atmosphere thread are saying that deleting and re-creating the old (I assume pre-20.x.x update) profiles seems to fix the battery drain issue.
I haven't tested this myself but it is at least a bit less extreme than just nuking and rebuilding your emuMMC.
People in gbatemp's Atmosphere thread are saying that deleting and re-creating the old (I assume pre-20.x.x update) profiles seems to fix the battery drain issue. I haven't tested this myself but it is at least a bit less extreme than just nuking and rebuilding your emuMMC.
In GBA temp, I said WRONGLY that I used a new micro sd card to build a new emuNAND and the problem presist. Then he suggest me to deleted and recreate the profile(player account). It has not been tested yet. However, there is actually no more problem after rebuilding a new emuNAND.
I forgot to update my post but yeah, deleting and re-creating the old user did not work for me.
I still refuse to believe that rebuilding the emuMMC is the only option, but I don't have the skills to figure out what causes the battery drain issues.
I tried to wireshark my switch via the dock & an ethernet adapter plugged into my PC, but I couldn't see any significant traffic in my (albeit limited and non-scientific) capture. Only thing I saw were some requests to nintendo's CTEST server.
Observation: While being affected by the power drain bug, I can still use my batteryless joy-cons attached to the console, so I assume that there is a process hanging in the background which doesn't allow it to switch to the standby state and just turns off the screen, like a wake-lock. Before the update there were only very few instances of their Home-Button being able to wake the console (both OFW and CFW). I updated my V2 from 1.8.0 / 19.0.0 to 1.9.1 / 20.1.0. Edit: Can confirm that creating a new user (via Menu), transferring all saves (probably optional) and unlinking+deleting the old one (Goldleaf) solved the issue for me. Edit2: It's not solved after all. Perhaps a reboot made it return?
So now I don't know if this is a new thing or if you already know it and someone tried it. I did it on V1 RCM. I did this test. I had emuNAND and sysNAND version fw 13.0.1. First I updated OFW sysNAND to 20.0.1. Then I removed everything "unclean" from the card and uploaded only clean AMS 1.9.0. and Hekate 6.3.0. So no patches, no sig or sys, no exosphere.ini, no default.txt in hosts, as I write, only clean AMS, just to be sure. When emuNAND started up to fw 13.0.1 I connected to wifi and updated the fw officially from N servers to 20.0.1. After the reboot, Hekate autostarted to emuNAND, then the AMS logo, then the N logo and then the swich did not boot into the system but rebooted itself again. I have the impression that it does this now after all the OFW updates to 20.0.1 (I had not tried 20.0.0 before). Then everything booted normally to emumNAND 20.0.1 AMS 1.9.0E. I turned off the console and added everything that is used and recommended for a safe emuNAND to the mSD, so sys_p, default.txt to host and exosphere.ini. Everything according to the recommendations of "Setup Exosphere / DNS MITM". Both the new Goldleaf 1.1.0 and TegraExplorer 4.2.0 made the same fw dump from emuNAND but be careful, there are no longer 235 files like you do from OFW sysNAND but only 231 files! Maybe after that mysterious console reboot after updating emuNAND, four files were deleted. I don't understand the reason, I'm not an expert. The dump with 231 files is not valid according to Goldleaf 1.1.0 and will not allow it to be installed. But the console works. I updated the fw emuNAND via Daybreak but with a valid dump of 235 files and the console also works after the update. I tried to update emuNAND again with the invalid dump with 231 files via Daybreak. This warning popped up but it allowed me to update. The console works. Update is valid! exFAT Validation failed with result: 0x00000202 Missing content: -Program id: 010000000000081c -Version: 20.0.0 -Content id 00000000000000000000000000000000 mSD is formatted as FAT32, so maybe it's just related to that, I don't know... I'll go test the consumption with the update with 231 files and write it here.... Google translate... EDIT: My conclusion: The battery consumption with WiFi on is not affected by the update method. Updating via Daybreak or via wifi via N servers makes no difference on the V1 RCM console in terms of battery consumption. The only difference is that via N servers not all 235 files are saved to the system, but only 231. This does not affect the functionality of the console if FAT32 is used on the mSD. During the update via N servers, exFAT support files are damaged or not saved. It is questionable how the update would turn out if the mSD card was formatted to exFAT, maybe all 235 update files would be saved to the system. But I can't find out, I don't use exFAT...
I also have this problem during installing a firmware from sysNAND after updated officially in one of my Switch OLED: exFAT Validation failed with result: 0x00000202 Missing content: -Program id: 010000000000081c -Version: 20.0.0 -Content id 00000000000000000000000000000000
Everytime need to download firmware from a web site instead to prevent this from happening. However it only happen in one of my switch OLED while the other switch OLED and switch lite do not have such problem. It happens in every dumps of previous and current firmwares. I doubt whether it is caused by any problem occured/damaged sysNAND during the mod chip installation.
I haven't tried it, but I have a hypothesis. If you're running emuNAND from a card, it probably can't update the drivers on the mSD. And since it recommends using FAT32 and not exFAT, that could also be the reason why files with exFAT support can't get into the system.
Observation: While being affected by the power drain bug, I can still use my batteryless joy-cons attached to the console, so I assume that there is a process hanging in the background which doesn't allow it to switch to the standby state and just turns off the screen, like a wake-lock. Before the update there were only very few instances of their Home-Button being able to wake the console (both OFW and CFW). I updated from 1.8.0 / 19.0.0 to 1.9.1 / 20.1.0. Edit: Can confirm that creating a new user, transferring all saves and deleting the old one solves the issue.
I tried the recommended workaround of deleting the old user and creating a new one (used DBI to delete, then System Settings to create a new profile), but unfortunately the battery drain issue still persists on my modded OLED Switch. I'm on firmware 20.1.0 with Atmosphère 1.9.1.
Even after transferring all save data to the new user, the device continues to stay warm in sleep mode and the battery drains unusually fast — similar to the behavior described with the wake-lock-like condition.
Has anyone had different results on OLED specifically, or is there an additional step I might be missing?
Hot charging solution: Rebuild the emuMMC. However I am not sure whether it will happen again after the next HOS upgrade. Tried upgrading from a rebuilt emuNAND v20.1.1 firmware to v20.1.5, do not have hot charging again.
Temporary hot charging solutions(either 1 of them):
- Open the switch off menu first, halfly put the Switch in the dock set, switch off the Switch and put it into the dock set immediately.
- Switch off the Switch while it is charging. Either switching it off normally or pressing the power button for 12-13 seconds to force it shut down are ok.
- Go back to HOS sleep mode before charging.
Status checking before hot charging occures: My dock set is using a LAN cable connected to a network switch. If the related port on the network switch connected the Switch dock set keep on lighting up after putting the Switch into the dock set, then the Switch is probably going to have a hot charging afterwards.
FWIW, I just upgraded one of my V1 Switches to 20.0.1 and left it in sleep mode for one hour and a half and there was no battery drain, same percentage when I turned it back on. Still not sure if that matters or not but I only have fake NNID's linked with Linkalho.
OK, I just updated my second Switch (same config, Emunand) to 20.0.1 and this one has the battery drain issue, about 5% per hour. The only meaningful difference between the two is that I had to create a new user at a point on the one that does not have the battery drain because the cloud save was copied from the stock. So theoretically, it should resolved by creating another user? I'll try it out.
I and the other one have tried deleting and recreating a player account in emuNAND OS however it did not help. They are stated above too.
What Switch models do you have?
OK, I just updated my second Switch (same config, Emunand) to 20.0.1 and this one has the battery drain issue, about 5% per hour. The only meaningful difference between the two is that I had to create a new user at a point on the one that does not have the battery drain because the cloud save was copied from the stock. So theoretically, it should resolved by creating another user? I'll try it out.
How did you copy the stock save to emuNAND? Rebuild emmuNAND?
Oh no it is an Emunand copied a while ago when stock was still on firmware 16, I think. That's another difference with the V1 Switch which does not have the battery drain, that one was copied from firmware 19.0.1 on stock, so maybe there is some kind of residue carried over from earlier firmware versions on Emunand when you update it from earlier Firmwares, no idea.
I ended up remaking my Emunand (Stock was in 20.1.1 but everything appears functional as others have said) from scratch and the problem is fixed. I left my Switch in the dock in sleep all night and this morning it was cold. I also noticed that the WiFi now turns off every time I put it to sleep, while it was staying on when it had the battery drain issue. It's weird because on stock, it also always remains on yet does not seem to have the battery drain issue.
Recently I update my Nintendo Switch V2 on Firmware 20.1.1 From 19.0.1.
I noticed that my battery after that was drain very fast in sleep mode (wifi enabled) but when put it in airplane mode there is no battery drain. I have install Atmosphere 1.9.1 and up Hekate 6.3.1. Everything is fine with the games. Possible Causes: Wi-Fi and Atmosphere Interaction: There's a strong indication that the combination of Atmosphere and Wi-Fi usage is causing the excessive power consumption. Sleep Mode Bugs: It's possible that certain background processes in Atmosphere, related to waking up or going to sleep, are not functioning correctly, leading to the drain. EmuMMC: Running Atmosphere within emuMMC (emulated NAND) might be a factor in triggering the battery drain.
Quick solution :
Disable Wi-Fi
It's possible that certain background processes in Atmosphere
And did you consider that maybe it's not Atmosphere process but some other process that you have put there and it's running in background?
Possible Causes: Wi-Fi and Atmosphere Interaction: There's a strong indication that the combination of Atmosphere and Wi-Fi usage is causing the excessive power consumption. Sleep Mode Bugs: It's possible that certain background processes in Atmosphere, related to waking up or going to sleep, are not functioning correctly, leading to the drain. EmuMMC: Running Atmosphere within emuMMC (emulated NAND) might be a factor in triggering the battery drain.
All these possible causes are not it since I've had the battery drain and it disappeared after creating a new EmuNAND and reinstalling the exact same modules.
Possible Causes: Wi-Fi and Atmosphere Interaction: There's a strong indication that the combination of Atmosphere and Wi-Fi usage is causing the excessive power consumption. Sleep Mode Bugs: It's possible that certain background processes in Atmosphere, related to waking up or going to sleep, are not functioning correctly, leading to the drain. EmuMMC: Running Atmosphere within emuMMC (emulated NAND) might be a factor in triggering the battery drain.
All these possible causes are not it since I've had the battery drain and it disappeared after creating a new EmuNAND and reinstalling the exact same modules.
Did u test the lastest firmware 20.1.5?
Did u test the lastest firmware 20.1.5?
No, I will be waiting for an officially compatible atmosphere version to do that. I'm also worried it will cause the battery drain issue again so I'll also be waiting for reports that it doesn't once you have created a clean EmuNAND or deleted and remade your users.
Did u test the lastest firmware 20.1.5?
No, I will be waiting for an officially compatible atmosphere version to do that. I'm also worried it will cause the battery drain issue again so I'll also be waiting for reports that it doesn't once you have created a clean EmuNAND or deleted and remade your users.
Atmosphère 1.9.1 already support FW 20.1.5
Atmosphère 1.9.1 already support FW 20.1.5
I know, that's why I said "officially" so when its compatibility is mentioned in the next atmosphere release :).
I am not especially planning on doing a release soon, since 20.1.5 works fine.
Récemment, j'ai mis à jour ma Nintendo Switch V2 sur le firmware 20.1.1 à partir de 19.0.1.
J'ai remarqué que ma batterie se déchargeait très rapidement en mode veille (wifi activé), mais lorsque je la mettais en mode avion, il n'y avait pas de décharge de batterie. J'ai installé Atmosphere 1.9.1 et plus tard Hekate 6.3.1. Tout va bien avec les jeux. Causes possibles : Interaction Wi-Fi et atmosphère : Il y a de fortes indications que la combinaison de l'utilisation d'Atmosphere et du Wi-Fi est à l'origine d'une consommation d'énergie excessive. Bugs du mode veille : Il est possible que certains processus d'arrière-plan dans Atmosphere, liés au réveil ou à l'endormissement, ne fonctionnent pas correctement, ce qui entraîne une perte d'énergie. EmuMMC : L'exécution d'Atmosphere dans emuMMC (NAND émulée) peut être un facteur déclenchant l'épuisement de la batterie.
Solution rapide :
Désactiver le Wi-Fi
Same problem in v20.1.1 on my Mariko switch. The CPU 3 is always at 33% charge on the home screen and the battery drains quickly. The temperature is 32°C. Switching to airplane mode is not a solution, and I don't feel like doing the Emunand again as I have a lot of games installed.
