the flash thing is for convenience but you don't need it.
Posted: 18 Sep 2014, 07:28
by 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.
Posted: 18 Sep 2014, 10:30
by 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)
Posted: 18 Sep 2014, 10:33
by 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.
The hardware instead is barely acceptable, anyway at the end you can have it working, so I guess it's ok.
Posted: 18 Sep 2014, 14:15
by Laser
matt3o wrote: 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.
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)
Posted: 18 Sep 2014, 14:45
by 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.
Posted: 18 Sep 2014, 15:24
by 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 .
Posted: 18 Sep 2014, 18:14
by 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…
Posted: 18 Sep 2014, 18:49
by matt3o
I must say... I love my new keyboard...
Posted: 18 Sep 2014, 18:55
by 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…
Posted: 18 Sep 2014, 19:04
by 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
Posted: 18 Sep 2014, 19:09
by chzel
MrMen wrote: About HHKB style, does anyone have a tip to fill hole created by the missing keys (on the bottom row).
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:
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
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!
Posted: 18 Sep 2014, 19:26
by 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.
Posted: 18 Sep 2014, 19:48
by DanielT
matt3o wrote: 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.
Posted: 18 Sep 2014, 20:09
by matt3o
I found out that NKRO works only on PS2 anyway
Posted: 18 Sep 2014, 20:16
by MrMen
Thank you for these answers ^^ now I think I will solder a bit more.
Posted: 18 Sep 2014, 22:54
by DanielT
Now I wonder, which is the non NKRO firmware? Is it the keymain_GKP.hex ? The keymain_NKRO.hex is the default one.
Posted: 18 Sep 2014, 23:52
by 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 4623 times
Posted: 19 Sep 2014, 00:08
by matt3o
DanielT wrote: 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.
Posted: 19 Sep 2014, 08:43
by 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
Posted: 19 Sep 2014, 09:42
by 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
Posted: 19 Sep 2014, 11:01
by 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
Posted: 19 Sep 2014, 11:05
by Laser
matt3o wrote: 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?
Posted: 19 Sep 2014, 11:14
by 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.
Posted: 19 Sep 2014, 11:17
by 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)
Posted: 19 Sep 2014, 11:58
by 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
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 ?
The hardware is OK'sh for some is fine for others has some QC issues.
