//-->
Google
 

Microcontrollers & Embedded System Designs

Understanding the Protocol

1)    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.

Byte
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
HEX
1E
00
0C
D1
00
07
00
01
00
03
00
01
60
00
72
D5
 
cable
cell
PC
get ver.
framlen + 3
 
 
 
 
 
 
seq
Padd
even
odd

 
 
 
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
 

Byte
0
1
2
3
4
5
6
7
8
9
HEX
1E
0C
00
7F
00
02
D1
00
CF
71
 
cable
PC
cell
Ack
framlen + 2
Type
seq
even
Odd

 
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
 
 

Byte
0
1
2
3
4
5
6
7
8
9
HEX
1E
00
0C
7F
00
02
D2
01
C0
7C
 
cable
Cell
micro
ack
framlen + 2
Type
seq
even
Odd

 
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.
 
Just like 2 people are talking!!! 
There have been 100795 visitors (364338 hits) on this page!
=> Do you also want a homepage for free? Then click here! <=