Infinity: A 60% Keyboard Designed by Haata now Available on Massdrop!

[njbair]

Interestingly I managed to avoid this issue even with clears, didn't even upgrade to the latest firmware yet as it's a lot of work to create a system to persist kll changes

So far I was mostly lucky with infinities, hope my luck persists, I also avoided the pcbs with the missing diodes

Going to share my 3rd infinity build soon, but here's the second one:

(Attachment Link)

Top row drilled to convert it to an 2u - before this I was in agony with a 1u Del

Did you give the HHKB layout a shot, with Backspace directly above Enter in the Backslash position? I found that works pretty well once you get used to it.

[KHAANNN]

Did you give the HHKB layout a shot, with Backspace directly above Enter in the Backslash position? I found that works pretty well once you get used to it.

I did but it just didn't work out, at first it was good but then I concluded it's definitely not worth overriding years worth of muscle memories
Comparatively, interestingly, the ISO to ANSI switch that I did when I switched to mechanical keyboards was painless, worthy (feeling-wise) and instant but I just had nightmares with the 1.5u Del

At the time of this decision keycap availability also played an important role but now even though most of the keycap sets I intend to use support the layout, I'm still going to stick to the regular 2u Backspace

I also use the \| key a lot and the tilde key not so much, so the 2u backspace and 1.5u \| makes sense on that level too (+ the muscle memories stay intact)

[KHAANNN]

Here is my latest/3rd build, a gift to my brother, with 60g lubed springs, tactile grey stems and the Hack'd by Geeks set:



Learned a lot with this build too, the most important lesson was to surface drill/sand-away the ground connections around the spots where the non-standard keycaps was going to be connected

And here are some build photos, the usb connector strengthening was probably my best one yet, it's tied, over-soldered, glued and hot-glued - however a strong pull could still tore it apart, but I'm guessing a strong pull could tore apart anything



After the components quality concerns, I considered using other PCB's, only the PCB is left from the actual infinity, however, I couldn't find an alternative PCB that I could verify the PCB routes/compatibility from photos, so sticked with the infinity PCB's - I also don't think there is an electronically bullet proof PCB out there yet, at least not for amateur 60%'s

[njbair]

Here is my latest/3rd build, a gift to my brother, with 60g lubed springs, tactile grey stems and the Hack'd by Geeks set:

(Attachment Link)

Learned a lot with this build too, the most important lesson was to surface drill/sand-away the ground connections around the spots where the non-standard keycaps was going to be connected

And here are some build photos, the usb connector strengthening was probably my best one yet, it's tied, over-soldered, glued and hot-glued - however a strong pull could still tore it apart, but I'm guessing a strong pull could tore apart anything

(Attachment Link) (Attachment Link) (Attachment Link)

After the components quality concerns, I considered using other PCB's, only the PCB is left from the actual infinity, however, I couldn't find an alternative PCB that I could verify the PCB routes/compatibility from photos, so sticked with the infinity PCB's - I also don't think there is an electronically bullet proof PCB out there yet, at least not for amateur 60%'s

What's the story with that plate? Is it plastic?

[Parak]

And here are some build photos, the usb connector strengthening was probably my best one yet, it's tied, over-soldered, glued and hot-glued - however a strong pull could still tore it apart, but I'm guessing a strong pull could tore apart anything

That's a pretty neat mod, definitely a lot of work involved! Are you planning to do even more? Because routing may or may not change on future revisions

Though I'd be remiss in pointing out that the extra solder is totally unnecessary, as a proper solder connection to a pad is generally stronger than the pad's connection to the underlying substrate, and is strongest in the intermetallic directly between the two parts (metal and pad). So, just a full reflow of each pad would have worked just as well, perhaps with the addition of a tiny bit of leaded solder. I think if you really want to go for total overkill, you could probably drill very small holes to either side (avoiding the traces of course), passing something like a thin steel wire through over the connector, and tying it off below with pliers.

[KHAANNN]

What's the story with that plate? Is it plastic?

It's 3d printed: https://geekhack.org/index.php?topic=72183.0

That's a pretty neat mod, definitely a lot of work involved! Are you planning to do even more? Because routing may or may not change on future revisions :p

Though I'd be remiss in pointing out that the extra solder is totally unnecessary, as a proper solder connection to a pad is generally stronger than the pad's connection to the underlying substrate, and is strongest in the intermetallic directly between the two parts (metal and pad). So, just a full reflow of each pad would have worked just as well, perhaps with the addition of a tiny bit of leaded solder. I think if you really want to go for total overkill, you could probably drill very small holes to either side (avoiding the traces of course), passing something like a thin steel wire through over the connector, and tying it off below with pliers.

I actually did just that, but with a very very tiny drill point, on my next attempt, I will drill from 3-4 points and wrap it with more wire (and maybe with a thicker drill point so it allows 1+ wires to be looped)

