Designing a custom Topre board

[attheicearcade]

Apologies for the absence, had to focus on finals. More updates soon, working on making sensing more robust.

Gosh, that looks good. BTW, have you considered DSA profile keycaps? They might be really nice on a curved board.

I have, probably something I will try eventually but I've never had DSA keycaps.

It is about 17.5 mm on Kinesis. My Katy keyboard has it about the same.
The distance is not the same for each pair but this seems to be the average.
I would not bother with it if you can fit common keycaps there (Oem DCS, SP DCS, SP DSA).

Indeed it seems to be okay from the single column I have, I'll probably leave it!

I joined DT just to say I support this project and I am looking forward to hacking my own with a little guidance. Let me know if you need any help

Thanks, post your findings!

wow, wow, wow. Great work. Keep it up please!

Thanks!

@attheicearcade are you still working on this project? If not, would you be willing to share the files? I love the design of the case.

Still going, been busy with finals until now. The design will be shared when I know it works somewhat

[cookie]

That is some next level shit here.... wow

[attheicearcade]

I've been working on a rudimentary firmware and have got good results, I'm thankful that the teensy keyboard and mouse libraries hide the pain of the USB spec away from me. Got keypresses working (no jittering so far) and analog mousekeys (which is really cool, I could see myself using it). There is some problem of improper grounding, not sure what is causing it but signals are much cleaner when I am touching the shielding. It doesn't seem to be too much of an issue yet but hopefully I can fix it.



You can see common mode noise and key state. Values are normalised between 0 and 1 by the calibration routine. This data was me tapping the keys as fast as I could. When touching the shield the noise reduces to around 0.03.

I have also ordered a slightly revised batch of mini PCBs to help with the wiring. Hopefully will be able to build the full keyboard soon. Until then, more firmware... which I have put on GitHub:

https://github.com/tomsmalley/strobe

It is a mess and I have never written C or C++ before so please forgive me. None of the USB stuff is in that commit. Supports 128 keys (16 columns x 8 rows).
The plan is to store settings and keymaps etc in the 2kb EEPROM. We will see how that goes, maybe it isn't feasible. I like the idea of not having to compile a keyboard firmware before using it, instead just using teensy loader and configuring over serial.

I also need to design the small PCB for the other hardware parts that sit under the thumb cluster. Not quite yet though..

[ramnes]

The code looks pretty clean for someone that never wrote any C/++ before!

[scottc]

Yeah, experience in C/C++ is often correlated with writing terrible and unmaintainable code...

[hbar]

Wow, you've done some great work here, congratulations! I haven't made any progress in the last few months, I keep getting horrible 50Hz noise, which is probably the penalty for my sloppy makeshift setup.

What happens when you press multiple keys at a time? Can you tell whether the actuaction point of a key depends on whether others nearby are pressed or not? Maybe you could test this while you're at it?

BTW, knowing C or C++ (or C# or Java, for that matter) equates to a negative programming skill level. (It's a proven fact that those who haven't seen any of these languages are much quicker to learn modern languages such as Haskell.)

[attheicearcade]

The 4 keys I have are all on the same row (and hence all effect each other as you describe) but the voltage drop is minimal even with all 3 other keys pressed. This is just controlled by the large row ground capacitor (as posted on the previous page) because the charge is shared among each capacitor on the row

Just figured out that all USB hid commands (page 53) fit neatly into a byte with enough room to spare to store function references (for switching layers and analog mousekeys at least). The EEPROM key map storage should be possible!

[tombodet]

Made an account just to say oh hell yes.

I got to the Dec update on pg1 and my jaw dropped open.

Best of luck to you!

[attheicearcade]

Thanks!

Managed to reduce the noise significantly and the circuit no longer needs shielding to work reliably. Firmware is (was) coming along, with an automatic key matrix detection and calibration routine. Postponing somewhat since I want more keys (and another half of a keyboard) to write the rest.

I'm wondering if there would be any interest in the 'case' that I have designed (it isn't finalised yet). This is in regards to finding a suitable manufacturing method. It's a balance between work and cost, I will be talking to some local places on Monday. The case should be compatible with both MX and Topre since they share a similar cutout size, the Topre also requires additional screw holes.

It seems to be coming along though!

[neverused]

Beautiful!

Sent from my Nexus 6P using Tapatalk

[damko]

