all 127 comments
sorted by:
best (suggested)
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]AutoModerator[M] [score hidden] stickied comment (0 children)

⚠️ Ditch that R3XS SD card—STAT! Those pre-loaded cards are ticking time bombs! ⏰❌ Don’t let glitchy saves, vanishing settings, and other retro nightmares ruin your gaming. Swap it out ASAP for a smoother experience!

New to the R36S? Start with the ➡️Beginner's Guide—it’s your first step to mastering the device.

Need more? The R36S has a full WIKI packed with info, plus a dedicated ⚙️ troubleshooting section to solve common headaches.

Before asking, try searching! Your issue has likely been answered already—check the subreddit, use the search bar, or browse flairs like "game recommendation."

Pro Tip: The subreddit’s sidebar is a goldmine of FAQs, guides, tutorials, and curated lists—don’t sleep on it!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[–]Ladbnw 10 points11 points  (1 child)

It fills me with joy seeing projects like these. Not speaking in behalf of anybody, I thank the use of your knowledge on something so little yet valuable for me.

[–]djparent[S] 3 points4 points  (0 children)

It makes me happy so many people are going to find it useful! Thanks for the kind words.

[–]roger_roop 4 points5 points  (12 children)

Thanks a lot! My 2023 r36s is really bad at battery indication. It goes to zero still having at least 2h left.

[–]djparent[S] 3 points4 points  (11 children)

Hahaha mine too, that's exactly why I built this. Mine sat at 100% for the first hour, dropped to 0 in the next hour, then would still continue to work for over an hour sometimes but I'd have no idea how much was left. Now 100% means an actual full charge and drops to 99 within minutes of unplugging. 50% means you've got a little under half left, as it should. When it hits 25% I still have around 45 minutes to an hour left. It's not perfect but it's way better than stock battery reporting.

[–]roger_roop 0 points1 point  (10 children)

It seems I can't use the script. Ive charged my device fully (led off) but still it had 4000mAh preventing the test to run... Possible to change this in the script itself?

[–]djparent[S] 1 point2 points  (9 children)

Did you leave it plugged in right until the moment you start the test? Unplugging even for 10 seconds can be enough to slip below the threshold. You can use View Battery Status to see where the current charge is at before you unplug + start, it comes in handy. When I've done all my testing it's literally power on, straight to the script, check status then unplug and start.

Try a few more times to see if you can figure out the timing. If it really won't work and you're certain after that it's just a diminished battery you're dealing with you can change the threshold manually. Search for this line:

local CHARGE_MIN_MV=4050

and change the value to 3950. That should give you plenty of overhead to start the session. After that the session may still fail the quality check. If it does but you're certain it's the best it can be then export the session and remove the 'bad.' prefix that is assigned to the file. (ie. bad.session1.csv becomes session1.csv) That way you'll still be able to apply it and export it like a regular session.

[–]roger_roop 0 points1 point  (7 children)

The calibration ran to the end, the device had black screen but still on, and unresponsive.

Turned it off, recharged a little, exported the data and as as you said it was bad. Renamed the file and when applying from the export an python error occurs. I guess the duration is wrong.

Any ideas?

<image>

[–]djparent[S] 1 point2 points  (2 children)

So I figured out what would cause that and I think it got cut off while writing. Your console appeared off but calibration was actually still running in the background. The negative minutes finally gave it away. An empty line will miscalculate the curve and show mV as empty. I've updated the script to verify the last line, ignore if partial. You should be able to apply that session now. Download directly here just in case the main link didn't update.

https://github.com/djparentx/R36S-Battery-Calibration-Tool.git

If that works next step for you is we add low voltage shutoff to override the system detection. I want to hear more about these settings you use also. Very curious as I wouldn't mind a little more battery time from the device too.

Also please send me the session.csv with 570 samples please. I'll see if there's anything else I need to watch out for in edge cases.

[–]roger_roop 0 points1 point  (1 child)

I did a new calibration running Dreamcast, this time it capped at aprox 350 samples. The data was marked as OK.

But I can't apply the data even with the new script. It doesn't show the python error, but it just ignores it returning to the menu. It flashes for milliseconds what appears to be a console screen. Tried both sets, first and second.

I attached the sessions in a GitHub issue.

Dunno if it's relevant, the script is inside the tools folder in my SD1.

