| On (Lasts for 10 seconds): | |
| hidapitester.exe --vidpid 340D/1710 --open --length 10 --send-output 0x0,0xFF,0x01,0x66,0xC8,0xFF,0xAD,0x52,0x81,0xD6 | |
| Off: | |
| hidapitester.exe --vidpid 340D/1710 --open --length 10 --send-output 0x0,0xFF,0x00,0x00,0x64,0x00,0x32,0x9E,0xD7,0x0D | |
| Address: VID and PID (Vendor ID and Product ID) | |
| 0x340D 0x1710 |
@Microgenital Nice one! My ultimate goal was to build a little app that could be controlled by a key binding so I could also get it to work with ATS or ETS. If you ever get around to building something lmk!
Thanks for figuring this out! I’ve put together a quick Go implementation of this (including a command line app) here - https://github.com/duckfullstop/blinkybeacon
I spent a little time on my own with an Openvizla USB MITM debugger to try and figure out what the bytes actually mean, but I’m not really getting anything more than the game just sending these sets repeatedly - maybe disassembling the game might yield some results? That’s way past my pay grade though.
@steve228uk hopefully this is something you can bind more easily to a game, but I am thinking about extending it to add support for listening for game events, artnet, etcetera if there’s interest
Hey there, your gist helped me a lot, thanks for that.
If you wanna have your beacon "blink" instead of "going around" the package to send is:
0x00, 0xFF, 0x07, 0xFF, 0x64, 0xFF, 0xEB, 0x7D, 0x9A, 0x03