I'm wondering if there would be any interest in the 'case' that I have designed (it isn't finalised yet). This is in regards to finding a suitable manufacturing method.

absolutely! it's a great design! I'm looking forward to see more about it. I'm wondering if it's going to be easier to bend and pierce a strip of metal, as in your design, or to carve it from one piece of aluminum. (sorry if I'm using wrong technical terms but it's hard for me to translate some). Piercing and bending a strip of metal should be easier accordingly to my experience and lighter in the end.

Please keep up the great job!

[damko]

Managed to reduce the noise significantly and the circuit no longer needs shielding to work reliably. Firmware is (was) coming along, with an automatic key matrix detection and calibration routine. Postponing somewhat since I want more keys (and another half of a keyboard) to write the rest.

Newbie question: why don't you use Ergodox firmware? It seems to me that there is a lot already done there.

[attheicearcade]

absolutely! it's a great design! I'm looking forward to see more about it. I'm wondering if it's going to be easier to bend and pierce a strip of metal, as in your design, or to carve it from one piece of aluminum. (sorry if I'm using wrong technical terms but it's hard for me to translate some). Piercing and bending a strip of metal should be easier accordingly to my experience and lighter in the end.

Please keep up the great job!

I think you mean milled, but no, it is laser cut 316 stainless which is bent afterwards. The press operator was having trouble with the workpiece slipping though, so I'm going to some local companies to see if they have more suitable (smaller) equipment.

Newbie question: why don't you use Ergodox firmware? It seems to me that there is a lot already done there.

The key sensing process is very different - the controller measures and records key depth in order to decide what to send to the computer, unlike an MX keyboard. Also, each side will have a teensy in it which is unlike the traditional ergodox. I am sure that some code is usable, certainly TMK, but I am enjoying writing it so far.

[pont0s]

Wow, that's great.

I'm wondering if there would be any interest in the 'case' that I have designed (it isn't finalised yet). This is in regards to finding a suitable manufacturing method. It's a balance between work and cost, I will be talking to some local places on Monday. The case should be compatible with both MX and Topre since they share a similar cutout size, the Topre also requires additional screw holes.

Absolutely.

[attheicearcade]

Some more renders with slightly refined design, still need to put some thought into the base and feet (tenting)

[v6ak]

Few notes/questions:

* Have you considered arrow keys? Since it looks like modeled after Ergodox, which often has arrow keys under “M”, “<”, “>” and “?”, this would be my concern when switching from Ergodox. Is there any strong reason for not adding one extra key in the very bottom row? (Maybe there is and I am not getting it.)
* Just curious: How much experience with ErgoDox do you have?
* TMK firmware would be a good step if you want many features for free. (E.g., mouse keys, trackpoint support, macros, various layering options etc.) In general, I feel OK not to bother with it in early stages (as some of those features are outside of MVP), but I suggest trying that as soon as you want to implement some of those features.
* I am interested by this project, despite having some issues in my eyes. First, the keyboard can't be as portable as Ergodox (but it might be still more portable than Maltron), but this is the price for good shape. The price is likely to be rather high. The third one is rather a matter of choice: I prefer tactile switches to linear. Anyway, I am looking forward next iterations. Maybe I will buy/assembly a MX version one day.

[attheicearcade]

* Have you considered arrow keys? Since it looks like modeled after Ergodox, which often has arrow keys under “M”, “<”, “>” and “?”, this would be my concern when switching from Ergodox. Is there any strong reason for not adding one extra key in the very bottom row? (Maybe there is and I am not getting it.)

Just on a whim while making the assembly. I want to have the number of keys per column (in left 5 columns) configurable, so if you want that extra key you'd be able to have it.

* Just curious: How much experience with ErgoDox do you have?

I have never owned one.

* TMK firmware would be a good step if you want many features for free. (E.g., mouse keys, trackpoint support, macros, various layering options etc.) In general, I feel OK not to bother with it in early stages (as some of those features are outside of MVP), but I suggest trying that as soon as you want to implement some of those features.

Mouse keys support is different for this since we have analog input. I want to keep configuration in EEPROM, so I doubt I'll move to TMK, but we will see.

* I am interested by this project, despite having some issues in my eyes. First, the keyboard can't be as portable as Ergodox (but it might be still more portable than Maltron), but this is the price for good shape. The price is likely to be rather high. The third one is rather a matter of choice: I prefer tactile switches to linear. Anyway, I am looking forward next iterations. Maybe I will buy/assembly a MX version one day.