My iron at it's highest temp wasn't re-flowing those solder points well, so I just added some leaded solder on top of them, I'm not sure how strong it is, these kind of modifications can even weaken things like you mentioned earlier, however, at least it will ensure that the usb port will handle minor forces

I have 3 PCB's left and 1 more that I can de-solder, I'm at least going to do 2 more like these, I gave away my previous builds and I really need a decent keyboard myself at this point :)
Thinking of a lubed-clear + green duo, with this layout: http://www.keyboard-layout-editor.com/#/layouts/86b3cd92a54335cd46b00b90f9e0201a
(My only concern is that the right side of the plate has too many hand soldered switches, so the plate sits a bit weakly on top of the pcb, there is a possibility for that plate piece to sit higher than usual, I guess I might also change the shapes of my plate pieces to prevent this)

Thanks for the heads up, I would wait, however I'm not guessing it would happen in 1-2 months

[njbair]

Tonight I finished building my second Infinity, this one in the standard layout with MX Browns. I put my Hack'd by Geeks caps on it and so far it's doing really nicely.

I went ahead and built my custom firmware for this one using TMK, and I have to say I enjoyed the process much better than messing around with the Infinity configurator. I'm already pretty familiar with TMK and I've made my own custom 60% layout for my hasu PCB Alps board, so there was no real learning curve other than the build process particular to the Infinity. I'm so pleased with this firmware that I'm probably going to load the same thing onto my first Infinity, a Hacker layout with Matias Quiet Click switches.

For those who are curious, it's actually super simple to build TMK firmware and flash it to the Infinity. In fact, you don't even have to overwrite the bootloader. Once I had all the build dependencies installed on my linux desktop, I just had to put the Infinity into bootloader mode by pressing the bottom button, then burn the firmware using dfu-util.

The big benefits of TMK, for me, are:

• Ability to save a layout. The current web configurators can't do this.
• Portability. I can use the same firmware as my other customs (and actually, most other customs, period).
• Approachability. TMK's documentation is much easier to parse than "the KLL spec," which means I can do much more advanced things with it than I've yet been able to figure out with KLL.

TMK is just an awesome piece of software, and hasu is dedicated to making it ubiquitous. He's even developed what he calls a "USB to USB converter" which plugs in between any USB keyboard and your PC, allowing you to make them totally programmable. That means I can theoretically make every keyboard I own work the same way.

I really can't express how happy I am with the results using TMK firmware on this board. I had honestly begun to regret buying two Infinities because of my inability to get the layout to do what I wanted, but TMK has given them new life. I'm pretty psyched, in case you couldn't tell.

[FuriousGeorge]

For those who are curious, it's actually super simple to build TMK firmware and flash it to the Infinity. In fact, you don't even have to overwrite the bootloader. Once I had all the build dependencies installed on my linux desktop, I just had to put the Infinity into bootloader mode by pressing the bottom button, then burn the firmware using dfu-util.

This is great to hear. I've got an Infinity ordered from the third drop and have been taking a look at TMK to use for spacefn. I've got a ubuntu virtual machine setup and I think I'm understanding at least the layout. I don't completely understand what I'm doing, but I'm muddling through. It's been a long, long time since I've done any programming. I don't think I've used C since high school, and I'm pretty sure the last time I did any programming for work was with 16 bit Visual Basic and Access. I suspect the estimated ship date of tomorrow is a bit optimistic and based on the previous drops I still have plenty of time to get familiar with it.

[njbair]

For those who are curious, it's actually super simple to build TMK firmware and flash it to the Infinity. In fact, you don't even have to overwrite the bootloader. Once I had all the build dependencies installed on my linux desktop, I just had to put the Infinity into bootloader mode by pressing the bottom button, then burn the firmware using dfu-util.

This is great to hear. I've got an Infinity ordered from the third drop and have been taking a look at TMK to use for spacefn. I've got a ubuntu virtual machine setup and I think I'm understanding at least the layout. I don't completely understand what I'm doing, but I'm muddling through. It's been a long, long time since I've done any programming. I don't think I've used C since high school, and I'm pretty sure the last time I did any programming for work was with 16 bit Visual Basic and Access. I suspect the estimated ship date of tomorrow is a bit optimistic and based on the previous drops I still have plenty of time to get familiar with it.

I'm actually using SpaceFn on mine. I know the Infinity has dedicated Fn keys, and I'm using those on and off, but on my AEKII 60% I don't have any Fn keys so I have Space and Enter set up as my Fn keys. It's pretty simple to set up, once you know how the firmware works:

