Create modify your own *perfect* dongles - ZuwaiiVR/Watchman_V2_detailed GitHub Wiki
Notice
Before doing any of these modifications, I'm not responsible for any damage or broken/bricked devices. However you will able to unbrick a device if something goes wrong with firmware upload/download.
As updating the firmware through USB is alittlebit out of the question right now, it needs signed keys to actually update the firmware the normal way using nrftool that sits inside the win32 folder in lighthouse tools within steamvr. The bootloader prevents updating the dongle if it doesn't have the correct signature. nor, clones that doesn't have UICR perfectly setup are also not able to update. Once NRFTool triggers DFU mode on the dongle, the dongle will just reset instead going into DFU mode, once in DFU mode it should enable a Serial Port connection, this is used for pushing the binary file to the device.. which doesn't do so.
Through SWD you can access the flash as many time as you want, even lock it or fully erase it. With lock you cannot access the flash memory but only clear it, so your firmware is sort of "protected" but there are ways to bypass this as this done by glitching the device. (which we dont have to do that luckily)
Creating from scratch
In this section I will be using the HolyIOT NRF52840 module, and the official Nordic Developer Dongle PCA100059. Both are working fine for being in use as Watchman Dongles, however, the HolyIOT modules needs some fine soldering, or even a PCB design (which I didnt). the PCA100059 dongle is ready to use, but also it lacks certain pins. I did some firmware modification specific for the PCA100059 to get access to those pins.
The HolyIOT module comes with no firmware, it's mainly empty, no bootloader so you need to flash the firmware through SWD, the PCA100059 has a bootloader but you might wanna get another bootloader on it that accepts UF2, or once you're on it, you could just flash the firmware directly on it instead having a bootloader.
OpenOCD & Raspberry Pi / Connecting up.
I use OpenOCD with a Raspberry Pi 4, and the Bitbanged JTAG SWD driver, to update and to debug. If you're known with Linux, then you should be fine.
Sofar I have used the command line version of RPI OS, and install OpenOCD using apt-get.
sudo apt-get install openocd
once installed, you need to create a new file and put the configuration down below in it. Call it like openocd-nrf.cfg
adapter driver bcm2835gpio
# Raspi1 peripheral_base address
# bcm2835gpio peripheral_base 0x20000000
# Raspi2 and Raspi3 peripheral_base address
# bcm2835gpio peripheral_base 0x3F000000
# Raspi4
bcm2835gpio peripheral_base 0xFE000000
# Raspi1 BCM2835: (700Mhz)
# bcm2835gpio_speed_coeffs 113714 28
# Raspi2 BCM2836 (900Mhz):
# bcm2835gpio_speed_coeffs 146203 36
# Raspi3 BCM2837 (1200Mhz):
# bcm2835gpio speed_coeffs 194938 48
# Raspi3 A/B+ BCM2837 (1400 MHz)
# bcm2835gpio_speed_coeffs 227428 56
# Raspi4 BCM2711 (1500Mhz):
bcm2835gpio speed_coeffs 243704 60
# SWD GPIO set: swclk swdio
#bcm2835gpio swd_nums 23 22
adapter gpio swclk 23; adapter gpio swdio 22
bindto 0.0.0.0
transport select swd
set CHIPNAME nrf52840
source [find target/nrf52.cfg]
# Uncomment & lower speed to address errors
adapter speed 1000
init
targets
Select which Pi you are using, I'm using Pi4,but if you're using Pi3 just uncomment and comment out the Pi4.
Once that's done, you connect your modules like this. this exclude power circuit on the HolyIOT, in that case you should read the datasheet how to connect them up. In my case I only gave VDD_nRF 3v3, and VBUS 5V. on the PC10059 module, you can power it up through USB.
Once connected up, run a Terminal shell, and run
openocd -f openocd_nrf.cfg
where openocd_nrf.cfg is the file you just created, if anything is alright you will be prompted with:
if not, check your wirings~ From here, you open a Telnet Session to your Pi's IP address on Port 4444. It can be either on the Pi, or a PC, up to you what you find best.
You can run some commands like: help To view all available commands. Either for testing:
halt
nrf5 info
Right now you can continue reading the other articles!
Multiple dongles (Or so called Super Dongle)
In Tundra's firmware, the max dongles they support is 7 pieces all together whether this is a limit of the used USB Controller, or defined received/transmitted frequency channels during generation by SN Number. I havent reversed this part of the firmware yet but by guessing, it may also offset transmit/receive timings, as the firmware outputs also a Clock Signal to a GPIO which can be read out by a oscilloscope.
Apparently not every chip is equal, the NRF52840 clock's drift very slowly, this means that sending and receiving will drift and can cause transmit at the same time a packet loss, as the NRF Radio is not perfect with multiple receivers. this is by connecting all clock signals from dongles to a Osciliscope, the short pulse from 666hz will slowly drift. In code this clock pulse generate by HW TIMER. I assume this was used for debugging in Valve's lab, as this clock pin isn't connected anywhere. There is also a Data OUT pin, which looks like if connection is OK, the OUTPUT signal will be mostlikely HIGH. It can be a small indicator when connecting a LED to it. Since it's a Data OUT pin, a LED can be hooked up. It can be used as a simple status pin..
| ---- | --------|
| state | LED |
|---|---|
| Power up | 2/4 brightness |
| Paired with tracker | 3/4 Brightness |
| Connection interruption | unstable blinking |
| Tracker powered off | LED OFF |
So far when I read the reversed code, it reacts on how many packet's has been received, it may also do different things at the same time.. As for example, exposing fully to a basestation will brighten up the LED more then when the don't expose. Ofcourse, the more basestation you have, the more Data goes through..
The way that Tundra solved this issue is by adding a Sync pin to the dongles, so all the dongle's will be in sync with each other. I Assume this was already implanted in Valve's firmware inside the Index HMD, as LYM and RYB does in fact the same with the GPIO. As the SW series can go up to 7 Devices, some of the ID's will sync 180'degrees later.
Connecting 7 dongles ( Pins & Ports )
I modified two firmwares, one specific for the PCA10059 boards, as my drawings arent that pro, the ones that marked green are for the PCA10059 boards.
| filename | description |
|---|---|
| nrf52_zwd_sn.bin | Firmware that can modify Serial number (need to make unique bin files to each fw!) |
| nrf52_zwd_sn_PCA.bin | Firmware that can modify Serial number, pins remapped to PCA10059 dev boards |
| nrf52_zwd_PCA.bin | Only pins remapped, no manual SN creation. |
| nrf52_zwd.bin | none of them. |
| Set of Bin files | I pre-patched the bin's for easy flashing |
| UF2 files | Providing these later, these are for easy flashing without SWD interface |
The DEVICEID can be manually set at offset 0x0004F0A4 to 0x0004F00B, this is not the final SN, mainly the raw ID from the chip.
Next Connecting:
As I mentioned above, ClockOut pin P0.27 can be connected to debug if all clocks are synced from each dongle, either leave this unconnected when not in use. The screenshot is quite old since 2022 as I started to reverse. During pin selection you can choose either using Tundra 7 mode, or stock default Valve Index mode. Simply ground them to select, the pins will be used during at boot up.
You must use at least one dongle that OUTPUT a sync signal on P1.05(P1.04), so GROUND P0.02(P0.13) and leave other pins open. The other dongles should incrementally selected, like 2......7. (Bonus: if you short P1.05 on Tundra dongle to ground, device will go into DFU mode, all dongles)
This drawing only shows how to connect them with their Sync pin, it doesn't include any other parts that is needed for the HOLYIOT modules. For USB hub, FE1-1s are pretty decent. Since NRF52840 doesn't take much power, a single AM1117_3v3 LDO is enough.
My current setup, it's dirty and may not RF approved, however it was a rapid prototype experiment back in 2022. You notice 10 dongles, it works better with custom DeviceID setup to arrange frequencies and not to frequency overlap them as much as possible. but crossovers between channels still exists.
Flashing
This section is when you have OpenOCD fully working. Before flashing on a existing dongle, make a backup!
reset halt
flash read_bank 0 flash.bin 0
flash read_bank 1 uicr.bin 0
For Index or Tundra dongle, the UICR contains a key that has been build for signing the firmware and uploading it with nrftool legally, with this your dongle with stock firmware will go into DFU mode. Offset is from 0x014 to 0x018, uint32_t value.
However, with this key set, the firmware won't boot. But setting it to 0xffffffff,0xffffffff. You will lose the ability to update legally in DFU mode(though there was never a update firmware available), but since you already programming through SWD, it's not needed. You can simply flash this file back onto the NRF52 if you want to revert this. Setting to 0xffffffff,0xffffffff, is basicly Debug mode, the firmware is not looking if the firmware is legit or not.
Source: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_nrf52840_dk%2FUG%2Fdk%2Fintro.html
Ok Flashing..
reset halt
nrf5 mass_erase
flash write_bank 0 nrf52_zwd_sn.bin 0
reset
Since it's a bitbanging library, sometimes the flashing fails, just issue the flashing command again to retry.
Once's done, you can hookup the dongle to your PC to test if Lighthouseconsole.exe detects it. (besure to setup the ID pins)
Version: lighthouse_console.exe (buildbot_vortex-windows_steamvr_rel_win64@vortex-windows) 08778553
Attached lighthouse receiver devices: 10
000300063C-4YX
000600063C-2YX
000100063C-2YX
000400063C-5YX
000200063C-3YX
000900063C-3YX
000A00063C-6YX
000700063C-7YX
000500063C-5YX
000000063C-1YX
lighthouse_console: Connected to receiver 000000063C-1YX
Attempting HID Open IMU: 000000063C-1YX
Lighthouse IMU HID opened
000000063C-1YX: Unable to request config start from device
000000063C-1YX: Triggered keepalive (succeeded)
lh>
Antenna's?
Stock antenna's are mainly PCB Traces or a ceramic SMD antenna's. What I have experience, Radio transmitting can be easy as sending it to 1 channel and it will be there, with some filtering components at the and you likely will avoid harmonics, transmitting away from 2.4ghz. Fine the strongest signal can be picked up with a SDR.
However, the dongles does transmit some Data, especially when you use haptics or updating device configurations etc.. and there is a ping to the trackers/controllers as well. by upgrading the antenna's, surely it will increase the signal receiving strength but also transmitting... the downside is, it will receive more WiFi and other garbage in the air, might corrupts the package faster and if in a tundra dongle design it can even overpower the dongles next to it aswell.
Here's the same picture, but receiver strength increased.
Much more garbage in the air then wanted! You can compare this with friends in your room, talking normally, but suddenly you decided to talk louder and nobody cant understand you proper. The Radio's on the NRF52 are not great too, like a normal broadcast radio station, you tune your radio for its best signal at for example 106.5Mhz FM, but you hear also the same Radio station at 106.4 or 106.6 just with added noise. This however is the same on the receiving side on NRF52 in my experience.
I have scripted a very easy code to transmit on a fixed channel with the NRF52 and a receiver. Transmitting data packages and receiving them back with another module. Weird enough setting them up on channel 5 (2405mhz) I still receive packages on channel 3 4 6 7, though I need to very close to the transmitter. Just imagine your own dongle receives your neigber's dongle information, because he's too loud.
This image shows my wireless Mouse. Also based on the NRF52840! but on 2Mhz of bandwidth, or.. 2mbit.
For now, if you like to spread your dongle's appart from each other, a Antenna might work fine, but to squeeze is down to 1 single box might cause trouble later on. the Stock antenna should be fine. if it were possible to use a Antenna Switcher and proper timings and frequency, it could redirect all to one antenna, but the NRF and it's tracker protocol is likely too slow to handle this. since we need the bandwidth, but also need low latency. the firmware limits to 1mbps so its small and we use already all of it.. w
Modify current dongle
Insert Tundra SW4 here, soon