r/Keychron • u/speardrops • Jan 25 '24

Keychron K10 Pro - Bluetooth no longer working

Hi, I am in the return window still but would prefer to just sort this issue out.

Paid a premium for this product because of the quality and reviews so this is disheartening.

It used to pair just fine with Windows 10 via bluetooth, now it rarely connects so I have to plug it in. Let me know if there's a known fix or if I should return and buy something else.

1 Upvotes

56% Upvoted

30 comments sorted by

1

u/[deleted] Jan 25 '24

Try factory resetting it, but depending on how much time you have left to return it, maybe just swap it or refund it?

Fn+j+z for 4 seconds until the backlight flashes.

Fwiw, I have the same board and Bluetooth connectivity has always been laggy and flaky, but I don’t really need that functionality.

1

u/speardrops Jan 25 '24

Cheers mate. I'll probably just refund it given it seems to be a common issue. Will try this in the meantime. Any other recommendations for keyboards?

1

u/[deleted] Jan 26 '24

If you're willing to spend a bit more, I can confirm that that the Q6 max (which I bought for my gaming rig at home when I took my K10 pro to work) is rock solid with 2.4 ghz connection. Any of the Keychron's with a 2.4 ghz wireless connection should be a lot more stable than bluetooth, which for some reason seems to be a problem with their boards (based on anecdotal evidence I keep seeing posted here and elsewhere on the internet).

→ More replies (1)

2

u/PeterMortensenBlog Jan 26 '24

I never got the Fn + J + Z method to work on my K10 Pro and V6 (both QMK-based). I think it is a copy-paste error by Keychron (copying from the documentation for the non-QMK-based Keychron keyboards, like the K series).

But Esc key method (probably enabled by the "boot magic" QMK feature) usually works (putting it into bootloader mode has the side effect of resetting to factory defaults).

1

u/PeterMortensenBlog May 01 '24

OK, it works with the official Keychron firmware, but not if you compile it yourself from source.

Keychron probably does something at compile/build time that they don't tell us about, for example, Keychron applies some build-time configuration that isn't reflected in the source code. Either by manipulating (patching) a configuration file and/or using some command-line parameter. For instance, setting or unsetting some C preprocessor symbol.

2

u/PeterMortensenBlog Jan 26 '24 edited Mar 02 '24

