How to Power Off Basestations remotely?



Will test and get back to you :slight_smile:


If you talk about “B” or “C” modes, these are not transmitted by BT but by the infrared emitter! :wink:. See this page for the detail (base station info block) ( Basically all the data in the lighthousedb file come from this info block.


Yeah but this documentation is not official, I bet it’s also available from BLE.
If the C is in passive how the Headset should know not to issue keepalives?

Looking at the Pimax logging:
[19-09-13 01:35:54][PSRV] prop:Prop_ModeLabel_String:B
[19-09-13 01:35:54][PSRV] prop:Prop_ModelNumber_String:HTC V2-XD/XE
[19-09-13 01:35:54][PSRV] prop:Prop_RenderModelName_String:lh_basestation_vive
[19-09-13 01:35:54][PSRV] prop:Prop_HardwareRevision_Uint64:150994953
[19-09-13 01:35:59][PSRV] lightHouse:LHR-E63A50AD H: Trying to start tracking from base 387D00A3: Samples didn’t yield successful bootstrap pose
[19-09-13 01:35:59][PSRV] lightHouse:LHR-E63A50AD H: Optical frames received again…

“lightHouse:LHR-E63A50AD H:” is optical frames and they seems to start after the “prop:Prop_ModeLabel_String:B” message which is usually linked to the file/usb/ble stuff.
I guess I have to try by myself :wink:


I bet it is not (just to jest :wink:). My experience is that as long as the LHs are not running (i.e. even when powered, but in standby), SteamVR does not recognize them, even if the headset is connected and powered on. I tested it mostly on HTC Vive which has BT integrated and normally turns on the LHs when SteamVR starts (if Power Management is enabled).

To see which devices are currently recognized by SteamVR you can use hmdq tool (, which (when run with props or all command) enumerates all currently recognized tracked devices (including the LHs) and reads all their properties.

I do not think there is any problem with issuing keepalives even for “C”. It is just not necessary, because it tracks “B” and it tracks it thanks to the IR comm.

Now, there are two systems in play though. The IR data transmission and the laser flashes. The headset detects the LHs as soon as it receives the IR data blocks, but it cannot derive its position from this. So to actually get the “pose” it needs also to receive successfully the laser tracking flashes. This is the reason why you see in the log that the system identifies the LH, but cannot get the pose.


Yep I have the same understanding about everything but I feel like would be really dumb not to expose the mode also via Bluetooth. Which makes it very likely!

I will definitely check out hmdq! I had not enough time so far to even read a tenth of all the available stuff around… you went really deep in.

Sure there’s no need to send keepalives for C but from the pi_server logs, which can be misleading being just logs and which I had only a quick look, the B is identified immediately and it’s the only BS which is sent keepalives.
But also just now I’m thinking… maybe at that time I was developing the thread and my script was not waking up the C…
Interesting stuff, will dig more next week.
Thanks for your support @risa2000, invaluable help!


ManniX so far V1.3 works perfect so thank you :slight_smile:


Nice! Thanks @Skidrow
Let’s share some more feedback guys, I’m coming back now.



Not sure I will release an RTX version, I’d need to charge big money for it :sweat_smile:

Just made a new version with minor enhancements:
Fix: Console log window centered on screen
New: Exceptions handling for main thread with Windows 10 toast notifications

Didn’t like with the exe if something was wrong it was just dying (eg. something wrong in the .ini)
Now you get a Windows 10 notification with its ominous sound.

Also started using releases so you can just tag it an get notified once a new version is published:


Found some issues with windows “device association service”, causing abnormal cpu usage, memory leak and even bsods.

Happens on last and previous version each time i start bs manager :frowning:
p.s. windows in insider preview branch, latest stable build (visible at the right bottom corner)!


@industria you are a real masochist to run an insider build :blush:

Let me ask you a bazillion of things…

Can you run it with --debug_ignore_usb and --debug_logs?
Would be nice if you can share the logs.

Considering the service name very likely the issue is related to usb and/or the bluetooth.
Do you have a USB BT dongle or integrated?
Which kind of USB controller do you have?
Did you try other ports for the Pimax HS and/or BT dongle?

How long does it takes to reach that level of memory usage after starting it?
It does it even with the HS off or you need to switch it on to have this leak?
Does it matter if the Pimax HS is detached form the USB?
Which kind of processor do you have?

If you are familiar enough try to look for some more info with Process Hacker:


Nevermind, I can reproduce it too after a while!
Checking out


Ehm yes sorry there’s a a leak in the bleak python library with the discovery function…
Almost unnoticeable unless the async function to send commands is improperly used.
Indeed also the original script after a while is degenerating and the service is consuming a lot of cpu cycles.
I brutally copied from the original without checking it, thought it was at no cost so ended up in the development backlog :blush:
With 2 threads and a more aggressive timing the leak issue becomes critical.
I’m using the library properly now and I see almost zero cpu cycles consumed by the device association service.
@industria thanks for the testing!

Just released new version 1.4.0 with the fix.
The BLE connection being properly used looks rock solid, I don’t see any sporadic error like with the previous builds.
It’s not very elegant but it works, I’ll rework the code properly at a later time.
Let me know about your testing!


Works perfectly for me , thanks for your jobs ManniX :wink:


Thanks this version works fine also for me. Why pimax I do not add a solution like this? This is something basic and important that you must implement


@ManniX - do you know if this will work for the new Index Basestations? If not, are there any plans to extend support for that? Thanks


@jakeyjo indeed I’m almost 100% sure they are not supported by this script. I don’t even know if they are supposed to work with the Pimax.
I’m not going to add support for it because I don’t have any BS 2.0 (and I’m not planning to buy) but the script can be easily modified by anyone.


@risa2000 do you know anything about the Valve LH 2.0 bluetooth communication?
@jakeyjo if I can find some info and you own them and are willing to test I can try. But it’s a shot in the dark…


@ManniX that would be awesome. Yes I can definitely help test. Thanks for considering it!


No. Though I might have, if Pimax shipped them :).