[Updated] Wireless GH60

[agodinhost]

... teensy and xbee (2 of each) ...

Our idea is to use bluetooth right?

Xbee is a complete different animal, way more expensive than the 6 bucks bluetooth module suggested here. Xbee is suggested for long distances (kilometers), we don't need it in an keyboard. I linked the Sparkfun Arduino Fio only as a reference, it uses the Xbee connector, true - but the idea here is to connect an bluetooth xbee compatible module on it (not one real xbee).

[Strelok]

... As far as I understand, what I need to add is a header for the expansion board ...

Err, nope, as far as I understood the idea is to build one modular keyboard matrix without any specific controller on it. This board will have some kind of header to connect it's columns/rows pins to our external controller bundle. It will required a major change since we will have to remove all teensy stuff from the current version and re-route the columns/rows pins to this header (we still didn't decide about the header).

Komar, I think it would be better to wait a bit - we are still deciding which path to take.

I'll add some sketches to let this idea clear, later today.

Would it not be easier to just make an expansion port of sorts? Plug something into the existing keyboard matrix opposed to replacing the matrix?

[agodinhost]

Would it not be easier to just make an expansion port of sorts? Plug something into the existing keyboard matrix opposed to replacing the matrix?

Yes, it would. We are not going to replace the matrix - we are going to remove all controller components and re-route the matrix to use some common connectors.

However, if I got it right, our goal here is flexibility. If you tie the controller to the keyboard matrix anytime you decide for
an modification on this controller you will have to review the whole PCB (instead of only the controller). You will see the pros and cons of each approach later - I'll post some sketches to help to figure it out.

... i'm going to try to run another set of prototypes of the gh60 board, and it would be just about right, if the gh60 is made more modular at the same time, to prototype any modules we might want..

+1 modular ...

[agodinhost]

Our options, pros and cons:

1) GH60 current version + usb charger + 5v booster + bluetooth:

* 5v, running @16Mhz
+ easy to build
- requires a minor GH60 PCB review
- some wiring required
- need someway to fix each module inside the case
- not modular at all

2) GH60 current version + usb charger + bluetooth:

* 3.3v, running @8Mhz (the firmware need to be tested at this speed)
+ uses fewer components
+ easier option to build
+ cheaper option to build
- requires a minor GH60 PCB review
- some wiring required
- need someway to fix each module inside the case
- not modular at all

3) Shield for 1 OR 2

+ no wiring required
+ shield fixed by connectors or sockets
+ so so modular
- not so easy to build, requires a new PCB for the shield itself
- requires a minor GH60 PCB review
- thicker (3 stacks)

4) GH60 v2 + usb charger + 5v booster + Teensy 2.0 + bluetooth AND
5) GH60 v2 + usb charger + Teensy 2.0 + bluetooth:


+ easy to build
+ cleaner matrix design
+ modular
- requires a major GH60 PCB review
- some wiring required
- need someway to fix the modules inside the case

6) GH60 v2 + Shield - usb charger + 5v booster + Teensy 2.0 + bluetooth AND
7) GH60 v2 + Shield - usb charger + Teensy 2.0 + bluetooth:


+ cleaner matrix design
+ no wiring required
+ shield fixed by connectors or sockets
+ modular
- requires a major GH60 PCB review
- not so easy to build, requires a new PCB for the shield itself
- thicker (3 stacks)

8 ) GH60 v2 + Complete custom controller PCB.
+ cleaner matrix design
+ cleaner controller design
+ no wiring required
+ controller fixed by connectors or sockets
+ smaller
+ modular
- requires a major GH60 PCB review
- hard to build, requires a new PCB for the controller itself
- slower option (more items to design)
- more expensive option
- more error prone

that's it, let's begin ...

[Strelok]

Our options, pros and cons:
...
that's it, let's begin ...

Wow awesome.

You'll have to talk to Komar, but I think any major GH60 revisions are unlikely, I don't know think everyone would want the GH60 set back significantly just to allow a niche feature like this.

If we can test the firmware at 8mHz and it works, the voltage booster ideas can be thrown out, correct?

