Wired split keyboard support

[matrixik]

I saw in few places users requesting wired connection between split halves of some keyboards using ZMK firmware (like Advantage360 Pro or Glove80) and developers said that it is not supported by ZMK for now so this is tracking issue for this request.

Personally I would also prefer wired connection when I'm using my stationary computer so that I don't need to think about charging or constantly using additional USB port (beside the one used for central role) when I have LEDs turned on all the time. And then using Bluetooth only on the go.

[BeatScherrer]

I'm currently using the nice nano wired without any issues on my sofle v2. zmk firmware on my repo but it's basically default generated. I don't even have batteries attached.

[caksoylar]

ZMK doesn't support wired communication between two halves. The data connection between the two sides go through Bluetooth, even if you are powering each side with wires. Maybe this is not clear in the FAQ item as well.

[ai212983]

Technically it is possible (and was done by Glove80 guys) to treat both halves as separate keyboards. Then one can have fully wired connection via USB splitter for example.

[cgoates]

This in progress PR is working toward wired communication between the two halves: https://github.com/zmkfirmware/zmk/pull/1117 It doesn't look like it's ready for testing at this point, but it is actively being developed.

[MrMarble]

What about charging the board through the jack cable? That way with only one cable you can charge and use both half at the same time.

I only have one type-c cable and when the keyboard runs out of battery I have to keep changing the cable to still be able to use it wile charging.

[caksoylar]

What about charging the board through the jack cable? That way with only one cable you can charge and use both half at the same time.

I only have one type-c cable and when the keyboard runs out of battery I have to keep changing the cable to still be able to use it wile charging.

This is not related to firmware but to the board you are using. As far as I know nice!nano doesn't support charging through TRRS while for instance Mikoto does.

[aureumleonis]

I'm really excited about this feature! Having one side die on me drives me crazy. As far as hardware goes, will it be possible to mix and match? E.g having a nice!nano on on the central side but a plain pro micro (and no battery) on the peripheral?

[Percentnineteen]

Pro micro doesn't speak zmk, so that won't work. I'm pretty sure you could get away with a port expander like the OG ergodox used to use right now (assuming you used a supported port expander)

[petejohanson]

Any mixed solution needs to be mindful to not force polling the peripheral side, otherwise battery life will suffer drastically, FYI.

So things like four wire TRRS with an i2c expander would work today, the battery life wouldn't be good.

[aureumleonis]

Interesting... do y'all have an intended hardware architecture for this use case? I'm planning a new build and want to make sure I have the correct pieces.

[petejohanson]

Interesting... do y'all have an intended hardware architecture for this use case? I'm planning a new build and want to make sure I have the correct pieces.

This will be more relevant for dual wired ZMK keyboards, e.g. running RPi pico/rp2040 on each half eventually.

[0x64746b]

I would love to run ZMK on any board using Pro Micros so that I

• can experiment with how the mod tap options differ from what QMK does
• later just switch out the Pro Micros with a pair of n!n to make the whole thing wireless (and maybe even switch back, when I borrow the n!ns for the next project ;))

[petejohanson]

I would love to run ZMK on any board using Pro Micros so that I

• can experiment with how the mod tap options differ from what QMK does
• later just switch out the Pro Micros with a pair of n!n to make the whole thing wireless (and maybe even switch back, when I borrow the n!ns for the next project ;))

Note: this is about wired split support for supported chipsets/architectures. ZMK will never support AVR/atmega based devices like the original pro-micro, because Zephyr doesn't support those 8-bit devices at all,not never will.

[Davides98]

there are some news?

[petejohanson]

there are some news?

There is an updated PR https://github.com/zmkfirmware/zmk/pull/1954 which is a new effort to make this move forward. That's hopefully going to move this forward.

[tcaxle]

I have just built a Sofle V1.1 using Nice!NanoV2s and it seems to work pretty seemlessley with split-wired. I have USB to the left shield and TRRS connecting left to right and keypresses from the right sheild are registered just fine on the connected computer.

My build is wired-only and does not have batteries. If you are looking to do a similar thing (want the functionality of ZMK but aren't bothered about the wireless bit) then I can confirm that it does work.

[petejohanson]

I have just built a Sofle V1.1 using Nice!NanoV2s and it seems to work pretty seemlessley with split-wired. I have USB to the left shield and TRRS connecting left to right and keypresses from the right sheild are registered just fine on the connected computer.

My build is wired-only and does not have batteries. If you are looking to do a similar thing (want the functionality of ZMK but aren't bothered about the wireless bit) then I can confirm that it does work.

That is not using wired data transport, you're just powering the other side over the TRRS cable, which may work, but is not advised, due to risk of damage to the controller if done incorrectly. Please just power both sides with USB after removing the TRRS while all USB is removed from the keyboard first.

[tcaxle]

I have just built a Sofle V1.1 using Nice!NanoV2s and it seems to work pretty seemlessley with split-wired. I have USB to the left shield and TRRS connecting left to right and keypresses from the right sheild are registered just fine on the connected computer. My build is wired-only and does not have batteries. If you are looking to do a similar thing (want the functionality of ZMK but aren't bothered about the wireless bit) then I can confirm that it does work.

That is not using wired data transport, you're just powering the other side over the TRRS cable, which may work, but is not advised, due to risk of damage to the controller if done incorrectly. Please just power both sides with USB after removing the TRRS while all USB is removed from the keyboard first.

Interesting. What exactly is the risk?

[Percentnineteen]

First, plugging or unplugging the cable under power causes a momentary short from power to ground. The charging IC is not very tolerant of that condition and frequently fries as a result.

Also, because the power path is undocumented there is no way to know if you are risking damage to any of the components in that path.

On Wed, Oct 18, 2023, 4:32 PM XLE @.***> wrote:

I have just built a Sofle V1.1 using Nice!NanoV2s and it seems to work pretty seemlessley with split-wired. I have USB to the left shield and TRRS connecting left to right and keypresses from the right sheild are registered just fine on the connected computer. My build is wired-only and does not have batteries. If you are looking to do a similar thing (want the functionality of ZMK but aren't bothered about the wireless bit) then I can confirm that it does work.

That is not using wired data transport, you're just powering the other side over the TRRS cable, which may work, but is not advised, due to risk of damage to the controller if done incorrectly. Please just power both sides with USB after removing the TRRS while all USB is removed from the keyboard first.

Interesting. What exactly is the risk?

— Reply to this email directly, view it on GitHub https://github.com/zmkfirmware/zmk/issues/1110#issuecomment-1769354710, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4HWRH4TSJMJSGGISFO5MTYABDIDAVCNFSM5NGBXWSKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZWHEZTKNBXGEYA . You are receiving this because you commented.Message ID: @.***>

[tcaxle]

Reasonable concerns, thank you for explaining.

[tcaxle]

First, plugging or unplugging the cable under power causes a momentary short from power to ground.

How will these hardware issues be addressed when wired data transport is implemented? Surely the risk of the momentary short stays the same regardless of whether the TRRS cable is being used for power delivery or data transfer?

Also, because the power path is undocumented there is no way to know if you are risking damage to any of the components in that path.

What do you mean by undocumented? For n!n-v2s at least, the full schematic is online: https://nicekeyboards.com/docs/nice-nano/pinout-schematic

[Percentnineteen]

Wired does not necessarily mean TRRS. Wired transport will (hopefully) include a massive disclaimer about this issue when it is officially supported. TRRS should never have been used in this manner, because it ALWAYS shorts adjacent pins on insertion or removal but the previous designs were tolerant and less likely to fail.

Second, yes the top level design is documented but the actual electrical path through them is not something documented in the documentation for those components from their manufacturer. Think of them as being off-label use for pharmaceutical drugs. Do they do something potentially useful? Yeah. Have they been studied for harmful side effects? No.

On Thu, Oct 19, 2023, 3:19 AM XLE @.***> wrote:

First, plugging or unplugging the cable under power causes a momentary short from power to ground.

How will these hardware issues be addressed when wired data transport is implemented? Surely the risk of the momentary short stays the same regardless of whether the TRRS cable is being used for power delivery or data transfer?

Also, because the power path is undocumented there is no way to know if you are risking damage to any of the components in that path.

What do you mean by undocumented? For n!n-v2s at least, the full schematic is online: https://nicekeyboards.com/docs/nice-nano/pinout-schematic

— Reply to this email directly, view it on GitHub https://github.com/zmkfirmware/zmk/issues/1110#issuecomment-1770298622, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4HWRHVEEHMV4NAWYSKZWLYADO7JAVCNFSM5NGBXWSKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZXGAZDSOBWGIZA . You are receiving this because you commented.Message ID: @.***>

[tcaxle]

Wired does not necessarily mean TRRS. Wired transport will (hopefully) include a massive disclaimer about this issue when it is officially supported. TRRS should never have been used in this manner, because it ALWAYS shorts adjacent pins on insertion or removal but the previous designs were tolerant and less likely to fail.

Thank you for clarifying.

Second, yes the top level design is documented but the actual electrical path through them is not something documented in the documentation for those components from their manufacturer. Think of them as being off-label use for pharmaceutical drugs. Do they do something potentially useful? Yeah. Have they been studied for harmful side effects? No.

What do you mean by this? The datasheets for all the parts are readily available online, and the voltage regulator and battery charging IC both have internal block diagrams. Or do you mean that the parts fitted on the controllers won't necessarily be on-brand, i.e. they are using grey-market imitation parts in production?

Putting aside the short-circuit risk (which I agree with you about) the major issue with powering the peripheral controller via the TRRS connection seems to be that it will be running at 3.3V instead of 5V, but this seems to be within spec from a (brief) look at the datasheet for the MCU. Assuming they are on-brand parts, the voltage reg and the charging IC both have internal diodes that allow back-flow of current and all the necessary protection circuitry to deal with being used in reverse.

My proffessional opinion is that, as long as you take precautions not to (un)plug the TRRS jacks while the keyb is powered up, there is little risk of damaging anything. However, I would be hesitant to connect batteries to the peripheral controller without further investigation and I would avoid connecting anything to the USB port of the peripheral as it will not have the expected 5V supply.

The application is hacky and definitely not an intended use-case, but I would happily bet the cost of a Nice!Nano V2 that it works just fine.

From the schematics for the nice!nano V2, and the Sofle V1 (my application) and information from the relevant datasheets, you can summarise the power path as in the attached diagram. The salient point is that the central MCU is powered from the 5V supply taken before the voltage reg, but the peripheral one is powered from the 3.3V supply taken from after the central voltage reg (and back-flowing through the peripheral voltage reg)

[Percentnineteen]

The chips are not off-brand, they are just being used in a manner that is not described in the datasheets. As you say, the issue is that the peripheral is being powered backwards through the charging chip and that backwards path is not described anywhere in the datasheet for the part. Things like current limits, voltage drops, etc are not known quantities in this mode of operation.

I agree with you that it is almost certainly fine (for at least some cases). In addition to the concerns you raised about plugging the peripheral in to USB or hooking up a battery, things like current draw (via LEDs, OLEDs, etc) may steer into more uncertain territory.

However, given the fact that so many people seem to fry the charging ICs and the fact that it is relatively benign advise to just plug the peripheral controller in via USB C, I do not believe this practice will ever become anything more than discouraged.

From my perspective (assuming no batteries), doing the wrong thing requires one extra wire (TRRS) while doing the right thing requires one extra wire (USB C). But doing the right thing carries fewer caveats and restrictions.

On Thu, Oct 19, 2023, 6:02 AM XLE @.***> wrote:

Wired does not necessarily mean TRRS. Wired transport will (hopefully) include a massive disclaimer about this issue when it is officially supported. TRRS should never have been used in this manner, because it ALWAYS shorts adjacent pins on insertion or removal but the previous designs were tolerant and less likely to fail.

Thank you for clarifying.

Second, yes the top level design is documented but the actual electrical path through them is not something documented in the documentation for those components from their manufacturer. Think of them as being off-label use for pharmaceutical drugs. Do they do something potentially useful? Yeah. Have they been studied for harmful side effects? No.

What do you mean by this? The datasheets for all the parts are readily available online, and the voltage regulator and battery charging IC both have internal block diagrams. Or do you mean that the parts fitted on the controllers won't necessarily be on-brand, i.e. they are using grey-market imitation parts in production?

Putting aside the short-circuit risk (which I agree with you about) the major issue with powering the peripheral controller via the TRRS connection seems to be that it will be running at 3.3V instead of 5V, but this seems to be within spec from a (brief) look at the datasheet for the MCU. Assuming they are on-brand parts, the voltage reg and the charging IC both have internal diodes that allow back-flow of current and all the necessary protection circuitry to deal with being used in reverse.

My proffessional opinion is that, as long as you take precautions not to (un)plug the TRRS jacks while the keyb is powered up, there is little risk of damaging anything. However, I would be hesitant to connect batteries to the peripheral controller without further investigation and I would avoid connecting anything to the USB port of the peripheral as it will not have the expected 5V supply.

The application is hacky and definitely not an intended use-case, but I would happily bet the cost of a Nice!Nano V2 that it works just fine.

From the schematics for the nice!nano V2, and the Sofle V1 (my application) and information from the relevant datasheets, you can summarise the power path as in the attached diagram. The salient point is that the central MCU is powered from the 5V supply taken before the voltage reg, but the peripheral one is powered from the 3.3V supply taken from after the central voltage reg (and back-flowing through the peripheral voltage reg)

[image: Untitled Diagram] https://user-images.githubusercontent.com/38703509/276587324-96526ab0-0f02-4da8-8da2-8474d5c60fbc.png

— Reply to this email directly, view it on GitHub https://github.com/zmkfirmware/zmk/issues/1110#issuecomment-1770578774, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4HWRC2LZUPSSWPQWASUV3YAECDDAVCNFSM5NGBXWSKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZXGA2TOOBXG42A . You are receiving this because you commented.Message ID: @.***>

[tcaxle]

The chips are not off-brand, they are just being used in a manner that is not described in the datasheets. As you say, the issue is that the peripheral is being powered backwards through the charging chip and that backwards path is not described anywhere in the datasheet for the part. Things like current limits, voltage drops, etc are not known quantities in this mode of operation.

I agree with you that it is almost certainly fine (for at least some cases). In addition to the concerns you raised about plugging the peripheral in to USB or hooking up a battery, things like current draw (via LEDs, OLEDs, etc) may steer into more uncertain territory.

True - my next port of call is to take some measurements of my keyboard running in this setup so see exactly what voltages are where and to check the stability of the rails when the keyboard is in use. Still waiting on my switches to arrive though so this will probably wait a week or so.

However, given the fact that so many people seem to fry the charging ICs and the fact that it is relatively benign advise to just plug the peripheral controller in via USB C, I do not believe this practice will ever become anything more than discouraged.

I agree: it's not something I would advise someone to do without a suitable disclaimer, and if you are going to offer any advice then advice that will definitely not cause issues is preferable to advice that only hopefully won't cause issues...

From my perspective (assuming no batteries), doing the wrong thing requires one extra wire (TRRS) while doing the right thing requires one extra wire (USB C). But doing the right thing carries fewer caveats and restrictions.

This is true, but the latter also requires an additional USB port, which I don't have spare. Someone above mentioned using a USB splitter, and that is probably the best compromise in this case, provided I can find one that has power and data on one fork and just power on the other.

Thanks for taking the time to talk this through.

[Fethbita]

One comment from me about implementing this, our corporate policy states that we can not use Bluetooth keyboards. I would like to use split keyboards at work that have ZMK firmware, but as it currently stands, I can not.

[sontags]

Just to make them visible, there are two (more) PRs likely related to this issue: #2080 and #2086.

Wired split was also teased in October 2023 (https://zmk.dev/blog/2023/10/05/zmk-sotf-6#coming-soon) by @caksoylar, I hope this is making some progress soon...

[Nick-Munnich]

Just to make them visible, there are two (more) PRs likely related to this issue: #2080 and #2086.

Wired split was also teased in October 2023 (https://zmk.dev/blog/2023/10/05/zmk-sotf-6#coming-soon) by @caksoylar, I hope this is making some progress soon...

There is also #1954. That said, #2086 currently seems like the most promising PR to me at least. All of the reports of people testing said branch have been great, and the issues with the branch seem more to be needing additional features than functional issues.

[NightWatchman]

I've got a lilly58 I built with two NRF52840 controllers in a wired configuration with no batteries.

Not sure if anybody else has had this experience of having a working wired configuration, but I've been able to use both halves by plugging my USB-C into the left half, and using a TRRS cable to the right half, as long as I have #include <dt-bindings/zmk/ext_power.h> in the keymap. Both halves worked fine for months with no issues.

Yesterday though, the right-half suddenly just stopped working unless I plug a USB cable into it for power. I haven't been able to figure out why yet. My controllers are from aliexpress, and probably knock-offs so it's entirely possible that one of them just crapped out.

[sontags]

@petejohanson just me being curios, not wanting to put pressure on this; there is a PR #2086 open for quite a while now and I wonder if you will be able to review the thing some time soon? As far as I can tell people seem do be happy with the implementation, and it appears to be a nice addition to the project... Thanks.

[ulfbert-san]

I've got a lilly58 I built with two NRF52840 controllers in a wired configuration with no batteries.

Not sure if anybody else has had this experience of having a working wired configuration, but I've been able to use both halves by plugging my USB-C into the left half, and using a TRRS cable to the right half, as long as I have #include <dt-bindings/zmk/ext_power.h> in the keymap. Both halves worked fine for months with no issues.

Yesterday though, the right-half suddenly just stopped working unless I plug a USB cable into it for power. I haven't been able to figure out why yet. My controllers are from aliexpress, and probably knock-offs so it's entirely possible that one of them just crapped out.

Did u find the solution? I've have the same problem. My right side isnt working.

[NightWatchman]

The best suggestion I have at the moment is to ensure that you are including the ext_power.h headers when building your firmware. If you are using https://github.com/nickcoutsos/keymap-editor, then you must ensure one of your keys is set to one of the external power operations like EP_TOG or the header will be automatically dropped. You also must have a TRRS cable or some other means of power delivery from the plugged in half to the other half.

I'm waiting for replacement controllers to arrive. In my case it suddenly stopped working with no config changes, so my best guess is some sort of hardware issue.

[Nick-Munnich]

For the legit nice nanos at least, the VCC pin has undefined behavior when used as a power input path. It stands to reason that it will degrade significantly quicker when used in that manner. I can easily imagine the same being the case for the knockoffs.

[NightWatchman]

That's a good point. I hadn't thought about that once my keyboard was up and running.

[Percentnineteen]

You are using the nice!nanos in an unsupported and undefined manner, so it is likely that they just gave up the ghost. You are effectively powering them by shoving power into a port that is intended to be output only.

On Sat, Oct 5, 2024, 3:26 PM Eric Rushing @.***> wrote:

That's a good point. I hadn't thought about that once my keyboard was up and running.

— Reply to this email directly, view it on GitHub https://github.com/zmkfirmware/zmk/issues/1110#issuecomment-2395182417, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4HWRHPC3XD5OMDSA72ZPDZ2BDPZAVCNFSM5NGBXWSKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMZZGUYTQMRUGE3Q . You are receiving this because you commented.Message ID: @.***>