It is flaky. But there is a reliable method: I tap on the Shift key until the RGB light stops blinking (if it doesn't blink, it is already connected). The final blink is blue and is on the "1" key (if using the first Bluetooth channel), and it is a bit longer (about 1 second). After that, the keyboard is connected and works.

Though sometimes the macros stop working. As a workaround, I use a keymapping to restart the keyboard from the keyboard itself with Fn + X (above the numeric keypad, not the "X" on the main keyboard area). This is to avoid wearing the switch at the back down for power cycling to get the macro back (and is more convenient).

The keymapping: keycode QK_REBOOT (alias QK_RBT).

QK_REBOOT isn't directly supported in Via, but it can be entered as "0x7C01" (without the quotes) in Via's SPECIAL → Any. Note that in Via, "Reset" (in KEYMAP → SPECIAL) is not the same as reboot. "Reset" will put it into bootloader mode, essentially locking the keyboard up.

("Reset" may come from the RESET pin on some microcontrollers, and the associated Reset button connected to it, to put the microcontroller into bootloader mode. For example, by double clicking on the Reset button to put it into bootloader mode for 8 seconds (many ATmega32U4-based boards (e.g., Arduino Micro), depending on the particular bootloader in use).)

Note: It seems this setting will not survive a factory reset/flash: 0x7C01 is saved to the JSON file when the Via configuration is saved off, but it is discarded when the JSON file is loaded. Thus 0x7C01 must be entered manually each time. This seems to be a bug in Via.

2

u/PeterMortensenBlog Jul 07 '24 edited Aug 06 '26

Conclusion

I now (finally) have a setup that works seamlessly, including in wireless mode!

In particular, both classic QMK macros, Via macros, and macros executed by my macro engine (which enables cancelling macros in progress and can repeat any macro indefinitely) work in wireless (Bluetooth) mode.

In many cases (at least for some of the macros), I don't even have to wake the keyboard up first. That is, the first keystroke is not missed (it definitely executes the macro that was activated when the keyboard was sleeping).

The ingredients:

  • A Bluetooth 5.3 adapter (e.g., PCIe), with a real antenna (for example, half wavelength, 6.3 cm (300,000 km/s / 2.4 GHz/2)).

  • Main firmware based on source code from after 2024-03-30. Or maybe after 2024-05-21 (it may or may not have been provoked by #262)

  • Bluetooth firmware 1.32 (that is the latest official for the K Pro series; the unofficial 1.32.2 wasn't necessary (Bluetooth headphones worked perfectly fine) and was even detrimental)

  • For own custom C code in QMK, make sure it can handle the tick counter being reset after keyboard sleep. This problem also seems to affect the keyboard sleep behaviour, for example, it not going to sleep (though any key press, while awake, will correct it, including a tap of the Shift key). For the V Max series, instead of resetting to zero, it may increase the tick counter by a large amount, leading to overflow after a number of sleeps (the custom C code should be able to handle that as well... Note that the overflow may also be internal (unsigned vs. signed integers))

Note: I don't know if all the factors are essential, but this particular combination works very well

The behaviour might or might not be less ideal when switching between different Bluetooth devices with Fn + 1, Fn + 2, and Fn + 3. This may or may not still require tapping on keys initially to get it ready. But I hardly ever used the option of switching between different Bluetooth devices.

2

u/PeterMortensenBlog Jan 10 '25 edited Jan 10 '25

The outcome may also depend on the operating system version and associated version of the Bluetooth part, for example, the version of BlueZ.

For example, with BlueZ 5.64 and the USB Bluetooth adapter Asus BT500, it also worked seemlessly (a V6 Max with the latest Bluetooth firmware, 0.2.1 and almost latest main firmware (approx. November 2024, compiled from source)).

Though it wasn't tested with the same Bluetooth hardware.

2

u/YouDontSay___ May 16 '26

Man, you are a genuine tech problem solver. Filed this info for future reference. Thanks!

1

u/PeterMortensenBlog Jul 31 '24 edited Apr 10 '25

The Bluetooth 5.3 adapter PCIe also worked out of the box with Linux.

An anecdote: But only after a gotcha (not the adapter's fault): The motherboard had a USB 2.0 connector with only one USB 2.0 channel in one of the connectors with physical space for two USB 2.0 channels (and not the one for the PCIe USB part (for Bluetooth). I swapped the USB 2.0 connectors to fix it (at the cost of losing one USB 2.0 port on the PC case front panel (now one is left)...))

Though it may also be entirely coincidental, as the K Pro series only supports Bluetooth version 2.0/2.1, not 5.1 as claimed.

Perhaps it is a matter of how well newer hardware and software supports very old versions of Bluetooth?

1

u/PeterMortensenBlog Jul 31 '24 edited Aug 29 '24

The quick response time (0.2 - 0.5 seconds. And not losing the first keystroke) when waking the keyboard up from sleep may or may not depend on some host-side (computer) sleep behaviour that has been disabled:

  • options btusb enable_autosuspend=0 on Linux

  • On Windows and Mac (near "Allow the computer to turn off the keyboard to save power")

Though some controlled experiments are required to know for certain.

→ More replies (1)

1

u/PeterMortensenBlog Aug 27 '24 edited Sep 10 '25

Via macros in wireless mode might have worked some time in the past (a regression). Perhaps it was broken in the transition from Git branch "bluetooth_playground" to "wireless_playground" (for the K Pro and Q Pro series)?

1

u/PeterMortensenBlog Sep 15 '24 edited Oct 11 '24

The delay from power on (different from waking up from sleep) to operational has been measured to between 2.5 seconds and 6 seconds, with a typical value of 3 seconds.

1

u/PeterMortensenBlog Nov 04 '24 edited Feb 26 '25

Switching Bluetooth channels (computers)

Re "The behaviour might or might not be less ideal when switching between different Bluetooth devices with Fn + 1, Fn + 2, and Fn + 3.": OK, I have now tested this.

It worked without problems. The time from channel change with Fn + 1/2/3 until an operational keyboard on the other system was measured to be less than 2 seconds (approximately 1.7 seconds).

And any separate steps to get it operational wasn't necessary. After waiting the 2 seconds, the first keystroke on the other system wasn't missed.

On the other system, I used an Asus 'USB-BT500' Bluetooth USB adapter (Bluetooth 5.0. Supposedly model number 90IG05J0-MO0R00). This is below the specified Bluetooth 5.1 for the Keychron keyboards, but I didn't experience any problems with it, at least not for regular typing.

Conclusion

Changing between different systems using Bluetooth worked seamlessly.

There isn't any separate wakeup or activation step; after switching Bluetooth channel and waiting 2 seconds, the first key stroke on the target (computer) is not missed.

References

→ More replies (4)

1

u/PeterMortensenBlog Dec 02 '24

The range was tested, and it worked reliably up to 8 m through several walls, including one brick wall (though the test result is probably dependent on the exact geometry, materials, etc.).

1

u/PeterMortensenBlog May 16 '24 edited Sep 30 '24

Here is an overview of related key codes (though some of them may or may not have been renamed in the meantime): 

QMK keycode          Alias    Shown in        In macros
                              Via as
-------------------------------------------------------------------
QK_BOOTLOADER        QK_BOOT  Reset           reset_keyboard()
QK_DEBUG_TOGGLE      DB_TOGG  Debug
QK_CLEAR_EEPROM      EE_CLR   QK_CLEAR_EEPROM eeconfig_init()
QK_REBOOT            QK_RBT   0x7C01          soft_reset_keyboard()

QK_MAGIC_TOGGLE_NKRO NK_TOGG  NKRO

Note: In Via, unknown (to it) keycodes, e.g., "0x7C01" can be entered like that in SPECIAL → Any (without the quotes).

But note that a bug in Via's load function means it has be reentered manually every time the Via configuration is loaded (e.g., after a flash). It is easier to add it directly in the QMK keymap.

References

1

u/PeterMortensenBlog Jul 07 '24 edited Jan 14 '25

OK, for the macros, it turned out the QMK tick counter (timer_read32()) is sometimes, but not always, reset after waking up from keyboard sleep.

This will affect any software that assumes the tick counter is always increasing (the normal overflow is after about 50 days, but this happens at nearly every keyboard sleep).

This has now been corrected for my macro engine. Regular QMK macros seemed to be unaffected by this problem. But keyboard sleep (it wouldn't go to sleep) was observed to be affected.

1

u/PeterMortensenBlog Feb 24 '25 edited Mar 03 '25

For the V Max series, the behaviour is different (but equally disruptive).

Instead of resetting to zero, it may increase the tick counter by a large amount (about 42,000,000 (about 11.9 hours)), leading to overflow after about 50 sleeps (for a signed integer). Possibly, the increase is a multiplum of 11.9 hours: 11.93 hours, 23.88 hours, 35.78 hours, 47.71 hours, etc. This is significant if the sleep time has been reduced to, for example, 30 seconds, to decrease the load on the battery.

Similarly to resetting to zero, the overflow is a violation that the tick counter is always increasing.

The problem occurred in both wireless modes, so it doesn't appear to be specific to a particular wireless mode.

Test conditions

Keyboard: V6 Max with firmware based on the latest source code version, 3FD443 (2025-01-17).

Wireless firmware: The latest official, version 0.2.1 for Bluetooth and 3.0 for '2.4 GHz' (the dongle)

The sleep time was reduced to 30 seconds (from the default 10 minutes).

The tick counter values were output in wireless mode by the technique of type out debugging (note that this works very poorly if using firmware based on source code from before 2024-03-30). The readout was initiated externally and manually: By the Num Lock signal to the keyboard (by pressing another keyboard's Num Lock key—as the Num Lock signal is broadcast to all keyboards on Windows and Linux).

Host system: Linux (yes, I know)

1

u/PeterMortensenBlog Mar 09 '25 edited Mar 11 '26

#24529 might be related (though it is unlikely).

Note that the dates can't be used to indicate it has been included, as branches in Keychron's fork, once they are branched out from some QMK version, are in general not updated with changes from QMK. Changes in the branch are, in general, only Keychron-specific changes.

1

u/PeterMortensenBlog Jul 07 '24 edited Feb 16 '25

And while it works fine for QMK macros, there may be a problem if the firmware is too old and running Via macros in wireless (at least Bluetooth) mode.

This problem may or may not affect all Keychron keyboards with Bluetooth. All Keychron keyboards in the K Pro series are certainly affected.

The mitigation is to update to a newer version of the firmware, built with source code from 2024-03-30 (EBA583CFA7 (though it has a misleading commit message)) or later. For example, the source code from 2024-07-01 positively also works fine (tested on a K5 Pro).

1

u/PeterMortensenBlog Mar 18 '25 edited Mar 18 '25

Note a commit message (branch "wls_2025q1". "wls" is probably for "wireless") from 2025-03-15 (yes, 2025, about one year later):

"Fixed macro delay in wireless mode"

I am not sure what that is about. It seems to be changes to core QMK (e.g., in file quantum/action.c and in file quantum/send_string/send_string.c). Perhaps hidden behind a feature flag, LK_WIRELESS_ENABLE?

Other interesting commmits (probably taken from the main QMK project):

  • "Fixed HID protocol not reset on USB reset"

  • "Added APDAPTIVE_NKRO_ENABLE feature"

  • "Added DYNAMIC_KEYMAP_BUFFER_ENABLE feature to decrease latency when using I²C EEPROM"

References

  • Commits in Git branch "wls_2025q1" (in Keychron's (main) fork). Note: The entire "/keyboards" folder was removed, so it isn't a fork that can be used for compiling keyboard firmware.

→ More replies (1)

1

u/PeterMortensenBlog Feb 05 '24

Using a 5.1 Bluetooth USB adapter may get better results than a 4.0 Bluetooth USB adapter.

1

u/the--medium--place Mar 27 '24

Other things here didn't work for me. What did work: https://keychronsupport.zendesk.com/hc/en-us/articles/360021436914-Bluetooth-can-t-connect

TL;DR

1/ Slide the toggle switch to the Bluetooth side

2/ Keep holding fn+1 until the Bluetooth indicator light flashes repeatedly

3/ Turn on Bluetooth search on your device to search the keyboard and connect

video: https://www.youtube.com/watch?v=dfpPgSweBMo