In your default layer, set the spacebar to FN2 (or FN1, FN0, or whatever. I'm using FN2 on mine). Then you need to set up your function layer, let's say Layer 1. Then you need to use:

Code: [Select]

[2] ACTION_LAYER_TAP_KEY(1, KC_SPC)

to tell it which layer to switch to, and which keycode to fire when tapped.

I also use ACTION_LAYER_MOMENTARY() for the standard Fn keys. There is also a lock one, I think, but I don't use that in my layout.

In case you're interested for reference or a starting point, here's the config I'm using right now.

[KHAANNN]

I really can't express how happy I am with the results using TMK firmware on this board. I had honestly begun to regret buying two Infinities because of my inability to get the layout to do what I wanted, but TMK has given them new life. I'm pretty psyched, in case you couldn't tell.

Thanks a lot for sharing this, I gave up on the infinity firmware's pace too, a while ago, however the firmware seems solid to me, by the way, are you able to measure the amper usage of the infinity kb with tmk_keyboard, my only concern with the tmk_firmware was that it uses a wrapper for ARM, I was afraid it could have been untested and maybe lead to issues (I'm very impressed that the infinitykb uses <=0.01A - I just wonder whether that's because of the firmware is light)

The actual reason I gave up on tmk_keyobard is because I'm too lazy to ssh to a linux server to compile tmk and the osx build routine simply doesn't work, the mbed library isn't compatible with osx/arm, however the issue seems to be pathced/non-existent at the linux versions - comparatively, modifying and compiling the infinity firmware is also very simple, similar to your experience with tmk

I want to extend the "Alt" functionality to output different character sequences that I use frequently, I want to merge the command functionality with the Fn key of the keyboard, but I also need to keep the regular "Alt"/"Cmd" functionality, mainly for Alt+click Command+click's and combos - and many more modifications similar to this, I guess I should also look into tmk_keyboard and test it on my infinity v1

[FuriousGeorge]

This got me motivated to finish up the keymap I had started and figure out github so I can post it. I haven't looked it over for errors yet, and I'm not sure I'm completely happy with where I have everything, but I think I got all the basics I wanted. Here's my initial layout. Is my understanding that the ACTION_MODS_KEY() function is necessary for shifted keys correct? I'm mapping a colon instead of a semicolon with ACTION_MODS_KEY(MOD_LSFT, KC_SCLN) or an exclamation mark would be ACTION_MODS_KEY(MOD_LSFT, KC_1). Is that right?

[njbair]

I really can't express how happy I am with the results using TMK firmware on this board. I had honestly begun to regret buying two Infinities because of my inability to get the layout to do what I wanted, but TMK has given them new life. I'm pretty psyched, in case you couldn't tell.

Thanks a lot for sharing this, I gave up on the infinity firmware's pace too, a while ago, however the firmware seems solid to me, by the way, are you able to measure the amper usage of the infinity kb with tmk_keyboard, my only concern with the tmk_firmware was that it uses a wrapper for ARM, I was afraid it could have been untested and maybe lead to issues (I'm very impressed that the infinitykb uses <=0.01A - I just wonder whether that's because of the firmware is light)

The actual reason I gave up on tmk_keyobard is because I'm too lazy to ssh to a linux server to compile tmk and the osx build routine simply doesn't work, the mbed library isn't compatible with osx/arm, however the issue seems to be pathced/non-existent at the linux versions - comparatively, modifying and compiling the infinity firmware is also very simple, similar to your experience with tmk

I want to extend the "Alt" functionality to output different character sequences that I use frequently, I want to merge the command functionality with the Fn key of the keyboard, but I also need to keep the regular "Alt"/"Cmd" functionality, mainly for Alt+click Command+click's and combos - and many more modifications similar to this, I guess I should also look into tmk_keyboard and test it on my infinity v1

Sorry, I don't have easy access to a USB power meter. I could hook up a multi, but I'd have to cut apart a cable.

As far as building TMK, I did it today in Windows using an Ubuntu VM (VirtualBox) and using USB pass-through. It took a little bit of setting up, but now that it's done it's super simple to rebuild.

It's not that the Infinity firmware wasn't solid...I think maybe my expectations for it are different because Massdrop is this big company, selling this keyboard as a fully-programmable device, and yet their own configuration utility has been stagnant and completely borked for months and months. I've also found the community support for TMK to be much better than KLL. Whenever you ask a question about Infinity/KLL, the answer is always, "ask HaaTa. He should be online later."

[HaaTa]

Yeah, sorry about not being as active I should be (I could go into working 13 hour days for the past 3 months at my real job, but no one cares about that ).
But! Work is actually slowing down so I should be able to more actively work on features/bugs again.

Yeah...that Massdrop configurator. I ended up having to get matt3o to help me out to get one made. Massdrop engineering screwed me over, promising me something in October, then saying in April, "Nope can't do it". It wasn't till May that I had something working.
At least the configurator is opensource now.

Like hasu, I'm just one guy working on keyboard firmware.
TMK is more mature/tested, KLL is more ambitious (and may have a larger install base at this point). But yeah, I make an effort to send all the keyboards I make to hasu just in case he wants to add support (I definitely read his code a lot when working on USB NKRO).

I haven't done any power measurements of the IC60 (I can do some if there's interest).


