Zend framework: Working with Gdata

October 9, 2009

In this post, I will talk about working with the open source zend framework and Google Health API . The zend framework offers an elegant method to access health data and post notices. I will talk about using the ClientLogin method first. ClientLogin method is recommended for desktop applications by Google. This post is based on the zend framework documentation and Google health API documentation.

The zend packages are available from Fedora repositories.

Authentication

Authentication is the first step in working with Gdata. The ClientLogin method uses standard username and password for authentication. We will be using the developers sandbox (https://www.google.com/h9) for our testing. The authentication code could be:


function authenticate()
{
$user = "user@gmail.com";
$pass = "passwd";
$h9service = Zend_Gdata_Health :: H9_SANDBOX_SERVICE_NAME;
$client = Zend_Gdata_ClientLogin :: getHttpClient($user, $pass, $h9service);
return $client;
}

This code creates a http client using the ClientLogin mechanism for the H9 sandbox service and returns the client. This should be your first step.

Health Service

The next step is to create a Google health service client from the http client. This could be the code:


$client = authenticate();
$useH9 = true;
$healthService = new Zend_Gdata_Health($client, "MyService", $useH9);

In this code block we call the authenticate() function to get the http client and create a health service client.

Profile List Feeds

ClientLogin Mechanism requires that we extract the profile ID for subsequent queries. It provides profile list feed from which we extract the profile we want.

The register feed is:

https://www.google.com/health/feeds/register/ui/profileID

The profile feed is:

https://www.google.com/health/feeds/profile/ui/profileID

Since one user can have more than one profile ID in Google Health, we need to extract the profile ID we need. For ClientLogin mechanism, we need to set the profile ID for the health service client. In the following code, we extract the profile from profile list feed and set the first profile ID for the health service:


$feed = $healthService->getHealthProfileListFeed();
$entries = $feed->getEntries();
$profileID = $feed->entry[0]->getProfileID;
$healthService->setProfileID->($profileID)

In the code above, we use the profile list feed to enlist all the profiles for a particular user. This feed is available only under ClientLogin authentication mechanism.

Feeds and Queries

Now that we have the profile ID, we can get all the CCR entries from the feed. To do so, we construct a query and use that query to get all the feed entries


$query = new Zend_Gdata_Health_Query("https://www.google.com/h9/feeds/profile/ui/$profileID");
$profileFeed = $healthService->getHealthProfileFeed($query);
foreach ($profileFeed->getEntries() as $entry) {
$ccr = $entry->getCcr();
echo '<p>' . $ccr->getXML() . '</p>';
$count++;
}

In the code above, we just print the CCR entries in XML format. If you want to print text of, say medication, you could use this code:


$query = new Zend_Gdata_Health_Query(SCOPE . "profile/ui/$profileID");
$query->setDigest("true");
$profileFeed = $healthService->getHealthProfileFeed($query);
$entries = $profileFeed->getEntries();
foreach ($entries as $entry) {
$medications = $entry->getCcr()->getMedications();
foreach($medications as $med) {
$xpath = new DOMXpath($med->ownerDocument);
$elements = $xpath->query("//ccr:Medications/ccr:Medication/ccr:Product/ccr:ProductName/ccr:Text");
foreach ($elements as $element) {
echo $element->nodeValue . '<br>';
}
}
}

In the code, above we use setDigest to get the entire feed as one entry. Hence it will loop only once here. We then use DOMXpath object to query the CCR text. We could get text of other categories this way.

Sending Notices

You can send notices to the profile which can be as simple as a text message or can optionally include a CCR element. I will just point out that it is very simple to send these. It is just one call.


$subject = "This is my subject";
$body = " This is the message ";

$healthService->sendHealthNotice($subject, $body);

Its as simple as that.

This concludes this post. In the next post, I will talk about other methods of authentication. This post should hopefully help anyone to get started on the Gdata API immediately.


Bluez tools and programming – Part II

October 2, 2009

In this post I will continue exploration of bluez tools and programming. Please check back my last post for part I.

hcitool

Let us explore the information extracted by hcitool. The format of the command is

$ hcitool [options] [command]

$hcitool dev

This will output the local devices in the format [hciX] [BD Address]

hcitool inq

This will inquire remote bluetooth devices and output information of the device. On my machine the output was

[BD Address] [Clock offset] [class]

This will scan the remote device. As opposed to inquiry, this will just output the bluetooth address and the user friendly name of the remote device.

hcitool name [BD address]

Given the address of the remote device, this command outputs the user friendly name.

$ hcitool info [BD address]

This will output the information of the remote device given its address. On my machine, it gave me this:

Requesting information …
BD Address: 00:20:E0:CC:29:7B
OUI Company: Actiontec Electronics, Inc. (00-20-E0)
Device Name: Blue1-0
LMP Version: 1.1 (0x1) LMP Subversion: 0x322
Manufacturer: Cambridge Silicon Radio (10)
Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00

As you can see, it outputs information needed for making a connection.

hcitool cc [BD address]

This creates a ACL connection to the bluetooth device whose address is given. You can specify the role of the local device as master or slave using -m option. Please note that this connection is not meant to stay endless. They will be disconnected. You should use other methods for persistent connections (I will talk about them later).

hcitool dc [BD address]

This will disconnect from the connected bluetooth device.

hcitool con

This displays the list of connections. The output might look like this:

Connections:
< ACL 00:20:E0:CC:29:7B handle 0 state 2 lm MASTER

This tells us that the host is connected to a device with address 00:20:E0:CC:29:7B. It is a ACL link and it is the master in the connection.

hcitool sr

This enables switching of roles of the host device. If it is master, you can switch it to slave.

hcitool rssi [BD address]

This displays the connection signal strength. The output might look like this (it says 1 for my connection).

RSSI return value: 1

hcitool lq [BD address]

This displays the link quality of the current connection. The output might look like this.

Link quality: 255

hcitool tpl [BD address]

This displays the transmit power level of the current connection. The output might look like this (it shows 0 for my connection).

Current transmit power level: 0

hcitool afh [BD address]

This displays the AFH map in hexadecimal. The output might look like this.

AFH map: 0xffffffffffffffffff7f

hcitool lp [BD address]

This displays the link policies of the current connection.

hcitool lst [BD address]

This displays the link supervision timeout settings. The output might look like this.

Link supervision timeout: 32000 slots (20000.00 msec)

hcitool clkoff [BD address]

This displays the clock offset setting of the remote device. The output might look like this.

Clock offset: 0x5206

hcitool clock [BD address]

This displays the clock of the remote device.

hcitool key [BD address]

This changes the link key (the pin) between the two devices.

This completes the most useful options for the command. There might be others that you might want to see. But the most important thing about hcitool is to know the various connection parameters.

In the next post, I will look into the BlueZ API. This will give us the capability to program these devices.


Bluez tools and programming – Part I

September 18, 2009

In this post, I will talk about the bluez userspace tools. I am using Fedora 11 for this exploration but it is applicable irrespective of the distro.

The bluetooth specification is very useful if you need to learn everything you need to learn! I have used the specification to extract and present some information here. The official page has all the information.

The userspace tools in bluez that are useful for the programmer are: hciconfig, hcitool and hcidump. I will attempt to describe the information extracted by hciconfig in this post.

hciconfig

To start using this tool, simply type the command:

$ hciconfig

This will output basic information about all the bluetooth devices.

or

$ hciconfig -a

This will output “all” the information (hence the option “a”) about the bluetooth devices

To know the usage for hciconfig, use option “h”

$ hciconfig -h

Let us examine the output of the command and understand the contents.

This would be a sample output for hciconfig -a

hci0: Type: USB
BD Address: 00:10:60:B2:9F:42 ACL MTU: 377:10 SCO MTU: 64:8
UP RUNNING PSCAN
RX bytes:1647 acl:0 sco:0 events:49 errors:0
TX bytes:454 acl:0 sco:0 commands:50 errors:0
Features: 0xff 0xfe 0x0d 0x38 0x08 0x08 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy:
Link mode: SLAVE ACCEPT
Name: ‘Blue-0’
Class: 0x4a0104
Service Classes: Networking, Capturing, Telephony
Device Class: Computer, Desktop workstation
HCI Ver: 1.2 (0x2) HCI Rev: 0x0 LMP Ver: 1.2 (0x2) LMP Subver: 0x309
Manufacturer: Broadcom Corporation (15)

This output shows that one bluetooth device is attached. Let us explore the meaning of the output.

USB: This is a USB device connected to out host. Other kinds could be UART, for instance.

BD Address: 00:10:60:B2:9F:42: This is the 48 bit unique hardware address of the device, similar to the MAC or Ethernet address

ACL MTU: 377:10 SCO MTU: 64:8: They refer to the two kinds of bluetooth data links: Asynchronous Connectionless Link (ACL) and Synchronous Connection Link (SCO). MTU refers to Maximum Transmission Unit which is the maximum Service Data Unit (SDU) they device is capable of receiving. For this device 377 refers to the MTU for ACL packets and 10 refers to the number of ACL packets sent in a transmission. Similarly 64 refers to MTU for SCO and 8 refers to the number of SCO packets sent in a transmission.

RX bytes:1647 acl:0 sco:0 events:49 errors:0: This refers to the statistics of the received bytes. It shows that no ACL or SCO bytes were received.

TX bytes:454 acl:0 sco:0 commands:50 errors:0: This refers to the statistics of the transmitted bytes. As before, it shows that no ACL or SCO bytes were transmitted.

UP RUNNING PSCAN: These are the bluetooth link states. The official spec defines them as substates. These substates define the parameters to enable discovery and establish connections with other bluetooth devices. The important substates are: page, page scan, inquiry, inquiry scan (The standby and connected states are kind of self-explanatory).

Broadly, paging substates are used for establishing connections and inquiry substates are used for discovery of devices.

page state: A bluetooth device in this state is the master device that is sending paging messages for connection
page scan state: A bluetooth device in this state is the slave that is set to receive paging messages from a master
inquiry state: A bluetooth device in this state is attempting to discover other devices in the vicinity.
inquiry scan state: A bluetooth device in this state is discoverable to other devices in the vicinity.

From the output, we see that our bluetooth device is in page scan state as well as UP and RUNNING.

Features: 0xff 0xfe 0x0d 0x38 0x08 0x08 0x00 0x00: This is a long list of features supported by the device. These are transmitted as Link Manager Protocol (LMP) messages for the devices to know each others capability. Each feature is represented as a bit mask. 1 indicates that the feature is supported and 0 indicates that it is not supported. Some of the features are represented by more than one bit.

For instance, byte 0, which is 0xff indicates that all the features in this byte are supported: They are: 3-slot packets, 5-slot packets, encryption, slot offset, timing accuracy, role switch, hold mode, sniff mode. The official bluetooth spec has the list of all the features if you are interested.

Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3: This lists the baseband layer data packet types supported by this device. They are represented as 4 bit fields. Please check the official specification if you are interested in details of all the data packet types.

Link policy: This refers to the settings which determines the behavior of the bluetooth device when it receives a request from another device. The possible policies are DISABLED (which is the current setting), ROLE SWITCH, HOLD, SNIFF and PARK.

Link mode: SLAVE ACCEPT: The modes for the bluetooth linking protocol. The other modes could be MASTER for instance.

Name: ‘Blue-0’: The user friendly name of the device.

Class: 0x4a0104: This is an identifier for the device composed of 3 bytes. The man page for hcid.conf describes them in detail. If we proceed from MSB to LSB for this number,

0x4a (Represents the service classes of the device): Bits 2, 4 and 7 are set which indicate “Networking, Capturing, Telephony”.
0x01 (Represents major device class): Bit 1 is set which indicates “Computer”.
0x04 (Represents minor class): Bit 2 is set which indicates “Desktop workstation” of major device “Computer”.

Service Classes: Networking, Capturing, Telephony: This refers to the services that the current host configuration can offer. It can be anything related to services offered by the device like “Rendering”, “Positioning” etc.

Device Class: Computer, Desktop workstation: The major and minor device classes as discussed above.

HCI Ver: 1.2 (0x2) HCI Rev: 0x0 LMP Ver: 1.2 (0x2) LMP Subver: 0x309: This refers to the versions supported by this device.

Manufacturer: Broadcom Corporation (15): The manufacturer of the bluetooth device.

Changing parameters via hciconfig

You can change configuration parameters via hciconfig. To see all the command line options:

$ hciconfig -h

Usage:
hciconfig
hciconfig [-a] hciX [command]
Commands:
up Open and initialize HCI device
down Close HCI device
reset Reset HCI device
rstat Reset statistic counters
auth Enable Authentication
noauth Disable Authentication
encrypt Enable Encryption
noencrypt Disable Encryption
piscan Enable Page and Inquiry scan
noscan Disable scan
iscan Enable Inquiry scan
pscan Enable Page scan
ptype [type] Get/Set default packet type
lm [mode] Get/Set default link mode
lp [policy] Get/Set default link policy
name [name] Get/Set local name
class [class] Get/Set class of device
voice [voice] Get/Set voice setting
iac [iac] Get/Set inquiry access code
inqtpl [level] Get/Set inquiry transmit power level
inqmode [mode] Get/Set inquiry mode
inqdata [data] Get/Set inquiry data
inqtype [type] Get/Set inquiry scan type
inqparms [win:int] Get/Set inquiry scan window and interval
pageparms [win:int] Get/Set page scan window and interval
pageto [to] Get/Set page timeout
afhmode [mode] Get/Set AFH mode
sspmode [mode] Get/Set Simple Pairing Mode
aclmtu [mtu:pkt] Set ACL MTU and number of packets
scomtu [mtu:pkt] Set SCO MTU and number of packets
putkey [bdaddr] Store link key on the device
delkey [bdaddr] Delete link key from the device
oobdata Display local OOB data
commands Display supported commands
features Display device features
version Display version information
revision Display revision information

For instance, to make the device discoverable:

$ hciconfig hciX iscan (or piscan to enable both page and inquiry scan)

In the next post, I will talk about more command line tools and bluez API.


Sound on ASUS M2A-VM HDMI MB with 64 bit Linux

August 26, 2009

If you don’t have sound on this MB with 64 bit Linux, upgrade your BIOS to latest (V 2301 at this time). It fixes the card detection issue.


radeon_gem_do_relocate message. Whats that?

August 26, 2009

My home machine runs F12 on a ASUS M2A-VM HDMI MB. With the changes to the radeon driver being continuously worked on, I get this message with my ATI X1950Pro card:

[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4

I presume it is harmless and only for debug purposes on Fedora.

Update: Looks like a bug has been reported on bugzilla: Bug 499335