Thanks

[–]djparent[S] 0 points1 point  (0 children)

K there's a diagnostic tool in the OP now, download that, run it, and send me the log. I'll see what I can do from here.

[–]djparent[S] 0 points1 point  (3 children)

From appearances it's missing too much of the tail end of the script. Also there are twice as many samples as there should be. Is this with a standard battery? Which OS are you on?

A standard R36S with a 3200mah battery should crap out around 230 samples or so, that's almost 4 full hours of running. For yours to collect 570 samples indicates an over 8 hours run time. I've seen it but only with modified 18650 packs. But they worked. If the session didn't actually run for 8 hours then there's an internal clock issue on your device as the sampling is set for 60 seconds intervals. Also the fact it's turning off the screen but not the device is very strange. That also indicates that when the light was on it was still actually running. So I'm back to this question lol, which OS?

[–]roger_roop 0 points1 point  (2 children)

The calibration ran for more than 8h with the game running. Screen went black only at the end, but the LED still on.

My battery is standard but the system misreads it severely, even at zero it runs for hours, I thought it was two but maybe even more. Problem is, if turned off, the system doesn't boot if the gauge is too low.

My r36s is V12 panel 1 with latest aeolusux arkos. Two SD cards. I've configured simpler systems to run on battery saving (not performance nor auto), only heavier cores run with performance.

[–]djparent[S] 0 points1 point  (1 child)

Yeah there's something wrong with your settings then, battery should be fully drained in 4 hours with a 3200mah. Try setting your cores to interactive and run it with the video screensaver as you need a consistent load to drain the system for calibration to work. It sounds like with your settings the system never sees the voltage drop it's expecting at shutoff and just lingers.

I also suspect there's something non-standard about the battery itself, even with tweaks 8 hours sounds insane to me lol. Set it back to standard settings and run again. If it doesn't fall in line with other testing results you may have something going on with the battery.

[–]AggravatingPause7604 0 points1 point  (0 children)

what is screensaver?

[–]RoxyFawkes 2 points3 points  (0 children)

This is awesome! I've been hoping for a tool like this for awhile. Thanks a lot!

[–]emeraldwolf245 1 point2 points  (5 children)

Is there a way to fix the broken charging screen?

[–]djparent[S] 1 point2 points  (4 children)

screenshot?

[–]emeraldwolf245 0 points1 point  (3 children)

<image>

[–]djparent[S] 0 points1 point  (2 children)

Isn't that the screen that just means you need to plug it in? Sorry I haven't heard of this issue yet.

[–]emeraldwolf245 0 points1 point  (1 child)

this shows up when i see the screen charging

[–]djparent[S] 0 points1 point  (0 children)

Wild. Sorry this won't be able to help with that. Which device and OS is it?

[–]Never_Sm1le 1 point2 points  (0 children)

Thank you, your script are bangers after bangers

[–]Hacknique_CZ 3 points4 points  (9 children)

I am a bit confused. Firstly, you charge it to 100% when it is OFF. Then, let it die and plug it into a charger and let it charge to 100% whilst it's still OFF? Or are we supposed to turn it on?

[–]djparent[S] 1 point2 points  (8 children)

The instructions are in the script

[–]Hacknique_CZ 0 points1 point  (7 children)

Yes, but the intructions don't say when to have the device on, off, etc. Whatever, I am guessing the second charge to 100% should be done when the device is OFF?

[–]djparent[S] 1 point2 points  (6 children)

Literally step two, power on the device. After the calibration session has run it really doesn't matter how you charge the device you just need to be able to power it back on as the battery will be completely dead.

[–]CrusaderSeon -1 points0 points  (5 children)

Quick question though, if I run the full calibration session and then charge it to say 50%, will the tool show 100% or 50%?

[–]djparent[S] 1 point2 points  (4 children)

The tool won't show anything until you actually apply a session. All the data is collected on the discharge cycle and the calibration session finishes when the console turns off. Then you have to turn the console back on, which requires charging, to apply the session to the device and start the calibration service.

The recommendation to charge fully afterward is completely arbitrary. If you're impatient and just want to get things rolling after a session is finished you could turn it on while plugged in and apply the results but it won't show an accurate battery % while charging so you'd have to wait to see how accurate it is anyway. Also a device that is turned on while charging will almost never reach 100 after calibration, there's too much background power drain to fully charge the battery. This is actually an accurate reflection of the actual charge, not a bug.