The current shipment of IC60 is delayed because of (stupid) pcb fabs. We've been trying to fix all the soldering and pcb issues on the IC60 (and ErgoDox) but it's been a long process.
As a bonus, this version of the IC60 will have quite a few fixes (better pcb fab, better soldering, general layout fixes based on user issues). We really do try to read all the comments.

Anyways, back to work so I can go home early and work on KLL

[njbair]

Yeah, sorry about not being as active I should be (I could go into working 13 hour days for the past 3 months at my real job, but no one cares about that ).
But! Work is actually slowing down so I should be able to more actively work on features/bugs again.

Yeah...that Massdrop configurator. I ended up having to get matt3o to help me out to get one made. Massdrop engineering screwed me over, promising me something in October, then saying in April, "Nope can't do it". It wasn't till May that I had something working.
At least the configurator is opensource now.

Like hasu, I'm just one guy working on keyboard firmware.
TMK is more mature/tested, KLL is more ambitious (and may have a larger install base at this point). But yeah, I make an effort to send all the keyboards I make to hasu just in case he wants to add support (I definitely read his code a lot when working on USB NKRO).

I haven't done any power measurements of the IC60 (I can do some if there's interest).


The current shipment of IC60 is delayed because of (stupid) pcb fabs. We've been trying to fix all the soldering and pcb issues on the IC60 (and ErgoDox) but it's been a long process.
As a bonus, this version of the IC60 will have quite a few fixes (better pcb fab, better soldering, general layout fixes based on user issues). We really do try to read all the comments.

Anyways, back to work so I can go home early and work on KLL

Appreciate you weighing in, HaaTa. I hope my post wasn't discouraging, it wasn't intended to be. Please take note, I recognize that my issues with KLL/Infinity firmware are almost all Massdrop-related. Your hardware and software are solid, and my only regret having purchased two Infinities, is that I got my Alps board in the Hacker layout (good luck finding a spacebar for that thing). Even your own responsiveness is commendable, all things considered. The big problems are a lack of practical documentation ("how do I" vs. just having to master the spec), and a lack of community members who know the ins and outs. I think both of these are solvable, especially with more time and experience.

You mentioned the configurator is open source, do you have a link to a repo? I'd love to work on adding the ability to save/load configs through the web interface.

Thanks as always for your great work.

[KHAANNN]

Yeah, sorry about not being as active I should be (I could go into working 13 hour days for the past 3 months at my real job, but no one cares about that :P).
But! Work is actually slowing down so I should be able to more actively work on features/bugs again.

Yeah...that Massdrop configurator. I ended up having to get matt3o to help me out to get one made. Massdrop engineering screwed me over, promising me something in October, then saying in April, "Nope can't do it". It wasn't till May that I had something working.
At least the configurator is opensource now.

Like hasu, I'm just one guy working on keyboard firmware.
TMK is more mature/tested, KLL is more ambitious (and may have a larger install base at this point). But yeah, I make an effort to send all the keyboards I make to hasu just in case he wants to add support (I definitely read his code a lot when working on USB NKRO).

I haven't done any power measurements of the IC60 (I can do some if there's interest).


The current shipment of IC60 is delayed because of (stupid) pcb fabs. We've been trying to fix all the soldering and pcb issues on the IC60 (and ErgoDox) but it's been a long process.
As a bonus, this version of the IC60 will have quite a few fixes (better pcb fab, better soldering, general layout fixes based on user issues). We really do try to read all the comments.

Anyways, back to work so I can go home early and work on KLL :D

Thanks for the update, the soldering and layout issues are pretty superficial actually once you accept certain things, I would love it if you could take a look at my "exact response" feature request (+ the ability to delay stuff, for os/language change combos)

The sub-standard component usage claims got me really worried tho, there were claims that Massdrop got the infinity PCB's manufactured with low quality or out-of-boundary capacitors, my mind was eased after Parak said this is not the case - but still, there is a lingering "what-if" in my mind

After inhaling this much second-hand PCB smoke and potentially causing a future cancer, I would at least like my keyboards to keep on working :)

Lessons learned:
1) Find or manufacture a PCB for this layout: http://www.keyboard-layout-editor.com/#/layouts/86b3cd92a54335cd46b00b90f9e0201a - instead of manually drilling into PCB's (next time) (it's actually pretty doable, but since I've done it 4 times, I just don't want to do it again, it's more challenging than it appears)
2) Stay away from Massdrop (always) (it's not that they are bad, the support is good, but they certainly don't prepare well and always deal with the aftermath, it's too much drama for me)

[HaaTa]

Just measured an IC60 current. I'd say it's around 18.3 mA @ 5 V
Which is pretty good given that I've done very little in the firmware to make it power efficient (there are things I can do, but I don't really want to look into them until I get more features implemented).

[KHAANNN]

