Cell Phone Comm | Senior Capstone Experience in Computer Science

Monday, April 30, 2007

Presentations are over now. There have been quite a few developments as of late which will now be posted on the downloads page. I think the Visual Basic code has turned out nicely. As for the Eye-Q I was able to get my hands wet and do some "proof of concept" type programs. The concepts from VB ought to port very nicely to the Eye-Q. We'll see how much I might be able to do in the next week if I can. Otherwise, even though the environment is not difficult exactly, there still is a learning curve involved. Either way, this is not quite the end for the project yet. I'll be sharing my results with Corey from Ariens a week from today.

Monday, March 26, 2007

So after presentations two weeks ago, one of the biggest questions of myself, Mr. Blahnik, and others was communicating between the Eye-Q and the wireless modem. Before spring break we made some phone calls to Multitech's technical support and they were able to point us in the right direction. After issuing commands for the modem to not use RTS/CTS flow handshaking and to ignore DTR and after obtaining a null modem cable to switch the transmit and receive lines, we were able to get communication working today. The Eye-Q was successfully able to communicate with the wireless modem in both directions; we were able to send an AT command and receive a response.

Right now, I will be working on installing CodeWarrior and getting ahold of a battery for me to use to power the Eye-Q once I receive it. I'll be excited to get this working from my own workspace.

Wednesday, March 7, 2007

I wrote a program today that was able to query the modem for information (model, serial, etc.) and send out a text message, both under program control. The idea behind the program is that it separates input incoming from the modem into lines and then places those lines into one of two queues. The first, and default, queue is the response queue. The second queue is the event queue. Only unsolicited "events" are being placed in here (i.e. new text message signal, telephone ring, no carrier signal, etc.). In this way, normal responses to user-issued modem commands are in one queue, whereas specific unsolicited events are in the other queue. I verified that upon receiving a text message, the indicator was indeed placed in the event queue. There are a few issues and bugs to work, however this looks promising. Corey will be here from Ariens on Friday to receive an update on what's been happening.

Monday, February 26, 2007

Work continues on figuring out just which of the AT Commands will be used in the API and which functions they will be used in. However, today I spent a lot of time thinking about a specific issue. If I give the cell modem an AT command, I will get an immediate response. However, sometimes the cell modem will send information to the computer unsolicited. For example, it will send a message after a text message is received. As well, every so often the cell modem will send an "OK" message apparently for no reason other than to inform the computer that it's still alive and well. The difficulty here will be in sorting out the data and getting it back to the right function calls. I will also need to be able to ignore any unsolicited input from the cell modem that I don't care about or haven't foreseen.

Sunday, February 18, 2007

Testing was a little difficult at first this week because it turns out the service plan on the cell modems had expired. Luckily, it just required getting the plan reactivated. I was able to hook up two cell modems to my computer, and I verified by running two copies of the VB test program on my computer and the appropriate AT commands that I was able to send and read a text message from each cell modem to the other. My immediate focus right now seems to be in setting up a plan for the organization and functionality of a Windows API for using the cell modems for text messaging. As well, last week I talked to Mr. Blahnik about the ordering of Code Warrior and the book. This should be taken care of now.

Sunday, February 11, 2007

So far the major development is a program showing the ability for a computer and the cell modem to talk to each other through a Visual Basic program using AT commands. Using AT commands, I have been able to do simple tasks such as checking the cell modem's model and serial numbers. As well, I have been able to call the cell modem from my own phone, receive notification within Visual Basic that there is an incoming call, and issue an AT command to answer the call. Also, I can send the cell modem a SMS text message and then issue an AT command to read the message. I was able to get Visual Studio 6 installed on my computer, and Mr. Blahnik was able to help translate my code from VB .NET to VB 6. As an editorial note, I am kind of disappointed with the decision to use Visual Basic 6. Not that using Visual Basic 6 will make the project any "harder", it's just that I feel Visual Basic 6 is only the second best tool for the job. The process of converting the code was easy enough, but the end result only comfirmed my suspicions that while functionality will remain the same, it will require more effort on my part to write a program of the same quality, especially when it comes to error handling and user interface design. I understand the reasons why Mr. Blahnik is pushing for VB 6, but right now I kind of wish I didn't know what I was missing out on with VB .NET.

In reading documentation, it appears there are two modes in which one can read or write SMS text messages using AT commands. First, there is a text mode which is the default mode of use. An SMS message can be up to 140 bytes long not including the header. By default, the text mode will send up to 160 characters at 7 bits per character. Alternatively, there is a PDU mode. Using this mode, we can specify the exact binary content of the 140 bytes of the message. However, we do not communicate with the cell modem in binary. The information to be sent (or that was received) is encoded in hexadecimal using the characters '0'-'9' and 'A'-'F'. Given the nature of the data we want to send, PDU mode seems to be the best candidate. However, in this mode the header information is also represented in hexadecimal, so I will likely have to research the format of the header information.

So now that I've done a recap of what's been going on so far, here's what the week ahead holds for me. My first goal for the week is to prove two way communication between two computers under program control through the cell modems. My second primary goal is to figure out which AT commands I will be using in the API to send/receive SMS text messages and to research the header format for "PDU Mode."

Monday, January 29, 2007

The website is up and running. More to come later...