Next GH-brewed KB design - 'The Light' (open for discussion)

[Soarer]

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?

Well, there's one other thing that using the timer interrupt does. It ensures that the column strobe lasts for exactly some multiple of the PWM frequency. There would be another amount of error if it was, say, 15.5 times instead of 16.

It really doesn't make the code much more complicated at all to use an interrupt - the main change is that the 'for(col=0; col
One interrupt, from the timer, would do what I listed above. Each column of keys would get stored in some buffer, and then there would be some extra code to handle the end of the scan, which would process the whole buffer in some way (debounce etc).

The _delay_ms(5) (in the Phantom code) would have to go in any case - you need the column strobes stretched out in order to light the LEDs. Anyway, that delay is not sufficient for debouncing, it's just making a timebase (at a bit less than 200Hz) for the scanning.

[bpiphany]

Also, I really really feel that the _delay_ms(5) should be replaced with some actual debouncing algorithm in any case.. I was hoping there would be more experienced programmers than me doing better firmwares for the phantom once it is out amongst the masses =) I will probably look into some of my own ideas for debouncing later when I lack other projects..... But that would be to learn myself, about debouncing as well as timer interrupts.

[Soarer]

Heh, I thought you would agree... I said it just to clarify for others :-)

Batch debounce would be the easiest.

You'd have three buffers, each with the key-state of all keys: the latest one from the interrupt scanning, the previous one, and the debounced output.

Each time there's a new 'latest' it gets compared to 'previous'. If there's any change then the debounce counter is reset, and 'latest' is copied to 'previous'. If there is no change the counter is advanced. If the counter gets to the debounce time then the 'previous' buffer is compared to the 'output' buffer causing key events for any differences, and the 'previous' buffer is copied to the 'output' buffer.


edit: The updating of 'previous' from 'latest', and the updating of the counter, could happen per column of keys. That would remove the need for a complete 'latest' buffer. It's just an optimisation though; it's easier to understand the concept as three complete buffers.

[hazeluff]

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.

[Soarer]

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 :-)

[alaricljs]

Anyone here with LUFA experience/knowledge?    edit: oh yeah, and any knowledge of free private code repo's?

[featherodd]

Never heard of LUFA  but looks very interesting..
http://www.fourwalledcubicle.com/LUFA.php

Pretty cool, it has examples combining multiple interfaces, eg "Mass Storage/Keyboard Device"

Bitbucket allows 5 users for private repos with free accounts.

[hazeluff]

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'm pretty sure the disaster situation is the LEDs lighting, but not bright enough or inconsistent lighting. The major major fallback is a board with LEDs (how boring...)

[__red__]

You guys are going to hate me for this but I think we're going to have to use either multiple mc or a single propeller in order to get the timings right.

A single threaded process is no longer going to cut it imho.

[Soarer]

I'll hate you for not saying why :-p

[Soarer]

alaricljs, thanks for the PMs, figured I may as well comment on LUFA vs PJRC here...

I haven't used LUFA, so I don't really know how 'heavy' it actually is - a lot of it is built with inline functions etc. so it's surely not as heavy as it looks! I prefer the PJRC level of working, but I have had to add quite a bit to it - suspend, wakeup, non-blocking API to it, etc.

It shouldn't be too hard to move from LUFA to the PJRC keyboard demo code or vice versa, assuming a fairly compatible interface at some level consisting of something like: usbinit(), keyup(), keydown() and getledstate(). (Of course any USB init might first need extracting to a seperate function).

[__red__]

I might try and knock out a test pcb design so we can answer these questions.

I'll post the design to this thread once I have it ready for dispatch to China.

[__red__]

Second pairs of eyes requested...

[ Attachment Invalid Or Does Not Exist ] 52652[/ATTACH]

Going to build a test numpad to help us gauge the bias values required.

[Soarer]

Are you going to add some resistors for current limiting? I thought one in line with each collector of Q6 to Q9 ...

[ Attachment Invalid Or Does Not Exist ] 52655[/ATTACH]

Another thought I just had is that on the full version, a column of 8 LEDs could be lit at once which would be about 160 to 200 mA in total. So it might be worth testing with 8 rows rather than 4 as you've drawn, to see what power supply smoothing capacitors might be required. It would also be a better testbed for the firmware, since it would be able to test all 8 PWM channels - the lack of columns wouldn't really matter, the firmware could just delay to pretend they are there.

[__red__]

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.

Both those options can be done off-board.


Red

[Soarer]

I'd planned on putting the resistive load off JP16.  So, in the prototype GND is actually "GNDish".

Afraid that won't work, for two reasons. First, each LED has slightly different V_f, so using one resistor for mutliple LEDs in parallel doesn't work well (uneven brightness). Second and most important, it will have different numbers of LEDs lit at different times, so a single shared resistor wouldn't be right for each of those different current loads.

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.

Makes sense. The way I'd do it is to put the resistors on the board, but first test the LED brightness in just one position by fitting a couple of wires to go off to a breadboard, figure out the required value, and then fit them not too flush with the PCB so they're easy-ish to swap later. (Plus, you could make the holes a bit larger so they're easy to desolder).

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.

I think the built-in pull-ups on the AVRs are about 10k - so about 0.5mA @ 5V Vcc. Nothing to worry about :-)

The rub is that I'm planning on prototyping with a 3.3V MCU instead of a 5V arduino or the like.

That could make it interesting, since the LED V_f + two voltage drops across the transistors could be about 3.3V!!

The other option of course is to resistify the base, but the gain curve of the NPNs will likely make that impractical.

Hmm, that might need yet more resistors to keep it stable, so maybe not a win anyway :-)

[bpiphany]

Ok, so I don't really know much about transistors.. But the ones to the left controlling the rows would have to be BJTs right? Otherwise the base  will not conduct any current and the column pins will not be able to pull the row pins down.

 I think this is a correct view, correct me otherwise, please? =)
 -BJT bases act as diodes with respect to the emitter
 -FET gates act more like capacitors relative to the source

But if the transistors are BJTs then there will need to be resistors in series with the base connections (no?). Will this screw with pulling down the row pins through the transistors? And to start with, will they be pulled down enough at all when there are 2 "diode" transitions down to ground? I guess voltage levels can be adjusted otherwise to alter what is considered low or high.

Perhaps someone should set up just one set of a switch, diode, LED, and row and column transistors, to see that this works at all...

Many white (and possibly other lighter colors as well) LEDs already drop ~3.3 volts, don't they?

[Soarer]

Hadn't spotted that! But yeah, it is wrong. They would have to be PNP transistors, with a resistor inline with each base.

[The_Ed]

Should this thread be moved since TheProfosist subforum is no longer visible?

[alaricljs]

Huh... that's interesting, any recommendations on where to move to?

[The_Ed]

Keyboards subforum?

[Soarer]

I don't think there's a need for both sets of transistors / FETs...

The AVR can source/sink up to 40mA per pin, but with an overall constraint of 200mA, and constraints on groups of pins of 100mA per group. The PWM outputs are spread across multiple groups, so those constraints aren't a bother, just the 200mA total. So, that's more than enough for 8 LEDs at 20mA each (or just over).

N-channel MOSFETs are cheaper, so it makes sense to use them. That means the diode and LED are reversed compared to earlier schematics, and a pressed key will be read as a 0 instead of a 1.

[ Attachment Invalid Or Does Not Exist ] 53360[/ATTACH]

[litster]

Mods, please move this thread out of TheProfosist forum as it is hidden from the rest of the forum.  You can only access this thread if you have a link to it.

[The_Ed]

I don't think any mods but alaricljs can see it either... I already suggested that it be moved to the Keyboards subforum. Is there someone that should be PM'd to move this thread?

[alaricljs]