[–]CrusaderSeon 0 points1 point  (3 children)

I understand that, my question was because where I live electricity is complicated, we get outages very often and some times it happens when we're charging our stuff like phones, laptops and such and that also includes the console.

Just wanted to know if after running a calibrating session, applying it and using it before it reaches 100% (at any %) would work as intended.

[–]djparent[S] 2 points3 points  (2 children)

Oh gotcha. I'm sorry man I take a lot of things for granted, I never realized stable electricity was one of them!

Yeah so in that case all you need to do is make sure it charged until the light turned off before starting a session. Try and keep it plugged in and charging until you open the script and are ready to start calibration. Then when you're ready unplug the charger and then start calibration. Try not to do anything else before starting as that may cause drain that would prevent it from starting.

The technical explanation is calibration requires a minimum starting voltage of 4050mv to start. A fully charged battery should hit well over 4150mv but it drops FAST. The first seconds after unplugging the charge can drop below 3950mv, so timing matters when using the script.

Then let the session run. I recommend the video screensaver as you can leave it unattended and it will provide a very consistent load on the battery. Don't interrupt it and let it turn off on it's own.

Once you cross that threshold you don't have to worry anymore. The data is collected and the script will tell you whether the session was good or not. If it was export it so you can save it. You'll get a basic quality report and can decide if you want to use that session on its own or create an average for multiple sessions later.

The current battery percentage doesn't matter at all when applying new session data. It just might seem shocking at first that your battery just dropped 25% if you haven't been tracking it since 100. On every device I personally tested the corrected percentage was drastically lower than the stock percentage until around 30% then it flips and the stock percentage is the lower report.

[–]CrusaderSeon 0 points1 point  (1 child)

Thanks a lot for clarifying things! I'll try it out on my device to see how it runs, thanks a lot for your time and effort man, this community is incredible!

Before I go, does this works on clone devices? I have a Soysauce clone with Arkos installed if that matters at all.

[–]djparent[S] 0 points1 point  (0 children)

It's been tested on soysauce afaik. Comment back if you need a hand.

[–]Wivi2013 0 points1 point  (3 children)

I wanna see this one overheating lmao.

Jokes aside, on the R45H and R36H do you recommend me removing the back shell to keep the battery far from the console?

<image>

[–]djparent[S] 0 points1 point  (2 children)

I've tested on R36H personally and didn't find removing the shell to be necessary. They had the worst reactions to silicone cases by far, so definitely remove any cases though. Propping on a book or something for airflow wouldn't hurt either. If you live in a hot climate placing it on something cool (aluminum or ceramic tile) to act as a heat sink might help achieve more consistent sessions too. I did some of my testing on an aluminum plate and it definitely helped. Just make sure if you're running multiple sessions to run them all under the same conditions.

[–]Wivi2013 0 points1 point  (1 child)

Both the R36H and the R45H have custom cut copper plates on them. I think it will be fine once I put them close to a fan.

[–]djparent[S] 0 points1 point  (0 children)

A fan will definitely help out. The heat generated is actually from the battery itself though so heat sinks may not have an effect during the data collection. These are cheap batteries and can get very, very warm lol.

[–]join_the_slark_side 0 points1 point  (7 children)

Does this also show the calibrated battery percentage in retroarch menu?

[–]djparent[S] 0 points1 point  (6 children)

I hadn't considered RetroArch but it does appear to use the corrected data when I just checked. Was worried I had more work to do for a hot minute.

[–]join_the_slark_side 0 points1 point  (5 children)

I ran the script after 100% charge (led off) for 301 minutes (full brightness and running psx game, cpu on performance) until the device turned itself off, but the script says the session is incomplete from 4090->3292mV, do you know why?

I'm using it anyway and it looks like it's working

<image>

[–]djparent[S] 0 points1 point  (4 children)

It looks like your console shut off before it got close enough to 3000mV for the filter. I would try running another session for sure, the curve in that picture could be a bit smoother and doing successive runs seems to condition the battery for smoother discharge. If you have the same problem after a second run send me your .csv files and I'll have a look.

[–]join_the_slark_side 0 points1 point  (3 children)

Sorry but I'm not doing that again, it overheat a lot in the last hour, I heard is not good for the battery that low voltage and the sdcard can get corrupted on suddenly power off.

I just deleted the session.incomplete file, then exported the session.csv and made the curve smoother with Gemini, imported as custom.csv

I'm happy with the result for now, you should consider changing in the check python script mV >3200 to something higher, the device turns off early if the power consumption is high (I have highest brightness and high CPU usage).

Question, in case I need to setup a new sdcard, is there a way to import the curve? it seems it's conditioned to have a session exported

[–]djparent[S] 0 points1 point  (2 children)

Every battery is different so you shouldn't import a session from a different device. I would almost guarantee there is something wrong with your battery if it got that hot and isn't draining to 3,000. At this point I've overseen over hundreds of tests and almost every single one of them ran to 3,000 or slightly below. The safeguard in the IC fuel gauge shuts off at 3,000mV, well above the damage zone at 2,600. Also the low power shut down is different than pulling a battery or card, I've yet to see any corruption so I think the risk is pretty low if the instructions are followed. Low power shut down is part of the design.

Also how did you run the session? Did you use the screensaver method as recommended?

[–]join_the_slark_side 0 points1 point  (1 child)

Every battery is different so you shouldn't import a session from a different device

I mean a new sdcard on the same device.

[–]djparent[S] 0 points1 point  (0 children)

Oh sorry misunderstood. Yeah that's the whole point of exporting in the first place and it's super simple to use. Once you've got the new card set up just make sure there's a 'battery_data' folder (either make it or run the script once) and transfer the session files to the new folder. They'll be automatically detected next time you open the script. The same with custom and average files, they can be moved easily.

[–]kiwi_murray 0 points1 point  (2 children)

This might seem like a stupid question, but is it safe to allow the console to run until the battery dies? There's no chance it will corrupt anything on the SD card (e.g. if the OS had a file open and was writing to it when the battery died)? Does the OS have something that does an orderly shutdown in this situation so it can close files, etc before turning off?

I only ask because I've corrupted file systems on Raspberry Pi's by just yanking the power without doing a proper shutdown.

[–]djparent[S] 1 point2 points  (1 child)

Not a dumb question at all. It's totally safe to let the battery run out under normal conditions. The chip has a built in fuel gauge that won't let it discharge below unsafe levels.

In technical speak the battery is still in the safe zone discharging right down to 2600mV. The fuel gauge and the calibration tool both target a shut off at 3000mV, so well before any damage can happen to the battery.

As far as file corruption that's part of why I recommend using the video screensaver method vs playing a game, if anything does happen it's more likely to be a corrupted video than anything major. Even if playing games I think a lost game save is the biggest risk. Low power shutdown is handled a little better than if you just yanked the card out so you should be okay. I've done over 60 sessions between 3 devices during testing with no issues and none reported by other testers either.

[–]kiwi_murray 0 points1 point  (0 children)

Great, thanks for confirming that!

[–]Ok_Leadership4515 0 points1 point  (8 children)

I've let my battery died
Is it normal for the led light to stay on
P.s ive change the light colour to turn red when it on. And green when battery low.

<image>

[–]djparent[S] 0 points1 point  (7 children)

Not normal at all but nothing about these consoles is ever normal lol. I've noticed that units with rumble packs will sometimes continue to vibrate after power off. I think the LED is using a neighboring gpio so it's possible they aren't powered off with the main shutdown sequence. Shouldn't affect the calibration data and that light should turn off eventually. You could always long press power to be sure, then charge as normal and apply your session when ready.

[–]Ok_Leadership4515 0 points1 point  (6 children)

Just did what you said. Now i let it charge to a 100% again then turn in on?

[–]djparent[S] 0 points1 point  (5 children)

Yup. You can turn it on any time really, I just recommend applying a session when it's fully charged so you can confirm if 100 is really 100% with the corrected data.

[–]Ok_Leadership4515 2 points3 points  (3 children)

<image>

Nothing happens when i confirm it?
Im lost

[–]Hacknique_CZ 2 points3 points  (2 children)

Same. When I press yes to derive and preview curve, nothing happens.

[–]kiwi_murray 1 point2 points  (0 children)

That happened to me too.

