Thursday, February 19, 2009

CECT i9 Phone

Perhaps this posting isn't very "open source" and you Mac fans out there might actually call this "ripped off source", but it's my blog and I can write what I want!

I need to travel on business to the US relatively often and very occasionally Asia. In the course of this, I discovered very quickly that roaming charges SUCK! I also discovered what most people in the world who are not Canadian take for granted - pre-paid, low-cost SM SIM cards. Imagine that, there are places in the world that don't tie you into long term contracts on handsets and where cellular phone companies compete for your business? It must be nice.

So, I ended up getting an unlocked GSM phone (a Samsung T509) and a T-Mobile SIM and another SIM from Maxis in Malaysia. I've gotten a bit tired of the Samsung, so I was browsing around for something else and I came upon something called the "CECT i9", which is one of a flurry of iPhone clones available from China. If you search eBay for "i9" you will come up with a bunch of folks selling them. What intrigued me as I did research was this description from the i9 informal support forum of how the phone is actually produced:

Q. Does CECT make the i9 phone?
A. Not directly. This is the same for the P168 & many iPhone clones. Though CECT may actually produce the parts for the i9 model phones, there does not seem to actually be a single manufacturer, but rather many smaller businesses which use their parts to build the phones & sell them, so there are usually no brand or manufacturer names on any of the i9, i9+, or i9-3G phones that are sold! No one can tell you if any particular i9 being sold right now is going to be any better than another because of the fact that the true
identity of the manufacturer is almost always unknown, & the features of the phone are directly affected by which version of the firmware the phone has on it. The newest youtube.com videos of the i9 phones are usually going to be those made of ones with the latest firmware versions & most features, so watch various youtube videos on the i9+ & look for one that has the features you like, then try & purchase from a reliable seller; ask them what features & firmware version are on the phone you are buying (even
show them the youtube link to an i9 phone with features you want), & hope that what you receive is exactly what they described.

I'm not sure if this exactly qualifies as "open source", but my wife rather cleverly referred to it as "Wiki Manufacturing", which reminds me of the mystery of counterfeit cars written up in The Economist a while back. What else could be manufactured this way and could it be extended to products that aren't "knock-offs"?

So, I threw caution to the wind and bought one off of eBay for something slightly under $100. It took a long time to arrive and I thought perhaps I had been rooked, but it did finally show up a few days ago. Here is a picture of the rather familiar face:


And here is a video of the actual thing working (sorry for the mumbling commentary!):



Just to be clear, I don't own an iPhone, so I really can't compare it directly to the real thing, but it does have several things you can't get from Apple:
  • Unlocked
  • Dual SIMs online simultaneously
  • FM Radio
  • Stylus
  • Change your own battery!
Here is is in comparison to my Samsung T509, BlackBerry Pearl (which is my day-to-day phone):



The screen is pretty bright and crisp and the touch screen is quite responsive, even if the interface is a bit quirky!


It is about the same thickness as my BlackBerry Pearl:


It has a nice feel in the hand and sits flat on a surface if you are trying to type something. The "shake" feature is interesting, but really not very useful. In fact, I would prefer to be able to turn it off in the media player because it switches songs almost as soon as you touch the phone!

The phone comes with:
  • 2 batteries
  • headphones
  • USB cable
  • Up to 8GB Micro SD expansion
  • charger that you plug the USB cable into
The headset is pretty cheap and, unfortunately, uses a proprietary plug:



It supports Bluetooth and paired very easily with both my Blue Ant headset and with my Mac. There is some rudimentary ability to synch up contacts, but that's about it. The camera is very poor (like most cell phones, frankly)! Here are some sample shots:

However, it will record video and audio reasonably well and it can be stored on the Micro SD card and transferred around via USB or Bluetooth quite easily.

The support model is almost as quirky as the phone experience. In keeping with the "Wiki Manufacturing" of the product, there is no central manufacturer website, there is no fancy "app store" and precious little documentation that comes with the phone. There is a very active user help forum (click here, but you will need to join before you can see the content). This forum has a huge amount of useful information and discussion, but like most internet forums, it is also full of outdated information and "rat hole" discussions.

