dekuNukem
Bluetooth packet timing
Hi, I've been trying my hand at making a bluetooth controller, but I seem to be struggling to get the timings right. Sometimes the switch eats my input, and sometimes it holds a button longer than I pressed it. Does anyone know what's going on?
I thought at first, that when you increment the timer byte, the switch reads the next packet, and ignores subsequent ones. It worked in manual testing, but it didn't work as well when speeding it up.
My goal is to achieve one full button press in 4/60ths of a second, or 2/60ths spent holding, 2/60ths spend releasing. I've tried a few ideas below, but nothing seems to help make it fully consistent.
Quantizing
- Always sleep 1/60th second before sending (no quantizing)
- Wait to send packet at the next 1/60th second
Adding vs Measuring elapsed
- Adding: += whatever the elapsed time was from now to previous send
- Measuring: Start an epoch after pairing, and measure elapsed time, convert to ticks
The difference between these methods are subtle. If in a perfect world the controller sent packets 16.7ms, 16.7ms, 16.7ms, then the adding method goes 16, 32, 48. But the measuring method goes 16, 33, 50.
Setting tick rate
- 60 tps (ticks per second)
- In a perfect world where every packet is sent 1/60th per second, this would increment by one every packet
- 200 tps
- This was the tick rate I saw in this video https://youtu.be/x5czfcZaZYk
- 4000 tps
- This is the implemented tick rate in Brikwerk's NXBT
- 222.61 tps
- This is the approximate tick rate from logs in Yamakaky's joy
- 60 × 256 tps
- Just for fun
- In a perfect world where every packet is sent 1/60th per second apart, this would appear to increment by one, but if it is off slightly, it gives a totally different number
Given any combination of these, I get the same/similar results. I'm rapid firing 10 full buttons presses in a row on the Test Controller Buttons screen. I often get all 10 presses, sometimes 9 or 8, and rarely 7 or fewer.
Any thoughts?