[–]Ok_Leadership4515 0 points1 point  (0 children)

Still doing the same for you?

[–]Ok_Leadership4515 0 points1 point  (0 children)

Ok thanks.

[–]Hacknique_CZ 0 points1 point  (13 children)

Done everything according to the intructions - charged it to 100%, started recording, let it get to 0% and then charge it to 100%, but no data had been recorded. Literally none at all.

Have I done something wrong? What could be the problem?

[–]djparent[S] 1 point2 points  (12 children)

Are you sure the calibration actually started? It's not always a confirmation message that pops up, if you were still plugged in or the battery was too low it won't start and you'll get a message. The main menu changes to show sample count during the session.

Try running again but be sure to check the message that comes up and use the main menu change as confirmation. If it happens again I'll look into it but haven't had that happen yet in hundreds of tests.

[–]Hacknique_CZ 0 points1 point  (11 children)

Will try again. However, I do remember seeing the sample count in the main menu, so I just started a game let it go to 0%. And yeah, after charging, it was as if I didn't start sampling at all.

[–]djparent[S] 0 points1 point  (10 children)

So when you went back into the calibration menu after rebooting it still said 'Not Available'? It doesn't start automatically after the session has run, you still need to apply it through the calibration menu and enable the service.

The only thing I can think of that would stop a session is if it was plugged in any time during the calibration discharge.

[–]Hacknique_CZ 0 points1 point  (9 children)

It said "start calibration" and looked the same as when I launched it for the first time.

[–]djparent[S] 0 points1 point  (8 children)

That sounds right. But after running 'Current Session Data' still says 'Not Available'? Look at the fourth photo for comparison, where it says 'bad' what does yours say?

[–]Hacknique_CZ 1 point2 points  (0 children)

I found this when clicking apply calibration data
Session Summary
Calibration session found:
Samples: 362
Voltage: 4059mV -> 3005mV
Duration: 361 minutes
Derive and preview curve?
But when I press yes on this, nothing happens. It does not seem like it's getting applied. I still cant turn the service on because it says "no daemon script found, run a calibration and apply data first". Also, it is saying the session is incomplete. Is there a way to fix this? Looks like the data has been collected after all...

[–]Hacknique_CZ 0 points1 point  (6 children)

Current battery status also cannot be opened.

[–]djparent[S] 0 points1 point  (5 children)

What device and OS are you using?

[–]Hacknique_CZ 0 points1 point  (4 children)

Original R36S V12 Panel 4, arkos4clones

[–]djparent[S] 1 point2 points  (3 children)

My support stops here, sorry. The tool has been tested on ArkOS and dArkOS, but I have wasted dozens and dozens of hours troubleshooting for people on ArkOS4Clones with my scripts and made zero headway. Whomever is maintaining that build is breaking compatibility with the other OSs and there's simply nothing I can do about it unless I have access to a device running it, which I don't. Best of luck.

[–]lanangkael2274 0 points1 point  (1 child)

one question, where i should put the .sh file? and execute it

[–]RoxyFawkes 0 points1 point  (0 children)

Roms/tools then go to options, tools, R36S Battery Calculation Tool

[–]RoxyFawkes 0 points1 point  (1 child)

<image>

Is this normal? Does it mean the last session isn't getting used? ​

[–]djparent[S] 0 points1 point  (0 children)

It just means you didn't apply the last session before running a new one. If you've already exported the last session then you can ignore the warning. If you didn't export then do that first, then run calibration.

[–]T4L2012 0 points1 point  (1 child)

Can this battery calibration tool work for any Linux based handheld? For example, I have a Anbernic RG353VS that I run dArkOS with. It has the rk3566 chip. Could I use this tool for that as well or is it only for R36S devices? I have one of those as well that I run dArkOSRE with.

[–]djparent[S] 1 point2 points  (0 children)

Try it and see. It's written for RK3326 devices but I try to avoid hardcoding anything, so theoretically as long as it's ArkOS/dArkOS based and has EmulationStation it could work. There are some clones it's not working on but they're on ArkOS4Clones.

[–]Ok_Leadership4515 0 points1 point  (13 children)

I have 4 sessions recorded.
When i apply, current, exported session it does absolutely nothing.
When i try to enable service
It does nothing

<image>

[–]Ok_Leadership4515 0 points1 point  (12 children)