Just measured an IC60 current. I'd say it's around 18.3 mA @ 5 V
Which is pretty good given that I've done very little in the firmware to make it power efficient (there are things I can do, but I don't really want to look into them until I get more features implemented).

infinity's are also very power efficient, that's why I was hesitant to switch to tmk, as I have no idea how much a difference firmware makes (the usb ampermeters read 0.00/0.01 with infinity/infinity firmware)

I guess I should find a compiled tmk firmware just for testing purposes, njbair, if you could upload one somewhere I could test it

90% - it will also use 0.00/0.01 similarly
5% - it could use more if it loops too much (?)
5% - it could use more due to not being native to ARM

[njbair]

Just measured an IC60 current. I'd say it's around 18.3 mA @ 5 V
Which is pretty good given that I've done very little in the firmware to make it power efficient (there are things I can do, but I don't really want to look into them until I get more features implemented).

infinity's are also very power efficient, that's why I was hesitant to switch to tmk, as I have no idea how much a difference firmware makes (the usb ampermeters read 0.00/0.01 with infinity/infinity firmware)

I guess I should find a compiled tmk firmware just for testing purposes, njbair, if you could upload one somewhere I could test it

90% - it will also use 0.00/0.01 similarly
5% - it could use more if it loops too much (?)
5% - it could use more due to not being native to ARM

Here you go.

[KHAANNN]

Quick question, how do you flash with the hex file?

I use dfu-util at osx to flash .bin's, but my quick google searches for hex flashing were fruitless

[njbair]

Quick question, how do you flash with the hex file?

I use dfu-util at osx to flash .bin's, but my quick google searches for hex flashing were fruitless

Yep, it's dfu-util -D infinity.bin

[KHAANNN]

Quick question, how do you flash with the hex file?

I use dfu-util at osx to flash .bin's, but my quick google searches for hex flashing were fruitless

Yep, it's dfu-util -D infinity.bin

The file you uploaded seems to be infinity.hex, that's why I asked, don't want to attempt a dfu-util -D before being sure :)

[njbair]

Quick question, how do you flash with the hex file?

I use dfu-util at osx to flash .bin's, but my quick google searches for hex flashing were fruitless

Yep, it's dfu-util -D infinity.bin

The file you uploaded seems to be infinity.hex, that's why I asked, don't want to attempt a dfu-util -D before being sure

My bad! See attached.

[KHAANNN]

Quick question, how do you flash with the hex file?

I use dfu-util at osx to flash .bin's, but my quick google searches for hex flashing were fruitless

Yep, it's dfu-util -D infinity.bin

The file you uploaded seems to be infinity.hex, that's why I asked, don't want to attempt a dfu-util -D before being sure

My bad! See attached.

Thanks!

There is no change in power usage, it's still 0.01A with tmk/infinity

[njbair]

Quick question, how do you flash with the hex file?

I use dfu-util at osx to flash .bin's, but my quick google searches for hex flashing were fruitless

Yep, it's dfu-util -D infinity.bin

The file you uploaded seems to be infinity.hex, that's why I asked, don't want to attempt a dfu-util -D before being sure

My bad! See attached.

Thanks!

There is no change in power usage, it's still 0.01A with tmk/infinity

I figured as much, as most cheap micro's don't have advanced idling states, so it usually uses about the same power regardless of what's running. Power-saving modes are usually only found on higher-end SOC's.

[HaaTa]

This chip does have power saving modes, but I haven't played around them much.
I might take a look at it once I get USB waking/suspending working properly.

[njbair]

This chip does have power saving modes, but I haven't played around them much.
I might take a look at it once I get USB waking/suspending working properly.

Ah, I forgot this was an ARM chip. I actually don't know much about those...most of my experience is with 8-bit stuff, and the Parallax Propeller back in the day.

Really, power saving doesn't sound like a huge priority because it would only even be an issue with laptops, and people generally don't leave a keyboard plugged into a laptop when they store it for transport. Unless there's another benefit that I don't know about?

[KHAANNN]

This chip does have power saving modes, but I haven't played around them much.
I might take a look at it once I get USB waking/suspending working properly.

Ah, I forgot this was an ARM chip. I actually don't know much about those...most of my experience is with 8-bit stuff, and the Parallax Propeller back in the day.

Really, power saving doesn't sound like a huge priority because it would only even be an issue with laptops, and people generally don't leave a keyboard plugged into a laptop when they store it for transport. Unless there's another benefit that I don't know about?

It might extend the longevity of the keyboard tenfold, assuming the processor is working when the computer is idle (?)

I don't think power usage itself is much of an issue, since it only pulls ~0.01A - but the longevity seems important

[Parak]

It's of significant benefit when calculating bluetooth feasibility...

*cough*

[FuriousGeorge]

It's of significant benefit when calculating bluetooth feasibility...

*cough*

My wallet doesn't want to hear about it, but the rest of me would love to know more.

[KHAANNN]

It's of significant benefit when calculating bluetooth feasibility...

*cough*

