Securecom; Wireless Personal Alarm, Emergency Software, SMS parser

The Wireless Personal Alarm (WPA/XPA) a pendant like electronic device for use by the old, infirmed and people in high risk situations developed by securecom technologies Ltd. Upon pressing a button on the device it finds the nearest bluetooth phone and GPS unit and uses it to send an emergency SMS message. I worked on this device and created the software that receives and process it's message and displays it on a map.
Technologies: Bluetooth, AT Commands, C Sharp, Securecom WPA (Embedded Bluetooth device), Embedded Devices, Bluecore2 Chip, C, Electronic Engineering
Project Size: 5/5
My Responsibly: Design, Research, Programmer for PC software. Assembly, testing and development on Embeded device.

Description: The Wireless Personal Alarm (WPA/XPA) a pendant like electronic device for use by the old, infirmed and people in high risk situations developed by securecom technologies Ltd. Upon pressing a button on the device it finds the nearest bluetooth phone and GPS unit and uses it to send an emergency SMS message. I worked on this device and created the software that receives and process it's message and displays it on a map.

Introduction:
I was hired by Securecom Technoligies Ltd. to fill the role of software developer and do some work on the hardware of their Wireless Personal Alarm (http://securecom.ie/wireless_personal_alarm.html) a Bluetooth Device that the user would carry and could press a button to ask for assistance from a monitoring site. It used Camberidge Recearch Systems Bluecore 2 Chip to get GPS coordinates from a Bluetooth GPS device and then send a help message through a predetermined Mobile Phone.
When I arrived the Device was working with a Nokia 6310 phone and a bluetooth GPS device. The WPA (wireless personal alarm) communicated with the phone and other devices over Bluetooth using a virtual series port (RFCOMM) and could then give instructions to the phone using AT Commands a language used to communicate with Telecoms equipment. The device would poll the nearby area of a GPS device use Bluetooth to get the position if available, Connect to a Phone, look through the phone book for an emergency contact number and then use the phone to send an SMS to that number containing the GPS information if available.

My roles there were develop software to work with the device. Assemble prototypes and to modify the software running on the devices Bluecore2 chip. The Bluecore2 chip contained a small amount of memory a processor and a bluetooth radio. C Code would be cross-compiled on a PC using GCC and flashed onto the chip.

The device did what it was supposed to but on the receiving end a phone received a text message with some coordinates in it. So I was asked to quickly make something that would do a better job. What the software did was talk to a receiving GMS phone in AT commands on a virtual serial port over Bluetooth and every 10 seconds or so ask the phone if it has any new messages, get them and parse them to get GPS coordinates and show them on a map. It was written in C#.

The main problem with the device was that is did not connect to a lot of newer Bluetooth phones. The prototypes worked perfectly with a selection of Phone models but not with others. This had been a problem that had persisted for a while but no solution had been found.
     I began by reading all of Securecom's code of the device, understanding it fully before moving on. I searched for similar issues and could not find anything obvious.
I found a clue by connection a PC to one phone that worked and another that didn't and manually sending the same AT commands the device would and logging the packets going back and forth. By doing this I discovered that the phones that did work received commands on a virtual COMM1(serial) port while the ones that didn't received on a virtual COMM2 port. The device was sending instructions to the wrong port.
     To rectify this I looked again at Securecom's code before realising that the problem was in CSRs implementation of the RFCOMM portion of the Bluetooth stack. They were informed and it has now been updated.