It is a real concern that when you want to switch off your beloved Crystal, it just isn’t doing what you wanted from it… It reboots and bam is back online, wanting you to beplay it even more. A sometimes working workaround for this is to first look at the screen to verify it is switched off and then press the power button of C. for about five seconds to power it off. For the case this wasn’t successful, my solution was to do it again and then wait until the battery LED is going off, only to then quickly pull the battery immediately followed by the DP cable on C.s side. But this isn’t working every time.
That’s not true anymore The last ten times or so it just switched off fine, looks like pimax Play SW 1.18.3.0 is doing wonders here.
So, about that restart loop… I’m beginning to suspect it might be related to the headset’s power consumption. It seems like it detects that power is still running even after you’ve pressed the shutdown button.
Jep, I’d play the whole day if my kids and wife allowed me hehe.
I could imagine, that it is somehow connected to the internal cooling solution? Because every time it doesn’t want to power itself fully off it is more than hand-warm, means 38-40°C at least. Now I don’t know if it is a problem that it gets so warm, or if these temps are default (which I’d think of they are normal for such a lot of electronics inside). I wasn’t able to see a structure in this failure, like “when this is the case, then it won’t switch off”.
Yesterday I wrote that it’s fine the last ten times or so; now think of what happened this morning It didn’t want to switch itself off, so I just pulled battery and cable on c.s side then.
another idea was that it’s connected to the LED rework, since it was introduced with this firmware. this idea arose because of the battery LED switching on and immediately off in a ~ 5-7sec loop. sometimes for about ten to 15 times, sometimes even longer and sometimes only one or two times; but every time when this happens the device is powering itself back on after that.
when you need logs or videos or anything (am capable of debugging android devices pretty well, btw on which android version is Crystals OS based on?) please don’t hesitate to give me corresponding instructions please
this atm happens more often again; it’s like it has good days and bad days. when I need it to switch off correctly because the battery needs charging then it’s not working, and when I switch it off being neutral about this or don’t even think about that it may need charging then it works. which leads me to the conclusion, that this may only happen beginning with a certain low percentage of battery level… I’ve never watched it in this detail, will do.
what I found too is that now it sometimes loses tracking, which shows in the way that the picture will fully drift away for three to four seconds so hefty that I have to close my eyes for not puking all over the table (just kidding, am not really motion sickness sensitive; but sometimes this really kicks ). additionally it switches off sometimes in the middle of a session, but simply pressing power button brings it back on then. this didn’t happen before the fw update. since it’s stuff which should’ve been fixed in fw before this last version I start to think that so your thought about messed up power consumption logic could be a point imo, jep.
these other flaws, something I should open a new topic about? I wanted to test the new template with added PC specs anyway (is it added already…?).
The shutdown bug has been acknowledged by our developer team, and today we had a discussion about it. After reviewing all the reports, I’ve urged the head developer to include this bug in their upcoming development project. Hopefully, the patch can be released as soon as possible to eliminate the issue entirely.
The tracking loss/drift might be related to the camera not detecting enough ambient light.
The shutdown bug is related to the power consumption logic, as we have opened the passthrough feature, which requires much more power supply than the previous patch.
I would suggest taping the proximity sensor to prevent the headset from entering screen saver mode during the gaming session.
I’m on LH faceplate with four LHs, I should’ve written that, sorry so this drifting is confusing me even more. not to the controllers btw, only HMD while driving for example where no controller is used. I had the wheelbase in mind and it possibly causing electric interferences (it’s a moza R21 which has an good amount of power lol; wouldn’t be surprised if there would be a minimal leak which can cause such stuff).
some questions for my understanding:
lighthouses, the hw itself, so the boxes mounted on wall meant:
are they dependant on any steam services / libraries or can they really supply tracking even when steam is not installed?
didn’t test this, but when it depends on steam stuff, then the drifting could be related to steam changes too imo.
taping proximity sensor:
the one above / on heigth of nose? this one should be covered all the time, maybe cleaning this part can help, thx for tipp. otherwise I’ll try taping it
shutdown bug:
this would really be muuuuch appreciated by plenty of folks, a lot of ppl are having problems with this
thanks for your answer, and no problem it being late in your opinion, it’s ok!
hmm, please count the LH tracking drift out for now I’ve found three additional mirroring surfaces which need covering, it’s better now. this room is offering plenty of space but has otherwise real bad conditions (reflecting surfaces being one of them, directly followed by a ceiling height of only 1.98m and others xD).
Could you please send me the serial number via DM? There’s a beta firmware update coming this week that our team developed to address the shutdown issue.
We’d love for you to test this firmware version and provide us with your feedback.
sry for my late reply, my writing mood is only slowly coming back atm. I hope it stays a bit^^ I’ve just hit you a PM, am excited if it may be working!