Base stations turning on and off repeating 5 times (attempt_count_set count)

[panmarco83]

Was just going to look into something in VR today and have been using steamvr_utils for some time now without problems.
click vr icon in steam where the master base station spins up (at a louder / faster mirror spin rate than normal) then stops, then repeats the same count as is stated in the config for attempt_count_set.

I tried switching from the current latest linux steamvr version to the linux beta version, same problem.

waited for the base station to spin down (fail out), then started steamvr without starting the base stations, then unplugged and replugged the power for the master base station (station b), it spins up (at a normal mirror spin rate) and triggers station c like it normaly would.

Now, this started happening only today so I suspect it might be something that changed with some f'ing update from ubuntu that messed with it.

Ubuntu 20.04.3
Kernel 5.17.1 generic (Mainline)
Mesa 22.1.0-devel

Any suggestions to what could be causing this ?

[DavidRisch]

I sounds like you have V1 Base stations, right?
In that case you could try running https://github.com/risa2000/lhctrl directly. If that also fails, please raise an issue in that repo. If that works (and it reproducably fails with steamvr_utils) it could be some issue with my use of lhctrl.

It sounds unlikely that this is related to an ubuntu update, the bluetooth connection seems to work and the transmitted data should not be altered by anything outside of the python scripts.

at a louder / faster mirror spin rate than normal

That seems very strange. Could something be wrong with that Basestation(s) (software or hardware)? You could try switchin which basestation is b and which is c.

[panmarco83]

I dualboot ubuntu and arch and have booted up arch (since I have been too lazy to finally switch over to arch until now) and I'm having the same problem here.
I'll take a look at the repo you pointed too and respond back afterwards.

[panmarco83]

Oh, and yes, it is V1 BS's, that's correct.
That worked:
python lhctrl.py -b <b-id> -c <c-id> --lh_b_mac <b-mac> --lh_c_mac <c-mac> -i 1
It started up just fine this time, it spun up a bit over optimal, then back down to optimal speeds.
(I've grown accustomed to the vibration sound it makes when spinning up and when it's stable)

The problem could be that the timeout (first BS) to "stabilize" and transmit all clear back is too short pr default.

[DavidRisch]

The problem could be that the timeout ... is too short

You are probably right. I am using a --lh_timeout of 10 (I don't know where I got that value from) and the default of lhctrl is 60.

Could you please try changing this line:

steamvr_utils/scripts/basestation_interface/v1_interface.py

Line 34 in eac1eaa

'--lh_timeout', str(10),

to '--lh_timeout', str(60), locally and check if that fixes the issue?

[panmarco83]

hm, looks like it was enough just by increasing it to 20.
Mind you that my entire Vive kit is the original I bought back in november 2016, so that's closing in on 6 years of (light to moderate) usage.
Nothing has needed to be replaces other than the power adapter to one of the base stations (just got a power adapter that could do the right voltage at the right amperage and that was that).
But the linkbox has started having some problems; last August I got a new GPU and the bluetooth chip in the linkbox stopped working after switching out the GPU for some reason.

Anyway, all this said; I don't know if this is the reason for the odd behavior of some of the devices or if it was just a small problem of timing somehow.

I'll probably need to replace the whole kit soon since the right eye display has just started glitching a little as well....

Anyway, thanks for the support :)

It should be enough to just increase to 20 instead of all the way up to 60 (seconds?) and/or possibly adding a config file option for it (along with a small explanation) in case of others having similar problems.

Should I close this issue or would you like to do it ?

[DavidRisch]

I set the timeout to 30 seconds so there is some headroom for people with even slower basestations then yours.

Thanks for basically diagnosing/fixing the issue yourself.

[panmarco83]

no problem, have a nice week :-)