All three keyboards are pretty similar.  They use a collapsing rubber dome to press together contacts laid out on two sheets of plastic separated by a plastic spacer.

I’m not going to give detailed steps, since other keyboards are probably a bit different, but here are my notes:

• I used Aqua’s Key Test which I found via Geekhack.org to test each key so I knew where to look for problems.  It’s very hard to test all the keys using a normal program like Notepad.
• I highly recommend taking plenty of pictures at each stage.  OK, I didn’t, but I had two other keyboards I could look at when putting everything  back together.
• I used CaiKote 44 to repair broken traces and re-coat unreliable contacts.  I paid ~$6 for the 1.0g jar at Fry’s.  It worked well, although it’s hard to apply precisely, especially using the included applicators, and worked best with a long time to dry (I let it dry for a day before re-testing the keyboard).  The jar looks small, but it does last: I was able to fix up all my keyboards, and a friend fixed a musical keyboard, without running out.
• I took all key caps off.  I think there’s a chance you could get the keyboard apart with the keys still on, but in any case, I needed to see how I could take everything apart and I wanted to clean the keyboar

Was it worth it?  Yes, because I like the size and feel of these keyboards, and you can’t buy either model today.

• Apparently, this option can be changed, but Ooma won’t make the change anymore.
• However, everyone on the forums recommends totally splitting your lines: Ooma connected to Internet only, local phone line connected to a different phone.  You do get extra features for free this way, for example, caller ID.
• Ooma occasionally changes their web interface around.  For example, the connection tone option (Ooma plays a special sound when the connection is made) has been removed.

Some final Ooma notes:

1. Semicon (July) has the most automated equipment (mostly wafer robots and back-end wire bonders) and vendors.  I’ve found some good new products at Semicon, but not many.  Heck, even most of the local automation distributors skip it, since the substantial exhibition costs outweigh the benefits.  I’ve skipped it the past few years.
2. Photonics West (January) has very little; typically there are a few data acquisition vendors and some lab automation oriented vendors.  Last time I went, there were a bunch of companies with serial or USB stepper motor packages with horrible, “intuitive” simple protocols.  Sometime I’ll write a rant about how I hate those; maybe it’s OK if you’re truly doing something simple and you’ve only used one brand, but I’ve used way too many different ones.
3. Embedded Systems Conference (April) typically has nothing directly related to factory automation, but I enjoy going because many of the underlying products are here, such as microcontrollers (MCUs), digital signal processors (DSPs), Field Programmable Gate Arrays (FPGAs), and Real Time Operating Systems (RTOS).

But when I plug it into a Windows 7 64-bit system (I’ve tried 2 so far), Win7-64 thinks it is an eHome Infrared Receiver (USBCIR).  The solution:

1. Go to Device Manager and look under Universal Serial Bus Controllers for the “eHome Infrared Receiver”, right click on it, and select “Update Driver Software”.
2. Select “Browse my computer for driver software”, press Next.
3. Select “Let me pick from a list of device drivers on my computer”, press Next.
4. Win7-64 then comes up with a choice of “eHome Infrared Receiver” or “USB Composite Device”.
5. Pick “USB Composite Device”, let the drivers install, and you’re done.  It’s worked great for me twice.

Note that this only works for the standard memory slots; if you want to use the SIM card reader, you have to install the Emprex software.

All serial buses have some protocol overhead, and software layers add even more.

I’ll take a quick look at CAN:

• CAN messages can carry between 8 and 64 bits of data.
• At 1Mbps, the maximum actual throughput is roughly 17543 messages/sec (1 byte data) to 8771 messages/sec (8 byte data) or 140,344 to 561344 bits per second of actual data.
• CAN does have many good features, like extremely fast arbitration (much faster and more predictable than CMSA/CD Ethernet), and producer/consumer messaging.
• So CAN is a good choice for a real time network that isn’t transferring a lot of data.  It’s even better if many nodes need to consumer data produced by one node (so the data is only sent once, unlike in a master/slave network where the master has to receive the data and then send it out again to each slave node).
• On the other hand, it’s not a good fit for a 1M sample/sec 16-bit ADC; high speed USB 2.0 or 100Mbps/1000Mbps Ethernet would be better choices.
• There’s also a cable length / speed trade off; as the bit rate increases, the maximum cable length (and branch length) decreases.
• The maximum number of messages gives an idea of what kind of update rates you can realistically see.  For example, a 100 node CAN network could handle a maximum of roughly 175 1-bytes messages or 88 8-byte messages per node per second.  So a 1 msec update rate for all nodes is impossible, but a 10 msec rate might be achievable.

Ethernet has its own set of considerations.  Just a few:

• Ethernet has significant protocol overhead, especially for small data sizes.  (Summation frame systems such as EtherCAT reduce this, but require non-standard hardware).
• If you’re using hubs, you have to take collisions into account.
• If you’re using switches, you have to consider the time the switches add.
• Ethernet and its typical protocols require a lot of resources; if your product uses an underpowered controller, even if it’s physically on 100BaseT, it might only be able to manage 1Mbps or less.
• For long distances, the time traveling between nodes can be significant.
• Higher level protocols such as TCP, ftp, NTFS, etc can add substantial delays and additional overhead along with their added features.

I’m not a USB expert, but I know USB 2.0 can’t deliver actual data at its advertised speed.

Another problem is that my posts almost always seem to grow.  I’m still slowly working on Assembling the PCB model for the Creating a 3D PCB Model with Eagle and Alibre, but a single post has mushroomed into 2 or 3 posts.  And I’ve decided I need to do more research, too.

I’m not interested in Twittering, Facebook, forums (been there, done that), and such.  With my limited time, I’d rather be working on unique content with depth that will last, not ephemeral tweets, even if I don’t post as often.

However, my New Year’s resolution for this blog still is:

• To post more often, with a goal of at least once a week.

But since it’s been too long since my last post, here are some quick notes:

• The next post on the Eagle PCB and Alibre series is in progress
• I recently picked up a Applicom DirectLink DRL-CNO-PCU CANOpen card.
  • Applicom is now part of Brad which is part of Molex.
  • Anyway, the DirectLink card is a PCI plug in card with a CAN connector (DB9F, first time I’ve seen that) and some sort of x86 processor.  The CANOpen stack is run on the DirectLink board; there’s no need to run a CANOpen stack on the PC side (e.g. CANFestival).
  • DirectLink cards are available for a variety of interfaces (e.g. DeviceNet, Profibus), and share a common API.  They’re meant to be used to interface fieldbuses with SCADA and soft PLC applications.
  • However, I noted that the CANOpen software does show support for DS402 (motion profile).
  • One nice plus is that the software will scan the network for CANOpen devices.  So if I have a CAN device with unknown ID and baud rate, I can just change the baud rate and then let the DirectLink card figure out the CANOpen ID.
  • I plan on writing more about this card, after I finish my current series.
• I managed to get over to Maido Stationery, and pick up some more JDM pens and a 0.3mm Kuro Toga pencil, so I’ll be doing another pen post soon.

You can download via subversion or the new download page.  You can browse with trac.

I plan on experimenting a bit with the format of the download page.

And, yes, I am still working on the Eagle PCB/Alibre series; in fact, I created the download page to support my next post in that series.

I’ve been very busy in the first half of 2010 with family and work, so I haven’t been able to post as much as I would like.

I am working towards finishing a few posts on creating a PCB model in Alibre from Eagle PCB, but as normal it is taking longer than I hoped.

Once the Alibre/Eagle series is complete, I will be doing a practical motion control series.