insideGadgets

A few months ago I was looking into how to use Fbus with a Nokia phone but didn’t have much luck and instead just wired up the keypad. I decided to revisit Fbus and this time happened to find some AVR code which could send/receive SMS’s so now I’m able to send an SMS using the Arduino and I’ll explain how we do this.

Before I go any further the 3 resources I used were:
Embedtronics – F-bus packet explanation with some examples of a packet
Avr and nokia3310 interface(sms) project on AVRfreaks – Code for an AVR to send/receive SMS
Gnokii – F-bus documentation and code to run on a computer

Firstly you need a Nokia phone which the F-bus commands are known, the best documentation is available for the Nokia 6110 and derivatives (Nokia 6130, 6150, 6190, 5110, 5130, 5150, 5190, 3210, 3310) – this was found in \gnokii-0.6.31\Docs\protocol\nk6110.txt

I was able to purchase a Nokia 6150 from Ebay for under $20. You can search up the Nokia pinout for your mobile phone – I found the TX, RX and GND for my phone.

The F-bus protocol uses 115,200bps so we can easily use the Arduino’s serial function to communication with the phone. All you need to is hook up the phones TX to the Arduino’s RX and then use a resistor divider (I choose 330 ohm resistors) to connect the Arduino’s TX to the phones RX as shown above.

Understanding F-bus packets

So now we have it all hooked up and ready to go, we have to know the frame format which F-bus uses, the \gnokii-0.6.31\Docs\protocol\nokia.txt provides us with this. For my phone it was F-bus version 2.

Frame format for FBUS version 2/Direct IRDA:
{ FrameID, DestDEV, SrcDEV, MsgType, 0x00, FrameLength, {block}, FramesToGo,
 SeqNo, PaddingByte?, ChkSum1, ChkSum2 }

 where FrameID:   0x1c: IR / FBUS
                  0x1e: Serial / FBUS
 DestDev, SrcDev: 0x00: mobile phone
                  0x0c: TE (FBUS) [eg. PC]
 MsgType:         see List
 FrameLength:     {block} + 2 (+ 1 if PaddingByte exists)
 FramesToGo:      0x01 means the last frame
 SeqNo:           [0xXY]
                  X: 4: first block
                  0: continuing block
                  Y: sequence number
 PaddingByte:     0x00 if FrameLength would be an odd number anyways it doesn't exists
 ChkSum1:         XOR on frame's odd numbers
 ChkSum2?:        XOR on frame's even numbers

The Embedtronics website has an example packet which is sent to the phone requesting its hardware/software information and the phones reply with the explanation. I’ll try to combine all the information together in my explanation so you can hopefully understand where everything fits in.

Request phone’s hardware/software information (the data is in hex):

Byte: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
Data: 1E 00 0C D1 00 07 00 01 00 03 00 01 60 00 72 D5

1E: Frame ID – this packet is being sent using F-bus
00: DestDev – this packet is being sent to the phone
0C: SrcDev – this packet is coming from F-bus
D1: MsgType – the type of message we are going to send/receive
If you check out \gnokii-0.6.31\Docs\protocol\nk6110.txt, it will say:
0xd1:
s Get HW&SW version     { 0×0003, 0×00 }
So 0xD1 is the MsgType, the “s” stands for the command we send to the phone and “0×0003, 0×00” is the command we will send to the phone.
00 07: Frame length – the length of the data that follows, in this case it’s 7 bytes going from byte 06 to byte 12.
00 01: Unknown – even though Embedtronics website has an explanation it doesn’t make sense as the only time this appears is if we are sending/receiving data that isn’t an acknowledgement packet, so something to keep in mind. These bytes can be ignored.
00 03 00: Command – in this case we send the Get HW&SW version command as shown above.
01: Frames to go – since we aren’t sending the phone any other frames this is the last frame so we send 0×01 (this isn’t sent in an acknowledgement packet)
60: SeqNo – this is the sequence number we send to the phone, it will ignore the 6 but keep track of the 0. When we or the phone sends an acknowledge to each others packets, we need send back the sequence number we received. The sequence number is incremented for each new packet we send or receive that isn’t an acknowledgement and the sender/receiver have their own sequence numbers which overflow once they reach 3 bits (0, 1, 2, 3, 4, 5, 6, 7, 0, 1, etc)
00: Padding byte – Anything we send to the phone needs to have an even number of bytes, we add this to our packet to bring us up to 16 bytes total length.
72: Chksum1 – An XOR of all odd bytes up to the SeqNo
D5: Chksum2 – An XOR of all even bytes up to the SeqNo

