Face U/MX-mini U replica knowledge base

[chzel]

Mind you, I tested the wake-up with the preloaded firmware, and I haven't tried any setting in BIOS or whatever.
OTH my Filco does wake up the pc.

[matt3o]

the code is open source https://github.com/showjean/ps2avrU

the flash thing is for convenience but you don't need it.

[DanielT]

Yep, you can program the board from a text editor, and it's OS independent.
I have to test with a newer version of the firmware, after more tests I saw that the problem I had with GRUB extends also with the BIOS, but only when I power-on the computer, if I reboot there is no issue.
I guess it could be related to the time it takes for the firmware to boot.
Maybe with a normal computer this is not an issues, but my setup is low power and very fast, the whole power-on/boot sequence takes just 15-20s

I never had this kind of problems with my Poker X, but that one is gone now
I didn't test the wake up because I don't use it, in my setup the important stuff is running on central server and the thin client boots very fast.
Overall I like the keyboard, I would not call it a dud, maybe we all do something wrong from the firmware point of view, but we have no support, we're flying solo The hardware is OK'sh for some is fine for others has some QC issues.

[Laser]

Well, in some of the 1.7 firmware changelong, sleep / wake-up is at least mentioned (http://blog.winkeyless.kr/17 , 07/16/2014) - i have the 1.7 firmware, must test the wake-up thing when i get home.

(BTW, the Korean page has firmware more recent than the "1.7 firmware update" GB thread)

[matt3o]

The firmware is really (really) well done. Probably one of the best I've seen. You can program the full thing from a text editor without re-compiling.

Just open a text editor, hold left CTRL+ALT+SHIFT and right SHIFT for 5 seconds, then release and follow the onscreen instructions. Keycodes reference: https://docs.google.com/spreadsheet/ccc ... ring#gid=0

The hardware instead is barely acceptable, anyway at the end you can have it working, so I guess it's ok.

[Laser]

The firmware is really (really) well done. Probably one of the best I've seen. You can program the full thing from a text editor without re-compiling.

Just open a text editor, hold left CTRL+ALT+SHIFT and right SHIFT for 5 seconds, then release and follow the onscreen instructions. Keycodes reference: https://docs.google.com/spreadsheet/ccc ... ring#gid=0

The hardware instead is barely acceptable, anyway at the end you can have it working, so I guess it's ok.

If I got it right, the "barely acceptable hardware" applies to SPRiT (non-replica) boards as well, right? Good thing is that any firmware problems "we" have, "they" have too, so in time they will be solved (if not already in latest version)

[chzel]

I think "barely acceptable" refers to component spec, assembly, and QC (or lack of).
If executed correctly I believe it is as capable as anything else.
A 32u4 would let us use more diverse firmwares, but that is a choice thing.
If the sprit boards use a reputable fab house with brand components, they will be way better and way more expensive.
But yeah, on the firmware side of things, ours problems are their problems too.

[DanielT]

The sprit boards are a newer revision from the hardware point of view, and made in Korea with better QC.
Now back to our replicas, I'm really pissed, even after the firmware update in BIOS I can not use the board, tested on 2 computers, same behaviour, one with Win the other with Linux, one Dell the other HP. Only if I reboot with the keyboard plugged in I can use it in BIOS and GRUB.
This is ironic, if I want to do something in BIOS I have to use a rubberdome I have laying around
Can anybody test this ? Maybe I can do some settings, both computers worked with Poker and HHKB .

[MrMen]

Bad news DanielT : my keyboard with my grub. It's on a dell xps 13. Clearly it's not as fast as another keyboard but it worked.
Now we just need to know why…

[matt3o]

I must say... I love my new keyboard...

[MrMen]

About HHKB style, does anyone have a tip to fill hole created by the missing keys (on the bottom row).
PS : I think I didn't read any answer about : what kind of LED can we put on this keyboard ? It's about electronic specs…

[DanielT]

@matt3o: I must say I love your keyboard too and that case is just perfect, would love one like that.
@MrMen: it seems that some motherboards have an issue with NKRO, this is why also GRUB has a problem. I will test 6KRO firmware, that one should work. Also my keyboard works in BIOS and GRUB but only after reboot, the problem is only at cold boot. Now for the LED's GON has a list on his site, depending on the type of LED you need a type of resistor. We have the resistors soldered so we need to match de LED, I will give it a look, I'm not good at this stuff, I use to know back when I was in the UNI, long time ago

[chzel]

About HHKB style, does anyone have a tip to fill hole created by the missing keys (on the bottom row).

Maybe sth like this?clicky

PS : I think I didn't read any answer about : what kind of LED can we put on this keyboard ? It's about electronic specs…

Leds are driven by 330R resistors, so any standard led will do (any color - 1.7V or 3.6V or whatever).

[Laser]

About HHKB style, does anyone have a tip to fill hole created by the missing keys (on the bottom row).

Maybe sth like this?clicky

Was almost ready to post the same finding - and yet, unfortunately i don't think they would cover the larger plate holes at PCB bottom, as those plate holes are larger than 1u - in case you want to keep 2 adjacent key places empty. One empty place should work though:



(src: http://geekhack.org/index.php?topic=40100.30 )

[chzel]

Just to clarify my "any led" comment:

Spoiler:

LEDs have a "working voltage" that is determined by their color. (red, green, orange etc. are ~1.7V, blue/white/purple are ~3.6V) an a maximum current they can sustain. (usually 20ma)
We supply them with 5V and we need to "burn off" the extra voltage. We do that with resistors following the formula V=IR.
So if we have green leds, it is

Code: Select all

3.3     =     I      *     330
  ^           ^             ^
voltage      current     resistor
to burn
off

and I works out to 10mA, well inside the safe zone.
For 3.6V leds it is 4.25mA. Even more inside the safe zone!

[matt3o]

I tried the keyboard on the BIOS and grub.

It is very faulty in the BIOS, but it kinda works. Doesn't work at all on grub.

[DanielT]

I tried the keyboard on the BIOS and grub.

It is very faulty in the BIOS, but it kinda works. Doesn't work at all on grub.

It looks like my scenario, I'll test the other firmware, see how it goes. For me this is important, at home I have only Linux and Solaris so I need it to work in GRUB. I'm not a gamer so NKRO doesn't mean much for me, can live without it.

[matt3o]

I found out that NKRO works only on PS2 anyway

[MrMen]

Thank you for these answers ^^ now I think I will solder a bit more.

[DanielT]

Now I wonder, which is the non NKRO firmware? Is it the keymain_GKP.hex ? The keymain_NKRO.hex is the default one.

[Laser]

Tapioca pic - detachable tiles; i may try some wooden ones later on.
And in a month or so, i hope to have proper legends on every cap.

mod01.jpg (49.62 KiB) Viewed 4403 times

[matt3o]

Now I wonder, which is the non NKRO firmware? Is it the keymain_GKP.hex ? The keymain_NKRO.hex is the default one.

I believe so, but have no prove.

[DanielT]

Nope, tested and that one has something to do with Ghosting, no effect on BIOS/GRUB.
It's a shame because it's a really nice board, easy to configure. That command line menu is so cool, I want to remap a key, just open a text editor (works also in vi/vim ) and remap, no dedicated software, no reflashing, OS independent

[matt3o]

it would be relatively easy to rebuild the firmware (and remove some of the useless features), I had a look at the vusb code and it's pretty straight forward... Problem is time... or lack thereof

[DanielT]

A 6KRO version would be nice. I understand the code, but lack the required skills to build something reliable
I assembled also the second PCB, no hardware issues, works just fine. Now I need a case also for this one

[Laser]

it would be relatively easy to rebuild the firmware (and remove some of the useless features), I had a look at the vusb code and it's pretty straight forward... Problem is time... or lack thereof

What would have to be changed, roughly, and would it solve the boot & wake-up issues?

BTW, have anyone tried hooking the keyboard with a USB->PS/2 adapter?

EDIT: And how about opening a issue at the ps2avrU github site about boot/wake-up issues? Is that the right place?

[DanielT]

If we make the firmware 6KRO the problem should be solved.
Don't have and adapter at hand, have one at work I will give it a try.
EDIT: I think we can ask on the git-hub page, and maybe we should.

[matt3o]

the software is 6KRO over USB. I don't think it is even possible to have NKRO over v-usb (even though hasu says he might work on that sooner or later)

[DanielT]

In that case we need to eliminate all the KRO crap to make it work, and I have my doubts that even with that it will work. From what I've been reading v-usb and BIOS don't mix 'n match

[Laser]

About suspend mode, there is some info mentioned at http://vusb.wikidot.com/examples
(under 'Implementing suspend mode')

Spoiler:

The USB standard defines a suspend mode. When the host computer goes into sleep mode, it requests that all USB devices go into a low power suspend mode. Suspend mode is signaled to the devices by the absence of any USB activity.

V-USB does not implement suspend mode by itself. This is the task of the main application. However, it offers hooks to check for USB activity. Since the only USB activity seen may be the frame pulse on DATA–, this data line must be connected to an interrupt. The easiest way to do this is to use DATA– for USB interrupts (not DATA+ as usual). Then define USB_COUNT_SOF to 1 in usbconfig.h and watch the global variable usbSofCount in your main loop. If it stops incrementing, you should put the device into suspend mode and wait for activity on the USB.

An example for this type of suspend mode implementation can be found in USB2LPT. This example uses the watchdog as timer to detect missing SOFs = USB standby. For USB wakeup detecting (SE0 = both DATA lines low for some 10 ms), the example uses either the watchdog for ATmega8 too, or the asynchronous pin-change interrupt available for the ATmega48. Both methods have advantages and disadvantages, especially in 5 V designs.

Using DATA– as main interrupt (INT0 or INT1) is the usual approach. An example for this method can be found in the Datenhandschuh project.

Also, is the NKRO issue something to do with the type of device the OS is seeing? E.g. a USB mouse by default won't wake up Windows, something like this happens for the keyboard seen as multiple devices? (reference: http://support.microsoft.com/kb/280108 ) In Windows, perhaps "Allow this device to wake the system from standby" option is disabled? (can't test now)

EDIT: Well, Win 64 sees both my QFR keyboard and the FaceU as generic "HID keyboard device" but the QFR has an additional "Power Management" tab with the option "Allow this device to wake the computer" (checked). As this page is missing for the FaceU driver, i take it power sleep/suspend/'wake' handling is not implemented ?