SteelSeries 7G wireless mod

[kile]

I think the best option is to wait until I finish the nRF24LU1+ code. When that is done it will be possible to have a small USB dongle on the PC side like this one http://store.diyembedded.com/index.php? ... ucts_id=28

I should receive the SparkFun nRF24LU1+ in about 10 days (I hope) and given enough time I will move the dongle code from AVR to nRF. Then I need to generalize the parts of the controller code that are specific to 7G and the number of cols/rows I have on the controller.

When all that is finished we'll have a more practical project for generic wireless keyboard controllers.

Unless I get an offer for a paying job and then I'm off again for a few months

[Muirium]

Sounds good to me!

By the way, how do you find computers behave with this when waking up from sleep? Bluetooth can take a few seconds to get its act together, which is annoying. Hopefully this is smoother.

[kile]

I have to admin I haven't checked that yet. But no matter how it behaves now, the nRF has a totally different USB, so we'll see when that is finished.

[tlt]

Would it be possible to use only a nRF and something to expand the GPIO on the keyboard side to make it even simpler?

[kile]

Yes, that is possible, but the GPIO port expander would have to be ultra low power too, and the only one I could find (I didn't look very hard) is the STMPE1600, which also only comes in a QFN package. So it's a no go again. And is it really simpler to have the nRF24LE1 & port expander instead of the AVR & nRF24L01+?

But, there is a 48 pin version of the nRF24LE1. That would be ideal for a keyboard side because it has the microcontroller, enough IO pins and the RF all on one chip. And it's only 7x7mm. The problem is that I could not find a breakout board for this chip anywhere, and since it's in a QFN package, there's no way I can solder it by hand.

[tlt]

Yes the 48 pin version makes a lot more sense. I started to look at this breakout board but I guess I would not be able to solder this thing either
http://www.adafruit.com/products/1377#Description

[tlt]

I found one breakout board that might be usable
http://store.diyembedded.com/index.php? ... ucts_id=27
The voltage regulator and the power LED might have to be bypassed to save power thought.

[kile]

I looked at that shop many times and never noticed it. Oh, well...

But I would prefer the chip antenna version. You would need a big keyboard case to have enough room for a RP-SMA antenna. But the chip antenna version is sold out currently.

And that adafruit breakout would probably not work even if you could solder it. With these frequencies (2.4GHz) the length and position of the leads and the components on the PCB are important. It might even work, but probably not very well.

[kile]

I received the LU1+ SparkFun module, and learned that I haven't actually destroyed the two dongles I already had. The reason why they weren't working was the way I called sdcc (the compiler for these microcontrollers). It turns out that the order in which you list the object files is important and that the source or object file that contains main() must be the first listed. So, for instance, if you compile the source files to generate the .rel object files like this:

Code: Select all

sdcc -c src_with_main.c
sdcc -c some_src1.c
sdcc -c some_src2.c

The linking stage must list the object file with the main() function first. So this is good:

Code: Select all

sdcc src_with_main.rel some_src1.rel some_src2.rel -o output.hex

But this will create some very strange behavior:

Code: Select all

sdcc some_src1.rel src_with_main.rel some_src2.rel -o output.hex

I've spent a few days banging my head against the desk until I found this out. Don't do the same mistake!

The controller in my 7G has been on the CR2032 for 3 and 1/2 months and it's still holding strong, but my 6 month estimate is still far away.

I've made a sample source code project that will be a starting point for the full USB dongle with RF. When plugged in, the dongle now enumerates as a standard USB keyboard, but the RF is still not working. The dongle just spits out a text message through the USB keyboard interface when scroll lock is on. I'm guessing I'm more than half way through to having a working nRF24LU1+ dongle.

If anyone's interested, all the source for the sample USB keyboard code can be found in the examples/lu1/usb folder of the nRF programmer project I've been working on. http://nrfburn.googlecode.com/

I've found another breakout for the 48 pin version of the nRF24LE1. Look for "PTR7048 nRF24LE1" on ebay, it's $20 for two pcs shipped. I have a breakout for the 32 pin version, and I will probably use that to write the controller code once the nRF24LU1+ dongle is fully working. I have an idea to make a wireless gamepad for "Elite: Dangerous" and the 32 pin breakout has 15 GPIO pins which should be more than enough for a decent gamepad matrix.

[kile]

And the nRF24LU1+ dongle us working! I need to test a little to check what the range is on different modules. I only tried the SparkFun one, and the range is better than the AVR based one I have on one of the photos. But I'm sure it will be at least acceptable.

The next project will be the the nRF24LE1 keyboard controller.

[Muirium]

Looking forward to it.

[kile]

As it turns out, the main factor for good quality connections is how much 2.4GHz traffic there is on the airwaves. At work, I hardly have any wifi so my 7G works with very little interference with the smallest dongle and the lowest transmit power. I've added some radio signal quality stats to the keyboard firmware, so when I enter the keyboard menu it tells me how many packets it tried to send, how many retries it needed to do, and how many packets were reported lost to the controller. On lowest power with the smallest USB dongle (the green one on the photos from the previous page) this is what I get for about half an hour of light typing:

Code: Select all

RF packet stats (total/retransmit/lost): 2909/433/0

On the other hand, if I run the same test at home I get pretty ugly results. Lots of lost packets, lots of retries. A bigger antenna on the receiver helps, but not much. The reason for this is that there is a WiFi router just behind the monitor which drowns my transmitter. It still works, but only with the highest transmit power.

I started writing the code for the nRF24LE1 controller. These are much different beasts than AVRs are and I will probably not be able to use much of the code I wrote for the AVR based controller. The way sleep modes work is much different that on the AVR and I don't think I will be able to achieve the same battery life as with the ATmega169PV. But it should still be good enough and should work for weeks on a CR2032. At least that's the plan.

I'll use a keyboard matrix with diodes and Omrons switches I build a while ago for developing the firmware and testing. It looks scary, doesn't it?

[kile]

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.

Well, it's now been a year since I've put the CR2032 coin battery in my main work keyboard and believe it or not, it's still working with the same battery. Except for a few hours in March, it's been on all this time.

I know this sounds crazy, and I can barely believe it myself, but it's the truth. The voltage of the battery was at about 2.9V for a very long time (until about a month ago), and has now started to drop. Currently it's at 2.84V, and I expect the battery will die in a few weeks to a few months. But who knows...

I've added a few things to the firmware in late march, then a few weeks later I've accidentally touched the programming pins on the back of the keyboard and reset the microcontroller. The pins are sticking out of one of the holes which were originally used by the USB HUB. So, the packet stats have been accumulating since late march.

This is it's current state:

7G wireless
firmware build Mar 2 2014 09:18:49
battery voltage: 2.84V
RF packet stats (total/retransmit/lost): 1779308/212925/11821
keyboard's been on for 229 days 17 hours 9 minutes 14 seconds

This means that a pair of quality, low self-discharge alkaline AAs would probably last at least 10 times longer. So, it's 10 years for a wireless keyboard without battery replacement... yeah, it's crazy...

All in all I will call this experiment an astounding success. I wanted to see how long I can push the batteries, and that's what I got. I couldn't have dreamed it will last this long, but I'm not complaining.

I will wait until the battery is completely dead and then I will make a firmware revision. I want to add a few ideas I've had during this time. I've also experienced a few obscure bugs that are very hard to track down because they happen once every few weeks.

Btw, I've grown very, very attached to this keyboard. I'm thinking about buying another one.

[joric]

I'm very sorry but I really don't understand, do you even use HID bluetooth profile? Otherwise it's all pretty wrong.

[kile]

I'm very sorry but I really don't understand, do you even use HID bluetooth profile?

No, I don't use bluetooth at all. At least not in the strict sense of the bluetooth standard. People often confuse bluetooth with any wireless device, but there is a difference. Every bluetooth device is wireless, but not every wireless device is bluetooth.

I use a family of microcontrollers which allow custom 2.4GHz radio communication. On the keyboard end, the controller scans the matrix and sends the results over 2.4GHz radio, and the USB dongle receives that data and sends it over to the PC. The dongle is recognized by the PC as a standard HID keyboard. So, instead of one firmware like with a teensy, now you need two: one for the keyboard and one for the dongle.

Also, there are no bootloaders, both the dongle and the controller have to be flashed by a flash programmer.

Otherwise it's all pretty wrong.

Well, it looks pretty right to me...


I got myself another 7G last year, from the last batch I could get directly from SteeSeries before the keyboard got discontinued. So now I have two wireless 7G keyboards.

I've added the CR2032 battery holder to the controller, and ordered a batch of PCBs. So, it can be powered by either the CR2032 which can be plugged into the controller, or any battery between 2V and 3.6V. For instance two AAs or AAAs or a larger CR123A lithium battery.

The source code and schematic on google code is a little stale, and since google code bit the dust last year, I will move to github in the near future.

I don't understand why this project hasn't cought on. I don't think it is too complicated for someone who has manually wired keyboard matrices on a teensy. Maybe the fact it doesn't have a bootloader or that the PCB is built and sized strictly for the 7G. Or maybe there is less interest in a wireless controller than it seems?

I can design a new PCB which will be a smaller, more generic and a little more beginner friendly wireless keyboard controller. How many people would be interested in something like this?

[hargon]

Ah, OK. Hope your project will be a success!

Just my opinion on this: But there are good arguments being made for bluetooth, e.g. you can use the keyboard almost everywhere without carrying the dongle around and tablets for example have bluetooth but no USB for the dongle.

[joric]

Considering outdated tech, I managed to flash hc-06 module ($2.48) with RN-42 firmware and now I have a HID bluetooth keyboard with no special effort whatsoever (the whole usb-capable keyboard would cost about $5-$6, with 32u4). Though it's bt 2.0 and it draws 20-40 mA but it doesn't need a dongle. Pics: http://imgur.com/a/1LHSR