Open fabianmuehlberger opened 5 months ago
I hope you understand the severity of this issue. Depending on the USB standard, routing of D+/D- is Critical for a functioning device. Read this guide: https://resources.altium.com/p/routing-requirements-usb-20-2-layer-pcb. A very comprehensive guide can be found here https://www.ti.com/lit/an/spraar7j/spraar7j.pdf?ts=1712482750918&ref_url=https%253A%252F%252Fwww.google.com%252F
I measured the trace length of D- is approximately 100mm or ~ 4 inches.
If you use USB fullspeed spec, the critical length 10% limit is exceeded, but it is within the 25% length limit, this might work but is not ideal.
For USB high-speed spec, you are exceeding the 10% length limit by a factor of 10. This means, if you use USB high speed, the board is out of spec and probably not working correctly!
Best
Not sure if this is related but I notice that if I leave mine idle on occasion I will have to unplug to get keystrokes sent, but all on board functions work properly. Or maybe this is a qmk issue and I need to fix some setting.
Edit might be the USB_SUSPEND_WAKEUP_DELAY. I will report back when I flash the firmware later.
Later: that has resolved the wake up problem, I'll submit a PR to update the firmware in your repo.
On another note now I randomly see 1 or 2 LEDs shutoff.
I'll add this here since that wake change I haven't had an issue with a direct usb connection to the laptop. However through my level 1 KVM I still experience this issue, but appears to be only on my work mac and not my Linux pc.
I will keep debugging but leaving this here since it could be related to the usb spec constraint pointed out.
Thank you for sharing. I keep to investigation too.
Hi, I took a second look at your PCB, and I highly recommend revisiting the USB routing. USB D+ and D- should always be the highest priority with the following criteria:
Not following these standards could lead to unreliable or faulty behavior of the keyboard.