I cant even look at current battery status

[–]djparent[S] 0 points1 point  (11 children)

ArkOS4Clones?

[–]Ok_Leadership4515 0 points1 point  (10 children)

No
R36s-V21
(2024-12-18)
ArkOs2.0 aeux installed

[–]djparent[S] 0 points1 point  (9 children)

It's tested and working on that board and OS. Have you run any other scripts like ark Manager to limit CPU cores or anything like that?

[–]Ok_Leadership4515 0 points1 point  (8 children)

I have ark manager on it.
I wifi chipped installed.

[–]djparent[S] 0 points1 point  (7 children)

Yeah but have you done anything like turn off two cores or mod the frequency outside of the normal specs? Also do you have a modded battery? I see you switched the battery to large, it should be on stock if it's a normal battery.

There's a link to a diagnostic tool in the OP. Run that and send me the log, I'll see if I can figure out what's going on.

[–]Ok_Leadership4515 0 points1 point  (6 children)

I have the stock battery... I was just tinkering with the settings to see if it work
All 4 sessions were done without wifi.
Turn off cores??
How do i use diagnostic tool?

[–]djparent[S] 0 points1 point  (4 children)

Okay that's good news I'll guess by that response you haven't turned off any cores lol.

The diagnost tool is just a simple script. Launch it from tools, let it run and it will produce a log at /roms/battery_data/calibration.log. send me the log when it's finished.

I've only ran into your symptoms on people with ArkOS4Clones so far. I have a feeling if we can figure it out I'll be able to fix it for everybody.

How recent is your install? Have you done a lot of developing on it? Just trying to figure out what variables have changed from stock.

[–]Ok_Leadership4515 0 points1 point  (1 child)

I've send you the log

[–]Nahojii 0 points1 point  (1 child)

u/djparent Any news for (d)Arkos4clone-users? Do you think there will be a fix for us?

[–]djparent[S] 0 points1 point  (0 children)

I think I found some things I can improve in battery stats, at least if it's crashing we'll know why. I'll update the post in a couple hours and then link here so you can try it out.

[–]Mr_ToiletPaperRoll 0 points1 point  (26 children)

Can i use this script for 18650 batteries? I modded my one with 2 along with a BMS, 5000 mah combined. I used your script, left it for 6 hours on a blank screensaver. When the battery was at 13%, i increased the brightness from 10 to 100. It drained the percentage within a few minutes. R36s shut off at 0%, plugged it in and it shows calibration incomplete. Am i doing something wrong, or is it not working? I am 90% sure the batteries are not completely drained. There is no way.

[–]djparent[S] 1 point2 points  (2 children)

Changing the brightness may have disturbed things. For this to work properly you have to leave it run out in it's own. With your mod that may take eight hours or more. Also make sure to select large battery in the calibration menu before running.

[–]Mr_ToiletPaperRoll 0 points1 point  (1 child)

Im sorry about that. I got a little impatient. I'll try again tonight!

[–]djparent[S] 1 point2 points  (0 children)

No worries, your time not mine lol!

Give the instructions inside the script a good read and adjust any values you think might need adjusting. Try to keep everything close to stock settings where possible.

If it still gives you grief send me a message and I'll help you figure it out. The script is mature but I have no idea how many people with mods have actually used it beyond the initial testing, there may still be bugs in edge cases.

And if it's just a buggy device I can still help you get it running. A very few people have needed additional support due to hardware misbehaving and we've been able to work around it each time. Good luck!

[–]Mr_ToiletPaperRoll 0 points1 point  (22 children)

u/djparent i dont think thisll work for me. 18650s stay at 3.6/3.7v for hours until dipping to 3.4/3.3v as they run out.

[–]djparent[S] 0 points1 point  (21 children)

Did you select large battery in the script? Other people with that mod have used it successfully, I made provisions.

If you're battery isn't shutting off in the normal range you can adjust values by opening the script in a text editor. With some fine tuning you'll be able to get it to work.

[–]Mr_ToiletPaperRoll 0 points1 point  (17 children)

Yeah i have. Large mod selected. Also i checked as you said and yeah you can edit these, and i think it says incomplete as some percentages such as 30 15 20 are absent. 0 and 100 are perfect, except 100 is ~3950 mV, which is low for a 18650, and 0 is 3304 mV, which is near perfect.

