I have already tried connecting the mobile to the lower USB-C port of the Pimax 8KX and it starts charging, although it warns that I check the connection with the charger as if it lacked power. But it does not cause deterioration in jitter values. I’ve already connected that same USB-C cable to the mobile charger to see if it added extra power, but the jitter has not improved or worsened, same values.
And this morning I have mounted the whole PC in the 30m2 living room, testing many points of view between base stations and HMD, heights, distances, etc … and in no case have I been able to obtain better values than those I published previously. Here everything is tested and there is no possibility of improvement. Nor can it be the USB cable or the PC ports, all tested in countless combinations. Same results.
I have also tried this tool which seemed similar to the jitter tester, but it also reports the controls, their position and deviation. And it is curious that my knuckles are much more stable without jitter than the HMD, and all the information that the knuckles receive from the same base stations is received by the internal dongles of the Pimax and they go through the same cable and usb to the PC. So communication with the PC is ruled out, that’s fine.
Tried connecting the extra USB power connector of the 8KX to a 2.0A PCIE USB Card, made no difference to tracking at all.
Tried the TrackingStats that @Chumet posted a link to, with both my 8KX and my 5K+, on same pc, same room, same LH2.0’s and same Index crontrollers, all reflective surfaces covered.
Avarage Positional Deviation and Avarage Rotational Deviation is allmost exactly double (twice as bad) on the 8KX. it confirms my previous findings with jittertester.exe
What is even more noticable is this…
Avarage Positional Deviation and Avarage Rotational Deviation of the Index Controller is allmost on par with the 5K+
Why the (sensored) can the tracking on the 8KX not be at least as good as the 5K+
So this concludes (as @Chumet did as well) it’s not the PC, it’s not the USB connection, it’s not the Valve LH 2.0’s it’s the 8KX that is a fault here.
Hi Helio
I know what you meant, but 2A should be more than sufficient on the extra power connector and the other connected to a USB3.0 as the only one on the internal MB USB hub.
Remember, this is Pimax’s design…
One data connector for USB3 and one USB2.0 connector for extra power.
Just think of the “new” optical cable… only One USB3 connector
If the suspicion now is in the additional power, there is nothing to do, I understand that the 5K + has a 12v power adapter, and the 8KX has a USB 2.0 (+ 5v). No matter how much amperage you put into the USB 2.0 or USB 3.0 port, 5v is 5v and not 12v as in the 5K +. But it seems to me that it is not a matter of food. I have been looking at the characteristics of the sensors, I think I deduce that they are TS4231 and operate at 3.6v. Either there is some HW fault that they should solve if possible with a firmware that correctly interprets the signals that reach these sensors, or they can recognize that the blue paint is impairing the reception of the signal.
I am thinking wattage vs voltage. The 12v might be being stepped down as if I am not mistaken all components can run on just 5v supply. The v2 prototype for example ran on 2 usb like the 8kX and from the demos then tracking ran. Though they were having some issues with power delivery(well dual usb 2.x cables). Leading them to switch to the 12v brick.
However as @MrAhlefeld has mentioned tge Optical cable only has 1 usb 3.x(which might not be sufficient for laptops). As far as I know those here with the optical cable I don’t think have reported tracking issues -> however not all 8kX owners seem to be having tracking issues.
So kind of perplexing. We pretty much need to be able to compare setups and hmds and try the hmds on a system where another has no perceived tracking issues.
Thank you so much for the feedback sir.
We have wrote this issue into the lists for our R&D, and hopefully they could figure out something to get it resolved.
Thanks for commenting @PimaxQuorra
But this has been stated more than a few times earlier, that R&D has been informed and so on…
So if you could PLEASE! have them working with us, use us that have the issue to try to mitigate it.
Consider this my personal invite for them to reach out to me.
There must be 2 different coatings, if that’s the issue. I have the 8KX with lighthouse v1.0 and now v2.0 and I see zero difference in tracking from v1.0 to v2.0. I’m not sure what would be considered decent tracking numbers but these are 2 tests with the v2.0 Pimax supplied lighthouses. and I don’t notice any jitter in the HMD.
Would you mind sending me or leaving your Pimax 8KX config.json file here? It is located in the path: C: \ ProgramData \ pimax \ runtime \ config \ lighthouse \ lhr-xxxxxxxx, if there are several folders that start with lhr …, one of them is the Pimax tracking configuration, it would be helpful to me. It helps to compare with mine a part of the file where the “modelPoints” is and describes the position of all the sensors. In my file there are some points that have very long numbers and it makes me wonder if it is not the correct one and it is causing me a very noticeable jitter. Your jitter data for me would be great, although that of an INDEX may be better, I am satisfied with getting something like your sample in your images.
I was referring to @cruser_icu , if you could share your config.json. please. And on what date did you receive your 8KX? For trying to see in time if it could be for a batch manufactured with the problem. I received my 8KX in October 2020.
So as far as I can see here, the jitter on the 8KX is still ongoing? Shame really, since I have a 4-station setup of Valve 2.0s and I am warming up to the idea of getting an 8KX. But they seriously are dragging this out to several months now without even acknowledging something being weird?
The difficulty is some have this issue while some don’t. What doesn’t help is pimax not offering much input on the subject.
As mentioned earlier we would pretty much need 2 people to get together with there setups and headsets to try them on each others and see if the issue us present or not.
I suspect something off between batches be it the sensors or housing. It could even be some kind of power delivery issue within the headset or a USB controller configuration issue in the headset like those experiencing HT detection issues on there 5k models.
Maybe that can be worked out by including order and delivery date of the HMDs in question into the dataset that it being built up? Maybe the errors to indeed line up with just a certain batch or timeframe being affected.
it confirms my previous findings with jittertester.exe
