The reason as to why I did this is that the SMD LEDs would provide good backlight even if one uses caps that are entirely not intended for backlight purposes.
I was thinking that a design like this would benefit from a special keycap. Something that would allow light pass up from the diode, but diffuse across the whole top of the cap. If only these Cherry caps were translucent instead of just glow-in-the-dark.
(Attachment) 39043[/ATTACH]
Those particular keys look like the ones with paper legends under plastic caps and they just used non-clear caps.
Edit: Name ideas - Lux?
GeeLux?
:rofl:
GeeLux?
:rofl:
I want a backlight phantom with full numpad on right and possible a trackpoint. And lets try to come up with a layout that pleases as many people as possible and one or two other variants to cove 90%+. Also a cheap cost effective but nice looking case for it.
full 104 keys
fits in cheap g80-3000 cases
LEDs - inside the switches
n-key rollover - diodes next to the switches
PCB mount holes - for if no plate is wanted
This should cover all but the tenkeyless crowd right? But then they already have a phantom.
The PCB should have the traces for you to put LEDs inside of the switches.
Yeah, I just looked at a housing now. It is 2 thirds blocked by plastic so the LED would be on top with the wires through the switch. Guess I was thinking of diodes when I said to open it up and put it inside.
There should be no problems at all with routing both the switch and the led matrix, even when diodes and pcb mounted switches are taken into account. Granted, the diodes might need to be smd mounted. Additionally, there's little reason for thick traces (that I know of) which obviously hamper routing severely. Signal traces, which is what the switch matrix uses, can be 8 or even 6/4 mil (depending on fab capability/pricing). Even relatively higher current LED traces don't need to be thick, depending on total length of the trace.
One would want a thick trace if there is a possible need to solder directly to the trace or for high currents, where the required width can be easily calculated. I'd rather have thin traces in this scenario, and if I ever happen to lift a pad while soldering, I'd just run a regular wire to the destination.
Anyway, as far as the layout is concerned, I do have a few ideas to throw around, but I can't find what people use to create the layout examples for visualization purposes..
I'm working on producing a nice looking render of the PCB, but as I mentioned I have an 87key backlit PCB design already completed. With full trace routing for all the parts involved.
I would prefer not to use surface mount components. They are a pain to solder (turns away the soldering-noobies, which I think should be cattered for).
I was worried about the number or traces needed, but perhaps you could do it still.
I mentioned this in another thread previously, but there are PCB shops which will quite happily do SMD assembly for you at very reasonable prices, including component sourcing, and then you just need to solder the through hole stuff yourself. So, I'm not particularly worried about SMD components in that regard, especially if we do the controller onboard.
So if I have this straight these are the new specifications:
full 104 key layout
fits in cheap cases - possibly g80-3000
LEDs - leads go through the switches and solder to the board
n-key rollover - diodes next to the switches - possibly SMD and possibly already installed (that would be awesome)
PCB mount switch holes - for if no plate is wanted
Well the only thing that has been agreed on in general is that it be a backlit KB and that the LEDs be individually controlled. Everything else is being discussed.
I do know that whatever anyone else wants to do I'll be moving forward with an 87 key version that will fit in a Filco case and likely put in the work to make it compatible with the CMStorm cases as well.
So if I have this straight these are the new specifications:
full 104 key layout
fits in cheap cases - possibly g80-3000
LEDs - leads go through the switches and solder to the board
n-key rollover - diodes next to the switches - possibly SMD and possibly already installed (that would be awesome)
PCB mount switch holes - for if no plate is wanted
Why would everybody want to pay for the circuitry to INDIVIDUALLY control the LEDs? The Phantom was tenkeyless, I need my tenkey. This should be the first full 104 customizable keyboard. And I will never buy a filco or CMStorm. The g80-3000 cases are cheap, nice to look at, and have a LOT of extra room inside for the extra circuitry to fit.
Yeah sounds pretty much like what I want. Not sure about fitting in cheap cases if we have some LED drivers (not sure how much extra needed for the LED control circuit). But yeah, sounds about right.
I think it would be cool, but I don't really want to pay for that.
My personal wish list...
PCB mount, I don't want to have to deal with a plate.
Layout similar to the Apple IIgs keyboard. Or essentially a Poker with a tenkey. Board designed in such a way I can just mount it straight onto acrylic, sort of like the Neo Zelia.
For LED I would like the ability to use RGB led, so I can change color on any key or groups.
I doubt many people would also want this, but there is my 2 cents.
My personal wish list...
PCB mount, I don't want to have to deal with a plate.
Layout similar to the Apple IIgs keyboard. Or essentially a Poker with a tenkey. Board designed in such a way I can just mount it straight onto acrylic, sort of like the Neo Zelia.
For LED I would like the ability to use RGB led, so I can change color on any key or groups.
I doubt many people would also want this, but there is my 2 cents.
Theres a better way of doign it. Have you seen LED CUBE mod?
http://www.youtube.com/watch?v=6mXM-oGggrM
For 8 x 8 x 8 = 512 LEDs. It is controlled with 64 + 8 = 72 Leads.
What it does is it abuses human perception by lighting them one by one really fast.
So given that we form the matrix on the PCB we only need like 'row + col' number of lines.
Having nothing on the bottom of the PCB will let you mount it easily on/in acrylic. My design has nothing on the bottom, all components are top-mount. RGB LED is impossible since they don't make 3mm RGBs.
That is the method that my design uses.
RGB are all 4 pin leds and wouldn't work in MX switch anyway. I wasn't really thinking about it... lol. So I suppose some sort of tricks would have to be used. Or be forced to place the led outside the switch which would be somewhat stupid.
What about RGB LEDs and a micro controller allowing each key's colour to be customised?
Sent from my iPad 2 using Tapatalk
looks like teensy 2.0 only has 5 PWM pins (? correct me if I'm wrong). Is there are a better choice (anything feasible) for this purpose?
My personal wish list...
PCB mount, I don't want to have to deal with a plate.
Layout similar to the Apple IIgs keyboard. Or essentially a Poker with a tenkey. Board designed in such a way I can just mount it straight onto acrylic, sort of like the Neo Zelia.
For LED I would like the ability to use RGB led, so I can change color on any key or groups.
I doubt many people would also want this, but there is my 2 cents.
I'm not so keen on that layout. I like the classic ones.
Thats pretty much what I was thinking of as well. I really like my Pokers, but the 2nd layer does suck. So tack on a numpad to solve that as you then regain the keys with out making it too much larger. Plus you get a numpad too, which a lot of people can't live without. I see no purpose for the redundant nav cluster at all. F-keys are debatable. If adding f-keys i would just assume stack them right on top of the numeric row like the Choc mini, instead of having a space in between to keep it sleeker.You could then do what they did with the realforce numpad and put some useful keys up there...
I mean I like full 104 layout the most.I like the function row for many things and you can on the fn layer make the 13-24 to have lots of resignable keys
Don't like the Function keys removed. I don't mind it being stacked right above. But didn't someone say they wanted to use like a cheap case. In that case It would be better to use normal full-layout.
Uh yeah, so where are those cheap cases found? Someone had said g80-3000 and I go to ebay and look to see the cheapest is $90. Errr wha?Might as well use a barebones WASD then....
Hey I just thought of another thing to add to a 104 version. MEDIA KEYS! Right above/below the 3 "lock" LEDs. They would be microswitches like in a mouse, and a potentiometer? knob for volume!
g81-3000 cases are the same as g80-3000 cases. And you can get them for cheaper than $20. I know the knobs aren't potentiometers, but I just can't think of what the name for that knob is at the moment. Why would you want less keys on a custom keyboard? The more keys the better, I don't have to constantly push modifiers then.Find a termainal keyboard case for a reasonable price then should fit you perfectly!
g81-3000 cases are the same as g80-3000 cases. And you can get them for cheaper than $20. I know the knobs aren't potentiometers, but I just can't think of what the name for that knob is at the moment. Why would you want less keys on a custom keyboard? The more keys the better, I don't have to constantly push modifiers then.
That is not what I am looking for at all. I would like to plan a keyboard that is close to a default layout so its reasonably close but phases together the home cluster and the number pad and other wasted space to allow more functionality in a smaller space.
I think adding another column onto the home cluster is necessary to get a proper numpad other wise were basically making a backlight Phantom 7bit using my layout as a reference....
It looks like 104 is a no-go on this thread... WHY?!!!...
People always complain about "wasted space"... So does that mean everybody has a 2 foot wide cubicle for their computer at home? It is about time a full 104 custom keyboard was designed! Hey... Here's an idea... How about a separate numpad PCB that you only order if you want a full 104? You just push the plug between the 2 PCBs together!
Wires are fine. And there could also be an optional media key PCB. The space and price issues are why I say the g80/g81 -3000 cases are the best option.
Wait you're thinking of like TKL + one column?. I'm thinking Full layout. @_@
It looks like 104 is a no-go on this thread... WHY?!!!...
So if I have this straight a 104+ will have:
104
+ 5 keys around the arrows
+ 4 more keys above the numpad with the 3 "lock" LEDs directly above those
+ media keys and knob in the center above the F keys
I'd have to cut a lot of extra holes in a -3000 case for those extra keys...
Ah I could use those keys, but what about the volume knob? Where does that go?
A design like this would give you room for EVERYTHING
(Attachment) 39393[/ATTACH]
For people who want 'WEY' to much stuff on their keyboard? amiright?
Sorry, I couldn't resist.
A design like this would give you room for EVERYTHING
(Attachment) 39393[/ATTACH]
For people who want 'WEY' to much stuff on their keyboard? amiright?
Sorry, I couldn't resist.
I have klipsch 2.1 computer speakers and Sennheiser HD 650 headphones that plug into a FiiO E7/E9 DAC/AMP combo. I myself do not need the volume knob, my dad does. And he already owns a griffin powermate because I had suggested that to him. For future computer builds I may need the knob myself too. That is why it would be cool to have it. Plus there are quite a few people that complain about not having the media keys/volume knob on most mechs.
Just put a small knob where 1 of those "extra" key spaces are. And we could have a firmware thing to make the LEDs respond in a spectrograph to music!
Take apart a griffin to figure it out right?
No knob for me please.
Hmm.. I'm kinda tempted to craft this madness (cobbled together in a spreadsheet in a few minutes):
(Attachment) 39405[/ATTACH]
Considering how infrequently I personally use a numpad, I'd rather have a shorter reach of a TKL to the mouse. I still need a numpad however for a few things, so that's why I put it on the left. I also consider full remapping, layers, and macros to be a functional requirement, so the left hand keypad would most of the time serve as a hotkey macro area for games and the like.
I think it might be interesting to have that functionality on the right and left at the same time
tyrannosaurus rex arms? My arms sit comfortably on the armrests of my chair. My left hand is directly on the wads, while my right is directly on my mouse. If I had a tenkeyless there would be a tenkeyless sized gap between my mousepad and keyboard. How in any way is there any less reaching on a tenkeyless?
Don't have to, just need to find what kind of knob it is and how it interfaces with circuitry.
http://hackedgadgets.com/2010/02/01/rotary-encoder-and-shift-registers-explained/:
It spits out grey code for the "position" it is in.
So you'd have to make something in the controller that keeps track of the position and when it changes Inc/Dec the volume. It is possible. You just need to mount it nicely.
Here's mine:
Ghosting can happen without those 2 extra diodes. It looks like your diagram is connecting to only one switch trace, and not connected to the circuit at all. And I have no idea why you are putting a resistor in there. The rotary encoders are 2-bit not 1-bit. They need 2 switches for those 2 bits.
Finally broke a hundred posts! Though if that hacker wasn't around i'd have broken it last week.
http://www.youtube.com/watch?v=uh27ftADFKo
First part shows with LEDs what will be sent to the teensy. Second half should be skipped... The on/off of the LEDs represent the open/closed of the mx switches. 2 bits, 2 switches, and the teensy will send the appropriate volume key code for each full cycle. I have volume up/down labeled because if they are the first to close in the cycle, then that is the direction I will have the volume go. Even though technically it is the combination of the switches that send the appropriate grey code for volume up/down. 2 extra diodes are needed per rotary encoder to prevent ghosting.
I am using diodes and you don't understand me.
You are using resistors and your bits are inverted, whatever that means. And I don't understand you.
As long as they both work everything is fine.
I will only join if it is a 104 or 104+. 129 keys can be put into a g80/g81 -3000 case without changing the spacing. 13 below the F-keys, 3 below scroll lock, 5 above the arrows, 4 above the numpad. And even with all those keys the "lock" LEDs stay the same, and there is an extra inch and a half above everything still for all the controller crap.
Well, if there's a target case then someone needs to provide measurements for the case. All the standoff locations and how the holes in the top frame correlate to those standoffs.
And it does look as though the spacing on the g80-3000 F-row is such that a set of keys would fit between it and the num-row.
fredDarmstadt, Great idea(s), individualy addressable LEDs, a whole 104 keyboards worth. we looked at that in aprox 1999 and didn't do it as it's expensive, and we didn't know any 3rd party software developers who would REALY be interested. but maybe the time has come. In about 4 months, we will introduce a standard 104 key layout KB with the same 50 million cycle keys and the same LED backlighting as we have and the same negative image keycaps we now have. Hey keep those ideas coming. you can E-MAIL me at tech support.
TOM g
You could use the added 13 key row as your F-key row. You are free to program it as you wish. The 129 key layout can be anything you want it to be. If the LED windows were moved on a g80/g81 -3000 case you could fit 133 keys. And if the F-key row spaces were removed you could fit 4 more on that and extra row below, totaling 137. I would rather stay at 129 to not mess with the layout.
I just looked at a picture of a leopold and there wouldn't be able to have the extra 4 above the numpad even. Same for filco. I'm seeing ducky's with 4 keys already there.
Maybe I'm just used to "mod room"... Call me old fashioned... I personally prefer the F-keys farther away, so the extra 13 + 3 would be macros or whatever. I don't want to accidentally quick save/load when I didn't mean it... stuff like that... And it's really only like what 6mm farther right?
If I have to I could take apart one of my g80's and measure and take pictures. Should I, or would I just be wasting my time?...
I did some digging and I got all the way back to 1999 for the idea of an individually controlled LED mechanical keyboard! It was DECK Keyboards! -
I think he was talking about the DECK Legend. Which is why in 2008 a guy made the Legend what it almost was.Show Image(http://geekhack.org/attachment.php?attachmentid=39354&d=1328222438)
Almost all of that will be internalized in the teensy and traces, I hope...
full 104 keys
fits in cheap g80-3000 cases
LEDs - inside the switches
n-key rollover - diodes next to the switches
PCB mount holes - for if no plate is wanted
This should cover all but the tenkeyless crowd right? But then they already have a phantom.
Uh yeah, so where are those cheap cases found? Someone had said g80-3000 and I go to ebay and look to see the cheapest is $90. Errr wha?
Uh yeah, so where are those cheap cases found? Someone had said g80-3000 and I go to ebay and look to see the cheapest is $90. Errr wha?
No 104 key layout is boring. There are so many already in the market!
What about a HHKB clone?
I would not complain about the possibility to have LEDs in the switches.
What about using G81 cases? There are tons of them, once the key caps came off ...
I've probably posted this like 10 times (most are probably still "missing") here already, but g80/g81 -3000 cases are EXACTLY the same. I use the F-keys for games too, but I've gotten used to and prefer the greater distance now. The cherry cases have the most "mod room" and are EXTREMELY cheap, especially if bought in bulk when they show up. If the extra row of 20 switches is put in between the F and number rows, you can use that as your F-row instead. You can program any switch to be any switch. There are virtual key codes for F1-F24, so make the original F-key row F13-F24. A 129 key layout PCB would have the original 104 in the correct positions for the cherry cases. You would simply cut out the plastic and populate whichever extra switch locations you want. I would for sure use at least 9 extra switch locations for the media keys and knobs. And I may cut out and populate others for macros if I feel like it. That is why the 129 is also known as the 104+. It can be used as a regular 104, or up to a 129, thus it is +.
It is hard to carry on this discussion when parts have disappeared at least 3 times that I've noticed.
What part of the F-keys on your board would be closer don't you understand? Your F-keys would be the extra row of keys in the empty space.
Both? Cherry case and rosewill case universal? I would think that the PCB switch mount holes would make this impossible. But if it's possible then our bickering is done!
Remember that with the LED control there is DOUBLE the routing.
FOR SCIENCE!
I LOVE PORTAL!
Preordered huh?
CRAP! I just realized... We also need the mounting holes for PCB mount cherry g99 stabilizers!
I've probably posted this like 10 times (most are probably still "missing") here already, but g80/g81 -3000 cases are EXACTLY the same. I use the F-keys for games too, but I've gotten used to and prefer the greater distance now. The cherry cases have the most "mod room" and are EXTREMELY cheap, especially if bought in bulk when they show up. If the extra row of 20 switches is put in between the F and number rows, you can use that as your F-row instead.
...
It is hard to carry on this discussion when parts have disappeared at least 3 times that I've noticed.
I Don't like that either...Sorry should of been clear.
Maybe we can HAVE BOTH!. I'm a genius, no more argueing. I can't imagine it adding a lot of routing since the switches for what i want and what you want are in parallel and can never both be used at the same time.
The trouble with Deskthority.net is it's filled with foreigners.
This should work. If not turn the switches around 90 degrees and we have the same situation as with the Phantm PCB (function row).
PCB vs Plate mounting: With the switch-opening-cutouts, there should be no argument against platemounting anymore.
Can we please have an extra column of switches on the left?
Why wont it fit filco? And I just realized that we will have to have wires running from the 3 "lock" switches' LEDs to also light up the LEDs in the upper right. They will be in parallel.
"flyovers" == wires or traces? By the way, are we going to be using the Teensy++ w/ Pins? I don't see how there would be enough pins otherwise.
Alternate? There would have to be A LOT of extra diodes to allow that...
DAMNED HACKER! FLIFLA MUST DIE! I don't know anything about BJT/FETs so you can do that. So... were you still going to implement your rotary encoders your way, or my way? Just curious since it would be interesting to see if both ways work, even if you do decide to come over to the diode way...
(= Calm down boys (and girls, what do I know..) Looking for this? I can't swear it'll work out exactly like that, but I have a feeling it should be doable.
If we do, it won't fit most cases. = /
Plate mounting imo is the way to go, specially with the lovely side holes on the phantom ones <3.
Okay! new list for 104+:
104
+ 5 above arrows
+ 4 above numpad
+ Esc through Pause/Break in double positions - in "regular" and cherry G80/G81 -3000 positions
Individually controlled LEDs - fit through holes in mx switches and solder to traces on the PCB
Fits into "regular" and cherry G80/G81 -3000 cases
n-key rollover - diodes next to the switches - possibly SMD and possibly already preinstalled
PCB switch mount holes - for if no plate is wanted
Cherry G99 stabilizer PCB mount holes - for if no plate is used and cherry stabilizers are wanted
7bit - Do you have a pile G81-3000 cases for those who want a cheap case here? I'll probably just buy a cheap G80-3000 for myself to get the case, PCB mount G99 stabilizers, and PCB mount switch bottoms.
Yeah, I'm not too familiar with transistors and stuff but my understanding is; BJT - current controlled current source, FET - voltage controlled current source.
We would of course just be interested in saturating them in any case, controlling the current by other means. I think the Teensy and all(?) microcontrollers are FET based anyhow.
How much output voltage are on those column pins. I'ma go debug and see if at least the LED component of integrated design above works.
I've been doing some work on this "universal" Filco replacement board. My idea is that it should be possible to fit it into both a Filco Tenkeyless case as well as the full size case. Perhaps adding tiny holes as drill guides for the different PCB mount stabilizer options. In my world fitting into a Filco case is still the best idea =) The Teensy++ would be used for a full size and a Teensy for a Tenkeyless. All different switch locations supported of course ;) (no full 7bit yet though...)
Given a sufficient run size (>25 boards) the price differential between doing 2 different PCB designs approaches pennies very quickly.
5V I suppose, don't forget current limiting on the LEDs. I didn't include it in that diagram.
i mwould like to have the option for the 2 F rows to be side by side and allow for 2 extra keys each like the 7bit it was implemented on the phantom to do that and standard should be able to be done on this right?
What are these 2 extra keys? You mean like compressing all the Function keys horizontally?yes compressed horizontally there would be the ability to have 2 more keys that I could put to use but like the phantom would still support the normal spacing as well.
And by the 2 F rows you mean like 2 stacked on top of each other vertically?
yes compressed horizontally there would be the ability to have 2 more keys that I could put to use but like the phantom would still support the normal spacing as well.
Yes 2 function rows stacked vertically there was talk of that when using the cherry case so if their easy enough to mod into the case im in.
KiCAD (http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CC8QFjAA&url=http%3A%2F%2Fkicad.sourceforge.net%2F&ei=nOUxT9H7I4GB0QG0w6WCCA&usg=AFQjCNH0VxUfziBdFHXuNXAiyXhAiJ0JHg)is what Prins and myself have been using.
Biggest reason I use Ki is because Prins made footprints for all the cherry parts available in one of his wiki's and instructions on how to use it. Eagle would obviously do the job, just need to get footprints done.
looks like we could even fit 3 more keys below PrtSc/NumLk/Pause http://tinyurl.com/6f7lowl so we could get 133 max then
Dude, you Arn't ambitous enough we put 8 ontop of numpad!
would love to do that but I think it would run into the LEDs...
KiCAD question:
Just curious how The extra switch positions are done on the Phantom. Is an extra component made and then the components made to overlap on the trace?
looks like we could even fit 3 more keys below PrtSc/NumLk/Pause http://tinyurl.com/6f7lowl so we could get 133 max then
Im thinking of not putting switches there at all. Do we really need them when you could get +12 function keys. That space also happens to be a great place to put the teensy/other mod things like the volumn nob and yeah the lock status LEDs are there too.
Will it really be possible to have mount-positions in 1/2 units steps in both direction (horizontal and vertical)?
LED or switch, whatever is prefered.
For Cherry cases there should be no problem with the controller, but Filcos have no room. That is a problem.
I think it can. doing the kicad files now...so many switches to put in XD
I think it may work, but if all the switches need LED, i don't think we can have all the traces done cos of the number of LED + Switches. I'll try tho.
Indeed, And I want to be able to fit it in the smaller filco board...and even with the two rows of Function keys, it wouldn't fit in a filco anymore...maybe we need to give up the filco case idea?
It is only a bit more than 1/2 a unit. Is the case for the Filco so tight?
BTW: I don't need LEDs in every switch. Just thought it might be useful for some.
A normal keyboard is quite possible to do with 21 columns. 14 for the alpha numeric, 3 for the nav cluster, 4 for the numpad. Only problem is that the number row fits 15 keys. This is easily solvable if no other rows are crammed with a lot of extra keys... The Teensy++ has 46 IO-pins, so using that chip would give more than enough pins to play with.
I do not use any special components for the overlapping switch locations. Simply put several footprints on top of each other. Remove holes that overlap and replace them with slots instead.
Will the alternation between polling and lighting the LEDs make them flicker? Like with an old CRT that has it's refresh rate too low?
If I'm following this right you'd need 21(columns) + 7(switch rows) + 7(LED rows) = 35 pins. And the 3 "lock" LEDs would be put into the top row on the "Num Lock", "/", and "*" columns right? Or am I way off? I'm an IT guy so I'm not an "expert" in circuits.
First discussion point: I can't find an antonym for Phantom, so I was looking at synonyms for light. I couldn't even name my own children if not for my wife, so I'll leave the discussion to you, the interested.
I hope someone does expand to a full 104. I reserve the name "Lux Aeterna" for a full 104 version. The 87 could be "Lux Mortalis".
Looks like this post has come back from the abyss! How can we not be trying? Everyday posts were randomly disappearing... Hopefully that's fixed now, as I can see more and more of my posts reappearing.
Holy crap! Are 1 in 4 posts here really mine? Guess I talk too much...
Umm... Why are there columns named LED row?...
Just make sure you don't make it so I can't put my 2 rotary encoders in the way I had planned. As long as it works, it works. So was this finalized or still under debate?
+ 5 above arrows - OK
+ 8 above numpad - The top extra 4 will be where the 3 "lock" LED windows are... OH!... Even if I don't put switches there I could still put my 3 "lock" LEDs there and control them right?
15 Key Function Row + ESC - Don't Condense! 13 keys here!
+ 15 Key Function Row below the Function row and above Number row - Don't Condense! 13 keys here!
+ 3 Between Home cluster and PrintScr keys. - OK
You are submitting a 137 key version. I would support 8 keys above the numpad if I can use the switches' LED traces for my 3 "lock" LEDs. I do NOT support condensing the dual F-rows to get an extra 4 keys. So I would support a 133 key version as follows:
133 key:
104
+ 5 above arrows
+ 8 above numpad - can use 3 of the top 4 switches' LED traces for the 3 "lock" LEDs
+ 16 in an extra row underneath Esc through Pause/Break that are in cherry G80/G81 -3000 positions
Individually controlled LEDs - fit through holes in mx switches and solder to traces on the PCB
Fits into cherry G80/G81 -3000 cases
n-key rollover - diodes next to the switches - possibly SMD and possibly already preinstalled
PCB switch mount holes - for if no plate is wanted
Cherry G99 stabilizer PCB mount holes - for if no plate is used and cherry stabilizers are wanted
That's good. That means my 129 key layout is inside of your 137 key layout. So... Now I have to find somebody with cherry doubleshot F13-24. I think I've seen white before, but never black sadly...
I will run a GB on the side for Doubleshots with clear legends.Er, wha? Do you know this is possible? I mean, why the hell haven't we seen any if this is possible? I'd be in for 2 sets.
Er, wha? Do you know this is possible? I mean, why the hell haven't we seen any if this is possible? I'd be in for 2 sets.
I've only ever seen UEV used when they did the clear caps in GB 3.
I like my cherry doubleshots so much I was going to just have the ambient glow around the keycaps. That glow that lasts for a split second before fading away efffect for the keys I press. It was in one of those videos. But if a groupbuy for clear legended keycaps with "faux (cycloverid)" cherry legends is done that would be interesting as well. Though that would cost a fortune in legending fees right? I don't like SPs standard font... It isn't... right... But hell if it wasn't that expensive for an SP font version I'd take a set. Crap... I think I need to buy a third set of doubleshots from 99-hk... I'll wait till later I think...
Including the f13-24, media keys, "clear", and a few others I can't think of right now?
Its the same type of plastic as the others. I shoudl be doubleshot-able. I'll go ask Melisa?
Actually I am pretty sure this is wrong. My memory tells me they were unable to double shoot that particular "color".
think i read something like this somewhere too.
also not sure how it would look like doubleshotted since the color of the base cap would still be (partly) behind it. if you look inside a cap you see what i mean :)
Ok, so I started to lay out a board with LED pads in every switch and ran into a couple of "problems".
1. Rotated stabilized keys like ISO enter and keypad + need to have the switch rotated to work with Costar stabilizers. This of course means the LED for that location will also be moved to the side of the key rather than straight down. Cherry stabilizers can have the switches rotated any direction.
2. Some PCB mount holes for Cherry stabilizers overlap alternative layouts switch-LED locations. I don't know how keen the factory is on doing overlapping holes. Probably not at all... Those holes would need to be drilled once the layout is chosen. Stabilizer locations for different "space bars" and around the "enter" area is a complete mess anyways and they cannot be drilled before layout has been decided either.
3. Some LED pads in the space bar row is just interfering silly with each other, but that looks like it can actually be worked out...
4. Are we aiming to have SMD for diodes, controller and everything except the MX switches and LEDS?
All in all though, this seems to end up less a mess than I thought =D
2) In terms of it overlapping other switch-LED locations, its ok as long as we arn't using those LEDs when a layout is picked. If it helps, I think not having the 7Bit mod row is alright. (Tho I can see that some people would want more mod keys; Like japanese layout).
3) Don't know what to make of this. We'll see for this one?
4) SMD for diodes for now. I think we can mount the controller, unless SMD the controller benefits us greatly. But if we SMD the controller, we need to implement the usb mini loader?
2. There is no problem once the layout has been picked. Switch locations overlapped by stabilizer mounting holes can of course not be interesting in that layout...
3. It's going to require a lot of manual tweaking, that is all. reversing the mounting direction of some of the LEDs. Nothing more than an annoyance when they are going to be soldered.
4. If we are having anything SMD mounted, I think we might just as well have as much as possible. This would probably also allow us to place all important components within the alphanumeric section. That would in effect make it possible to cut down the PCB to any size desired. One PCB for Tenkeyless/full size/Poker/whatever. Also leaves more room for switch locations where the Teensy would have had to go otherwise.
But now I am taking a shower and heading off to the pub, see you Monday =) This is going to be one long weekend....
3. It's going to require a lot of manual tweaking, that is all. reversing the mounting direction of some of the LEDs. Nothing more than an annoyance when they are going to be soldered.
4. If we are having anything SMD mounted, I think we might just as well have as much as possible. This would probably also allow us to place all important components within the alphanumeric section. That would in effect make it possible to cut down the PCB to any size desired. One PCB for Tenkeyless/full size/Poker/whatever. Also leaves more room for switch locations where the Teensy would have had to go otherwise.
I created a separate module and schematic component for a switch with an LED. At least on the pcb, it's easier to deal with for movement purposes, since you'll always have the LED holes in a specific location. Also, square pads should indicate anodes. You've probably done both of these things already anyway, so I'm likely being redundant :p
Yeah, the hope here is to implement siberx's design, as otherwise there's a lot of work that would need to be done..
Just as teasers, the stabilizer holes are supposed to be the size of the copper pads. Those holes are .039" = 1mm for easy drill alignment.Show Image(http://i43.tinypic.com/dq6uxx.jpg)Show Image(http://i39.tinypic.com/2h2mn3l.jpg)
Pads will be round, squared and stars... =P And there aren't even any diodes in those pictures yet =D
Pads will be round, squared and stars... =P And there aren't even any diodes in those pictures yet =D
I think that the one potential problem there is overlapping anode and cathode for differing switch positions means pin reassignment in the firmware most likely. It's also a bit of a headache schematic wise, I'd think.
We should be fine if we rotate the switches when that happens?
I don't see how it can't be done. Also transparent/translucent colorless is a plastic that SP has. Its one of the samples.
(Attachment) 39826[/ATTACH]
UEV!
They can, but not in the normal double-shot way. It will be more expensive. I think they did some keys with transparent legends, but don't remember the manufacturer.
I just emailed Mellisa she said it's possible, but they wont do it. Because of all the obstructing.
Eugene-
While it is physically possible to use the material as a first shot, we won't sell keys this way. There is too much plastic under the keycap to interfere with the purpose of using the clear material.
Sorry!
I'll quote it.
Anyway I guess she means the that net like thing underneath that you see on all doubleshots?
But I Reckon the ambiance of the light should still make its way to the other side...
Wait, so entirely transparent keys are fine, but using that material as an infill is not? ¬_¬
Yeah...
Well cos if we do Clear legends on Opaque keys, you'll see that the mesh does kind of get in the way. I think one option may be for Translucent Clears and have WASD lazer engrave/etch them. I mean if we get a good amount of support for it maybe he'll do it. At the moment I can't think of another option.
Well if we get the interest, I may ask her to do a test if possible? I think Opaque legend on clear will look somewhat silly, but Clear legend on opaque keys seems like its possible, even tho the reduced brightness.
Poor black Cherry doubleshot :-(
The light should shine through the transparent (white in the picture) legend, somehow.
.' ' indeed.
Ok, moment of silence is over.
The legends should be where the LED is, like on the new Vortex keyboard which got stuck.
Make this
No, that's a choc mini/race with good size modifiers and not retarded size onesWell its missing like 60 keys from what I want to do ; p
Look at the Deck Legend. All of the legends are on the top half of the keys, directly underneath the LEDs. All switches are oriented upside down with the LEDs on top. And the ENTIRE bottom of the keycaps allows light through, not just a mesh.
Ask Deck who makes their keycaps. And if they make them in-house if they would make custom sets for us.They don't even make sets of their own for sale separately, people have asked. So chances of anyone asking them to make a custom set are slim to none
Ask Deck who makes their keycaps. And if they make them in-house if they would make custom sets for us.
NICE pic!
Must be why I am the Number One Keyboard Expert On The Planet.
Vote here:
http://geekhack.org/poll.php?pollid=309&do=showresults
I know personally that the razer won't last more than a few years. They are just rubber painted onto clearish white keycaps that have had the legends lasered off.
Make thisShow Image(http://www.otd.kr/gn/data/file/album/3697244786_145d02f8_DSC01289.JPG)
The thing I don't like about that 2 piece method is the square seam on the top of the keycaps... But it is still technically the best method for backlit keys right?
Between this and the Razer method, I'd go for the Deck method.
They both don't sound appealing at all :peep:
I edited for a crazier option 3. What do you think about Translucent keycap with dyesub legends?
I dont want to go blind
la S er... not Z. And I already have lasers. The goggles are what's expensive when it comes to lasers. The 2 pairs I own cost $87.60 and $157.94. Better safe than sorry. I wonder how long it will take to pay off school loans when I keep buying all sorts of "toys"... Though if the keyboard could blind an unauthorized user that would be friggin' awesome!
Does anybody even have a machine that can dyesub the entire keycap minus the legend?
And I have lasers to burn things. Because burning things is cool. Uh huh huh... (beavis and butthead)
I swear that close to 2/3 of the posts here must be from us 2...
So then I WOULD need my laser goggles! Too much light would go through the keycaps. And Plus clearish white would look HORRIBLE on a black keyboard!
Try to get SP to do the Deck Legend method.
Seems like it would still give me a headache trying to see the legends through the glow. When I used the razer blackwidow ultimate in the past I had to turn it down low. I don't have enough pigment in the back of my eyes so my pupil expands to the size of my iris in a normally lit room. I can't see in the dark, and outside I'm blinded... And I get those oh so pleasant optical migraines from my dad's side... Oh and I also have glasses because I can't see even 6 inches anymore... I have a headache right now... And this is why I thought that I should still use a standard doubleshot set and just have the ambient glow around the keys... I need to go get some excedrin now...
It was my understanding that the red/yellow Chinese flag cap was done as a yellow PBT keycap dyed red and lasered to get the yellow to show linky (http://geekhack.org/showthread.php?24994-dyesub-104-87-group-round-1&p=478130&viewfull=1#post478130) makes me wonder about white PBT dyed black and lasered... Mmmm PBT
+ 8 above numpad - can use 3 of the top 4 switches' LED traces for the 3 "lock" LEDs
+ 16 in an extra row underneath Esc through Pause/Break that are in cherry G80/G81 -3000 positions
[...]
Fits into cherry G80/G81 -3000 cases
The thing I don't like about that 2 piece method is the square seam on the top of the keycaps... But it is still technically the best method for backlit keys right?
There are features inside the G8x-3000 cases that would make those requirements a bit difficult.
There are both "newer" cases for keyboards with windows keys, and there are older winkeyless cases.
These look almost the same from the outside, but they are somewhat different inside. The winkeyless cases are of higher quality with thicker plastic, so I think that they could be more desirable for this custom keyboard.
What complicates things is that there are poles here and there protruding from the top and/or bottom of the case through the PCB to hold it steady, and most of them are located in-between the function row and the numeric row where the extra row of function keys would go.
These poles are also in somewhat different positions inside newer and older cases, but the winkeyless cases have much fewer of them.
With a newer case, you would also have to cut away plastic for keys above the numpad.
Having an extra row of keys above the function row old would also involve some cutting, but a lot less and you wouldn't have to be tidy. The plastic could be twisted off with a pair of pliers even.
Also:
* It is not possible to add a plate without a lot of cutting, and it is a bit difficult (and noisy and dusty if you use a dremel)
* Winkeyless and winkeyful keyboards have lock LEDs in different positions (but that is a minor issue)
(I know this because I transplanted a Chicony 5181 with plate-mounted Monterey switches into a newer G80-3000 case ... and then I got an older case and did it all over again. I should really post pics of that mod ...)
It's still not the most optimal, judging from my used TG3s. The top coating is basically fading out to the point of letting more of the backlight through, and washing out the legend.
I wonder if the reverse would be more feasible, where the cap is clear with some color of an infill. The LEDs can then be wide angle, for a rather different effect than typical backlit keyboards, but at least forever lasting.
Correct - there will be blockage from the 'Grid' under the keycap - little to no light will come through.
The only way we can do translucent legends is to mold them in a translucent polycarbonate material, paint them with black paint, then engrave to expose the translucent legend. As you might image, this is our most expensive process.
It's not an inability, it's just the FEEL of typing on a PCB compared to a plate. I prefer the feel of PCB, but to do that I need the PCB holes to mount the switches and G99 stabilizers. To use the extra keys there will have to be plastic cut away, this was already known. But even if extra keys aren't used the extra row may call for a few nubs to be removed. I will open one of my keyboards up now to find out. I will post again in a few minutes.
The only way we can do translucent legends is to mold them in a translucent polycarbonate material, paint them with black paint, then engrave to expose the translucent legend. As you might image, this is our most expensive process.
Depending on the amount of paint used, this sounds like the type of method that was used on the keys on my cortrons (http://geekhack.org/showwiki.php?title=Island:13306&viewfull=1&page=1&do=comments#post292001). It is definitely a very durable process, but skimping on the paint turns it into a TG3/Deck keycap :/
The Razer BW are done with this method, The worry is the wear on them.
Yeah, the cortron uses extremely thick coating; I can see and feel the edges of it in the legend, and even the used board does not show any wear on the keycaps at all. I doubt that SP uses the same type of process..
1. RED - Cut off the 3 "barrels"
2. BLUE - Grind down the bits that stick up in the 3 "lock" LED area
3. GREEN - There are 5 screw holes
4. YELLOW - There are 2 stabilizing pins that go through holes in the PCB
Only because we are adding those extra keys. If we were doing ONLY 104 it would fit perfectly WITHOUT modding.
The extra keys underneath F1, F9, Scroll Lock, Pause/Break (possibly, it's really close), and the extra 8 above the numpad would have to go for us to put this into a cherry case WITHOUT modding it.You are saying that those poles stick up into that area between the function row and the number row. And we need to put holes into the PCB or Mod the case. But maybe, we can fit those holes in the PCB? ( I don't know, we are really pushing this towards ease of putting it in the cherry case).
They don't even make sets of their own for sale separately, people have asked. So chances of anyone asking them to make a custom set are slim to noneThey used to sell these blank keycap kits. Maybe they can be convinced to do it again, though you'd still need a process to paint the legends.
The GeekHack servers must hate me right now. I'm taking up all the bandwidth with my pictures. My sister's new camera is awesome. She'll scream at me later when she realizes I took it from her room.
"You are currently using 29.44 MB to store 38 uploaded attachments." - Yeah and it takes FOREVER to upload that much to these slow ass servers...
I told her I used it... I got screamed at... I'm forbidden from using it again... I'll still use it when I want... Rinse and repeat...
Can the Protruding bits be cut off?Yes, and that is quite easy if you have modded plastic cases before, but it might not be for everyone.
What's the reason for not being able to use plates?There are "skirts" down the edges of the key groups. These touch the top of the PCB. To fit a plate in there, you would have to cut away approx. half the height of these skirts. This is tricky and a bit of work to do. The biggest difficulty is getting the height right. If you get that wrong then either it won't fit or the top will be wobbly.
Yes, and that is quite easy if you have modded plastic cases before, but it might not be for everyone.
Winkeyless cases are easier to modify, because they do not have those big-ass "barrels" (as The_Ed called them).
There are "skirts" down the edges of the key groups. These touch the top of the PCB. To fit a plate in there, you would have to cut away approx. half the height of these skirts. This is tricky and a bit of work to do. The biggest difficulty is getting the height right. If you get that wrong then either it won't fit or the top will be wobbly.
Awful picture, but you can see the burrs where I have cut.
(Attachment) 39989[/ATTACH]
Gotta go. I'll post more later.
Those keys shouldnt pass any light as they are colored to be opaque. I have a keycap molded out of PBT natural if you want to test it for backlighting...
Tell her hi.
Send her this link too:GLWIC (http://geekhack.org/showthread.php?24707-Why-Is-The-Ripster-So-Darn-Pissed-At-Signature-Plastic-Key-Group-Buys&p=465725&viewfull=1#post465725).
On second thought, better not.
I hadn't noticed those "skirts" before. Here's a picture of what he's talking about. It looks like it'll take <10 minutes for those who aren't using a plate (like myself). But if you are using a plate it'll take about 30 minutes. I bet some people would rather make their own case than mod one for half an hour to make the plate fit. Why do people even like plates in the first place? What benefits do they bring? I can only think of cons... 1. They detract from the typing experience 2. They make it a pain in the ass to modify switches 3. They make the keyboard friggin' heavy... the list goes on...
So are we just going to use the 2 screw holes on the sides and the 2 stabilizing pins to mount the PCB? This should be enough right?
Have you ever typed on PCB mounted mx? I have typed on both PCB and plate mounted, and I prefer the FEEL of PCB mounted. They both feel different, and unless you've tried both you can't comment on whether or not you like plates in my book.
I tested the rotary encoders I bought and oddly the left and middle pins are pins A and B, while the right pin is the shared Ground pin... From Digi-Key they were $12.60 (after tax and shipped) for 4 of them. They will work quite nicely as my volume and fast forward/rewind knobs. Now all I need is a PCB to wire them to... How long do you think it will take for the PCBs to be completed?
Technically without a custom PCB I would need 2 layers. A mounting layer that's just a blank board that I drill mounting holes in, and a wiring layer that has only circle contacts. That would mean a custom case that's friggin' high too. I won't be doing that much work, so I'll wait for this custom PCB. I just want you to throw out a rough estimate of when you think this custom PCB will be completed.
If an orange LED is yellow through the PBT, then what color will a blue LED be through the PBT?
Dye Sublimated in cycloverid replica cherry font?
Would the letters themselves be what's dyed or everything but the letters? And if it's everything but the letters is that just the top or the top and the sides?
no, we get it. they don't dye the sides of the key anyhow.
do you even know if they're willing to dye their clear/translucent plastic?
it's one of those things where we'd need to see it first.
easiest way to get an impression of what it would look like is to get a set of blanks and get decals cut. we'd need white balanced shots to see how different LEDs react to the plastic. i'm also curious about the margins/boarders that SP could work with, assuming they'd be willing to cover ~95% of the key's top surface in dye. i'm going to guess they'd want a premium for that much ink.
NEVER! Characters can't chip off the key caps or wear down because we use a sublimated negative printing process which drives the ink into the plastic keycaps at 525°F. This means permanent printing from the inside out, not just on the top, and gives the letters a permanent place inside the plastic.
Isn't the legend fee fixed?
Do whatever you can to help get this rolling. As I have no experience making PCBs I can't really do much. Pictures and witty banter are pretty much all I can contribute. By the way, that "keycap flip" is quite clever. When I first saw it a while ago it took me a good 10 seconds of confusion before I saw "it". I'll have to figure out how to accurately measure those 7 holes to see "for sure" which ones can be used, and where "exactly" they would have to be put on the custom PCB. I'm thinking a rigid clear plastic sheet... Now all I have to do is find a big enough piece somewhere... Or is there a better way?
I'm sort of still working on it... I need to read up a lot on the electronics =) I asked for some help on a Swedish electronics forum, and got a lot of good tips.
My design will be a universal Filco (perhaps also Poker) replacement board though. With a lot of extra options and bonus layouts with homemade cases. Like alpha+numpad instead of standard tenkeyless, and the ability to keep only the alpha plus any setup of the rest =)
I think I'm getting a good idea on how to wire everything. There will be shift registers (http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn74hc595&fileType=pdf) to hold all the LED data, 6 rows × 3 per/row × 8 bits/registry, each row will be loaded serially, all rows in parallel, into a the storage registry, then the data is clocked out the outputs. The rows will be cycled by a separate decade counter (http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=CD4017B&fileType=pdf) clocked by a PWM output pin. Keypresses will be read through three buffers (http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=SN74HC541&fileType=pdf), six columns at a time.
Then there needs to be a lot of diodes like always, and a bunch of transistors, some capacitors all over the place and the MCU and all the extra components that it needs to have... I think I am going to stick to the ATmega32u4 like on the Teensy, then at least I know that the HID interface will be working =P The smaller ATmega32u2 would be easier to squeeze in, but I am unsure of how easy or possible it is to make the keyboard code run on it.. I don't know anything about this AVR business... Also I need to figure out how to program the MCU, I have a programmer that I at least think is able to do these MCUs =)
Source (S), through which the majority carriers enter the channel. Conventional current entering the channel at S is designated by IS.
Drain (D), through which the majority carriers leave the channel. Conventional current entering the channel at D is designated by ID. Drain to Source voltage is VDS.
Gate (G), the terminal that modulates the channel conductivity. By applying voltage to G, one can control ID.
Show Image(http://geekhack.org/attachment.php?attachmentid=41183&d=1329744434)
Wait, 6 rows? I thought we were doing a 7 row 133 key board. And how could you possibly route it to work as a fullsize, tenkeyless, and poker?! That's a lot of extra circuitry you're adding too. Wouldn't that drive up the price too much? How is a filco replacement board "universal"?...
So if I have this straight - Those Transister_NPN would be replaced by FETs. C would be Source (S), B would be Gate (G), and E would be Drain (D).
When in polling mode - the FETs on the LED rows would have their gates closed to prevent the LEDs from lighting up during polling. Each column would take it's turn having it's gate open to be polled through the switch rows.
When in LED lighting mode - The FETs on the LED rows would have their gates opened (when polled) to allow the LEDs to light up when they are polled. Each column would take it's turn having it's gate open to light up the LED rows that were polled.
Is this what you're trying to do?
I quite liked the idea of using the polling columns to shift through the LEDs as well, Is the shift registers really necessary?
Also, would it be hard for others to load, since not everyone has a programmer.
I might go head with what I had in mind and design with the teensy as the MCU. I think with the use of some FETs there doesn't need to be shift registers.
Have you documented any measurements for things that I could possibly get off of you? Also maybe components like diodes/resistors designs for the software. That would be handy.
Oh, and I forgot... 21 columns on a full size board, and 21 for the LEDs, and then 7 rows on top of that. That is a lot of I/O without some external logic components.
Edit: Well make that 11 + 11 cols plus 14 rows and that is less of a problem.
(= Calm down boys (and girls, what do I know..) Looking for this? I can't swear it'll work out exactly like that, but I have a feeling it should be doable.Show Image(http://i41.tinypic.com/2d9bfqg.jpg)
The current design is (15 + 3 + 4) 22 Column + 7 Row = 29 pins For the keyboard itself, with 7 more for the LED Rows.
By reusing the same pins of the Column of the keyboard for the LEDs I save a lot of pins.
22 columns?
1. 13
Extra 13
2. 14
3. 14
4. 13
5. 12
6. 8
Largest is 14. 14 + 3 + 4 = 21...
+ 7 * 2 = 35...
Am I missing something?
Yeah, so I haven't slept a lot lately... Of course it should be done that way around, but I think you should consider 11+11+14. That still fits the Teensy++ and lowers the required frequency of cycling the matrix. Now I've got some more work to do, no sleeping yet =P
I just thought of a compromise. 14 keys on the F and extra rows. The 14th would be between Esc and F1. That wouldn't interfere with anything. Sound good?
I'm not seeing it... What layout IS that? Or is it just incompletely populated with switches that are in the wrong places?
First of all, turn off the ratsnest... ;D
Second, keys not fitting on the grid needs to be adjusted "manually". Right click the component and set the coordinates by hand. Make yourself a spreadsheet of all the switch coordinates. It will come in handy, I promise =)
I don't have any footprints for SMD diodes. You want to make them yourself anyhow to make sure they are correct. There are a lot of different ones. Different manufacturers mmay even have different recommendations for pad layouts. Check the datasheet for the exact part you will b using. If you are going to have a manufacturer mount the components you might need to specify "good" solder mask clearances and solder paste patterns as well. I haven't looked into those things.
There's no way that the 9 holes required for every switch won't interfere with each other if there is a 15 switch spacing laid over a 13 switch spacing on the F and extra rows. We would have to have the F and extra rows be either 13 key or 15 key. Unless there is diagram proof that they both fit we should go with the traditional 13.
The PCB switch mounting pins are the most likely holes to interfere with each other, followed by the diode holes. And even if all the holes fit, the traces may not with so little "land".
The PCB mount cherry G99 stabilizer holes are also a concern for interfering.
I have been referencing these 2 PCBs for my spacing concerns. How sure are you that EVERYTHING will fit?
Prin do you have SMD component for diodes (schematics)? Also should i change the grid to fit the different mod switches? The settings now don't quite work for the 1.25 mods (or 1.5) I don't know. It doesn't lay out right. I'm currently using your 0.1875" setting for the grid.
The 5 above the arrows is where "play/pause", "next track", "previous track", "stop", and "mute" will go. I need the 4 directly above the numpad for the 2 rotary encoders for "volume up/down", and "fast forward/reverse". Can't you just throw out the 4 above those 4? Is a 1 x 4 key plot too small? If we truly are using cherry or custom cases you could still have all 8 of those and put everything that doesn't fit in that extra 1.5 inches at the top.
The ns only tell how fast signals they can handle. With the processor running at 16MHz the shortest possible time for anything is 62ns, and I don't know if it is even possible to turn I/O-pins on for a single clock cycle. In any case that's probably not going to be interesting since there will be a lot to do between I/O-signals.
I am soon going to know this link (http://www.cherrycorp.com/english/switches/key/mx.htm) by heart... The LED pads should be on the same distance from the center. Otherwise there is something wrong with the footprint. There is a little diode symbol on the casing. Getting that orientation is of course prettier, but it doesn't really matter =) The LED fits into the switch any way around. It might be a bit late now but I would recommend integrating the LED pads with the switch footprint.
For this project I am going to use a 4-pin schematics switch symbol with the LEDs included. When I did the Phantom I had separate LED symbols, and separate components. But they were only 3 LEDs =) I also made a MX_LED footprint with the same coordinate origin as the switch to line them up easily.
you'll have to help me out here, since I can't read the original post on kbdmania... but from what Google translate did (or didn't) parse, I don't see any evidence from either the post or that picture that the LEDs are outside of the housing. the positioning of the light would actually suggest that the standard LED pass through in the housing was used.
and for what it's worth, the give-away for me is the capslock key. if you're designing lighting independent from the switch, I don't see why anyone would choose to offset the light on the capslock key.
Just did my first try at soldering an ATmega controller. It didn't come out excessively bad at all =D Simple $50 40W soldering iron, a lot of flux, and lead free solder. I haven't tested it yet but I don't think I managed to break it... I had to do some cleaning up after the first side of legs. After that I nailed the right amount of solder to cover all pads in one go.
Hey, better than what my first attempt at hand soldering SMDs. You can clean the residue with denatured alcohol and a lot of paper (which will get shredded on the TH parts) if you want.toothbrush and drug store isopropyl works fine and doesn't leave bits of paper everywhere.
Prototyping a controller? :D
toothbrush and drug store isopropyl works fine and doesn't leave bits of paper everywhere.
Kester “44”®
Rosin “44”®
is a high activity RA core flux designed for
excellent instant wetting action, even on Nickel surfaces.
Although “44”®
is a RA-based material, the residues are
non-corrosive if not cleaned. Per J-STD-004, “44”®
is
classified as ROM1 flux.
Product Description
Kester 44 Rosin Flux is an activated rosin formula
for use in flux-cored solder wire. Kester 44 Rosin
Flux has virtually dominated the field of activated
rosin core solders for well over four decades. An
outstanding performance feature of this flux is the
"instant-action" wetting behavior. The high mobility
and fast-spreading action of this flux results in
more reliable production line soldering.
Performance Characteristics:
• High activity RA formulation
• Excellent solderability to a wide variety of
metallizations
• Industry standard RA cored wire for decades
• Classified as ROM1 per J-STD-004
Cleaning:
Kester 44 possesses excellent fluxing ability, the flux residue is non-corrosive and non-conductive under normal
conditions of use. When exposed to an elevated temperature and humidity environment (38°C, 94% RH) for
72 hours, there is no evidence of corrosion caused by the flux residue. Throughout its many years of wide
usage, 44 Rosin Flux has produced many billions of soldered connections. In all these billions of solder
joints, involving the most delicate and critical of electrical and electronic components, there has never been
an authentic instance of corrosion by the flux residue under normal conditions of use. This mild property of
the residue permits leaving the flux on the assembly for many applications.
That's exactly what I've got (except a whole liter) and yes, it's ugly if you don't clean it off. I'm working on methods to apply less. The 'bottle syringe' I've got lets way too much out at one time.
Status update? I bought a set of vintage doubleshot F13-F24 from Tarkoon. And yes I know beige/grey clashes with black. I just couldn't find them in black.
i actually think it's not a bad idea to let this sit for a bit until we have some experience getting a lot of phantoms built. we're going to learn a lot with this first wave, and realistically even if we finished the design tomorrow it would be summer before we got product anyway.
◦ Numpad, navblock, and function row can be cut off, leaving a fully functional board.Yeah, but you can't move a section to the left side. ;)
There might be room on the PCB for the extra switch holes on most locations. It gets really messy where there are many (partially) overlapping switch locations.A few weeks ago I sketched this in Inkscape (with only approximate hole dimensions). Yes, really messy... and you can't have LEDs because LEDs would require all switches to be oriented one way.
And wireless ANYTHING sucks. Laggy, unresponsive, or the batteries are dead... Wired just works. You don't "fix" what works.
I'm a little cranky from lack of sleep...
Edit: You could mod yours to be wireless, but everything I've had that's been wireless has never "worked".
A few weeks ago I sketched this in Inkscape (with only approximate hole dimensions). Yes, really messy... and you can't have LEDs because LEDs would require all switches to be oriented one way.
(Attachment) 45632[/ATTACH]
If PrinsValium turns the switches like you did he could fit all of the PCB mount switch holes right? Pilot holes for the PCB mount stabilizer holes would be a compromise I could live with. Just as long as plateless is fully supported I'm good. I'd buy a few PCBs so I can try different things too.
With the 7bit layout support built into the PCB design, I don't think it is possible to have fully supported plateless design because of vast amount of overlapping switch locations. My request to have the tiny holes to support PCB-mount switches is only for when you want to use PCB-mount Cherry switches in a plate-mounted configuration (e.g. easier to acquire, harvest from old boards).
the whole point of this board is LEDs. we can't turn the switches, and even if we could, i think the vast majority prefer plate mounting at this point.
if you want to cheap out on switches by harvesting old ones, i don't know that a custom PCB is really the way to go -- just harvest a pcb while you're at it...
Typically backlit KBs have the LED above. So if you want compatibility with any available backlit keycaps, it would need to be above.
The Phantom prototype I built has vintage Cherry MX Brown springs and stems. I like it more than any of my Filcos. Also, there will be times that you will only be able to get a hold of PCB-mount Cherry switches, new or vintage. It is not every day you can join a Cherry switch group buy to order whatever switch type you want. Tell me, when was the last time you joined a Cherry switch group buy before the Phantom group buy? There are people who joined the Phantom group buy for other parts but didn't order any switches.
I am not advocating to do a PCB-mount design only. Just the flexibility to use PCB-mount switches in a plate-mount design.
Typically backlit KBs have the LED above. So if you want compatibility with any available backlit keycaps, it would need to be above.doesn't the race have them below?
keep in mind that you can't drill out the stabilizer holes if there are traces routed through there :P
Just include the holes.
My question of whether or not cherry off-center spacebars will work on this PCB still hasn't been answered.
PCB mounting pin holes should be included wherever they are not eaten whole by another hole. This will allow people to scrounge from old boards and for me specifically to go plateless. Plus I have too many switches with PCB mounting pins I would like to be able to use. Why should everyone be forced to buy new platemount switches? Just include the holes.
PrinsValium, thanks for the tiny holes! :-)
One question, with SMD, components will be soldered when the PCB is made, I assume. So diodes will be installed to all switch locations, even for the switch locations that are not going to be used, correct? Don't think this is a problem since diodes are cheap and I don't think it would save us money doing it other way. Just checking.
We wouldn't need to remove diodes from the PCB for locations we don't use, right? Just trying to thinking through the steps required to put the keyboard together like the wiki I did for phantom installation.
Wow... Has it really been a whole month of silence?...
REVIVE! EAT THE FLESH FROM OUR FINGERTIPS!
Oh... And it's my 20th birthday today!
...
Has there been any progress on anyone's prototypes?
Thats the main thing I like. But, i'm worried because the time an LED is "ON" is maximum only 1/numCol.
Not a problem if you use bright enough LEDs :-)
I'm thinking if we don't put the limiting resistor/allow for forward biasing above the typical continuous voltage, and by cycling through the columns (The LED would pretty much see a square wave with a small duty cycle), we can get away with bright/normal brightness of the LED, without burning them out.
You'll need some current control, even if it's only a small resistor (per LEDROW).
Also, efficiency tails off when you over-current them; you don't get twice as much light with twice the current.
Nice LEDs are pretty cheap bought by the 100 :-)
This (http://www.mouser.com/ProductDetail/ON-Semiconductor/CAT4016VSR-T2/?qs=3JMERSakebofiwsDkU1n4g%3d%3d) is the chip I had been looking at. An ON 16 channel LED driver: CAT4016VSR-T2. Uses 1 resistor on a pin to set max current, and then you can do PWM externally for individual leds.
This (http://www.mouser.com/ProductDetail/ON-Semiconductor/CAT4016VSR-T2/?qs=3JMERSakebofiwsDkU1n4g%3d%3d) is the chip I had been looking at. An ON 16 channel LED driver: CAT4016VSR-T2. Uses 1 resistor on a pin to set max current, and then you can do PWM externally for individual leds.
Yes, and while I have zilch in code due to lack of time... It's based on a working keyboard design that had full individual led control w/ PWM.
edit: running on an ATMEGA32U2 btw (the working design)
Here's a quick pic of the layout for my LED test board w/ 1 of them acting as sink and source using 6 transistors.
(Attachment) 52144[/ATTACH]
Conceptually, you can ignore the serial input and the latching. Just think of it as being 16 bits sent from the CPU which set the outputs of that chip on/off.
The transistors just invert 6 of the outputs (needed because the 'off' state of an output is high impedance). That makes it work to drive a matrix of LEDs.
To light them all without flicker, the CPU will need to update the chip at about 1kHz or so. To then do some PWM to vary the brightness of each individual LED would need more updates - how many more depends on how many levels of brightness you want (and how many the CPU can manage!).
Yeah, Teensy++ has quite a few channels, but they're split over 3 or 4 timers so would be hard to synchronise. If this scheme worked on a '32U2 though, it would've been doing the PWM in software on an interrupt, I guess.
Likewise, I'm not interested in the sense that I'd want trick lights myself, but I can't resist the odd comment :-)
They would have to do quite a few pulses per column strobe is my guess. But the downside would just be fewer controllable intensity levels if not, or a slightly 'unsteady' look to it.
hazeluff - PWM is all about timing! If the MC has to do it in software it takes a fast running interrupt, which mustn't be held up by anything else. In a controller 'anything else' just means USB handling though, and there are ways around that, to a point.
I'm not sure why it needs an interrupt or why timing is involved. I might be missing something here, But when I was using an Arduino, it is possible to set PWM on output pins very easily, so I don't know what could go wrong...I'm assuming the MC the teensy is using could do the same thing.
Are we getting our wires crossed here? I was talking about individual light levels per LED, but maybe you are talking about a single level for all LEDs? That would indeed be a lot simpler :-)
Neither of those will fit inside the switch.
(Attachment) 52280[/ATTACH]
The system is all controlled by 2 Atmega 168 micro controllers that run arduino. One of them handles all time-keeping and button/alarm events and the other handles displaying the digits on the tubes. Essentially I have one micro-controller as a master that sends short serial messages that tell the second micro-controller of what time it should display on the tubes.
Just for prototyping purposes, would probably have to cut the keycaps in half or something barbaric like that. LPD8806 drivers should optimally be surface mounted to the PCB board in series. They should be able to drive most 5V RGB LEDs (I think).
If you want to destroy one of your own boards for science, be my guest. Ripster, our fellow scientist, was banned so he can't grace us with any more of his wikis here.
No I am talking about different levels of light per LED, not all LEDs...
If we look back at that schematic prins made. We're using the column pin from the switch matrix to also determine which column of LED to choose from. And with the LED Row pins we can apply PWM to set intensity of the LED at (Col,Row).
Tho Im not sure if the teensy has enough pins that can do PWM.
SMT LEDs wont work optimally with a mounting plate, at least not without some solution to transfer the light up to the surface. Are there any T1 RGB LEDs? Modifying the switch housings to accept 4 leads might be feasible. Or drilling a 3 mm hole straight thru and using a light pipe with SMT LEDs.
Well I wasn't sure about whether it gave enough control over the PWM to be able to do it in hardware, but actually I think it might.
Timer 2 could be used to run a timebase for the columns at a few kHz.
Timers 1 and 3 can be set to do 8-bit PWM, and have 3 PWM outputs each. Timer 0 is 8-bit anyway, and has 2 PWM outputs.
So each time the column interrupt fires, the handler would do something like...Since the column updating forms part of the PWM, any jitter in handling it would result in varying light levels. This would have to be minimised.
- disable PWM outputs
- disable column n
- update PWM output compare values
- enable column n+1
- enable PWM outputs
- read keys
The PWM channels should run at some multiple of the column scan frequency. At 16MHz clock and 8 bit resolution they would be running at 62.5kHz. Dividing that by 16 gives roughly 4 kHz, which sounds about right. That would be divided again by the number of columns to get the overall matrix scan frequency, and that wants to be high enough that you don't notice flicker in the LEDs.
for(;;) {
_delay_ms(5); // Debouncing
for(col=0; col*col_port[col] &= ~col_bit[col];
_delay_us(1);
//Turn off PWM (LED ROW) outputs
for(row=0; row//Do w/e setup needed for PWM
//Enable PWM (LED ROW) outputs
key_id = col*NROW+row;
if(!(*row_port[row] & row_bit[row])) {
if(!pressed[key_id])
key_press(key_id);
}
else if(pressed[key_id])
key_release(key_id);
}
*col_port[col] |= col_bit[col];
}
Having an interrupt for the column scanning gives it accurate timing. You need that so each LED is on for (1/num_cols) * (256/pwm_val) * 100 % of the overall scan time. Without it, you might have some other interrupt fire during a column strobe which would make that one take a longer time than the others, and the light level wouldn't be right!
As for the discussion on RGB LEDs, I don't think it's wise to try and implement so many things at once. Also, the extra pins don't fit in the switches without significant modification.
Makes sense now. Maybe it wouldn't affect it too much if we don't do interrupts, unless that difference in timing is significant. Just a speculation.
Also, the keyboard polling and lighting both will be interrupts?
Yeah, then everything seems fine. I think the main concern is the LEDs and if i physically will work. Otherwise the firmware can be changed and played around with.
The disaster situation wouldn't be a total disaster, you just wouldn't be able to vary each LED individually. You'd still need the interrupt to give it stable timing, and therefore stable brightness. But I think it should all work OK :-)
I'd planned on putting the resistive load off JP16. So, in the prototype GND is actually "GNDish".
I'm trying to keep values that I'm going to vary off the test board completely so they're easier to switch in and out without constant re-soldering. Breadboards ftw.
I'm less concerned with the LED current draw and more concerned with the current draw when keys are pressed. Wondering what the resistive element of that is.
The rub is that I'm planning on prototyping with a 3.3V MCU instead of a 5V arduino or the like.
The other option of course is to resistify the base, but the gain curve of the NPNs will likely make that impractical.
Most boards with full LED's tend to have a second cable for more power.apparently not http://www.pjrc.com/teensy/low_power.html
I don't think you can save much by choosing a different MC.
I'm thinking a test would have to be done to see how bright/expensive the LEDs would have to be. A maximum of 20ma for slightly less than 1/22 of a second for maximum brightness. A different LED in each row with only 1 column could test 8 different LEDs at once with very little programming and setup.
and say they're 20,000mcd - highly unlikely, but should still be plenty bright.
Quantify what is bright enough - blinding even in bright sunlight?
My OLIGHT-M21-X has a Cree XM-L with OTF600lm!Heh, not running at maximum!
22 columns =That's not generally how it's done :-)
("Esc" -> F12 + 2 extra) = 15
(Arrows -> numpad) = 7
the question remains: is all this scanning going to need to be done in firmware by the micro? or is there a register it can set every once in a while to control scanning rate and PWM duty cycle? i'm too lazy to read datasheets XD
Well I wasn't sure about whether it gave enough control over the PWM to be able to do it in hardware, but actually I think it might.
Timer 2 could be used to run a timebase for the columns at a few kHz.
Timers 1 and 3 can be set to do 8-bit PWM, and have 3 PWM outputs each. Timer 0 is 8-bit anyway, and has 2 PWM outputs.
So each time the column interrupt fires, the handler would do something like...
- disable PWM outputs
- disable column n
- update PWM output compare values
- enable column n+1
- enable PWM outputs
- read keys
Since the column updating forms part of the PWM, any jitter in handling it would result in varying light levels. This would have to be minimised.
The PWM channels should run at some multiple of the column scan frequency. At 16MHz clock and 8 bit resolution they would be running at 62.5kHz. Dividing that by 16 gives roughly 4 kHz, which sounds about right. That would be divided again by the number of columns to get the overall matrix scan frequency, and that wants to be high enough that you don't notice flicker in the LEDs.
I meant more mkawa with his abstract talk of cores, threads and message passing. But heh!
OOooooh… :(
I was so happy about your compliment !
The problem I'm gonna have is how to inject code for the rotary encoders I'll be putting into mine. I can't even begin to code it without the rest of the coding finished and debugged. Or I'd have to write everything from scratch. But the electrical layout will have to be finalized before any coding whatsoever can begin.
Timer 2 could be used to run a timebase for the columns at a few kHz.
Timers 1 and 3 can be set to do 8-bit PWM, and have 3 PWM outputs each. Timer 0 is 8-bit anyway, and has 2 PWM outputs.
I can code C++ and would be able to use 12 (10 but 12 is easier) variables to make them into "keys" for the regular scanning.
Can I Helps into coding light effects please ? :D
X X X X
X X X X
X X
X X
X X
X X
X X
X X
Knock yourself out!
First, how are the display buffers going to work? For output we obviously need one that's the LED matrix. For drawing into we probably want a buffer based on the physical layout - which maybe has extra rows/cols in it, e.g. between number and function rows, that don't get copied to the output.
Alas, I have almost no knowledge in µcontrollers or electronics, and can't really follow what you are talking about.
Could you link me to some more information on this project (maybe the existing code), and/or some documentation?
So it will either process at the end of scanning and slightly delay/shorten the PWM cycle, or process during the PWM cycle if that's possible. It would be ideal to process it during the PWM cycle.
Can it process the PWM cycle and rotary encoder code at the same time?
Damn trolls!hah! that's the problem with you embedded types; can't see the forest for the trees! :)
Hmm, there isn't exactly much existing code yet!
By buffer I just mean a 2D array for storing the brightness for each LED, and double-buffered so that you can draw into one while the interrupt is reading from the other.
What I was thinking though, is that the drawing buffer could have more pixels in it than we have LEDs - perhaps a full 7x21 grid. That would make certain effects easier to implement, and more, well, effective :-)
Also, how about having multiple LEDs under the spacebar, to make it more of a grid there? No reason we can't have some LEDs that don't have switches.
These high-level things need thinking of as well as the low-level stuff!
Couldn't you process the encoders' signals on interrupts? You could have one for each signal wire. Your interrupt might be delayed a little if the scanning interrupt fires just before you get an input, but it shouldn't be by too much, and wouldn't happen often. The reverse, where your interrupt fires just before the scanning interrupt, could disrupt the LED brightness, but if you code your interrupt to be quick that should be ok too - I reckon you could code it very cleanly that way, since in each interrupt handler you already know which signal has changed.
Having a real actual grid to work with while programming would be awesome !
Just think of the interrupt as doing a lot of the work for you - if you poll you have to figure out whether any signal has changed, but the interrupt tells you that straight off.
With a rotary encoder you don't have to wait for a set of 4 input changes - each single change can be one step, because it's possible to determine which direction it's going in based on the state of the unchanged signal.
24ppr with only 2-bits would be an insane 96 inputs per rotation and you could only input a multiple of 4. Rotary encoders have physical "bumps" for every ppr. I consider one "bump" as one input. Which means that even though I can tell direction from 2-bits, I still have to use 8-bits for one input.
Remembering about the bumps means I have to rethink the code slightly. I think I know how I'll do it. Positives and negatives from the 2-bits. When 4 is reached in either direction it inputs. But only when it's between "bumps".
I'm down to 16 variables and the inputs will exactly line up with the "bumps".
The polling frequency of 1000hz for the rotary encoders lines up exactly with the polling frequency of the switches. Why would I use an interrupt instead of the polling that's already happening? That seems like a waste of processing.
So 15 seconds for half a turn of the knob???!!!
I haven't been keeping up with this and it seems a lots gone through, anyone mind recapping it to save me the pain of reading through the recent stuff?
I haven't been keeping up with this and it seems a lots gone through, anyone mind recapping it to save me the pain of reading through the recent stuff?
PrinsValium and litster got married and are on honeymoon.
djuzah, mkawa and the_ed have huddled into an irritation of trolls.
The prototype is still absent.
There was a run on suncream at the store because of rumours of 100,000 lumen keyboards.
The network has confirmed a second series, so the first won't have any real ending...
Any chance on the clock being 32kHz? That would raise the actual poll rate high enough.
PrinsValium and litster got married and are on honeymoon.
djuzah, mkawa and the_ed have huddled into an irritation of trolls.
The prototype is still absent.
There was a run on suncream at the store because of rumours of 100,000 lumen keyboards.
The network has confirmed a second series, so the first won't have any real ending...
Wow, it's scary how close to reality those are... Cree XM-L FTW!
The aluminum cases act as the heatsinks!
:rofl:
Funny only because it's truth.
I was scanning the posts and then I saw my name next to "married"! BTW, I am going to meet BiNiaRiS this weekend for our secret rendezvous. Please don't tell Prins!don't be silly litster, you're happily married to ping!
I was scanning the posts and then I saw my name next to "married"! BTW, I am going to meet BiNiaRiS this weekend for our secret rendezvous. Please don't tell Prins!Oh no! Now he's having an affair with BiNi?!?!
Oh no! Now he's having an affair with BiNi?!?!there are no cherries involved here. bini's cherry(ies?) was stolen long ago
What sort of nasty Cherry vintage board swapping is going on here!
that person should naturally not be the_ed because i never have any idea what he's talking about. (rotary encoder? wth?)
That means I'll either have to lessen the debouncing time or have less than 2 RPS. Is 16kHz very likely?
Mr. Ed is the Ed!Show Image(http://www.tvcrazy.net/image/data/media/34/mister%20ed%20glasses.jpg)
During the switch transitions noise is generated, typically lasting from 1 to 5 milliseconds; the switch is “bouncing”.
edit (sorry): We can easily keep a few pins aside for you, which can trigger interrupts (if you want). But messing with the timing stuff isn't going to happen - you'll just have to see if it works for you once it's done, I'm afraid.
he said he still has some minitouches though!
The system is all controlled by 2 Atmega 168 micro controllers that run arduino. One of them handles all time-keeping and button/alarm events and the other handles displaying the digits on the tubes. Essentially I have one micro-controller as a master that sends short serial messages that tell the second micro-controller of what time it should display on the tubes.
I've known this since the beginning. And who knows, it may only work if I rewrite the code. I may end up with a regular backlit board with fully functioning rotary encoders, or I may get lucky and get them fully functioning with individual LED control still working. Everyone can customize them any way they want.
mkawa, STFU about 2 CPUs! -look at my edit! look at my edit! i even googled!!
look at my edit! look at my edit! i even googled!!
not only that but it just occurred to me that it shouldn't be too hard to export the keyboard's "frame buffer" as a device on the host controller anyway. YOU WILL GET YOUR WAVE THING EVEN IF I HAVE TO HACK FOR SEVERAL HOURS, SIR SOARER
Sod's law - "bad fortune will be tailored to the individual", "anything that can go wrong, will", and "Toast will always land butter side down"...Yup :-)
Since it's firmware I can't just recompile and check for errors. I have to flash it and use it, then make tweaks, flash it again, rinse and repeat.
And you said I was confusing YOU with rotary encoders... Yeah, go get your "WAVE THING", and take your sweet time.this is clearly a rathole, but to elaborate for a second. here's the firmware model i have in my head:
How did you become a moderator anyway? I've always been curious.
foreach tick:
update fbuf;
scan the LED matrix, updating the PWM registers with the contents of fbuf
poll the keyswitch matrix
dump active keys onto usb bus
foreach tick:
scan the LED matrix, updating the PWM registers with the contents of fbuf
poll the keyswitch matrix
dump active keys onto usb bus
ISR(tick) {
// update column strobe and pwm for column
// read column of keys
// put any new key events for the column into a queue
if ( ++column == num_columns ) {
// process event queue and send to usb
// if frame buffer is ready, copy it to output buffer
}
}
It's an interrupt firing off a timer, set to trigger at a few kHz, some multiple of the PWM frequency.got it, thanks!
(In fact we could run it off one of the PWM interrupts, if we counted to the multiple before running it. It's easier to code using a separate timer though, I think).
Damn it, you've been busy. We've celebrated midsummer here. I didn't read it all, particularly not the parts about marriage. The ErgoDox project is doing some serial IO communication. That is only to an expander though. I don't know if it is any harder doing it with another processor.
[strike]a-ha! so is there is a shared register you can sandwich between them and not have to do this complex bus business. that said, this SPI thing looks like it's subject to write endurance, and not really meant for high traffic.[/strike] (google-fu fail) anyway, it does sound to me like soarer's reasoning is sound in that we don't need another micro. the only thing we might need is a bit more current, but i'm sure there's some way to do this without changing micros
It's always better to go overkill than underkill. Go overkill with the LED controller.
As to where to put everything - A separate daughter board with headers will plug into the back. It will contain all of the controlling circuitry. A slightly taller case will be required, but it would be the easiest solution.
PrinsValium and litster got married and are on honeymoon.
djuzah, mkawa and the_ed have huddled into an irritation of trolls.
The prototype is still absent.
There was a run on suncream at the store because of rumours of 100,000 lumen keyboards.
The network has confirmed a second series, so the first won't have any real ending...
Why does everybody keep saying Djuzah? :(
I think somebody needs to prototype the led thing, maybe hack something quick with arduino, to know if the current you intend to send is enough.
We can't just assume, and wait for the first prototype to realize it's not enough/ it's enough :p.
All of the asuming I'm seeing is from those who a) say it won't be bright enough without a driver, b) want someone _else_ to build prototypes, and c) don't have thought-out suggestions, just spanners to throw in.
I know from experience that getting an ultra bright LED to just glow nicely, rather than blindingly, takes a huge reduction in current and/or duty cycle. The LEDs on my teensied breadboard are using 10k resistors - which works out at only 0.25mA!! Also, doubling the current from say 20mA to 40mA won't give a subjective doubling of brightness.
All of the asuming I'm seeing is from those who a) say it won't be bright enough without a driver, b) want someone _else_ to build prototypes, and c) don't have thought-out suggestions, just spanners to throw in.
I know from experience that getting an ultra bright LED to just glow nicely, rather than blindingly, takes a huge reduction in current and/or duty cycle. The LEDs on my teensied breadboard are using 10k resistors - which works out at only 0.25mA!! Also, doubling the current from say 20mA to 40mA won't give a subjective doubling of brightness.
i just want to say that design brainstorming is far from throwing a spanner in. naturally it all comes down to prototyping prototyping and prototyping, but it's good to have some ideas or optimizations in mind in case we find that first prototypes are deficient in some dimension.
as for brightness, i have no idea how much current we'll need, just that we may need to increase current handling capability. remember, there's going to be a keycap on top of the LED...
Hm, you are suggesting ultra bright leds, how much more do those cost against regular leds? because we need 100 of them for each board :o.
Why don't you go and look!!!!
You seemed to have a pretty good idea about what you exactly want.
Sure, I have an idea of what WE'd want, but I haven't shopped around. Maybe $10 on the 100, at a wild guess.
You do realize that 'regular' LEDs are orders of magnitude less bright, and the driver will only increase current by 2 or 3 times, right?
If there are locations for extra transistors and perhaps serial resistors for them, the resistor pads can be shorted, and the base/gate of the transistor can be shorted to the output. This allows for transistors for those who want them, or driving directly from the uC. The transistors need to be placed somewhere though, but there should be plenty of room.. =)
The only problem is that the transistors invert the signal, so the code would have to know to invert the PWM values... should have plenty of pins spare for an input from a jumper though :-)i'm personally fine with having multiple loadable versions of the firmware or some flags in the config and build scripts
The only thing i want to correct is that transisters dont nessesarily invert signals. It depends on how its setup.
I didn't say they always inverted ;-)
But in this application, we want a switching mode, so that imposes a few restrictions, doesn't it?
Ummm The problem is we need two, one for column and one for row. And it's quite impractical to make them both work of active high signals. one of them is going to be inverted.
Morning me raging at stuff i skimmed over. = )
Definitely crossed wires here!
N-channel FET would be used to connect the row or column to ground when it's input is high - an inversion.
P-channel FET would be used to connect the row or column to supply when it's input is low - an inversion.
If we take out the P-channel FETs, we'd need to drive the row or column active high instead :-)
In terms of voltages you are right...I was thinking in current.
nFET conducts when gate is high. But pFET will conduct when gate is low. (Based on some diagrams a bit back).
Okey doke, so I have 3x AS1130's on the way and I'm laying out a breakout... who's got the software skills and wants to tackle this?i can't program the thing unless i have a sample (can't simulate). soarer's the more capable though. maybe get a couple protoboards wires up and send one to him?
high impedance. It's that third state that makes it possible to cross the streams as it were.can you explain in terms appropriate for a dumb programmer?
ooooh, so input pins can be effectively read as don't cares?
The controller in my avi is an AS1130 from austria microsystems. It uses a 12x11 matrix to control 132 LEDs and you control it via I2C. It has 8bit PWM on every LED and a bunch of other neat features.
Yes, that is a channel count I was trying to avoid.
Yeah, but it would also allow you to tell the firmware to sink all it wants in the case of crazy USB2 mobos like Gigabyte and their 1.5+ Amp USB2 ports.[9:14:59 PM] mkawa: http://www.usb.org/developers/devclass_docs/BCv1.2_011912.zip
It's not 12 pins, my breakout is only using a subset in order for me to learn it. It's 23 pins for the LED matrix.
Yes, that is a channel count I was trying to avoid.
12 pins to control up to 132 LEDs, and 2 pins for I2C comms is too much?
Isn't that a small miracle of efficient pin usage?
2) yes that austrian MCU is incredibly pin-efficient. it's quite pissy that MOQ is so high on it from the manufacturer, and it's not available via the usual sources (yet?)
How do the Korean boards do it? I've not looked at an A.87 or similar.
same answer as alaric. what other MCU has that many PWM channels? there are more LED controllers these days though, and this chip may have wider distribution now. the last time we looked at this was like 6 months ago.2) yes that austrian MCU is incredibly pin-efficient. it's quite pissy that MOQ is so high on it from the manufacturer, and it's not available via the usual sources (yet?)
If sourcing the AS1130 is going to be an issue, why not just drop in a second general purpose MCU to do LED driving?
Aha, gotcha.How do the Korean boards do it? I've not looked at an A.87 or similar.
Less control. They can't do the reactive or single LED control.