We will take the reply from Embedtronics website:

1E 0C 00 7F 00 02 D1 00 CF 71

1E 0C 00 D2 00 26 01 00 00 03 56 20 30 34 2E 34 35 0A 32 31 2D 30 36 2D 30 31 0A 4E 48 4D 2D 35 0A 28 63 29 20 4E 4D
 50 2E 00 01 41 3F A4

The first frame is an acknowledgement from the phone to us saying it received our request.
1E 0C 00 – Destination and source are swapped around since the phone is now sending a frame back to us
7F: MsgType – the phone is sending us an acknowledgement packet
From nk6110.txt it says:
0x7f: Acknowledge(FBUS/IRDA){+type, seq }
Acknowledge(MBUS)…
00 02: Frame length – 2 bytes.
D1: Command – in this case “+type” is the Msgtype we sent the phone in the previous frame
00: SeqNo – the phone sends back the last number of our sequence number which was 0×60 so it sends back 0×00 (0×60 & 0×07, it only cares about the last 3 bits)
CF: Chksum1
71: Chksum2

The second frame is the information we requested.
1E 0C 00 – Destination and source are swapped around since the phone is now sending a frame back to us
D2: MsgType – the type of message
From nk6110.txt it says:
0xd2:
r Get HW&SW version     { 0×0003 “V ” “firmware\n” “firmware date\n”
“model\n” “(c) NMP.” }
So 0xD2 is the MsgType, the “r” stands for the command we will receive from the phone and “0×0003” is the start of the hardware/software version.

00 26: Frame length – 38 bytes.
01 00: Unknown – looks like this time the unknown data is reversed, can be ignored
00 03: Command – in this case we receive the get HW&SW version
56 20 30 34 2E 34 35 0A 32 31 2D 30 36 2D 30 31 0A 4E 48 4D 2D 35 0A 28 63 29 20 4E 4D
50 2E 00: The HW&SW version which if you put in a hex editor reads as: V 04.45.21-06-01.NHM-5.(c) NMP..
01: Frames to go – last frame
41: SeqNo – the phone has generated it’s own sequence number
3F: Chksum1
A4: Chksum2

Now we have a chance to reply to the phone. If we don’t reply with an acknowledgement packet, the phone will try to send the information to us 3 times but it will still perform the action/command we sent it.

Let’s send a reply, from the Embedtronics website:

1E 00 0C 7F 00 02 D2 01 C0 7C

1E 00 0C – We are sending a frame to the phone
7F: MsgType – we are sending the phone an acknowledgement packet
00 02: Frame length – 2 bytes
D2: Command – in this case we acknowledge the phones message type it sent us in the previous frame
01: SeqNo – we send the phone its own sequence number which was 0×41 so we send back 0×01 (0×41 & 0×07)
C0: Chksum1
7F: Chksum2

Hopefully the above has given you an idea of how we send and receive information from the phone, let’s try this out on the Arduino now. Remember when programming the Arduino, you need to disconnect the phones TX/RX (pin 0 and 1) from the Arduino.

Sending the HW&SW version request

byte msg[] = {
0x1E, 0x00, 0x0C, 0xD1, 0x00, 0x07, 0x00, 0x01, 0x00, 0x03, 0x00, 0x01, 0x60, 0x00, 0x72, 0xD5 };

void setup() {
  Serial.begin(115200);
  delay(1000);
}

void loop() {
  // Initialise the F-bus
  for (int z = 0; z < 128; z++) {
    Serial.write(0x55);
  }
  Serial.println("");
  delay(100);

  // Send our command
  for (int x = 0; x < (sizeof(msg) / sizeof(byte)); x++) {
    Serial.write(msg[x]);
  }
  Serial.println("");

  // Wait for a reply
  while (1) {
    while (Serial.available() > 0) {
      int incomingByte = Serial.read();
      Serial.print(incomingByte, HEX);
      Serial.print(" ");
    }
  }
}

Download fbus_hw_sw_version. In this example, we have our message stored in an array, we initialise the F-bus by sending (0×55) “U” 128 times, send our command from the array, wait for a reply and we don’t send any acknowledgements back.

UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
1E C 0 7F 0 2 D1 0 CF 71
1E C 0 D2 0 26 1 0 0 3 56 20 20 35 2E 30 32 A 30 32 2D 30 32 2D 39 39 A 4E 53 4D 2D 31 A 28 63 29 20 4E 4D 50 2E 0 1 41 3C AE
1E C 0 D2 0 26 1 0 0 3 56 20 20 35 2E 30 32 A 30 32 2D 30 32 2D 39 39 A 4E 53 4D 2D 31 A 28 63 29 20 4E 4D 50 2E 0 1 41 3C AE
1E C 0 D2 0 26 1 0 0 3 56 20 20 35 2E 30 32 A 30 32 2D 30 32 2D 39 39 A 4E 53 4D 2D 31 A 28 63 29 20 4E 4D 50 2E 0 1 41 3C AE

Above we see the results – the 128 U’s we sent, the acknowledgement packet received and the HW&SW version received 3 times, notice that the single characters we receive back such as C, 0, are actually 0x0C, 0×00, etc. There will be random looking characters in-between the 128 U’s and the reply (that I can’t insert into wordpress), which is the command we sent.

I have made a very basic C file fbus_checksum_and_output which can be used to calculate the checksum for any commands you want to send so you can easily modify the code above by just changing the msg array variable.

Sending an SMS

Now we can move on to sending an SMS. Using code provided from the AVRfreaks project, I was able to clean it up and modify it to only send an SMS and do nothing else.

To send an SMS we use:

0x02: SMS handling
s Send SMS message      { 0x0001, 0x02, 0x00 (SEND REQUEST), ... }

But I wasn’t able to find what SEND REQUEST meant which is where the reviewing the Embedtronics website helped find the SMS format.

unsigned char FBusFrame[200];
unsigned char SMSC[] = {0x07, 0x91, 0x16, 0x14, 0x91, 0x09, 0x00, 0xF1, 0x00, 0x00, 0x00, 0x00};
unsigned char RecipientNo[] = {0x0A, 0x81, 0x40, 0x21, 0x43, 0x65, 0x87};

void setup() {
  Serial.begin(115200);
  delay(100);
}

void loop() {
  // Initialise the Fbus by sending "U" 128 times
  for (int x = 0; x < 128; x++) {
    Serial.write("U");
  }

  // Send the SMS message
  SendSMS("Hi All. This message was sent through F-Bus. Cool!!");

  // Keep listening for a reply (we won't send any acknowledgements back)
  while (1) {
    ...
  }
}

We only really have to worry about 2 variables and the SMS message to send.The SMS center number is provided by your mobile phone provider which is relaying the SMS we send on to our recipient. The data in this case isn’t really hex but rather are the actual numbers and are back to front. The SMSC we are using would really read +61 411 990 001 (0×16 reads as 61, 0×14 reads as 41, etc). The same back to front format applies to the ReceipientNo which would really read as 0412 345 678

