I read somewhere that the Pimax can detect if you have taken it apart and deliberately brick itself - is this true? They said something about a red-green flashing light, and that the only way to reset the unit was to ask the manufacturer.
I need to take my Pimax apart to modify it - there is not enough room for my nose, it is slightly out of focus and there is dirt inside from manufacturing. I can fix all these issues myself.
I don’t care about voiding the warranty. I am happy to take the ‘risk’ as I am proficient in building and repair of electronic devices.
ive took mine apart 3 times to clear dust from the display (yep everytime i remove a bit of dust i seem to get another bit on there lol). and it still works fine. but this is only my anecdotal evidence
Where did you read that ? It’s funny you mention this. I’ve come across code that’s called ‘take apart detect’ in the FW, not 100% sure what it does though, it seems to read some GPIO, so I think there must be a sensor somewhere. It also does something with the EEPROM, so I’m guessing that once the sensor detects a take apart, it will store the event in EEPROM, so there’s no way to ‘fix’ it yourself, cause it will still ‘remember’ the intrusion, even if you’ve solved the intrusion. Your only option then would be to hack the FW code or ask PIMAX nicely 
But slaughteredlamb above mentioned he had no problem, so who knows …
BTW please don’t pm regarding such FW hack, I don’t do such thing, I want to stay friends with Pimax
1 Like
Can I ask what program you used to decompile the firmware? Or do you have access to the source?
Thanks for the reply - it seems some people ‘get away with it’ and some don’t. I’d really like confirmation from the company of whether this is sheer luck / carelessness or a deliberate built in booby trap though.
Oh, and I found where I originally read about a possible booby trap (in the comments section) : Pimax VR 4k Disassembling - YouTube
No source code, pure hacking. I made a topic about it: http://community.openmr.ai/t/firmware-hacking-custom-modding/842
Be warned, not for hacker newbies, you need ASM experience in order to make sense out of the disassembly.
Anyway, yeah the comments in that youtube video you posted indeed confirm what I saw in the FW code. Be very careful, cause there IS a take apart detection and after reading the comments, it also does seem to work, at least in some cases.
It’s ok to take it a part. I had to do it to replace the system board with a new one that PIMAX sent me to fix a problem.
So I understand the FW code a bit better. The take-apart code works like this:
- Check EEPROM for the ‘take apart’ status. If it was previously set, then function returns true
- Else, read GPIO (general input/output pin, so is reading some sensor). If pin is high, save ‘take apart’ status to EEPROM and return true.
else return false.
So I’m sure now that if you ever trigger the take apart sensor, then it saves the info to FW.
EDIT So I’ve just confirmed that this code IS being called on HMD startup !! I’m not sure though why some people don’t seem to run into problems while taking their headset apart, they somehow seem to not trigger the ‘take apart’ sensor. But the ‘take apart’ detection code is there and it IS being called !
i took it apart up to the point where i got to remove the blue light filter lenses and no further so maybe if you take it completely apart i.e. so that you have direct acces to the screen not just access through the lense wholes. maybe it triggers off then. either way i dont think im going to risk it a 3rd time to take it apart for the bit of dust that got in there when i was cleaning the original bit of dust off
Good work Do you know if manually flashing the firmware erases/resets the EEPROM? Is this information available on the STM32 datasheet perhaps?
I must say I find it bizarre that they would include something like this - what do they hope to achieve by blocking mods in this fashion? The way I see it - if I own something then I have every right to take it apart and alter / improve it. In this case the improvements are 100% necessary.
Could a dev / manufacturer please reply to this thread.
I have looked at every disassembly picture I can find online and I cannot see anything that looks like a trigger for this. I’m thinking it has got to be a switch or a light sensor right?
The only valid reason I can think of is in case of a warranty claim.
If you’ve taken it apart then bye bye warranty.
That would be fine provided it doesn’t deliberately break itself. We really need an answer from the devs on this.
there is a warrenty tab that you have to break over one of the screws in order to take it apart anyway
You thought right ! 
It reads this sensor upon ‘take apart check’: http://www.mouser.com/ds/2/239/Lite-On_LTR-303ALS-01_DS_ver%201.1-348680.pdf
I’m not sure yet what it actually does when it detects a ‘take apart’ …
1 Like
may be a dumb question but does the light sensor work if the headset is not plugged in because i took mine apart 3 times and it works fine
1 Like
That was my prime suspect too, but I also thought that perhaps it was reading the light level of the panel backlight (that is it’s no.1 ‘application’ in the datasheet).
1 Like
The light sensor needs power and the STM32 chip reading the sensor output needs power too. Unless there’s a battery in there (it would probably be the flat, round ones you find on a PC motherboard) or some sort of capacitor setup (unlikely) then i think it would only be able to trigger if you disassembled it when plugged in.
1 Like
On closer inspection, if the takeapart routine is reading a single GPIO I don’t think the LTR-303ALS is our candidate because it runs on an I2C bus.
1 Like