True, this keyboard wasn't designed for portability. Especially with it's barebones nature (exposed wires could get snagged). It will most likely be expensive, largely thanks to the Topre part, but it should be MX mount compatible (I don't have any switches to test).

[v6ak]

Just on a whim while making the assembly. I want to have the number of keys per column (in left 5 columns) configurable, so if you want that extra key you'd be able to have it.

That sounds very flexible.

Mouse keys support is different for this since we have analog input. I want to keep configuration in EEPROM, so I doubt I'll move to TMK, but we will see.

Maybe mouse keys are something different than you think. Mouse keys are physically ordinary keys, but they are mapped to a mouse button, mouse movement, mouse movement acceleration or mouse wheel. It might sound crazy, but it is surprisingly useful. (Unless you use wrong layout, which forces some RSI-friendly habit like using the very bottom row too often…)

[attheicearcade]

Maybe mouse keys are something different than you think. Mouse keys are physically ordinary keys, but they are mapped to a mouse button, mouse movement, mouse movement acceleration or mouse wheel. It might sound crazy, but it is surprisingly useful. (Unless you use wrong layout, which forces some RSI-friendly habit like using the very bottom row too often…)

Yes that's what I mean - we have actual key depth available to use as a resource - so for example the deeper a key is pressed, the faster the mouse moves in a certain direction. As opposed to being finite steps with each key press (unless I am missing something crucial? I have only used mouse keys for a few minutes, maybe this is desirable). Of course button pressing works the same though.

[v6ak]

Aha. So, you aren't saying it can't be implemented, you are saying that you want to take advantage of finer input. That makes sense. I have no idea if TMK supports this. Quick Googling of „TMK topre“ suggests it somehow supports capatitive sensing, though.

[damko]

I think you mean milled, but no, it is laser cut 316 stainless which is bent afterwards. The press operator was having trouble with the workpiece slipping though, so I'm going to some local companies to see if they have more suitable (smaller) equipment.

Maybe a sheet of copper or lead between the press and the metal can do the trick?

The key sensing process is very different - the controller measures and records key depth in order to decide what to send to the computer, unlike an MX keyboard.

Does this mean that you can decide at which point of the key run the signal is actually sent to the pc?

Also, each side will have a teensy in it which is unlike the traditional ergodox. I am sure that some code is usable, certainly TMK, but I am enjoying writing it so far.

Wow, this is so cool!

[damko]

(I don't have any switches to test).

there is a massdrop open https://www.massdrop.com/buy/gateron-sw ... guest_open

[attheicearcade]

Maybe a sheet of copper or lead between the press and the metal can do the trick?

It would critically affect the bend radius. But I have visited another place who think they can do it with no problem.

Does this mean that you can decide at which point of the key run the signal is actually sent to the pc?

Yes, the actuation point is adjustable.

[hbar]

Thanks attheicearcade for the boards, you can see first results here: workshop-f7/hbar-beta-aka-hbar-s-first- ... ml#p316182

[hbar]

I'm wondering what signal level you get out of your row lines with that large capacitor. If you want to detect 2pF with a "buffer" capacitor of 220pF, you'd get about 1/100 of the excitation pulse (make that 3V), which amounts to about 30mV. Not too bad, but then again the keys have a much lower capacitance at the actuation point, I guess it's more like 0.2pF, which reduces the pulse height further to about 3mV. The ADC graphs you posted appear to show a very strong signal. Can you enlighten us about what absolute pulse heights you see?

ħ

[attheicearcade]

I think you are in the right ballpark there, I am away from my test bench for a week or so, so I can't provide scope pictures. I have raised the buffer capacitor to 1uF now, since dropping the resistor value by a factor of 5. But also the capacitance varies linearly with key depression, it's a key part of the topre patent.

[nothing4me]

Any updates?

[RichardinFinland]

Anyone know what component is C15 on a topre novatouch board? I assume it's a capacitor?

[hbar]

Anyone know what component is C15 on a topre novatouch board? I assume it's a capacitor?

You're lucky that I just butchered my Novatouch a couple of hours ago, so I can actually have a look. Yes, C15 looks very much like a capacitor, 0402 size.

ħ

[RichardinFinland]

What can I replace it with?