Luckily I hate bluetooth, or my fomo would ache

Bluetooth is really really challenging, I've read several complaints about GON's usage being laggy, overall it's rare to read about a non-laggy usage

I guess the case would need to be plastic, likely the plate too

[FuriousGeorge]

A plastic plate wouldn't be a bad idea just to keep weight down. I have a Minila Air that actually works really well over bluetooth, but a programmable board with a more standard layout would be a huge upgrade. If it was a little lighter, even better.

[KHAANNN]

A plastic plate wouldn't be a bad idea just to keep weight down. I have a Minila Air that actually works really well over bluetooth, but a programmable board with a more standard layout would be a huge upgrade. If it was a little lighter, even better.

I guess for a portable keyboard it's logical, but for a stationary keyboard, bulk amplifies the experience, light keyboards slide over the desk, a keyboard with an aluminium case is barely bulky enough, a plastic cased keyboard would be too flimsy

[KHAANNN]

I want to test the capacitors to see for myself whether they really match the specs: https://github.com/kiibohd/pcb/blob/master/Massdrop1/massdrop1.pdf

As my electrical knowledge is basic, is it safe to measure the capacitances when the capacitors are connected to the circuit?

Since C6 seems relatively isolated, I went ahead and checked it, it reads 93n - while the spec is 100n - the PCB kept on functioning afterwards

I would like some advice/insight before I go forward

[njbair]

I want to test the capacitors to see for myself whether they really match the specs: https://github.com/kiibohd/pcb/blob/master/Massdrop1/massdrop1.pdf

As my electrical knowledge is basic, is it safe to measure the capacitances when the capacitors are connected to the circuit?

Since C6 seems relatively isolated, I went ahead and checked it, it reads 93n - while the spec is 100n - the PCB kept on functioning afterwards

I would like some advice/insight before I go forward

Pretty sure it's safe. A multimeter does actually charge the cap in order to measure it, but I think it uses very little power. I know I've measured caps in-place before without ever breaking anything. Obviously you want to unplug the keyboard first, but you probably assumed that.

[HaaTa]

It's less about breaking something, and more about getting an accurate capacitance reading. The only way to get a good reading is to desolder the cap first...

[njbair]

So what's actually been said about the capacitors? That they are out of spec for what the chip is supposed to be able to handle, or that they are just off from the label?

IME, discrete components are never right on...I think they just make a bunch of caps and measure them, and the ones that are within 1% go into the +/- 1% hopper where they can charge more for them, and on down the line until there are no truly accurate caps left in the +/- 10% hopper.

[HaaTa]

So, we aren't actually sure if there is a problem with all the caps or not. The ones I've tested seem to be fine. But it's possible the fab sourced cheaper components (and not the exact part numbers we specified) without telling us.
For the current (and future) manufacturing runs we're stressing with the (new) fab not to do this and use only the part numbers we specify.

But yeah, there was an out of spec cap on the reset line it seems. That would definitely cause issues.

[njbair]

But it's possible the fab sourced cheaper components (and not the exact part numbers we specified) without telling us.

This kind of utter disregard to quality is becoming the norm. But a lot of businesses continue to order goods from these places because it's still cheaper to have things made overseas PLUS have a US shop repair them, than to have the whole thing made here. I know of one manufacturer who would actually have their Chinese-made molds shipped directly to their US repair shop, with a standing order to "look them over and fix whatever's wrong with them." The company saved thousands per order this way.

[KHAANNN]

The C5 C1 C3 looks like they are in parallel, the C6 read 93, C5 was out of boundaries likely because of the circuit connections (the C1,C2 is 2.2u, the C3-C6 seems to be 100n)

If anyone else is interested, it might be a good idea to compare some readings

I have a pack of generic SMD capacitors from China that I bought years ago, they are all ~1% accurate, unless this fab is douchey beyond imagination I don't see how they could go so wrong, similarly, I can't imagine how a part manufacturer could produce so out-of-bound components and stay in business

At this point I hope the issue is an exaggerated one and my readings were faulty as the circuit is affecting them

[njbair]

I don't see how they could go so wrong, similarly, I can't imagine how a part manufacturer could produce so out-of-bound components and stay in business

Because it costs 0.2 cents instead of 0.3 cents, and people are scumbags.

[HaaTa]

Was browsing App Notes and found one on low power modes. VLPR is the keyword you're looking for.

http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4470.pdf