I think 2 or 3 are our best bet, but I'm not well versed on the subject.
What does everyone else think?

Edit: I'm going to update the first post with information.

[agodinhost]

You'll have to talk to Komar, but I think any major GH60 revisions are unlikely, I don't know think everyone would want the GH60 set back significantly just to allow a niche feature like this.

Komar is already doing some review into the PCB for himself I think.

If we can test the firmware at 8mHz and it works, the voltage booster ideas can be thrown out, correct?

Yes, that's correct.

I think 2 or 3 are our best bet, but I'm not well versed on the subject.

2 is more a prototype - assuming some basic electronics knowledge and some wiring I think that anyone with those parts is already able to assembly and play with this option (don't forget the firmware, it needs the hid/bluetooth support code).
3 is cool, but I'm more fond to 6 or 7.
8 is just a dream at this point - we still even decided about the connectors to use, imagine 8?

BTW: it took me 4 hours to draw all these cute little drawings so, please, give your 5 cents!!!
 

[agodinhost]

I forgot to list this option, 9:
We could use the Arduino Fio + Bluetooth Xbee module:

Arduino Fio v3 - ATmega32U4 OR Arduino FIO Atmega328P.
This ATMEGA328P version requires an V-USB based firmware.

The Bluetooth XBee compatible module
Take a look at the top of this shield - our little guy BC417!!!

* 3.3v, running @8Mhz (the firmware need to be tested at this speed)
+ready to use
+modular
- price
- requires a minor GH60 PCB review
- some wiring required
- need someway to fix the module inside the case
- thicker (3 stacks)

[agodinhost]

double post ...
sorry

[Strelok]

I'll make a post in Interest Checks and link to here.

[agodinhost]

How about this connector?

Option A:


ATX 20 Pins power connector, PCB mount

It has 20 pins, more than enough to wire all our rows/columns ...

+ 20 pins
+ cheap
+ easy to find
+ easy to solder
- way thicker

[alaricljs]

It's also huge

[WhiteFireDragon]

How about this connector?
ATX 20 Pins power connector, PCB mount

lol you kidding me? That's the older ATX PSU connectors. It'll be fine for prototyping, but good luck ever getting that into a case for a final production board.

[agodinhost]

Option B:


Option C:


Option D:


+ 40 pins and you can break it down
+ cheap
+ easy to find
+ easy to solder
- exposed pins
- easy to bend

Option E:
An VGA connector? 15 pins
 

[agodinhost]

lol you kidding me? That's the older ATX PSU connectors. It'll be fine for prototyping, but good luck ever getting that into a case for a final production board.

You choose, it's only one option - but I do agree, it's way big!

My personal preference is B, I do use it everyplace I can.

Any other option guys? Please?
We need to decide which connector to use in order to review the PCB ...

[agodinhost]

For those whom are willing to start to prototype:

The TX RX pins are 7 and 8 on teensy 2.0 - not 0 and 1 as I said before, sorry, 0 and 1 are used as tx rx on arduino - take a look:
Teensy, Using the UART (Real Serial Port)
We need to remember that this is not the uC pinout - it's the teensy pinout.

The ATMEGA2U4 tx rx pins are 20 and 21, as you can confirm on his datasheet.

>>UPDATED<<
This bluetooth module already came with the logic level converter required to talk to the teensy without ant risky of burning the rx line. This is the very same BC417 module soldered on one "shield" to make our lives easier.

[Strelok]

I was thinking we could mount however many we need of these, facing sideways, to the GH60 PCB:


We can hard mount the expansion board into the GH60 with 90° pins like these:


Or, put more sockets on the expansion board and use male to male pin wires to connect them, like a bread board, so that if you break a pin you only need to replace a wire. I don't think bending pins will be an issue though.

If we can prototype this on the current GH60 somehow, and there is enough interest, we can have custom boards printed with only the necessary components, this way we can control the form factor and reduce production cost.

[hasu]

agodinhost, these bluetooth modules on ebay  doesn't support HID protocol, you have to implement HID yourself with low level API(HCI?). I don't know how difficult that is, though I'm sure that is not a simple job.

Roving and Bluegiga modules support HID for us, this is a reason why they are not cheap as ebay one.
And it may be difficult to obtain those modules from outside of US /Europe such as Japan or Brazil. IIRC, Mouser doesn't ship Bluegiga module to Japan due to radio regulation.

[agodinhost]

... these bluetooth modules on ebay  doesn't support HID protocol, you have to implement HID yourself with low level API(HCI?). I don't know how difficult that is, though I'm sure that is not a simple job.

Yup, it's not a simple job. That's why I did already mentioned that would be easier to use the hidapi library in the first page. I never used this library myself, I saw some guys using it with teensy and they were happy. BC417 is way popular and cheap and I did already used it with arduino without problems.

Roving and Bluegiga modules support HID for us, ...

I don't know these modules that you mentioned.
I just did one search on ebay for these modules that you suggested and I think they are way too expensive, 54 bucks for an bluetooth module? geee, you are an rich man!!!
 

Are these the modules that you mentioned?
Bluegiga WT12 Breakout Board by EWS
RN-42 - Bluetooth Module BOB - Roving Networks

... this is a reason why they are not cheap as ebay one.

I don't know why these modules that you suggested are so expensive but I don't think it's because of the "internal" HID support, sorry. Take a look at this bluetooth keyboard, it does have support for HID and it's cheap (US$ 7.5).

And it may be difficult to obtain those modules from outside of US /Europe such as Japan or Brazil. IIRC, Mouser doesn't ship Bluegiga module to Japan due to radio regulation.

No restrictions here in Brazil for BC417 (nor in Switzerland) and it's kinda easy to get it - most of our electronic stuff is imported from China anyway.
Would be good to check it in US and others.

[Strelok]

I have this bluetooth module that supports HID I think.

[aggiejy]

I have this bluetooth module that supports HID I think.

Was this already mentioned?  https://www.sparkfun.com/products/10823  Or would that not work?

[Strelok]

Was this already mentioned?  https://www.sparkfun.com/products/10823  Or would that not work?

This would probably work.

[agodinhost]

I have this bluetooth module that supports HID I think.

This RN-42 module seems to be the same animal mentioned by hasu.

Was this already mentioned?  https://www.sparkfun.com/products/10823  Or would that not work?

This is the RN-42 module without any accessory. Teensy running at 16Mhz, 5v, will require one logic level converter (as it is for the BC417 module).
Even using this module, most probably, we will still need changes in the firmware code, at least a few tests.
Don't buy it thinking that it will be "plug and play" and that everything will work as a whistle - will be more like "plug and pray".

I'm fond to BC417 because of the reasons aforementioned.

[hasu]

Bluegiga WT12 and Roving RN-42 also has CSR chip, maybe I guess their hardware is almost same as cheap one. What its firmware on the chip offers is important, not chip itself, I think. I know people likes cheaper option, but it is not necessarily cost effective, in particular for DIY project.

But building up HID stack up on HCI yourself is very interesting and challenging job. After quick search I found this project by LUFA guy Dean. It communicates with bluetooth HID device with AVR and USB bt dongle. It looks like this is closer to what you need than hidapi. http://code.google.com/p/bluetooth-explorerbot/

My another concern is those cheap Serial-Bluetooth adapter may not support HCI interface, though I'm not sure. You can find its datasheet says something about HCI?

I'd like to say that I'm not trying to discourage you to do that challenge

[agodinhost]

What its firmware on the chip offers is important, not chip itself, I think.

Agree. The RN-42 offers too many protocols and functions, that's why - IMHO - it's more expensive than the BC CSR:
- BCSP, DUN, LAN, GAP SDP, RFCOMM, and L2CAP protocols
All of these are at firmware level ...

I know people likes cheaper option, but it is not necessarily cost effective, in particular for DIY project.

It depends if you are building just one or hundreds of boards, mkawa already mentioned that:

... if all you want is to build a one-off, i can definitely see a way to hack up even the beta pcb to support this stuff. it will be ugly, but for a one-off, ugly should be a-ok..

We still haven't decided about the approach to follow but I already know (my magic 8 ball warned me) that we aren't going to be able to attend everybody's wishes (even mine).  I found the "raw" RN-42 module on ebay for about US$ 16,00 - so so 10 bucks more than the BC.

... After quick search I found this project by LUFA guy Dean. It communicates with bluetooth HID device with AVR and USB bt dongle. It looks like this is closer to what you need than hidapi. http://code.google.com/p/bluetooth-explorerbot/

Nice project! I'll have to get some free time to see the details about this explorer ...
I think you are right, I took a peek into the HIDAPI source code and it doesn't seems to be what we need.

>>UPDATED<<
This project uses the Arduino R3 (ATMega16u2+ATMega328) + RN-42 and sends raw HID data emulating one keyboard .
This guy already used arduino + bluetooth (BC417 module) + HID into his project and seems that it worked fine. My idea is to write an port of it to teensy (it wouldn't be so hard it would?)
There is also this another HID/MIDI library, the HIDUINO (source code here) for reference.

My another concern is those cheap Serial-Bluetooth adapter may not support HCI interface, though I'm not sure. You can find its datasheet says something about HCI?

Do we really need this HCI support? HID with support for mode 0000 (keyboard) would not be enough?

I'd like to say that I'm not trying to discourage you to do that challenge

You are not (yet  ).
Worst case scenario I'll build my own version. 

Anyway I do have at home 4 BC417 and I just found one sparkfun charger/booster. My plan for this weekend (with my wife's permission, sure) is to work on the basic prototype. I'm going to wire all modules together according to the option 1 and then I'll try to write some code as proof of concept - this code will send keypresses to the pc (just that). The first part is okay, no big deal. I'll update this topic with my findings ...

hasu? do you already have the RN-42 module?

[agodinhost]

I was thinking we could mount however many we need of these ...

I think it's okay - seems that all connectors that you pointed are common 2.54mm male headers too, so it will be easy to change then later if required.
+1 2.54mm male whatever header

[agodinhost]

Hi guys.

Please, any news regarding the firmware running at @8Mhz?

I'm not sure but seems that there are two firmware versions been used on GH60, is that right?
Hasu's tmk_keyboard (LUFA)
Komar's version, it's LUFA based?

There is any other version? Any V-USB variant?

[komar007]

Mine's custom, no LUFA.
It should run on 8 MHz, though I haven't tested it.

[hasu]

I don't have time to try @8MHz and further work now. But I have a plan to work on my bluetooth HHKB again if I can get time.

Right, GH60 has two versions of firmware at this time.
My firmware includes V-USB, LUFA and PJRC stack support you will be able to swap those USB stacks easily.

[agodinhost]

It should run on 8 MHz, though I haven't tested it.

Please, could you try it at 8Mhz Komar? This test will guide us to decide if we are going to use or not the 5V booster in the GH60 wireless version.
Aren't you using V-USB too?

My firmware includes V-USB, LUFA and PJRC stack support you will be able to swap those USB stacks easily.

Awesome, I think that this flexibility will make our lives easier.

Komar, please, I do already have the github url to the tmk_keyboard but I don't know if you do already have posted the link to take a look at your version. Could you?

[komar007]

I need to buy a crystal. I don't think I have 8MHz at home. But I don't think it can be a problem. The docs say 8MHz is the "standard" crystal to generate 96MHz by PLL, so I'm actually using a non-standard config now...

[agodinhost]

I need to buy a crystal...

You don't need, you can use the internal oscillator, no crystal is required.

[tp4tissue]

And here I thought 'wireless" was blasphemy..

cool stuff...

was polling rate discussed?

[hasu]

I confirmed it works at USBKEY with AT90USB1287 at 8MHz crystal. Not fully tested but it seems to be OK.
You need to change only chip(MCU) and freq(F_CPU) setting in makefile.

I didn't try internal RC oscillator. Try it when you make your prototype.

[Strelok]

And here I thought 'wireless" was blasphemy..

cool stuff...

was polling rate discussed?

People who whine about wireless connectivity haven't used it since the '90, or think they're Fatal1ty.

Polling rate has not been discussed yet, although I doubt it's nearly as much of an issue with keyboards as it is with mice.

[tp4tissue]

And here I thought 'wireless" was blasphemy..

cool stuff...

was polling rate discussed?

People who whine about wireless connectivity haven't used it since the '90, or think they're Fatal1ty.

Polling rate has not been discussed yet, although I doubt it's nearly as much of an issue with keyboards as it is with mice.

Fatal1ty? where've you been

no body wants to be him for halloween anymore..

Anyway.. on the subject of polling...  how much "more" power is used for 1khz vs 125 standard. and would it matter if we had nice batteries

[hasu]

>>UPDATED<<
This project uses the Arduino R3 (ATMega16u2+ATMega328) + RN-42 and sends raw HID data emulating one keyboard .
This guy already used arduino + bluetooth (BC417 module) + HID into his project and seems that it worked fine. My idea is to write an port of it to teensy (it wouldn't be so hard it would?)

I believe former one is what exactly we want. This keyboard can communicate with host  with Bluetooth HID profile. While, latter one is not bluetooth keyboard, blackberry and Arduino with  Bluetooth *serial emulation* module receives key strokes from blackberry and sends forward them to PC via USB HID.

I think you must need Bluetooth HID profile to use keyboard with notePC, Android, ipad, or iphone.
(To hook up to Apple products some special treats may be needed, I guess.)

My another concern is those cheap Serial-Bluetooth adapter may not support HCI interface, though I'm not sure. You can find its datasheet says something about HCI?

Do we really need this HCI support? HID with support for mode 0000 (keyboard) would not be enough?

I think so If you are trying to implement HID profile yourself.
What is that? I don't know 'mode 0000' at all.

Anyway I do have at home 4 BC417 and I just found one sparkfun charger/booster. My plan for this weekend (with my wife's permission, sure) is to work on the basic prototype. I'm going to wire all modules together according to the option 1 and then I'll try to write some code as proof of concept - this code will send keypresses to the pc (just that). The first part is okay, no big deal. I'll update this topic with my findings ...

hasu? do you already have the RN-42 module?

No. I have WT12 in one of my HHKBs.

[komar007]

I need to buy a crystal...

You don't need, you can use the internal oscillator, no crystal is required.

You can't do USB full speed with internal RC.

[agodinhost]

I confirmed it works at USBKEY with AT90USB1287 at 8MHz crystal. Not fully tested but it seems to be OK.

Awesome!

You need to change only chip(MCU) and freq(F_CPU) setting in makefile.

Yup, the fuse settings.

I didn't try internal RC oscillator. Try it when you make your prototype.

The internal oscillator runs at 8Mhz too. The main concern here is to be sure that the uC speed will not affect the firmware execution (internal or not). I read somewhere that a USB device requires at least 16Mhz (I don't know if LUFA is affected by this).
I'll give it a try anyway.

I need to buy a crystal...

You don't need, you can use the internal oscillator, no crystal is required.

You can't do USB full speed with internal RC.

Nope, you can't. I was saying to use the internal oscillator (crystal) to execute your code at 8Mhz ...

Polling rate has not been discussed yet, although I doubt it's nearly as much of an issue with keyboards as it is with mice.

We could define the polling rate as one parameter, with a minimum and maximum values to be safe, the rate value is kinda personal. I'm not sure but I think that LUFA does the pooling internally to dispatch the USB events.

[phetto]

What modifications will have to be madeto a case?

[agodinhost]

What modifications will have to be madeto a case?

We are still prototyping and doing some proof of concepts - dunno.
The main idea is to change nothing but we don't know if it will be possible ...

[phetto]

If nothing has to be done with the case, Heeeeellooo duck poker!

[komar007]

You can't do USB full speed with internal RC.

Nope, you can't. I was saying to use the internal oscillator (crystal) to execute your code at 8Mhz ...

Okay, so I think there shouldn't be any problems. I think I have tested some older versions at 2MHz with internal prescaler.


BTW, the expansion header is currently near the controller:
(view from the top)
Does this make sense? I can still move it around a bit.


I'll be making the next and (hopefully) last prototype before group buy soon.

[bpiphany]

You don't need, you can use the internal oscillator, no crystal is required.

You can't do USB full speed with internal RC.

I've run pjrc's keyboard code with both the 32u4 and the 32u2 on the internal oscillator with some success. It's not guaranteed to be stable though. The 32u4 can actually be made  to run in low speed mode, and the internal oscillator should be good enough for this. It's in the documentation somewhere. I haven't really read up on that, but you decide the USB speed by pulling either D+ or D- high I think (done internally). I wish they would have included this option for the 32u2 as well since I am more interested in the smaller package =)

[agodinhost]

The 32u4 can actually be made  to run in low speed mode, and the internal oscillator should be good enough for this.

We do need the higher speed guaranteed under 3.3v, I think that 8Mhz will be good enough.
Below 8Mhz, most probably, we will face some issues with lost keypresses (assuming it works). I never used any speed lower than what the internal uC oscillator provides.

BTW, the expansion header is currently near the controller:
(Attachment Link) (view from the top)
Does this make sense? I can still move it around a bit.

I'll take a look asap.


Those are the expansion pins is that right Komar?
Give me 1 hour, I'm checking it.
We will need at least the pins 20 and 21 (ATMega32u4 TX and RX), 5v, 3.3v, GND and any unused pin into this header.

[esoomenona]

Why is that PCB so shocked?

[hasu]

BTW, the expansion header is currently near the controller:
(Attachment Link) (view from the top)
Does this make sense? I can still move it around a bit.

I'll take a look asap.

Show Image

Those are the expansion pins is that right Komar?
Give me 1 hour, I'm checking it.
We will need at least the pins 20 and 21 (ATMega32u4 TX and RX), 5v, 3.3v, GND and any unused pin into this header.

No, they are via holes. You can find six expansion pins at middle bottom part of the pic. They are labeled as +,-,0,1,2,3.
In current GH60 design RXD(PD2) and TXD(PD3) are used for key matrix scan, though I don't know about new design.
You can use software serial to communicate with module instead of hardware UART even if those pins are not available.

[hasu]

oops, sorry for double post.

[Strelok]

The 32u4 can actually be made  to run in low speed mode, and the internal oscillator should be good enough for this.

We do need the higher speed guaranteed under 3.3v, I think that 8Mhz will be good enough.
Below 8Mhz, most probably, we will face some issues with lost keypresses (assuming it works). I never used any speed lower than what the internal uC oscillator provides.

BTW, the expansion header is currently near the controller:
(Attachment Link) (view from the top)
Does this make sense? I can still move it around a bit.

I'll take a look asap.

Show Image

Those are the expansion pins is that right Komar?
Give me 1 hour, I'm checking it.
We will need at least the pins 20 and 21 (ATMega32u4 TX and RX), 5v, 3.3v, GND and any unused pin into this header.

No, it's these.

[agodinhost]

No, it's these.

No ...

Ohh, I thought it was the ISP connector.
I didn't checked the datasheet yet ...

In current GH60 design RXD(PD2) and TXD(PD3) are used for key matrix scan, though I don't know about new design.
You can use software serial to communicate with module instead of hardware UART even if those pins are not available.

I'm not sure if the software serial works well with the bluetooth module (RN or CSR).
Anyone?

A few bluetooth references:
http://www.seeedstudio.com/wiki/Bluetooth_Shield
http://www.seeedstudio.com/wiki/Serial_port_bluetooth_module_%28Master/Slave%29
http://www.george-smart.co.uk/wiki/Bluetooth_RS232_Module

I'm still updating my blog with the USB Lipo Charger wiring options and as soon as I finish it I'll start to work on the Bluetooth wiring.

I think it's better to wait a bit until we do make sure that everything works fine just to avoid to stay changing the PCB layout.
Any other idea guys?
8-))

[Strelok]

I overlayed  the Picture of the expansion pins onto the revA and highlighted what is likely the best place for a recess in a case. This is a top view.

Do you think about 4"x3" will be enough room?
Edit: I just realized the expansion holes are in the front, but the extra room in the case is in the back. We will have to use wires to connect expansion boards.



This should be thick enough for at least one layer of extra PCB with headers.