Why?

---

First of all, the information you read here is made out from my point of view, what I have experienced and what I could do about it. Also some friends also helped me to look at certain points.

Lately I have been watching more deeper into hardware, and wanted a bit more challenge. This after a small USB-C project on a STM32 uC, flashing through SWD, but it seems you can debug through there too. Gues what, the NRF52 has also a SWD debug port to flash it's firmware and debug. For this you need a JLINK by Segger, however I don't own this hardware, the STLink v2 can flash STM32 products only. so how? With Raspberry Pi and OpenOCD, you were able to flash it's firmware and debug memory addresses and update UICR using the GPIO on the RPI, this also works for many devices such as STM32 etc.. This kinda really wants me to do some deep dive into the firmware, and create modified or custom code onto them.

It's now 2024, in 2022 I tried to do modification but I had no idea where to start and if it would work, so I pickup this project again and start digging around again.

Flying trackers

---

You see it everywhere, in VR, yourself, your friends, etc in social games using more then 5 SteamVR tracked devices. They recover quickly at some point but for example a livestream or live performance, it's not really ideal as it can also distract you from doing a performance and trying to recovering it.

General Common fixes

The most common fix is to use the extension lead and cradle that you received with your HTC Vive trackers, place them far away your PC and from each dongle. Also USB3 port's tend to be noise too on 2.4ghz when that device is active such as writing to a hard drive or flash disk.

You can just extend it with a USB2 hub, USB3 hub will be overkill as it don't use USB3 data transmission, and it doesn't use the 4 added data pins inside the connector. This common issue is everywhere where many users thinks, if USB2 bandwidth isnt enough add USB3 to solve's its problem because its 5gbps + instead of 480mbps,,, but it isnt. Another example would be like, you can breakout your USB3 port, and connect a Mouse/keyboard to the USB2 datalines, and a USB3 Harddrive to the USB3 data lines. These Dongles work's on USB Full Speed, it's bandwidth is max around 1.5mbps, and its usb specs max out on 12mbps, so you have plenty of room in the 480mbps space! You would say, connecting it to a usb3 port will cover you up to 5gbps, no it isnt!

This also implies on USB-C as that connector is just many stuff in one.

Reflective or shiny surfaces as your windows or glossy monitor screens, mirrors, they mess around with tracking too, cover these up or let them reflect away from your space. Sometimes if your controller has been offsetted by a few CM, cover up the entire tracker/controller for 3 seconds, and get it back into the space. this will allow the tracking system come back aka, it re-calibrates internally (in lighthouse_driver.dll).

Tundra's replied to me after a question on their Devkit: Trackers are just data collectors.

Next one is Wifi congestion, if you're living in a place with alot of wifi around, and actively used it's sad, trackers don't like it. Wifi has some functions to let go Bluetooth packages first having the Bluetooth Coexistence option enabled.. but the trackers are not Bluetooth, they have support for bluetooth but they are using the Nordic's proprietary Protocol. In common they are lookalike like BLE packages.

In this case, it's either asking your neighbor to reduce maybe the Transmit powers of their devices or move to another place, the dodgy work around would be building a pharaoh cage, aluminum foil all around you lol. Speaking about transmit power, reducing 2.4ghz transmit power to its lowest level is recommended, also increase the Beacon Interval, the beacon package is normally used to transmit your SSID in the air and your phone will pick it up etc..