This tutorial is meant for all enthusiasts who want to turn their appliances on/off with the famous 8051.
A lot of info is freely available on the net on subjects aforementioned. Many old phones qualify for the job. Siemens, Ericsson etc have an inbuilt modem so do recent Nokia phones. It is quite easy to understand the command set of these phones as they can be governed by ‘AT’ commands and can be operated on a modest 4800/9600 baud.
Well, I am not going to go deeper in explaining ‘AT’ controlled phones.
I intend to use the Nokia older phones like 5110/3210/3310 etc, for which Nokia has developed its own protocol which it calls MBUS and FBUS.
MBUS is the older and slower one which operates like half duplex and can be used @ 9600 bauds. This communication uses only one wire therefore; whatever is xmitted is received on the same line, so it’s a bit difficult here.
The other protocol is FBUS (currently FBUS2) which operates @ 115200 bauds and is full duplex. There are 3 wires Tx, Rx, Gnd as in RS232. We will be using this protocol.
Looking at the popularity, we will use the Nokia 3310 phone (likewise 5110, 6110, 3210 can be used, but will have to check the pinouts for those)
Download abhi_FBUS.xls
Download Circuit Diagram
Setting up the Phone
It’s a bit tricky to get to the FBUS pins in Nokia 3310.They are below the battery.
There are special data cables for this and you can get it from a mobile/cable shop for around Rs 100/- (You will have to check if it’s an MBUS or FBUS cable though)
(Incidentally if you are in Pune, you can get it near Dagdusheth ganpati)
The cable looks like this
The encircled part is the pins that fit in Fig1.0 (phone)
Note: To check whether the cable is FBUS/MBUS, remove the 4 screws (one is shown by arrow). If the Tx, Rx, Gnd are separate pins (not soldered together) then its FBUS. Some FBUS cables which have MBUS pin disabled have an unknown config, that I was unable to understand but surprisingly work well with Logomanager (nokia s/w).What I did was separate the pins in the connector, and use individual pins. But before this I cut off the DB9 end, and put a plain DB9.The cables DB9 has electronics in it. (See Fig 1.2)
If you are to use the above cable be sure to connect DTR and RTS as shown above else the cable will not get power, and you will be left wondering ‘what’s wrong with my schematic?’ This is because the cable when connected to the PC and accessed through Logomanager works fine.
But if you were not to use the above schematic, do following steps.
a) Cut off the DB9 portion(which houses above electronics)
b) Add a plain DB9 connector to the wires which are cut loose. Connect Rx to Pin 2, Tx to pin3 and Gnd to pin 5.
c) The phone runs on 3V, and our Microcontroller (haven’t discussed it yet) runs on 5V.So it will sure damage the phone. For this, just convert the 5V on microcontroller Tx side or correspondingly on Phone Rx side(simple voltage divider which converts 5V to 3V See Fig.1.3)
d) Nothing to be done on Micro Rx side because it works with 3V.
But apart from above steps you can directly solder wires to the FBUS (but be careful )
Hurray we have setup our phone for communication, and we are ready!
Communicating with the Phone
As said earlier, communication with the phone is full duplex 8 bits, no parity, 1 stop bit and @115200 bauds.
So when connecting the AT89S52 microcontroller to the phone you have to setup baud rate of 115kbps using Timer 2. To initiate the communication we have to send character ‘U’ or 0x55 128 times to the phone. That’s all. The race track is ready now!
Understanding FBUS protocol
So here’s the difficult part. The FBUS2 protocol is made up of numerous bytes and always start with ‘0x1E’ for cable type of connection (we are really not worried for IR or Bluetooth here)
Let’s see a frame of bytes which when sent to the Nokia 3310/5110 phone will reply back with the h/w and s/w version of the phone.
Byte0=Frame id 1E=cable
Byte1=Destination address=00=phone
Byte2=Source address=0C=terminal/micro/PC
Byte3=Type of command (D1=get version)
Byte4=MSB of frame length
Byte5=LSB of frame length=07 (7bytes ahead and more)
Byte6=Byte7=Byte8=Byte9=Byte10=Byte11=don’t need to worry about them! J
Byte12=Sequence number or Seq.No. (Very important)
Byte13=is padding byte and is present if Frame length is odd.
Byte14=Even checksum
Byte15=Odd checksum (embedtronics.com was wrong here)
Byte5 has the info of how many more bytes there are about to come till Seq.No.. comes (which means that after Seq.No.., minimum 2 bytes checksum are always present and a padding byte=0x00 is inserted to make the whole frame even .In our case padding byte=0x00 is present since frame length is odd=0x07)
A little more about the sequence number here: The Seq.No. as the name suggests defines the sequence of frames and goes from 0 to 7 and back to 0..and so on.
E.g: In above example if we were to send the same Get version frame 9 times in a row, what should be done? You are absolutely correct! In the first frame, Seq.No.. is 0x60, next its 0x61,next 0x62……0x67 (and back to..) 0x60. That’s all. The phone will be having a count of the source’s (micro) Seq.No.’s, and if it’s incorrect, then phone will not respond. And you will have to re-initiate the whole ‘U’ sending again.
Now about the checksums. These are nothing but the XOR of all bytes. In our case they are XOR of all bytes in even positions and odd positions
E.g.: in above example the even checksum will be calculated like this
Byte0 XOR Byte2 XOR Byte4 XOR Byte6 XOR Byte8 XOR Byte10 XOR Byte12
0x1E ^ 0x0C ^ 0x00 ^ 0x00 ^ 0x00 ^ 0x00 ^ 0x60
=0x72
(Keil compiler)
Whereas odd check sum is obtained by XORing all odd placed bytes
Byte1^Byte3^Byte5^Byte7^Byte9^Byte11^Byte13=0xD5
Now we’ve understood how a frame is made up.
When such a frame is sent, the nokia phone replies with 2 frames
a) An acknowledge frame to tell us that ‘he’ recd the frame.
b) Actual data frame.
Let’s see how the ACK frame is made up
Keep in mind, the above frame is sent by Nokia. (Nokia is source now)
Byte0=Frame id 1E=cable
Byte1=Destination address=0C= terminal/micro/PC
Byte2=Source address=00= phone
Byte3=Type of command (7F=acknowledge frame)
Byte4=MSB of frame length
Byte5=LSB of frame length=02 (2 bytes)
Byte6= (replying to what was sent/asked by micro) D1=get version
Byte7=Seq.No. (no padding byte present after Seq.No. since
Frame length=0x02=even)
Byte8=Even check sum
Byte9=Odd check sum
After this ACK frame, the phone will send the actual data frame, with the h/w and s/w version (check my excel sheet on this)
It isn’t over yet!..The phone also wants a confirmation that we/microcontroller have received the data, so it will be waiting for the ACK frame that we are supposed to send. If we don’t send this ACK frame, the phone sends the data two more times (after the first frame) which means that we are entitled to the data 3 times before phone stops sending data.
This also means we need to send an ACK frame to the phone now. This too is quite simple .The ACK frame that we should send is like this
I think there’s no need to explain the bytes now, but for the sequence number.
When we/micro sends an ACK frame, the sequence number is not the one we are generating (from x0 to x7) but it is the last three bits of the Seq.No. of previous received data frame. No? Haven’t got it? Let’s take the example of the Get-version frame.
The phone had sent 0x41 as the sequence number in its h/w , s/w data frame
0x41= 0100 0001 b
We need to send the lower three bits xxxx x001 b of this Seq.No. as our ACK frames sequence number. (But I have found that the lower nibble’s MSBit is never 1, so masking off the higher nibble just does the job)
You know how to calculate checksums.
The general idea is like this
a) Abhijit asks for some data
b) You say, “I understood what you want”
c) You send what Abhijit wanted.
d) You wait to see if Abhijit got what he wants.
e) If Abhijit does not say that he received the data,You send the data one more time.
f) You wait to see if Abhijit got what he wants
g) If Abhijit does not say that he received the data,You send the data one more time.
h) Now You stop sending data.(Since Abhijit is really deaf or he is rude)
i) On the contrary if Abhijit says he got the data the very first time, you stop sending more data.
Understanding a received SMS Frame
When your girl friend (or boyfriend! Hi to all girls) sends you an SMS like
“Get lost!” (W/o the quotes lol) do you really know what’s going on underneath (I mean in the protocol)
Let us see that now.
When an SMS is received on your phone, phone will immediately send the SMS on the FBUS to your microcontroller(in our case AT89S52), like in the excel sheet (SMS sent was “hello”). Let’s understand it.
(I will now discuss only the relevant bytes now)
Byte3=Type=SMS functions=0x02
Byte5=Frame length=0x31=odd=there has to be padding byte after Seq.No.
Byte9=Subtype of SMS functions=SMS recd=0x10
Byte10=SMS location? SIM/PHONE; 0x02=SIM
Byte11=Inbox location=0x07=7th position (will be required to delete SMS)
Byte15 to Byte 20=SMS service centre no.
e.g. The number is recd as BCD
Byte28=SMS length=0x05 (5 bytes ‘packed’sms.We will come to ‘packed’ after this)
Byte31 to Byte36=Senders number (recd same as SMS service centre no.)
Byte48=SMS data starts here and ends at offset given by Byte28.
(Seq.No. and check sums as earlier)
What is a packed SMS?
The packed SMS for ‘hello’ is
Actually you can find more info on this subject by googling for PDU format or TPDU
The site www.embedtronics.com also gives good info on this.
Now how do you decode this SMS?
Simply DON’T! I didn’t!
Instead store coded templates of the SMS (as the above one) in code memory for your various devices to be controlled.
E.g. If you have 4 devices to be turned on and off, name them
Device1, Device2, Device3, Device4
So now if Device2 (connected to P2.5) has to be turned on, send SMS
Device2 on
Which when coded is C4 B2 3D 3D 2E CB 40 6F 37 (hex)
So now you can put this code in Code memory and compare the received ‘packed’ SMS instead of decoding/unpacking the SMS. Quite easy!
But otherwise you can write the unpacking code too at the cost of memory.
We are using AT89S52 which has got 256 bytes RAM and 8K code memory.
But since it does not have EEPROM, there is no point customizing SMS for user and therefore no need unpacking the SMS.
To summarize, whichever way, you can now take appropriate action according to the SMS received.
Deleting SMS
Once action has been taken on the SMS, it is really no worth to us now and must be deleted, otherwise the inbox gets full. See the frame for deleting SMS in excel sheet(Download section).
Byte9=SMS delete command=0x0A
Byte11=SMS location in inbox, should be taken from SMS recd frame (Byte11)
Calculate Seq.No. and check sums as usual.
If correct delete is done, phone replies with Delete-Ok frame (check sheet)
What do you need to do with that?
You need to send ACK to that yaar!
If somehow, the delete command was unable to do the deleting operation, which may be due to numerous reasons, (The basic reason being the noise on FBUS [which we can do really nothing about, with the scheme we are using].
Other reason is sending wrong Seq.No. Protocol is really strict with this!)
Phone sends a Delete error frame (check sheet).So you know that the particular SMS has not been deleted, and needs to be sent a fresh Delete-frame.
Alternate method to get SMS
Incidentally there is another way to get the SMS than wait for it.
In the above frame (SMS handling) the Byte9=0x07 is the Get-SMS command.
So what you can do is, check for a location (Byte11) say 2nd location for new SMS after a specified interval (which you can decide 5 seconds, 10seconds etc).
If there is no new SMS, alternately the location is empty, Phone replies with
Empty-SMS frame which you can check in the excel sheet
So now everything is clear I hope. We have discussed just the SMS related functions of the FBUS because that was all we needed. You can check www.gnokii.org for more information on other features like Call-handling, Battery-monitoring to name a few.
Some TIPS
· We had started with using the AT89S52 controller which has the limitation of RAM size (256 bytes).All the frames are received in this RAM of which half may be used for stack operations, registers etc.
You have seen that a mere ‘hello’ frame is 58 bytes long. Some more declarations will require using RAM, so more and more of RAM is used. In such a case what if a really long SMS is received?
No need to panic! Simply delete such an SMS without taking any action. Subsequently all that needs to be taken care of are the actual SMS we are going to consider or have stored in our code memory!
People have therefore used AVR controllers for this. Incidentally you can use external EEPROM for the 52 controller as well. However using the S52 is simpler and serves the purpose of only switching devices on/off
· We have not discussed anything about the Battery connections and charging it. You cannot remove the battery and connect +5V directly to the battery terminals. The battery has some electronics built in to identify type of battery and temperature of battery. Elaborately what you can do is design a charger which switches off when battery is fully charged (nokia battery chargers are CV chargers and have no electronics to cut off power on full charge)
· The above method is tedious and a simpler way exists. Take an old nokia battery, disassemble it. Now connect your power supply +5V to the B+ and Gnd to B- terminals.
· Power Supply should be able to deliver up to 3A max
0 comments:
Post a Comment