unsigned char SendSMS(const char *Message) {
  // Clear buffer
  unsigned char j = 0;
  memset(FBusFrame, 0, sizeof(FBusFrame));

  unsigned char MsgLen = strlen(Message), FrameSize = 0;
  unsigned char c, w, n, shift = 0, frameIndex = 0;
  unsigned char oddCheckSum, evenCheckSum = 0;

  // Encode the message into 7 bit characters
  for (n = 0; n < MsgLen; n++) {
    c = Message[n] & 0x7f;
    c >>= shift;
    w = Message[n+1] & 0x7f;
    w <<= (7-shift);
    shift += 1;
    c = c | w;
    if (shift == 7) {
      shift = 0x00;
      n++;
    }
    FBusFrame[frameIndex + MsgStartIndex] = c;
    frameIndex++;
}
FBusFrame[frameIndex + MsgStartIndex] = 0x01;
FrameSize = frameIndex + 44; // The size of the frame is frameIndex+48 (FrameIndex + 48 + 1 - 5)

We encode the SMS message which converts our 8bit ASCII into a 7bit because readable text in ASCII only ranges between 0 – 127 (7 bits) which means if our message starts off with “Hi”, the last bit of the “i” would be on the first bit of the “H”, the Embedtronics website explains this is more detail.

// Insert the frame values to prepare to send an SMS
FBusFrame[0] = 0x1E;
FBusFrame[1] = 0x00;
FBusFrame[2] = 0x0C;
FBusFrame[3] = 0x02;
FBusFrame[4] = 0x00;
FBusFrame[5] = FrameSize;
FBusFrame[6] = 0x00;
FBusFrame[7] = 0x01;
FBusFrame[8] = 0x00;
FBusFrame[9] = 0x01;
FBusFrame[10] = 0x02;
FBusFrame[11] = 0x00;

// Insert the SMS Center number
for (j = 0; j < sizeof(SMSC); j++) {
  FBusFrame[12 + j] = SMSC[j];
}

FBusFrame[24] = 0x15; // Message type
FBusFrame[28] = MsgLen; // Message length (uncompressed)

// Insert the Recipient number
for (j = 0; j < sizeof(RecipientNo); j++) {
  FBusFrame[j + 29] = RecipientNo[j];
}

FBusFrame[41] = 0xA7; // Validity period

We insert the usual starting frames to send an SMS, insert the SMS center number and the recipient number. The other things like message type, validity period,etc I didn’t bother to look into much because the Embedtronics website referred to the GSM spec so I took their word for it and assumed it’s all correct.

// Check if the Framesize is odd or even
if (FrameSize & 0x01) {
  frameIndex = FrameSize + 5;
  FBusFrame[frameIndex] = SeqNo;
  frameIndex++;\
  FBusFrame[frameIndex] = 0; // Insert to make the Frame even
  frameIndex++;
}
else {
  frameIndex = FrameSize + 5;
  FBusFrame[frameIndex] = SeqNo;
  frameIndex++;
}

// Calculate the checksum from the start of the frame to the end of the frame
for (unsigned char i = 0; i < frameIndex+2; i += 2) {
  oddCheckSum ^= FBusFrame[i];
  evenCheckSum ^= FBusFrame[i+1];
}
FBusFrame[frameIndex] = oddCheckSum;
FBusFrame[frameIndex+1] = evenCheckSum;

// Send the full frame to the phone
for (unsigned char j = 0; j < (frameIndex+2); j++) {
  // Debug to check in hex what we are sending
  //Serial.print(FBusFrame [j], HEX);
  //Serial.print(" ");

  Serial.write(FBusFrame [j]);
}

Now we just check if the frame is odd or even and insert a padding byte if needed, we also calculate the checksums and then send all the frames to the phone. If you want to see what it’s actually sending in hex you can uncomment the debug part. Download fbus_send_sms.

UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
1E C 0 7F 0 2 2 83 1C F2
1E C 0 2 0 9 1 8 0 2 64 35 0 1 40 0 3B 39
1E C 0 2 0 9 1 8 0 2 64 35 0 1 40 0 3B 39
1E C 0 2 0 9 1 8 0 2 64 35 0 1 40 0 3B 39
1E C 0 A 0 15 1 8 0 71 1 0 1 B 1 2 F2 D2 1A 3B 5 F5 20 0 0 1 41 0 FC 6A
1E C 0 A 0 15 1 8 0 71 1 0 1 B 1 2 F2 D2 1A 3B 5 F5 20 0 0 1 41 0 FC 6A
1E C 0 A 0 15 1 8 0 71 1 0 1 B 1 2 F2 D2 1A 3B 5 F5 20 0 0 1 41 0 FC 6A
1E C 0 A 0 15 1 8 0 71 1 0 1 B 1 2 F2 D2 1A 3B 5 F5 20 0 0 1 42 0 FF 6A
1E C 0 A 0 15 1 8 0 71 1 0 1 B 1 2 F2 D2 1A 3B 5 F5 20 0 0 1 42 0 FF 6A
1E C 0 A 0 15 1 8 0 71 1 0 1 B 1 2 F2 D2 1A 3B 5 F5 20 0 0 1 42 0 FF 6A 

We receive the reply from the phone. First it sends the acknowledgement packet and a few seconds later it sends the rest.

If you wanted to listen to make sure the SMS was successfully sent you would look at:
0×02: SMS handling
    r Message sent          { 0×0002 }
Which is found at in the text above at: 1E C 0 2 0 9 1 8 0 2

Interestingly it also sends us the network status 6 times after that:
0x0a: Network status
    r network registration  { 0×0071, ?,?,?,length,netstatus,netsel,cellIDH,cellIDL,lacH,lacL,netcode,netcode,netcode }

So that’s all there is to know and now we know to send an SMS! The next step is to move away from the Arduino, we’ll need dedicated USART which the ATtiny2313A and 4313 have so I might pick one of those up and see how it goes. If I can get that working then this can replace the Nokia Keypad SMS Sender that I have connected to my alarm system.

Edit 17/03/13: I found that you can only send 1 SMS with the code above. Trying to send a second SMS only gives back an acknowledgement of the packet we sent but not the SMS itself. After lots of testing, I found that you should firstly send 128 ‘U’, then send the request for the HW&SW command and then send the SMS.