Category: Hardware
[…]
Op zich een behulpzaam aanbod, maar ik zit er niet op te wachten. Men vraagt hier toestemming om per kwartier het stroomverbruik uit te lezen, en te delen met derde partijen, iets wat een serieuze inbreuk maakt op mijn privacy. Ik meet mijn eigen stroomverbruik en ik kan precies zien of er iemand in huis is, hoe laat we gaan slapen, hoe laat we opstaan etc. Dat hoeft niemand anders te weten.
[…]
(Source).
I’ve noticed my AirPod Max being stuck at ~74% battery and not wanting to charge any further. It’s running the latest firmware and I usually charge them on a (legit) usb-A-to-lightning cable connected to my monitor. Even keeping them connected charging overnight would somehow max out at 74%.
There are a few Reddit posts with other people facing the same issue with AirPod Pros (case not wanting to charge further than 74%) but no concrete answer or solution is posted.
For me, what helped, was to use a wall charger (doesn’t have to be Apple); it’s still using a similar usb-A-to-lightning cable. Letting it charge for a while managed to get it to 100%.
Why 74% and not… 75%? ¯\_(ツ)_/¯
Edit: as some people pointed out, this may actually be Apple’s Optimized Battery Charging. I am not seeing any notification though.
I am not sure what is the problem — I’ve upgraded Shan’s 27″ 2k monitor to a 32″ 4k monitor and AutoCAD LT recently updated from 2021 to 2022. Shan‘s been using a 2017 i5 NUC (NUC7i5BNB) with 32Gb RAM using the onboard GPU. Something that should be plenty for a bit of Windows, Chrome, Photoshop and AutoCAD LT.
For the past few weeks, several times a day her screen would black out for half a second or so and then everything should go back to normal. Sometimes it would happen several times in a row, sometimes it wouldn’t for hours on end.
I tried several things, including getting a 8k 120hz HDMI cable, using a usb-c to DP cable, changing the GPU vRAM minimum from 128Mb to 2048Mb (quite the hack, as it can’t be set in the bios — requires messing around in the registry. Wow.), updating all the drivers, updating the bios, making sure the NUC was properly ventilated and keeping cool (every full moon the NUC shuts down due to overheating in Singapore if I set the fan to ‘balanced’ instead of ‘cool’), and probably more. And because it happened so sporadically it was quite hard to debug (to the point I sometimes didn’t want to believe her as I couldn’t see it blacken out).
Shan was getting frustrated (which in turn means I get frustrated)… and I started looking at getting either an eGPU (I can get a free Nividia M6000, just need the enclosure, but the enclosure would be $$), an AMD Ryzen 5 or 7 NUC (no more Intel in this house, but also $$$), or some other refurb (massive) desktop some friend had lying around (HP z240 or something, zero $, but Shan would kill me for having this massive thing on her desk).
Turns out, the quick fix, was to simply disable hardware acceleration.
Run GRAPHICSCONFIG and uncheck hardware acceleration.
This is probably not ideal in the long run (hopefully it’s an issue with AutoCAD 2022 that is getting fixed, as opposed to the onboard Intel GPU getting messed up with AutoCAD).
When in doubt… Turn off hardware acceleration.
I rarely use Bluetooth on my RPis. I’m already facing enough issues with my iMac and Mac Mini (it lags, it randomly disconnects in meetings, etc).
My pwnagotchi on the other hand is counting on a BLE network to connect to the internet: for now I am using my iPad, and while that works, it causes my iPad to disconnect from WiFi (because of course, it can only do tethering from a mobile network, not from its WiFi network).
I wanted to explore if I could set up bluetooth tethering/internet sharing from my RPi4 server… But for that BLE had to work! And for some reason BLE was not working on Liana.
[bluetooth]# power on
No default controller availableFor some reason no controller was available. The drivers were definitely installed…
apt install bluetooth pi-bluetooth bluez raspberrypi-sys-modsbut hcitool dev ; hciconfig -a weren’t returning anything.
After quite some extensive Googling I found the solution…
Check if this returns something:
# ls -l /dev | grep ttyAMA0
lrwxrwxrwx 1 root root 7 Sep 1 15:08 serial1 -> ttyAMA0
crw-rw---- 1 root dialout 204, 64 Sep 1 15:08 ttyAMA0As opposed to:
# ls -l /dev | grep ttyS0
# (no output)Then continue to do the following:
# make a backup
cp /boot/cmdline.txt /boot/cmdline.txt.bak
# edit the file
nano -w /boot/cmdline.txt
# edit the first part from
# console=ttySerial0 to console=ttyAMA0
# the line should be something similar to but do NOT blindly copy paste it as you won't be able to boot due to your PARTUUID being different
console=ttyAMA0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
rebootAfter rebooting … it works!
liana ~ # hcitool dev ; hciconfig -a
Devices:
hci0 DC:A6:32:B1:0E:79
hci0: Type: Primary Bus: UART
BD Address: DC:A6:32:B1:0E:79 ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:2397 acl:0 sco:0 events:118 errors:0
TX bytes:2603 acl:0 sco:0 commands:99 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'liana'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 5.0 (0x9) Revision: 0x13b
LMP Version: 5.0 (0x9) Subversion: 0x6119
Manufacturer: Cypress Semiconductor Corporation (305)
liana ~ # bluetoothctl
Agent registered
[bluetooth]# scan on
Discovery started
[CHG] Controller DC:A6:32:B1:0E:79 Discovering: yes
[NEW] Device 7F:A9:BC:8D:E4:14 7F-A9-BC-8D-E4-14
[NEW] Device 58:EB:19:D8:D4:23 58-EB-19-D8-D4-23
[NEW] Device A4:83:E7:42:79:F6 A4-83-E7-42-79-F6
[NEW] Device 58:7B:24:1B:CC:5C 58-7B-24-1B-CC-5C
[NEW] Device D9:05:9F:DB:55:19 N0163
[NEW] Device 5F:DA:90:34:82:68 5F-DA-90-34-82-68
[NEW] Device 77:2A:1B:11:54:7D 77-2A-1B-11-54-7D
[NEW] Device 42:BF:0B:38:F3:20 42-BF-0B-38-F3-20Next step is trying to get tethering to work…