This is exactly what a community is for !
Thanks guys !
This is exactly what a community is for !
Thanks guys !
Has anyone tried to see if lighthouses show up on something like smart phone BT?
I know Wii Motes required a Toshiba BT install editing out the Toshiba driver to your driver.
Agreed but I’m just lazy and don’t want to code the additional UI elements required to allow users to add/edit remove IDs (e.g. if they make a typo). Will impose a time limit of tonight for automatically getting the IDs before I go down that road.
Yeah, it seems to be intermittent, at least with the base stations I have. I’d say they advertise the full name (including the partial ID) about 50% of the time.
I have a Bluetooth dongle on my PC from BlueSoleil. In one of the tools from it, the basestations show up - but no BlueTooth Services (to connect to) are being found. Or at least the given software don’t recognize the service as one which it can connect to.
But this shouldn’t be a problem if ixalon is able to speak with the basestations via the OS API. With that it shouldn’t matter which BT Device you use.
They do show up with a Bluetooth LE debug tool/app such as https://itunes.apple.com/us/app/cysmart/id928939093?mt=8
They advertise GATT services (i.e. Bluetooth LE) which differ from normal Bluetooth services (which e.g. require pairing).
Ah thats the difference, thanks for clarifying this
Have you looked at Wii motes? I knoe they required spoofing a toshiba BT to allow pairing.
It seems I was able to wake-up one of my basestations unfortunately, it is not completely reproducible.
I was using my Raspberry Pi built in BT to do that:
pi@hass:~ $ sudo hcitool lescan LE Scan ... 40:??:??:??:??:A1 HTC BS A1F2A1 40:??:??:??:??:A1 (unknown) 14:??:??:??:??:FF (unknown) 4C:??:??:??:??:02 (unknown) 4C:??:??:??:??:02 MJ_HT_V1 4C:??:??:??:??:69 (unknown) 4C:??:??:??:??:69 MJ_HT_V1
Then I run
gatttool -I -b 40:??:??:??:??:A1
[40:??:??:??:??:A1][LE]> connect Attempting to connect to 40:??:??:??:??:A1 Connection successful [40:??:??:??:??:A1][LE]> char-write-req 0x0035 1202012cffffffff000000000000000000000000 Characteristic value was written successfully [40:??:??:??:??:A1][LE]>
At this point the BS started spinning and after maybe like 55 seconds stopped. It could be because it is configured as “C” (slave) and without “B” it shuts itself down. I should power “B” as well, but if I do that, both will start, and I won’t know how to shut them off remotely.
The other unclear point right now is that when the BS stopped, I was not able to wake it up again immediately. Like if there was some additional timeout. Only after several minutes I was able to reproduce the procedure.
Maybe I am doing it all wrong and I should try to control “B” station as “C” seems to be able to wake up simply by seeing “B” being active. But it is definitely a good start.
Holy #$*# that´s what i call progress !
I would focus on b (master) and ignore c (slave) because later will automatically power on/off depending if b (master) is powered on or not. So there is no need for the Tool to support a Shutdown Command for the c (slave) basestation at all.
I can also imagine that the Motor of the basestations need some time to settle into a position where they can ‘restart’ in a ordered manner. Might be the reason why you can’t restart them immediately. For our purpose a quick restart isn’t needed either. Those who falsely shutdown their basestations just have to wait - a simple notification that there are some minutes to wait would be enough.
btw. do you have a recommendation for a gatttool replacement for windows?
Yes, that is why I had a look on “B” station just now. There is definitely a difference between how “C” and “B” behave.
I can put running “C” into the stand-by mode by executing the command (suggested here)
[40:??:??:??:??:A1][LE]> connect Attempting to connect to 40:??:??:??:??:A1 Connection successful [40:??:??:??:??:A1][LE]> char-write-req 0x0035 1202012cffffffff000000000000000000000000 Characteristic value was written successfully < here the basestation starts spinning, if it was in stand-by before > [40:??:??:??:??:A1][LE]> char-read-hnd 0x0035 Characteristic value/descriptor: 00 12 01 2c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [40:??:??:??:??:A1][LE]>
Is a bit tricky, first I am not able to let it fall “asleep”, once it is powered, it runs indefinitely, and also wakes up “C” along the way. Which is the intended behavior, but when I execute the same command on running “B”
[40:??:??:??:??:12][LE]> connect Attempting to connect to 40:??:??:??:??:12 Connection successful [40:??:??:??:??:12][LE]> char-write-req 0x0035 1202012cffffffff000000000000000000000000 Characteristic value was written successfully [40:??:??:??:??:12][LE]> char-read-hnd 0x0035 Characteristic value/descriptor: 00 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [40:??:??:??:??:12][LE]>
The 3rd-4th bytes are
00 00, while with “C” the response was
01 2c. If it is a timeout value (as suggested by the link above), then my “B” is clearly set to not timeout, which is consistent with the observed behavior.
Now, according to the author of the description, the timeout can only be set if real ID is provided instead of
ffffffff as is in the command I tested.
So the conclusion so far is, basestation “C” is already set with non-zero timeout (300), while “B” is set with zero (0), and in order to be able to put “B” into stand-by as well, this value has to be changed, but so far I do not know which ID to use to do it.
I believe it is the 8 character hex code written on the back of the base station called “ID” (half of which should be visible in the name advertised over Bluetooth), so for your “C” base station:
xxxxF2A1 (think you said it was
Are you sure you activated the energie management and stand by feature via SteamVR Bluetooth Settings while the HTC Vive was connected?
Please note: in case you’ve upgraded the firmware recently, even when you had activated the power management before the firmware update, you still have to de- and reactivate the energie management feature otherwise it seems not to work. You can check this by leave the htc vive connected, stop steamvr and both stations should shutdown - if they arn’t you have to reapply the management settings.
Would it be possible for you to capture the bt signals while you activate the power management settings via https://github.com/virtualabs/btlejack ? Those should set the timeout?
Btw. i am not sure if timeout means only: IF i (as a basestation) can’t reach my partner within the ‘timeout’ window of 300 sec, i will shutdown myself? In this case it would make sense that “B” (master) does not have any timeout set because it don’t care for the slaves.
I do not have any BT LE sniffer hardware (as for example suggested BBC Microbit device), which btlejack supports.
I believe the timeout means the time in which the basestation goes into the stand-by if it does not receive another wake-up call. Vive works like that: when you choose BT managed power for basestations they run only as long as they keep receiving the “pings” from the PC. Once the pings stop, they wait for particular “timeout” and then go into stand-by.
From what I saw however 300 does not seem to correspond to 300 seconds, the basestation “C” went into limbo after about 55 seconds. The similar time I seem to recall from when I used Vive and shut down the SteamVR, there was a short delay, before the basestations stopped.
btw. found via Reddit. Might be some hints hidden there…
Try the SteamVR web interface at http://127.0.0.1:8998/console/index.html . It has a log of bluetooth communications and you might understand better of how it works. You need to be in the SteamVR beta.
OOooorr… we register ourself for a Free SteamVR License:
And get from there support or even get access to the base station specs.
Might be extremely usefull to plug in a Vive and do the normal startup and shutdown procedure.
The the logs will be filled with precious info !
I see the console in my standard SteamVR version and it is amazing! I have not connected Vive yet, so no bluetooth info. On the other hand, it seems I was able to keep my basestation running for specified time by using the commands described above and pinging “B” repeatedly. So technically, I am able to control them.
So your Basestation is shutting down with the first command? But only if you stop sending a ping? Wasn’t there a command to power it on/keep it on - without pinging it? i mean, the pimax 5k+ without the breakout box isn’t pinging the boxes neither.
Waking up an already sleeping base station works with the ID set to 0xffffffff.
P.s.: If i think about it … yeah it might be that the ping IS necessary. If you activate the power management and connect then the Pimax 5k+, the basestations are going into standby and never wake up again. Makes sense - because - the pimax 5k+ is either sending the power on, nor the pings necessary…
I guess you cracked the code
Cool this also means that you could even shut down / crash your computer and the base stations are powering off automatically