Apparently it's possible to get 2.3 mA using the larger mk20dx256vlh7's (what I'll be using the on the Infinity Ergodox).
https://forum.pjrc.com/threads/25755-Teensy-3-1-overclock-to-168MHz?p=48878&viewfull=1#post48878
Though I'm not sure how many peripherals have to be disabled.

My idea would be to transition to VLPR mode (2 MHz clock) when the keyboard is idle scanning after a certain amount of time. Once the first keypress is detected, re-clock the back to usual speed.
The post also mentions it should be possible to overclock to at least 96 MHz reliably (for both the mk20dx128vlf5 and mk20dx256vlh7). I'm only going to be running at the rated speeds. I don'[t really trust overclocking for a mass-produced product.

[KHAANNN]

Is there an imminent significant improvement that enables improved modifier mixing/overriding?

Otherwise I'm going to make the tmk_keyboard switch soon, the mbed/osx issue have been preventing me but I've been thinking of writing a routine that will rcp the firmware directory, compile on a virtual machine, pull the firmware back - but I've been delaying this as the added features weren't vital - can't delay anymore tho

(I also decided to use my Rev 1.02 PCB for my next build, as the 60% PCB market isn't too bright right now, if the new PCB is ready, I might wait 1-2 weeks and either buy a PCB from someone or request a replacement from Massdrop)

[HaaTa]

Probably not imminent. I'm currently finishing up ErgoDox related things (base firmware is done, minus a final compatibility check).
However, in a couple weeks I have a business trip (to Chicago) so I might be able to dedicate a bunch of time to things like modifiers/timing/etc. because it's harder to do hardware related testing without my lab.

The spec is pretty much done (unless there are some extra features needed).
If you wouldn't mind taking a look (specifically any section with "State Scheduling" and "Timing") to see if you can do what you want with this spec?
https://www.overleaf.com/read/mnnqqpnxhhyr

Also, as an FYI, I'll be posting all the KLL specs here -> http://input.club/kll

[KHAANNN]

Probably not imminent. I'm currently finishing up ErgoDox related things (base firmware is done, minus a final compatibility check).
However, in a couple weeks I have a business trip (to Chicago) so I might be able to dedicate a bunch of time to things like modifiers/timing/etc. because it's harder to do hardware related testing without my lab.

The spec is pretty much done (unless there are some extra features needed).
If you wouldn't mind taking a look (specifically any section with "State Scheduling" and "Timing") to see if you can do what you want with this spec?
https://www.overleaf.com/read/mnnqqpnxhhyr

Also, as an FYI, I'll be posting all the KLL specs here -> http://input.club/kll

I checked the spec, not too deeply, it's pretty complicated as it is, I think the spec sheet could use a good "Examples" section with some real life scenarios (so people could just check the examples and adapt them to their use cases)

For example, what is the combination that converts Shift+Esc to a "~" without the "Esc" ever leaving the keyboard?

[HaaTa]

That one, it depends on what's your expected behaviour.

If Shift, then Esc is the only one you need (and should be working since the first Infinity shipped in February):

Code: [Select]

U["LShift", "RShift"] + U"Esc" : '~';
For clarity, I'll explain what this means.
U["LShift", "RShift"] means I want to take any of these keys in this range as an element. It's also possible to do U["A"-"Z"]. Be careful though, some ranges don't behave as you'd expect ("1"-"0" is actually 0,1,2,3,4,5,6,7,8,9 and "0"-"9" is 0,9 because of how USB Codes are arranged in the spec).
The + just means both have to happen at the same time.

The single quotes ' ' are a special macro expansion. It will evaluate any ASCII expression into USB Codes. Case matters unlike the double quotes (which is for symbolic names).
'~' expands into U"LShift" + U"BackTick".

I don't mind creating a list of commonly used 'Examples" actually. Unfortunately, I don't really know what they are (I don't use keys like this very often). If I can get a list of commonly used "special" keymappings I could write up a wiki page on how I'd implement them (or which KLL spec they'll be implemented in, and what the syntax would look like).

[njbair]

That one, it depends on what's your expected behaviour.

If Shift, then Esc is the only one you need (and should be working since the first Infinity shipped in February):

Code: [Select]

U["LShift", "RShift"] + U"Esc" : '~';
For clarity, I'll explain what this means.
U["LShift", "RShift"] means I want to take any of these keys in this range as an element. It's also possible to do U["A"-"Z"]. Be careful though, some ranges don't behave as you'd expect ("1"-"0" is actually 0,1,2,3,4,5,6,7,8,9 and "0"-"9" is 0,9 because of how USB Codes are arranged in the spec).
The + just means both have to happen at the same time.

The single quotes ' ' are a special macro expansion. It will evaluate any ASCII expression into USB Codes. Case matters unlike the double quotes (which is for symbolic names).
'~' expands into U"LShift" + U"BackTick".

I don't mind creating a list of commonly used 'Examples" actually. Unfortunately, I don't really know what they are (I don't use keys like this very often). If I can get a list of commonly used "special" keymappings I could write up a wiki page on how I'd implement them (or which KLL spec they'll be implemented in, and what the syntax would look like).

I could never figure out how to set a new default layer (for switching between QWERTY & Dvorak). That, and the inability to save a configurator layout were the reasons I loaded TMK on both of my Infinities instead.

[KHAANNN]

That one, it depends on what's your expected behaviour.

If Shift, then Esc is the only one you need (and should be working since the first Infinity shipped in February):

Code: [Select]

U["LShift", "RShift"] + U"Esc" : '~';
For clarity, I'll explain what this means.
U["LShift", "RShift"] means I want to take any of these keys in this range as an element. It's also possible to do U["A"-"Z"]. Be careful though, some ranges don't behave as you'd expect ("1"-"0" is actually 0,1,2,3,4,5,6,7,8,9 and "0"-"9" is 0,9 because of how USB Codes are arranged in the spec).
The + just means both have to happen at the same time.

The single quotes ' ' are a special macro expansion. It will evaluate any ASCII expression into USB Codes. Case matters unlike the double quotes (which is for symbolic names).
'~' expands into U"LShift" + U"BackTick".

I don't mind creating a list of commonly used 'Examples" actually. Unfortunately, I don't really know what they are (I don't use keys like this very often). If I can get a list of commonly used "special" keymappings I could write up a wiki page on how I'd implement them (or which KLL spec they'll be implemented in, and what the syntax would look like).

Doesn't this mapping also output the "Esc" tho? the whole point of my question is to avoid the Esc

(Couple of examples for the SpaceFn layout could be great, I don't use it myself, but it seems like a challenging layout)

[njbair]

SpaceFn is a great example, because it's not just the spacebar, but it can be any key.

TMK implements this with a default 200ms tap threshold. If the key is pressed for less than 200ms, it outputs the specified scan code. But if pressed for longer than 200ms, it becomes a modifier. Hold-repeats require a double-tap (tap then hold) action, to bypass the modifier action which would normally be triggered while holding the key down.

Personally, I use spacebar and Enter, as well as a dedicated Fn key, to access my function layer. I would love to see some KLL examples of this.

[HaaTa]

Ah, yep, you are correct.

This is an interesting problem because there has to be an algorithm to decide which output is more important (e.g. priority).
For this example, there are 3 different outputs going on simultaneously:

• Shift
• Esc
• Shift+BackTick

(the shifts actually overlap, so they aren't really a problem in this example)

The most sophisticated algorithm, would be to apply a priority rating to each macro assignment. This might be useful for extremely sophisticated combinations, but nothing really comes to mind right now.

Perhaps the easier option is to exclude sub-keys in the macro from being processed. This could be done, without changing KLL (and I think makes more sense overall).

For example, when pressing Shift, both Sequences (Shift and Shift+Esc) activate. Since Shift is complete, it sends out the Shift USB Code. Now, when Esc is pressed, there are two Sequences that can be activated (Esc, and Shift+Esc).
Since Shift+Esc is a long macro and already has an element ready in the sequence, it takes precedence and "consumes" the Esc key. This means that USB Esc is never sent.

Would something like that work? I'd probably have an enable/disable option for it in KLL (default enabled, because I think it makes more sense than the default case).
I'll think about it over lunch, but I could probably implement this rather quickly (maybe today?).

[KHAANNN]

Ah, yep, you are correct.

This is an interesting problem because there has to be an algorithm to decide which output is more important (e.g. priority).
For this example, there are 3 different outputs going on simultaneously:

• Shift
• Esc
• Shift+BackTick

(the shifts actually overlap, so they aren't really a problem in this example)

The most sophisticated algorithm, would be to apply a priority rating to each macro assignment. This might be useful for extremely sophisticated combinations, but nothing really comes to mind right now.

Perhaps the easier option is to exclude sub-keys in the macro from being processed. This could be done, without changing KLL (and I think makes more sense overall).

For example, when pressing Shift, both Sequences (Shift and Shift+Esc) activate. Since Shift is complete, it sends out the Shift USB Code. Now, when Esc is pressed, there are two Sequences that can be activated (Esc, and Shift+Esc).
Since Shift+Esc is a long macro and already has an element ready in the sequence, it takes precedence and "consumes" the Esc key. This means that USB Esc is never sent.

Would something like that work? I'd probably have an enable/disable option for it in KLL (default enabled, because I think it makes more sense than the default case).
I'll think about it over lunch, but I could probably implement this rather quickly (maybe today?).

I think it's still overly complicated

An exact response routine would be simpler, instead of a ":" it could be used with > for example, like U"Shift"+U"Esc" > "~";

The logic would be:

while current stack is not a prefix of the exact output needed, release keys
activate the keys needed
re-activate the released keys except the last one (Esc in this case)

U"Shift"+U"Ctrl"+U"Command"+U"A" > U"Shift"+U"B"

First U"Command" would be release, then U"Ctrl" would be released, then U"B" would be tapped
To restore things, U"Ctrl"+U"Command" would be restored

This is the TMK way by the way: https://github.com/tmk/tmk_keyboard/issues/233

By giving people practical access to the events, hasu simplified stuff like this significantly

Comparatively, kll is probably more complex

My point is, it might be a good idea to add some programming examples, methods, integration points