Ergodox latency

[musclecups]

I'm curious if any ergodox users have experienced latency issues as a result of the IO expander used in the lefthand of the classic ergodox. 

That is to say: do lefthand keystrokes register noticeably later than righthand keystrokes?

As a followup to anyone who owns both a standard and an InputClub "infinity" ergodox, is there any difference in this latency?

Thanks!

[iaeen]

I have never used the original ErgoDox, but the infinity has no noticeable latency.

HaaTa addressed the issue on the Massdrop comment board (here: https://www.massdrop.com/buy/infinity-ergodox/talk/352332, also see tyr.goossens' post immediately above). The description is pretty technical, but the takeaway is that the poll rate for the interconnect is several orders of magnitude faster than the USB poll rate. With the infinity, the keypress is virtually guaranteed to travel over the interconnect and reach the USB comm buffer before the next USB cycle.

[Findecanor]

The Infinity has different electronics. There are microcontrollers on both sides, not an I/O expander on one and a microcontroller only on the other side.

Anyway. I have gone through the source code for the official firmware for the original ErgoDox, and it does not poll the left side less often than the right side.

[musclecups]

does not poll the left side less often than the right side

Someone intimated to me that using the MCP23018 I/O expander with i2c protocol between the boards would lead to measurable latency differences between the left and right sides of the board.  So it's not the polling I'm asking about, but whether or not the data is there yet to be polled?

I'm unfamiliar with the topic, but the data sheet for the chip says that it operates at either 100kHz or 400kHz.  In the Massdrop discussion referenced above, it is mentioned that USB 2.0 operates at 1000Hz.  So, the i2c transmission and reception should add negligible delay to the computer's receipt of the keypress, especially when compared to the debounce processing?

My question boils down to this:

TLDR - Does using an I/O expander to communicate left-hand keystrokes add measurable (or maybe significant) latency to reception of the keypress, or should I simply route the matrix to the right side wholesale?

[vvp]

There was a post about in on deskthority (or maybe here on geekhack???). IIRC, the I2C handling was taking about 120 µs. If so, then it is not a big deal since poll rate on full speed USB (12 mb/s) is 1 ms or more. It may represent a  considerable part (about 12%) of processing but it should not result in higher latency.

That is if I remember it correctly. Search ergodox thread on deskthority (or maybe even on geekhack) to know for sure.

If you care about latency then optimizing debouncing is more important. Debouncing is typically around 5 ms. You can bias debouncing to the released state or to the pressed state. If you bias it to the pressed state then press will be detected with about 1 ms delay and release with about 6 ms delay. If you bias to the released state then press will be detected with about 6 ms delay and release with about 1 ms delay. Choose your poison!

[xephon]

As firmware engineer that uses UART and I2C bus all the time, I can't imagine either bus give any sort of meaningful latency to be honest. Nevertheless, their behavior on NKRO may be vary. In particular, it is quite possible for UART to perform way better providing NKRO than I2C due to the nature of the bus design.

[musclecups]

Thanks, that's exactly the experienced response I was seeking!

I think I read somewhere that Hasu's TMK firmware has NKRO (or 128 at least).  I don't think I'll need more than 6 for what I plan to use it for, anyhow.

[obfuscated]

If you look here: https://github.com/benblazak/ergodox-firmware you'll see that the ergodox is at ~167 Hz scan rate.
And if you look here: https://github.com/benblazak/ergodox-firmware/blob/master/references.md you'll see that the cherry mx switches have 5ms debouce time, which limits them to 200hz. I doubt there is a problem with latency in there.

@xephon: Do you use some async code to talk to the i2c bus, because the code in the ergodox is synchronous and thus there is major slowdown? I'm not testing ergodox directly, but a similar design using arduino micro and mcp23018.

[HaaTa]

So, the latency isn't a huge deal, though it can give an edge.

The big reason why the original ergodox has a bit of delay: Poll+debounce.

1) Poll, you need to query, then receive the data. The original ergodox is not asynchronous.
2) Debounce, you must poll multiple times in order to determine if the key was press/released

Just removing (2), would make it significantly better (sadly I don't have an original ergodox around to scope the latency).

For the Infinity Ergodox I was deciding between UART, I2C and CAN. And ended up going with UART:

• Not difficult to implement
• Totally asynchronous (without multi-master)
• Available on pretty much every MCU

By sheer luck I managed to get the UART running stupid fast without errors, so that was just a fun extra.

Advantages the Infinity Ergodox has that makes it faster:

• Asynchronous
• Debounce before transmission
• DMA UART receive buffers

[Data]

Purely anecdotal and subjective:

I game on my Dox (Falbatech PCB) and have never experienced latency on keystrokes.  If there's a delay it's insignificant.  I haven't hooked it up to a scope or anything, but then I've never really had a reason to.   

[xtrafrood]

Phew, during my Ergodox research I came across mentions of latency. I won't worry about it anymore

[obfuscated]

For the Infinity Ergodox I was deciding between UART, I2C and CAN. And ended up going with UART:

• Not difficult to implement
• Totally asynchronous (without multi-master)
• Available on pretty much every MCU

Do you have a schematic somewhere?

[HaaTa]

All our schematics and gerbers are here -> https://github.com/kiibohd/pcb

[Questengine]

I've not noticed any, but I'm not a super-fast typer, so I'm probably not an authority on the matter.