Wired split keyboard support #1110
Comments
|
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. |
|
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. |
|
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. |
|
This in progress PR is working toward wired communication between the two halves: #1117 It doesn't look like it's ready for testing at this point, but it is actively being developed. |
|
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. |
|
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? |
|
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) |
|
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. |
|
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. |
|
I would love to run ZMK on any board using Pro Micros so that I
|
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. |
|
there are some news? |
There is an updated PR #1954 which is a new effort to make this move forward. That's hopefully going to move this forward. |
|
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? |
|
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
<#1110 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4HWRH4TSJMJSGGISFO5MTYABDIDAVCNFSM5NGBXWSKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZWHEZTKNBXGEYA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Reasonable concerns, thank you for explaining. |
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?
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 |
|
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
<#1110 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4HWRHVEEHMV4NAWYSKZWLYADO7JAVCNFSM5NGBXWSKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZXGAZDSOBWGIZA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Thank you for clarifying.
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)
|
|
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
<#1110 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4HWRC2LZUPSSWPQWASUV3YAECDDAVCNFSM5NGBXWSKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZXGA2TOOBXG42A>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
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.
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...
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. |
|
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. |
|
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. |
|
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 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. |
|
@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. |
Did u find the solution? I've have the same problem. My right side isnt working. |
|
The best suggestion I have at the moment is to ensure that you are including the 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. |
|
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. |
|
That's a good point. I hadn't thought about that once my keyboard was up and running. |
|
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
<#1110 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4HWRHPC3XD5OMDSA72ZPDZ2BDPZAVCNFSM5NGBXWSKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMZZGUYTQMRUGE3Q>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
@ai212983 do you happen to have a link or any reference about that? |
|
Under that scenario, it still requires synchronizing the modifier keys, because most people don't press right-shift for the right side's capital letters. If I recall, the Glove80 (Which is what I'm following this issue for) is simply doing this over Bluetooth, even when fully wired to the machine on both sides, something I'm looking to avoid such that bluetooth can be disabled entirely. |
|
For Windows and Linux, modifier state is global so they can be activated by any keyboard. I think macOS handles them per-keyboard, which would be an issue if the two halves are separate keyboard devices. |
|
I think there are people (such as myself) that do the "programmable keyboard" part at software level. This way, the only thing that we need from the keyboard halves is to send a unique scancode whenever a key is pressed. (For anyone interested, there are tools such as |
They have it in their FAQ, also see their quick test instructions and there's more in the User Guide about USB output mode. Please note, halves are still communicating with each other via Bluetooth. |
|
I was able to make a fully wired build of the Glove80. (Each half is an independent USB keyboard.) If anyone is interested in that in the future, here are the changes that I've made: vn971/zmk@upstream...vn971:zmk:main You then need a small keymap to work with. Like this one: https://github.com/vn971/zmk-config/blob/master/config/glove80.keymap If you want to try this build out, here's the firmware that you can flash on your Glove80 (it's tested to be working): https://github.com/vn971/zmk-config/actions/runs/12671985945/artifacts/2401620965 (the last downloadable artifact in https://github.com/vn971/zmk-config/actions/runs/12671985945) Note that most of the QMK/ZMK-like features stop working this way. This is because each half is now essentially a USB keyboard, independent of each other, just sending their unique scancodes and keypresses. To bring back all the layers, tap-dances and other smart functionality, you will need a software tool like P.S. Because the keyboard doesn't have any bluetooth or smart features this way, the firmware gets very small, too. It's |
|
Greetings to all. I'm new to ZMK, and I'm starting to learn about all this for a very specific project I have. I already bought one nice!nanoV2, a battery and a spiraled slinky USB type C cable. I've decided to take on the endeavor of soldering another USB C port to the nice!nano and connect both halves of the Raise using I2C to a single nice!nano and have the full keyboard connect to a PC via bluetooth. I want to abstract this system as a single board. A new fully wireless version of this keyboard is being sold by Dygma, but I still want to do this project instead of upgrading. I'm wondering if this idea still falls under the scope of this issue's concept of "wired split keyboard". Having both halves be connected by a single cable but still using bluetooth for the full keyboard sounds somewhat like a hybrid split keyboard (not fully wireless but still not physically connected to a PC). |
That's not exactly in scope for this, since we are focused on UART based wired split to start, but this certainly includes refactoring to make other split protocols easier to implement. |
|
Could an optional wired mode be implemented? So by default the parts would communicate wireless, but when it was detected that they were connected via wire, or manually triggered if monitoring for it was too resource intensive. That way you wouldn't have the hassle of the cord in between the two when you don't care about latency, but it is available if you do. |
I believe that is planned, with the help of an extra pin used to detect the wired connection. |
|
I don't know too much about hardware stuff, why would an extra pin be necessary? Can't the controllers just tell there is a voltage on the receive pin, while holding a constant voltage on the transmit? If you were to wire it up so they can charge batteries off each other it would be a bit annoying to go from 4 wires to 5. |
|
Would these be the UART interrupt pins or a different dedicated pin? |
and others
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.
The text was updated successfully, but these errors were encountered: