SteelSeries 7G wireless mod

[kile]

I have had the good ol' SteelSeries 6G (v1) since it was released in late 2006 (it was called SteelKeys 6G back then) and I bought another one in mid 2007. Unlike almost everybody else, I really love the big-ass enter and the short backspace and that layout was the main reason I bought them in the first place. I didn't know much about mechanical switches, and it took some time to get used to them, but now I really love it. So a few weeks ago I treated myself to a brand new 7G. That huge wrist rest is really nice.

And now I want to build a wireless controller for the 7G There are a few practical reasons, but mostly I just want to have some fun and learn a few things along the way.

Of course, if I want to build this I will have to sacrifice the audio jacks and the USB hub, but I don't use those anyway. I think the hub is USB 1.1 full speed (although I am not 100% sure about that) which means that it's too slow for pen drives. So, all in all not much of a loss, really.

The main reason I want to do this is the dreaded SteelSeries function key. I've used that key for Win-E and Win-D combinations since the late 90's and I don't intend to change that habit soon. I don't use the right Win key at all, so a swap would be perfect. I guess I could just cut some PCB traces and do a little rewiring to achieve the same goal, but that would be irreversible and ugly and certainly not as much fun.

Another reason is experimenting with ultra low power circuits. I've built a few AVR based thingies in the past, but low power was never an issue with these. I want to make the controller and transmitter last as long as possible on a pair of AAs. The batteries will be inside the case, and replacing them will require opening it, and that's a problem if it has to be done often. So getting as much power as possible out of them is the first priority. I'm hoping at least a few months. I also thought about LiPo with an on-board charger but decided against it - over discharge is a bit risky with LiPos and I wouldn't feel comfortable with it. Maybe in the next version.

The keyboard controller and transmitter will be run by an ATmega169PV. It's the cheapest AVR I could find at my supplier that has enough pins and can be powered by two AAs without a regulator. The max clock is only 4MHz for the voltage range of the batteries, but even that is more than enough.

The wireless communication will be done with a nRF24L01+. I have used these modules in the past and I really like them. They are small, simple to use and very low power. And don't need a voltage regulator when powered by two AAs.

The receiver part will be adafruit's ATmega32u4 (I have one of these) but a Teensy or any other USB capable AVR will do just fine. AVRs are great because I could use the tmk_keyboard firmware. And here's the biggest problem I am having: attaching an nRF24L01+ module to an AVR USB board will make it big and awkward - it will not make for a nice wireless dongle. It lookes like Atmel made a AT90USB162 and nRF24L01 (no plus) dongle a few years ago, but those are not produced any more. They are called AVRUSBRF01 and you can still get them on ebay for 40 EUR. Ouch! I think I'll pass.

I think in the end I'll get a nRF24LU1+ dongle and use that. It's a 8051 microcontroller with USB and an nRF24L01+ compatible transceiver. I can't use tmk_keyboard on it, and I've never used any microcontroller other than AVRs so it means I'll have a new learning experience. But I'll get into that only when the controller works fine with the ATmega32u4 breakout.

So far I have mapped the keyboard PCB connector http://deskthority.net/wiki/Controller_ ... lseries_7G and I am finishing the layout and routing of the main controller board. Fun times ahead!

Any comment or question is more than welcome!

Thanks for listening!

[Muirium]

Good work. Wireless is something I'm always looking for in mechanical keyboards, but never find (besides the elusive Japan-only Bluetooth Filco). Keep us posted!

[TheJJ]

Well, you could desolder the pin header from transceiver board, put it on the back of your AVR board (with doublesided tape/glue) and connect with thin wire. Cheap and very easy to make, you only need some attention while soldering and/or use some thermal resistant tape.

Creating an individual daughterboard would be a more elegant way to solve this, but it's more expensive (ca. 10$ board + 5-10$ parts) and soldering QFN package can be a really BIG pain in the a$$, so only for an expert armed with a good soldering iron

[Peter]

Unlike almost everybody else, I really love the big-ass enter and the short backspace
and that layout was the main reason I bought them in the first place

I love Big-Ass RETURN 2
Despite the fact that I have some quite nice vintage boards - And all the IBM M's I could dream of -
And my programmable Access-Is in progress !!
My daily driver is :
A SteelSeries 6Gv2 with Cherry Blacks and the 1. GH 'Dolch-style' GB key-caps, with 'Nordic'-pack !

I chose the 6G over the 7G because it's one less cap to worry about in group-buys -
There are plenty as it already is !

[kile]

Well, you could desolder the pin header from transceiver board, put it on the back of your AVR board (with doublesided tape/glue) and connect with thin wire.

Yes, I though of something similar, and that is probably what I will have to do if I have problems with space. On the other hand, I don't like the antenna part of the transceiver getting too close to some copper traces on my PCB beneath. I don't know anything about RF PCB design, but I am guessing it could make problems.

Creating an individual daughterboard would be a more elegant way to solve this, but it's more expensive (ca. 10$ board + 5-10$ parts) and soldering QFN package can be a really BIG pain in the a$$, so only for an expert armed with a good soldering iron

One look at a QFN chip was enough to convince me that soldering it was out of the question. I might even be brave enough to try to do it with a QFN microcontroller, but there's no way I would try it on an RF chip - especially since I would have to somehow solder the bottom of the chip to the board. And then there's the problem of the PCB design. No way

I chose the 6G over the 7G because it's one less cap to worry about in group-buys -
There are plenty as it already is !

Have you ever opened the 6G? If so, have you seen the controller and does is it look like the 7G? If I make this controller, I am hoping that it will also fit a 6G, but I've never seen how they look from the inside. I am guessing it would fit because the case for both the 7G and the 6G look the same except for the holes for the audio jacks and USB connectors on the 7G.

[TheJJ]

I don't know anything about RF PCB design, but I am guessing it could make problems.

Thre are some projects to look at and good documentation from Nordic semi, your only problem is QFN.

On the other hand, I don't like the antenna part of the transceiver getting too close to some copper traces on my PCB beneath.

Antenna trace is usually on the top layer, so it should be ok( 90% ) as long there is no contact between PCBs. The output will be lover because controller PCB acts as a shield+there will be some interference, but you dont need max range anyway(your KB transceiver is the limiting part here).
In case of problems (RF/EMC is a b*tch^^) or when you need more range you could place the antenna (ca. first 1/3PCB) "free". Or use extermal antenna (wire), or put some space between PCBs (usually ~3mm space is more than enough) etc.

Code: Select all

                    || -USB header
original header- |  |
                 |  | 
 transceiver-    |  |  -controller board
                 |  |
                 |
        antenna- | 

/edith says: Typo!

[kile]

In case of problems (RF/EMC is a b*tch^^) or when you need more range you could place the antenna (ca. first 1/3PCB) "free". Or use extermal antenna (wire), or put some space between PCBs (usually ~3mm space is more than enough) etc.

Thanks, those are good advices. But I will only look into these if I actually have range problems. The way I see it, the furthest this has to go is from the PC to the couch which is very rarely over 5-6 meters. But you can never have too long a range either.

I have etched the two sides of my PCB last night. I set the iron too hot, so I had some toner smudging, but nothing serious - there doesn't seem to be any broken or connected traces.

I build double sided PCBs from two separate 0.8mm single sided PCBs. I sand them down to the alignment markers I have placed on the PCB graphic and glue them together with super glue. I use the gel variety of super glue so I have time to align the two PCBs before they stick permanently - the liquid super glue works too fast. This method takes a little longer than using double-sided 1.6mm PCB but it's much more reliable and there are hardly any problems with alignment.

[kile]

I finished the PCB, soldered everything and realized I made a mistake. I swapped the upper and lower rows of the keyboard PCB connector. I will have to update the wiki with the correct pinout.

The good news is that the positions of the connector and the holes are spot on. It fits even better than the original controller.

So I have to design and build a new PCB. Btw, this is why I like making etched PCB prototypes. At least I didn't f**k up a whole batch of factory made PCBs that took a month to get to me from China.

[JBert]

In case of problems (RF/EMC is a b*tch^^) or when you need more range you could place the antenna (ca. first 1/3PCB) "free". Or use extermal antenna (wire), or put some space between PCBs (usually ~3mm space is more than enough) etc.

I build double sided PCBs from two separate 0.8mm single sided PCBs. I sand them down to the alignment markers I have placed on the PCB graphic and glue them together with super glue. I use the gel variety of super glue so I have time to align the two PCBs before they stick permanently - the liquid super glue works too fast. This method takes a little longer than using double-sided 1.6mm PCB but it's much more reliable and there are hardly any problems with alignment.

How do you get the vias to work though, do you solder in a bit of stranded wire or do you rivet those?

[kile]

How do you get the vias to work though, do you solder in a bit of stranded wire or do you rivet those?

I use the leads of 1/4 Watt resistors. 3-4 resistors are enough for the entire board. The leads are 0.5mm thick - prefect for a small via.

[kile]

The new PCB is working! I have left a hole on the part of the PCB underneath the nRF antenna. The cable on the picture is a UART connector I use for debugging.

So far, the keyboard matrix scan and the RF data transfer are working (I tested it with a ATmega644p dev board on the receiver side). I haven't started doing the USB or the low power optimizations yet.

I think I might change my mind about tmk_keyboard and just do a minimal firmware with only the things I actually need (the SS/RWin key swap). I doubt anyone other than me will build or even need this. Although I might do an interest check to see if I'm wrong.

It looks like this controller will not be compatible with the 6G v2. Judging from the pictures I found here http://blog.gaingame.com/2010/09/14/ste ... rd-review/ the 6G has all the electronics integrated into one single-sided PCB. Bummer...

[Muirium]

Nice update. Really hope this thing works out just great. Wireless is the next frontier for us!

(Also: A.I.! One of the more thoughtful movies I've seen. The last hour could have used some serious trimming, but it's got a complex feel to it that I can't help but like. Certainly a better philosophic adventure than Prometheus. Euch!)

[kile]

I'm typing this on my wireless 7G

I've had another change in my plans. I decided to ditch the ATmega32u4 for the receiver and just use a circuit I built a while ago which already has a header for the sparkfun nRF24L01+ breakout, an ATmega88 and a USB connection wired to work with the obdev's V-USB driver. And things seem to work just fine. It's too big for an actual dongle, but it's great for testing and developing.

I still haven't made any low power optimizations on the AVR or the radio, but that is the next step. I just read the relevant parts of the AVR docs about low power, and I'm about to start playing with it. The problem is that I don't have any tools to measure current consumption in the less than 1mA range, which is what the circuit should draw on average if everything is configured to consume as less as possible. I think I can fix this by charging a large capacitor and then running the circuit from the power stored in the cap. I won't be able to tell exactly how much current the circuit is drawing, but I will be able to tell how long it will run on a fully chaged capacitor. And that way I will be able to tell if any change in the configuration is drawing more or less current.

I ordered two different nRF24LU1+ dongles from ebay. Man, these things are tiny. I plugged one of them in and my PC recognized it as a "Nordic Semiconductor nRFready Basic Remote Dongle". It turns out, these already have a wireless QWERTY keyboard firmware on them and in theory I would only have to know the protocol and send the data in the format that the dongle expects to have a working system without any need to program the dongle. But there's a catch. To get the documentation about the protocol it looks like I have to buy the entire development suite http://www.nordicsemi.com/eng/Products/ ... art-Remote . So, that's out of the question.

I also found the nRFgo-SDK which is a collection of C source code for the nRF24LU1+ and nRF24LE1. These contain the source code for the Gazell protocol stack which allows very robust RF connections. At first glance the code looks quite portable. I wonder if I can port it to AVRs.

[Muirium]

How I'd like to make one of these work with one of these. Bluetooth XT, AT and PS/2. Programmable too!

[kile]

I've added a few things since my last update.

The first is the ability to "play" a text string as keystrokes on the receiver. So, the keyboards sends the string "this is a message" to the receiver which is then translated into keystrokes. These keystrokes are then sent to the PC as if the user typed "this is a message".

I used this to build a menu system which at the moment is used to set the brightness of the LEDs and the output power of the transmitter. Pressing Func+Esc enters the menu and this is what it currently looks:

Code: Select all

7G wireless
firmware build Jul 30 2013  13:38:18
battery voltage=2.83V
keyboard's been on for 0days 21hour 39min 10sec


what do you want to do?
F1 - change transmitter output power (current 0dBm)
F2 - change LED brightness (current 1)
Esc - exit menu

Pressing F1 or F2 then opens a sub-menu which allows changing these values.

The menu shows the current battery voltage. This needs a little tweaking to be more accurate, but it serves it's purpose at the moment. In the next PCB revision, I want to improve the circuit which measures the voltage. I have to dig into the AVR datasheets and look for some examples.

The firmware also has a clock (watch) which starts when the keyboard receives power. That's the "keyboard's been on for..." part of the menu. This clock is used in the sleep system (see below), but can be used as a real clock too.

There is also a LED "driver" thing which allows sequences to be replayed. So, for instance, I can play an LED sequence where 1 LED is on for a while, then 2, then all three. The driver also allows gradual transitions from bright do dim and back, but this still needs some testing, I think there are bugs in it. This can be used for all sorts of indicators.

The bad news: transmitter range sucks! On highest transmitter output power (0dBm) I get a range of 6-8 meters, and on the lowest I get 1-2 meters tops. I've used these modules for other projects, and I've confirmed a range of at least 60 meters. The chip should also be able to send a signal through at least one wall, which is not the case now. This, of course, means there is something wrong. I don't know what causes these, but I'm guessing either the keyboard PCB or my controller PCB are somehow shielding the transmitter. Tests are needed...

I don't do any frequency hopping. The channel is hard-coded at the moment. The transmitter will to re-send the package for for a number of times, or until it gets an acknowledge from the dongle.

The controller does not have any reverse voltage protection. So, reversing the batteries will probably fry the entire circuit. I will have to add this in the next controller revision.

The firmware doesn't do any encryption of the data it sends. This means that it's not too hard to build a circuit that can "listen" and log keystrokes. This can be fixed, of course, but it's not very high on my priority list. I'm not very paranoid...

The firmware puts the keyboard into sleep for a variable duration of time which depends on the time since the last change of the state of the keys. The idea is that while the user is typing, this sleep time will stay relatively short (say, 4ms) and if the user is not typing this interval will gradually increase to a max value (at the moment 71ms). Then, as soon as the user starts typing again, the sleep duration will jump back to the minimal value. Currently the implementaion of this is very crude, and needs more work. I plan to make this configurable so that the user can select if he wants to save power with longer sleeps, or have a more responsive keyboard and drain the batteries quicker. I also thought about making a "deep sleep" mode which puts the keyboard in a state where it will sleep for longer durations (say, 500ms) between matrix scans and wait for a specific key combination to get out of this deep sleep. The idea here is that you want to put the keyboard in deep sleep if you want to transport it, or if you want to lock it. The keyboard could also go into deep sleep if no keys have been pressed for a long time (30 minutes or so) to preserve power.

Because of this sleep system I decided I will not do any debouncing. What's the point of debouncing if I'm already scanning the keyboard matrix every 4ms or longer? Any comments on this?

The source code and the Eagle CAD schematics of the controller PCB are on:

https://code.google.com/p/7g-wireless/

So, that's it for now.

[matt3o]

I followed this thread with envy. I really need to improve my skill in electronics... as of now all this is so over my head...

[Muirium]

Nice! Some real thought going into this. Especially re: deep sleep. I wonder how much power you save by sleeping the matrix compared to sleeping just the Bluetooth system. Sending signals is a big drain, but just the controller?

My Apple keyboard wakes up acceptably fast after hours or days of standby, by pressing any key. I've never even tried priming myself for some high speed typing the very instant it comes back on, perhaps they use something like your idea, perhaps not. Certainly, a special key combo to wake it back up could be useful when stowing the keyboard in a laptop bag. Depends how much power is used up by all the other unwanted keystrokes.

The controller does not have any reverse voltage protection. So, reversing the batteries will probably fry the entire circuit. I will have to add this in the next controller revision.

Is that something a simple diode in line with the batteries could fix?

[kile]

Nice! Some real thought going into this. Especially re: deep sleep. I wonder how much power you save by sleeping the matrix compared to sleeping just the Bluetooth system. Sending signals is a big drain, but just the controller?

Well, the problem is I just can't be sure. I don't have any equipment to measure currents which are less than 1mA. I ordered two cheap ampere meters on ebay. One is in the 0-50uA range and the other 0-500uA. I still haven't received them, so I can't measure anything. Once I get them, and provided they work properly, I will know more.

Once I get these, I will probably make some changes to the sleep system. There are sleep modes that draw less current than the mode I use now, and I will probably use those later. But to use those I need to drop the crystal oscillator and use AVR's internal RC oscillator. This is a good thing, I've never done this before, so it will be another chance to learn.

Certainly, a special key combo to wake it back up could be useful when stowing the keyboard in a laptop bag. Depends how much power is used up by all the other unwanted keystrokes.

That's my concern. If the keys are pressed and there is no receiver in range, the keyboard will try to send the data a certain number of times (set to 10 times at the moment) before it quits. And this draws a lot of current by the transmitter (12mA).

You are right in that the keyboard matrix scanning is not very power consuming. It's very fast and I've added has an optimization that will make the scanning run very, very fast if no keys are pressed (which is most of the time). On the other hand, every bit of power saved counts.

Is that something a simple diode in line with the batteries could fix?

Yes, it would fix it, but not very well. Normal diodes (1N4148) have a voltage drop of about 1V which means that the voltage available to the circuit will be at least 1V less than the actual battery voltage. And that means that I would be wasting most of the capacity of the two alkaline AAs. Not a good idea. Even low drop schottky diodes have a 0.3V drop, which is much better, but still not very good.

The solution I'm lookin into are MOSFET transistors. Here's a video tutorial on the subject:

http://www.youtube.com/watch?v=IrB-FPcv1Dc

[kile]

I've added all the things I wanted to add to the controller. I chose a TPS1101 N-channel MOSFET for the reverse voltage protection, which seems to work as expected. I've removed the 3.6468MHz crystal as the system clock, and now I'm running everything from AVR's internal 1MHz RC oscillator. I've added a 32KHz watch crystal for a more accurate timer, but honestly, this is a little bit of an overkill. It's not really needed, although the firmware depends on it at the moment.

I've received the two microampermeters from ebay and they both work fine. One has a range of 0-50uA and the other 0-500uA. The one for 500uA needed a little fix, because it's hand's axis wasn't lying where it should. I've tested them and they seem to be accurate. Which is amazing considering these things cost $7 shipped. And they confirm that the circuit is really drawing as little current as it should. In sleep mode the current draw is about 7uA for the entire circut. In active mode at 1MHz (when the AVR is actually ticking) the draw should be around 0.6mA according to specs (can't measure this - it's out of my meter's range). At 1 MHz it takes 390us to scan the keyboard when no keys are pressed. All this means the batteries should last a looong time

I've added the deep sleep lock mode to the menu. Selecting it will put the keyboard into long sleep periods (~60ms) between matrix scans, and wait for a Func+Del+LCtrl key combination to unlock.

I've moved the nRF module as far away from the controller and the keyboard PCB as I could. This improved the RF range a little but it still isn't as good as it could be. But it's good enough for me.

So, that's it for the keyboard controller for now. I'm happy with it. Now I want to get those nRF24LU1+ dongles to work with the keyboard. I need to build a programmer for the chip, because I can't seem to get into the chip's USB bootloader.

[kile]

I'm finishing the nRF24LU1+ programmer board and software. I think I might run a batch of these programmers and try to sell a few on eBay. I'll make them open source/open hardware, just like the 7G controller.

The power consumption of the controller circuit is so low that I thought there was something wrong with the part of the circuit that measures the battery voltage. It stayed at 2.77V for about four weeks, and it finally dropped to 2.76 a few days ago. So it looks like it will take at least a year to drain the two AAs I have in the case, and probably much more. Just for laughs and because I want to see how the circuit behaves when the batteries are drained, I am now powering the controller from a CR2032 lithium coin cell. I wonder how long it will last. If it lasts more than a month, I will make another controller revision an add a CR2032 battery holder to the PCB -- it's connected with wires to the board at the moment.

I've replaced the stock MX blacks on the keyboard with MX greens and tactile greys on Enter, Esc and Space. Thanks, 7bit It took about 2-3 hours of desoldering/soldering but it was fun. Now I know I don't like the tact greys, they are way too heavy. I will replace them with greens the next time I open the case, or maybe just leave them on PrintScreen/Scroll lock for reference. So now I have a total frankenboard, and I love it

[beltet]

Will follow this thread, would be awesome to make on of my own.
Thinking of buying a 6gv2 for it. Let us know if 2032 works well. That would be awesome.

[kile]

Will follow this thread, would be awesome to make on of my own.
Thinking of buying a 6gv2 for it. Let us know if 2032 works well. That would be awesome.

Thanks for the interest, but this will not work on the 6G v2. The V2 has a different main PCB with everything integrated on one board. This will only work for a 7G.

[beltet]

Will follow this thread, would be awesome to make on of my own.
Thinking of buying a 6gv2 for it. Let us know if 2032 works well. That would be awesome.

Thanks for the interest, but this will not work on the 6G v2. The V2 has a different main PCB with everything integrated on one board. This will only work for a 7G.

Then it will not be a 6gv2 ;D!

[kile]

My wireless 7G has worked since mid october on a CR2032. When I powered the controller from the battery, the battery voltage was around 3.18V. Within about 2 days it dropped to around 3V, and I was a little disappointed thinking it won't last more than two weeks. But it looks like that is normal for lithium coin cells - a fresh CR2032 starts at 3.2V, then quickly drops to 3V, and then it stays there for a long time. See this for details: http://m.eet.com/media/1121454/c0924post.pdf

How long it will actually last I really don't know, but it looks like 6 months is very realistic. So, I've updated the the circuit and added a CR2032 battery holder. I haven't built this version of the PCB, and I don't think I will. The difference between this one and my last prototype (the one I'm using every day) is too small to justify that. I think the PCB and the battery holder will fit the case just fine, but I can't be 100% sure.

I was quite busy these last two months, so I haven't done a lot of work on the nRF24LU1+. But I've finished the paying project I was working on, so now I'm free to get back to the dongle. I've built an nRF24xx programmer which I plan to use to port the dongle code from AVR to nRF 8051. Here's the programmer circuit and source:

https://code.google.com/p/nrfburn/

The two nRF24LU1+ dongles I have seem to be useless. They don't have the RESET pin brought out, which seems to be necessary for a correct programming sequence. Actually I'm quite sure I've destroyed them by not resetting them before and after flashing. So I've ordered a SparkFun nRF24LU1+ breakout which has a RESET, and I will continue when I receive it in about two weeks.

[matt3o]

wow, 6 months on a coin battery?! that's impressive, I couldn't juice more that 3/4 days out of my experiments (BT2.1). Wondering how long it would last on bigger (rechargeable) batteries.

I wish I had the know how to copy your experiment. BTW, thanks for sharing!

[Muirium]

Whoah! Sounds like… sorcery. Any wizards, witches, summoners or seers in the family?

[kile]

wow, 6 months on a coin battery?! that's impressive, I couldn't juice more that 3/4 days out of my experiments (BT2.1).

I know very little about Bluetooth, but I vaguely remember that the host and the device need to send eachother packets at regular intervals to keep the 'connection' alive. This means there is significant power consumption even if there's no data to send.

The advantage of these nRF24L chips is that you have total control of what is sent and when. Because of this I can keep the nRF module on the 7G in low power mode where it consumes less than 1uA. That's about one 20000th of what an average LED consumes. And it consumes about 12mA when it actually sends or receives data. One packet takes about 1ms to send and that includes the acknowledge packet that the receiver sends back to the transmitter (the dongle sends to 7G in our case). So, it's about 1ms for a transaction which happens every time something changes on any of the keys - when a key is either pressed or released. As soon as the data is sent, I set the nRF back to low-power.

And that's only the consumption of the nRF. The ATmega169pv running at 1MHz on the internal RC oscillator powered at 3V consumes about 0.6mA. When in power save mode it consumes about 6uA. All this is in the datasheet.

So obviously, the trick is to try to keep the AVR in power save mode for as long as possible. Tests show that it takes about 390us to wake up the AVR, scan the matrix and go back to sleep. This assumes that no keys are pressed. If any key is pressed, it will take longer, and if the controller detected a change in the state of the keys, it will have to send a new packet to the host. But in relative terms this happens very rarely. Most of the time the keyboard is in power save mode and waits for a keypress.

The most important reason why the circuit draws as little as it does is that it doesn't have any voltage regulators and both the AVR and the nRF are powered directly from the battery. No amount of power save modes will help if you have a linear voltage regulator which draw 10-20mA all the time.

I don't think I mentioned this but I also cheated a little with the caps/num/scroll lock LEDs. If I handled the LEDs like a normal keyboard does, and had even a single LED on all the time (I always type with num lock on, for instance), this would drain the battery in 2-3 days tops. I don't think even a pair of AAs would last longer than 10 days. So what I do is, I only show the state of the LEDs for about a second or two after the state changes. For instance if only num lock is active, and you press caps lock, num and caps LEDs should be turned on. And that's what happens on my controller but only for two seconds after which all the LEDs are turned off. Otherwise I would be burning about 10mA per LED all the time.

Wondering how long it would last on bigger (rechargeable) batteries.

NiMH batteries are pointless for this because their self discharge rate is the limiting factor, not the power consumption of the circuit. LiPo or LiIon are better, but these complicate the circuit and their voltage levels are outside the allowed voltages range for the nRF (1.9V - 3.6V).

I wish I had the know how to copy your experiment. BTW, thanks for sharing!

Believe me, the most difficult thing here by far is programming. And from what I can see on the forum you already know enough of that to get you going. Everything else is just about having enough patience to carefully read and understand the datasheets. Three years ago I hardly knew anything about electronics - I could tell apart a resistor from a capacitor but I didn't know anything about what they can be used for.

The absolute worst thing you can do is decide this is too hard before you've even tried it.

But you do need some tools. An oscilloscope is good (I don't have one), but a logic analyzer is even better for these kinds of things and it's cheaper. I recommend Saleae Logic which I have used since I started this hobby. I can not begin to describe how useful this thing is. When I bought it I was a bit reluctant to shell out 150EUR for it, but now I know that it was worth to me at least 5 times that much. The knowledge I gained and the frustration it saved me is something money can not buy. Ok, I'm a Saleae fanboy, I admit it...

And if you have any questions about any part of this project or any other I did - please ask. You see, I really enjoy learning and talking about electronics and I haven't had this much fun with a hobby since I started learning about programming some 25 years ago. But I don't know anyone who I could talk to and share my enthusiasm with. So, these forums are a sort of therapy for me So, ask away, cause I'm more than happy to share everything I know

Whoah! Sounds like… sorcery. Any wizards, witches, summoners or seers in the family?

Not that I know of. I was as amazed about how well this works as you guys are

But the 6 months is still only an estimate. The battery is currently at 2.92V after two months of use. In May we'll see if I was correct. Or maybe sooner


Geez, that was a long post

[Muirium]

And an informative one!

You did exactly the right thing with power saving: race to sleep. The goal is to be asleep as much of the time as possible, and then some; reminds me of myself in fact!

I'd really like to use this in a generalised case for custom keyboards. What do you think? I hand wire matrices (or I plan to get Matt3o to cook me a hand drawn PCB next time) and run everything off a Teensy over USB. No LEDs involved! What would I have to change to adopt your solution? The Teensy I suppose…

[kile]

So, you want to have a teensy on the PC side, plugged into USB with an nRF attached, and a general wireless AVR keyboard controller on the other side?

If that's true, you will have to change the keycode lookup tables in matrix.c, and rethink the matrix scanning function in case you have something other than 16x8 rows/columns. That's the controller.

The dongle would need a new USB handler, because at the moment I use the software V-USB library. I really like V-USB, have used it several times, and for me it's a lot easier than hardware USB that the Teensy has. Just because I've never used hardware USB on AVRs. Making that work would probably be the biggest part of this.

[Muirium]

I don't necessarily need a Teensy involved at all, really. That's just what I'm used to.

My current 60% matrix is 15x5, and I'm thinking of going a little bigger for the next build, potentially. Wireless with this kind of battery life is very tempting, even if it is of course with a dongle.