Probably the most valuable feature is that it does support Java mobile (J2ME), which does allow you download and install Java apps quite easily. The Java memory size is limited to only 2MB and the phones processor is pretty slow, so you need to be careful what you install! The best Java app I have installed so far is Opera Mini 4, which actually works like a charm!

This comes to some of the bigger drawbacks - the phone only supports GPRS data (no EDGE or 3G) and it lacks any email functionality. Opera Mini works basically OK with GPRS as long as you stick to the simpler "mobile editions" of websites, but the lack of email is rather frustrating. It seems like the only email client that can be made to work is an open source project called MujMail , but unfortunately this is only very awkwardly adapted to the touchscreen. You can at least get web-based mail with Opera Mini, but no push capabilities (which I normally have turned off on my BlackBerry).

Finally, the good old fashioned voice features seem to work fine. Both SIM cards are online at the same time, so you can make or receive calls on either SIM whenever you want. This allows you to chose which SIM currently has the best deal for time where ever you are at. In a more enlightened world, you could have one pre-paid SIM with the best, rock bottom cheap voice plan and the other with the best data plan. There are lots of features for tracking the exact number of minutes and cost of calls & SMS on the phone so you can manage your calling costs closely.

Over all, this isn't a bad phone really. It certainly isn't an iPhone, but then for around $100 it does offer a number of features you can't get on the iPhone. It is definitely a superior phone to my Samsung T509 which cost about the same from TigerDirect (and has no multimedia and won't synch contacts). In a recent online poll in the support forums users were asked to rate their i9s on a scale of 1 to 5. Many people dumped on the quirkiness and non-iPhone-ness of the unit and rated it a 2, but many others said, for what you pay it, it is quite decent and gave it a 3.5 to 4. I think I am in the 3.5 to 4 camp. If it had more processor and memory and could run a true open source OS like Android, whoever these mysterious, anonymous manufacturers are would have a pretty nifty phone!

Anyone want to buy my Samsung T509?

Sunday, February 15, 2009

RFID Arduino Door Lock

Back again after a short hiatus...

This project actually looks rather silly and this time I have a video to prove it! A while back I bought an Adafruit Motor Shield (click here for more info) and a couple of servo motors. I was looking around for a quick project when I remembered my old friend the RFID reader (which you will remember from this post). Perhaps because my day job involves the hotel industry, I thought why not have a try at building a door lock?

I am actually rather proud of this one, because I actually set about the design process in a proper organized fashion. I thought about what I wanted it to do and then drew a diagram of what pins I would use then I set about designing the software in a reasonably organized way. I must be getting the hang of this - only a moderate amount of banging my head on my desk!

Without further ado, here is the exciting multimedia part of tonight's presentation!



Now for a couple of quick pictures. This shows the inside mechanism:




And here is the RFID reader on the outside of the door:



Oh no, another poorly drawn Eagle CAD schematic:




Hardwarewise, it is very simple. The only oddity here is that I have actually used the Analog pins of the Arduino as Digital pins. This is done quite simply by calling them pins 14 - 19. Why? This is because the Motor Sheild either uses or covers up most of the usual digital pins. Really, for a simple servo motoro like this, I am not actually using all those digitial pins, and, in fact, I probably don't need the Motor Sheild at all. An Arduino can drive a simple servo without any extra circuitry. However, I wanted to set this up so that a stepper motor could be substituted in later on.

Software

So, here is the code that makes it work:
/* ======== Arduino RFID door lock ============

copyright Chris Armour, Feb 2009

*/

#include <AFSoftSerial.h> //Adafruit soft serial library - slightly modified!
#include <ServoTimer1.h> //Ada Motorshield servo library