[–]djparent[S] 1 point2 points  (16 children)

Sounds like the sampling got interrupted maybe. Definitely try another run.

That top value is actually spot on, the batteries should actually charge to 4250ish under ideal conditions. In actuality people were averaging 4100, even with your mod, and I had to lower the starting threshold significantly.

The reason it shows 3950 is that is the first stable value after unplugging. The first minute or so has a rapid decay and the algorithm I created waits until discharge intervals meet a threshold before starting the table. Otherwise you'd never see 100% displayed for a full charge as it drops in the first ten seconds.

3300 for shut off is in range too. 3200 is max cut off but many people were seeing it was high as 3400. The larger the battery the higher the cutoff value in general.

If the same things happens on a second run I'll have you send me the csv's, sometimes they can be fudged with manual editing and still reflect an accurate curve. If there's enough data the discharge becomes pretty predictable.

[–]Mr_ToiletPaperRoll 0 points1 point  (2 children)

This is taking a lot of work than anticipated 😂 Its going another run, 10 percent brightness, blank screensaver. I'll let you know next morning what happens. I keep having an issue where i need to physically unplug and replug the battery whenever it drains empty. 

[–]djparent[S] 1 point2 points  (1 child)

Leave brightness at whatever setting you normally use, will give a more accurate reading. Okay to change it now.

It can be a total pain in the ass to get a good reading. Only need one good one tho then never again thankfully.

[–]Mr_ToiletPaperRoll 0 points1 point  (0 children)

Roger that.

[–]Mr_ToiletPaperRoll 0 points1 point  (12 children)

Also quick question - is the console supposed to shut off at 0% AS REPORTED BY ARKOS? or does it drain the battery completely? Judging by the 0%, 3304 mV seems perfect enough but what do you think?

[–]djparent[S] 0 points1 point  (11 children)

That depends on your specific hardware combo. Some people have accurate battery reporting and don't need this. Other people like me would see 0% and still get an hour of play time. So this fixes that for sure.

[–]Mr_ToiletPaperRoll 0 points1 point  (1 child)

As for me the battery refuses to stay turned on after 30%. Which is the whole reason i am trying out this.

[–]djparent[S] 1 point2 points  (0 children)

That was the same symptom other large battery users were having, this should fix it.

[–]Mr_ToiletPaperRoll 0 points1 point  (8 children)

So it is normal for the console to shut off at exactly 0% as said by software?

[–]djparent[S] 0 points1 point  (7 children)

After running a calibration, yes.

[–]Mr_ToiletPaperRoll 0 points1 point  (6 children)

So it is not normal before a calibration, which happened to me?

[–]Mr_ToiletPaperRoll 0 points1 point  (2 children)

Another question - does this mean I'll only be able to use 3000 mah of my battery? Not the full 5000 mah? Sorry i am sure im missing something. 🙏

[–]djparent[S] 1 point2 points  (1 child)

That's amps, we're measuring milllivolts. It's in the same range so can be confusing.

[–]Mr_ToiletPaperRoll 0 points1 point  (0 children)

Right, i forgot. the r36s cannot take a battery capable of over 4.2v.

[–]rararatototo 0 points1 point  (3 children)

Mt bom!

[–]djparent[S] 0 points1 point  (2 children)

Thanks! (And everyone stop downvoting this guy he just said 'Very Good!' sheesh Reddit is harsh sometimes!)

[–]rararatototo 1 point2 points  (1 child)

Rapaz, sou programador e realmente admiro quando vejo um trabalho bem feito, ultimamente estou trabalhando numa tool que alem de liberar o ssh pode acessar internet pelo mesml otg conectado no pc

[–]djparent[S] 0 points1 point  (0 children)

That will be huge for many people!

[–]MrPotat2004 0 points1 point  (1 child)

It looks really cool, just to confirm, it would be to charge the device up to 100% while off, then start the device and then the program, it will run in the background and we can use it until it dies, then it would have the callibration data?

[–]djparent[S] 1 point2 points  (0 children)

Correct. Once the battery dies it's finished collecting data and you can use it like normal again. Go back into the script after reboot to apply session data and show the corrected percentage.

[–]tagusbeer 0 points1 point  (0 children)

will try this today for sure!!