When reaper is available I'll have him move it to Keyboards unless you have a better suggestion.  Aside from iMav he's the only one with sufficient privs to do it.

[mkawa]

a second teensy? i thought we had decided on using a dedicated LED driver IC instead? am i confusing projects?

[Soarer]

Second Teensy - no. I reckon that would cause as many problems as it solves!

LED driver probably also no, IMHO. Resistors are fine, and cheap. As are N-channel MOSFETs. Using the driver just seems a more complicated method overall, unless we found one that did absolutely everything for us (but in that case it probably wouldn't integrate nicely with the key scanning).

[mkawa]

so a dedicated LED driver absolutely will do everything for us. and i'm not sure what you mean by "integrate nicely with the key scanning". i thought the idea was to have an independently controllable LED per switch. the schematics i see on this page don't seem to get us there (although i don't remember enough from my kindergarten level analog systems classes to read them precisely enough).

[Soarer]

When and if you find a driver that will do everything, that's great. They do exist, but they're not cheap.

Well... I didn't think I'd have to draw out the whole matrix to get my idea across! The switch, diode and LED would obviously be in every position of the matrix. There would be one resistor per row (8 rows), and one MOSFET per column (however many columns). Total cost for driving components: about $1 :-)

The columns would be scannned, and the LED rows would have PWM applied to them - the 8 channels from a Teensy++ take care of individual levels, with a max brightness for the LEDs of 1/num_cols of their full brightness with an uninterrupted 20mA DC.

[mkawa]

hmm.. i see. so instead of providing constant current you just scan the LED matrix every cycle-ish and the result is a PWM signal to the on LEDs (or pwm to the passive driver fets then constant current to the LEDs via some transistor magic)? and the teensy++ has enough pins and current to independently handle this LED matrix? that does sound quite good, if it will work and the things won't just flicker at us.

the other worry i have is that processing the LED pins will make key handling that much more complicated in the firmware. can the teensy++ mux over this much stuff at once? (ie, will handling key events interrupt the LED scanning?)

someone (i can't remember who) mentioned a nice looking LED MCU that could do constant current to 100+ LEDs in about the size of an AVR in another thread. i remember it had something to do with reviving the dox, but not exactly which thread...

[The_Ed]

Even if everything works, this is what worries me - "1/num_cols of their full brightness" - That could be too dim of a maximum. 22 columns means that the maximum brightness is only 1/22 of it's actual maximum brightness. But regular LEDs aren't very bright to begin with.

[Soarer]

The PWM would get switched to each column in turn. A single LED would see a waveform something like this:

[ Attachment Invalid Or Does Not Exist ] 53476[/ATTACH]

As far as 'regular' LEDs goes... there simply isn't the power available to light them up at 20mA each. Either you run them at reduced current, or muxed like my suggestion - so in any case, you might want to use more efficient LEDs. What is 'regular' anyway? I think the first LEDs were only 1 or 2 mcd, so even modern low brightness types at 30mcd or so would still be brighter muxed than the first ones were on DC! They might be 6 pence or 10 cents each. Ultra high brightness might be 1000 to 5000mcd, and cost maybe 20 pence or 30 cents each at most. I'm not sure they're really needed - even muxed they would certainly be TOO bright at 20mA!!

[mkawa]

just brainstorming: is there a more power efficient micro we could use than whatever the teensy is based on? that would free up a bit more current for LEDs

[The_Ed]

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.

[hazeluff]

Most boards with full LED's tend to have a second cable for more power.

I don't think you can save much by choosing a different MC.

[IvanIvanovich]

Bah, just make it so it needs a laptop brick for power... problem? LOL.
To be serious I hope you electronics guys get these things sorted and move it on to the next phase soonish. Else I might as well just grab a Ducky Dragon.

[mkawa]

if you want a dragon-like board anytime soon i would suggest buying one. design and production will take a while regardless.

[mkawa]

Most boards with full LED's tend to have a second cable for more power.

I don't think you can save much by choosing a different MC.

apparently not http://www.pjrc.com/teensy/low_power.html

it doesn't matter if we have a second cable if we can only drive 200mA max using the AVR.

[Soarer]

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.

Why 1/22? Surely there won't be that many columns, will there?

[mkawa]

ed's just being obtuse. we're not building 160 keys into this pcb afaik

anyway, it still calls for a prototype. soarer: do you have enough parts lying around to test this?

[Soarer]

Not really - I don't trust the mcd rating of the LEDs I've got (ebay cheapies!), and they're 5mm anyway. And can't find my MOSFETs. I could get some more.

How can we quantify what is bright enough? What keycaps does it have to shine through?

Talking of cheap ebay LEDs, these are about 5 pence each, and say they're 20,000mcd - highly unlikely, but should still be plenty bright. The prices I mentioned earlier were from Farnell - not as cheap, but at least you'd know what you were getting.

[bpiphany]

Since you already have transistors at each column, why not add the extra eight for the LEDn as well? This would allow you to use the full 500 USB mA. Say 480mA after the uC gets its share =) That would then be 60mA per LEDn. Brighter then that will not happen without extra power in any case.

Using 8 rows on a regular board is a little bit of a pain when laying out the matrix. 6 is easier to work with, and gives ~21 columns on a full sized board. 8x13 is actually 104 for you ANSI people

[bpiphany]

and say they're 20,000mcd - highly unlikely, but should still be plenty bright.

Aren't candelas a unit where direction comes in as well as actual photon flux? Making the irradiation angle very narrow would give a high value in cd, I think...

Edit: ok no reason to put it as a question. Lumen per steradian http://en.wikipedia.org/wiki/Candela.

[Soarer]

Sure, you could, but...

• one set of MOSFETs (either on rows or columns) would need to be P-channel, and they seem to be relatively expensive, for thru-hole version at least.
• the column MOSFETs would need to be uprated to handle 8 * 60mA = 480mA
• fewer components is nicer
• less current is nicer

Buying better LEDs just seems to me to be a neater way to do it!

[bpiphany]

More current will always mean more light on some end, and that seems to be important to some...

Don't forget about BJT based technology. Cutting components =)

[mkawa]

i don't know that less current is nicer. the design should be flexible enough to scale from just bright enough to see to "blinds you everytime you hit a key". some people like that stuff

[bpiphany]

There are also similar darlington arrays with 7 channels. One 8 channel for the rows, and 7+7 channels for the columns should suffice for most layouts. Or 8x(8+8) if that is required.

[Soarer]

I don't see any PNP arrays! And if I'm reading the datasheet correctly, the voltage drop across them is around 1V.

Less current is always nicer if it acheives the same end result.

Anyway, I ask again:

Quantify what is bright enough - blinding even in bright sunlight?

What keycaps will be used?

[bpiphany]

More current will always achieve more results

Yes, that was way too early.. The arrays can only be used at one end of course. Preferably the rows since they carry more current.

Also, i said something wrong about flux. Flux is the per area unit. The Swedish words threw me off a little.
Flow is flow in Swedish as well. And is the total flow of whatever per time unit.
Flux is called "flow density" and doesn't have a word for itself. And is the flow of whatever through a unit area per unit time.
Candelas is flow through a certain (solid) angle, and is somewhat more related to flow than flux, but on other ways not. A very narrow beamed light source will have more candelas than a source with the same total photon output, but more wide angled.

Quantify what is bright enough - blinding even in bright sunlight?

We will need a large parabola outside that focuses the sunlight and directs it through a optical fiber to the keyboard. Inside the keyboard we will have hundreds of small mirrors controlled by tiny motors...

[Soarer]

Yeah, always worth checking the radiation pattern. Unfortunately, most sold on ebay don't even say what make they are, let alone have any proper data!

Something with a beam as narrow as this would be fine for lettered keycaps though:

[ Attachment Invalid Or Does Not Exist ] 53552[/ATTACH]