// =========Initialize variables and so on =========================//
ServoTimer1 servo1;
AFSoftSerial rfidSerial =  AFSoftSerial(14,15);
//Note that this uses a version of the AFSoftSerial library modified to support pin numbers > 9.
int LEDPin = 16;
int incomingByte[16];
int oldCardNum = 0;
int newCardNum = 0;
int goodCardNum1 = 56;
int goodCardNum2 = 51;
int Angle = 0;
int LockState = 1; //1 = unlocked 0 = locked
int LockLED = 17;
int InButton = 18;
int buttonWas = 0; // The state of the switch (pushed = 1, not pushed = 0) last time we looked
int buttonIs = 0; // Current state of the switch

//==========Setup pins & servo ===============//
void setup() {
Serial.begin(9600);
rfidSerial.begin(9600);
pinMode(LEDPin, OUTPUT);
pinMode(LockLED, OUTPUT);
pinMode(InButton, INPUT);
servo1.attach(10);
servo1.write(Angle);
}

//===========Functions=====================//
void getButton() {
buttonWas = buttonIs; // Set the old state of the button to be the current state since we're creating a new current state.
buttonIs = digitalRead(InButton); // Read the button state
}

void openClose(){ //Evaluates the LockState variable
 digitalWrite(LEDPin, HIGH); //Turns on pass/fail LED
   if (LockState == 1){
     Angle = 180; //Turns servo to UNLOCKED position
     LockState = 0; //toggles Lockstate
     digitalWrite(LockLED,HIGH); //Turns on LockLED to show door UNLOCKED
     }
   else {
     Angle = 0; //turns servo to LOCKED position
     LockState = 1; //toggles lock state
     digitalWrite(LockLED,LOW); //Turns off LockLED to show door LOCKED
     }
   servo1.write(Angle); //Move the servo appropriately
   delay(1000);
   digitalWrite(LEDPin,LOW); //after 1 second, turn off the pass/fail LED
}

//================= Main loop =========================//

void loop() {

getButton();
if((buttonIs==1)&&(buttonWas==0)) { //If the button has been pushed, call openClose to toggle the state of the servo & LEDs.
 openClose();
   }

if(incomingByte[11] > 0){
 oldCardNum = incomingByte[11]; //Sets the value of the last read RFID card to oldCardNum. Just using the 12 digit of the card ID.
}

if(rfidSerial.available() > 0) { //If the AFSoftSerial RX pin reads new incoming data.
 for (int i=0; i <= 16; i++){ //It reads the next 16 characters
     delay(10);
 incomingByte[i] = rfidSerial.read();
     newCardNum = incomingByte[11]; //Pick out ASCII character #12 since it is unique across the 5 cards I have.
      }
  }

if(oldCardNum != newCardNum) {  //Check if a new card # has been received.
  if(newCardNum == goodCardNum1 || newCardNum == goodCardNum2){ //If the new card number equals either of the key cards.
    openClose(); //run the openClose function
   }
else { //If the card isn't a good card, flash the pass/fail indicator 3 times.
  for (int x=0; x <=3; x++){
  digitalWrite(LEDPin, HIGH);
   delay(100);
   digitalWrite(LEDPin,LOW);
   delay(100);
  }
}
Serial.println(newCardNum); //serial output for debugging.
}

}


I am actually rather proud of this code. It uses actual functions for getting the value of the button and for evaluating the lock/unlock state. Of the five RFID cards that I have, two of them are hard coded as "good cards" and the other three trigger the flashing LEDs as "bad cards".

The main thing to note in this software is that the Lady Ada AFSoftSerial library had to be modified to use the Analog Pins (i.e., digital pins in the range 14 to 19). Apparently the AFSoftSerial library is hard coded to work with pins below 13. This is the one time I actually had to ASK SOMEONE for help on something related to the Arduino (in contrast to the Gumstix, which took endless asking to get working!). Anyway, here is a link to the forum posting for those who are curious. It is a simple fix that user mtbf0 came up with, but it was over my head!!

That's enough for this project. This one was fun since it actually moves and potentially does useful work!