2/19/2016

Zeo Mobile, bluetooth let mein

Using bluetooth on Windows 7 you can discover and connect to the Zeo Mobile headband without Android.

It was originally designed to partner with a bedside alarm clock. It then evolved to use iOS and then Android.

When it is paired with a desktop it exposes two bluetooth profiles, one for iOS and one for other devices.

The iAP bluetooth profile is Apples proprietary version of the SPP profile for the exclusive use of its manufacturing partners.

The SPP bluetooth profile is a specification for emulating a Serial Port connection over bluetooth using the RFCOMM protocol.

To expose these to applications on a desktop local device drivers must be assigned to each connection.

These are connections initated by the desktop to the device over bluetooth.

While the connections have been established and drivers brought online. I have not had success in opening communications with the device. I am deficient in some crucial bit of information.

Within the same time frame of setting up the outbound connections to the Zeo, an unsolicited [inbound] connection attached to the desktop and spawned a new comm port.

The new comm port however also did not surface information. It could be a timing issue however since I had nothing watching the any of the comm ports.

When I did get around to attempting to connect to them with PuTTY I got error messages like this one:


[Huh - This: Note that RFCOMM/SPP only allows one connection from a remote device to each service. So do not use BluetoothClient and a virtual Serial port to connect to the same service at the same time; the second one will fail to connect. - orthogonal observation, I have several devices paired with same zeo.. any one of which might be holding the port open.. and denying access. - also noticed that in hcitool, (iAP) is on RFCOMM channel 1 (SPP) is on RFCOMM channel 2 ]

It also appears installing the Zeo app causes android devices to publish a bluetooth service called [ Zeo Android ]


There is little known about this [ Zeo Android ] service, except that it would make a good place for a serial port debugger if app developers wanted to create such a thing (pure speculation). It could also be a PIM or OBEX service.. I have no idea. But it is an interesting mystery.

OSX on Mac looks the same:



Windows - automatically provisoning a Virtual COM port when Adding a Bluetooth Device

MSDN [ Installing a Bluetooth Device ]- seems to be saying the bthci service will drive Pnp to install a device driver based on the contents of an inf file. The inf file used will be determined by a matching identifier pulled from the SDP discovery packet, the simplest being based on the discovered 
BTHENUM\{ServiceGUID}
Each service port has a unique guid, therefore a unique inf file should be created for each and installed on the operating system. Many Bluetooth devices seem to skirt this issue by advertising "commonly recognized" ServiceGUIDs like 
GenericSerial, BTHENUM\{00001101-0000-1000-8000-00805f9b34fb}
Since Zeo advertises unique ServiceGUIDs its ports will need special inf files. They should look like the default bthspp.inf file contents with a change to the ServiceGUID identifying the SPP port on the Zeo.

Zeo SDP also does not advertise much more about the device than its name.

Windows also does not have an iAP device driver - the closest in the default windows driver base is for Apple: Apple Mighty Mouse

The purpose of this would be to drive the plug-n-play system such that anytime a Zeo is detected its spp serial port would automatically be assigned a virtual com port and the proper device drivers to support that virtual com port would be loaded. The assumption is of course that while the Zeo mac address will change "slightly" (the last few digits), the SPP ServiceGUID would be a static "assigned" sequence by the manufacturer.

It is also possible that it is not a Serial type of communications, the only thing that makes this look likely is the SDP advertisement. It could also be some other type of protocol. But its unlikely.

I rather think its a protocol that does use RFCOMM but intermitently. That is while on the PC side a virtual serial port must persist, or a program that uses RFCOMM needs to listen, the actual connection and flow of information would be on the zeo terms.. it would waste too much battery power on the zeo to keep the connection up all of the time. So it probably makes a connection, delivers its information, and disconnects.

In the other direction, the pairing operation probably assumes the zeo is in pairing mode, exchanges the passkey '0000' and then closes its connection. The zeo app on the mobile does not appear to proactively reach out and communicate to acquire headband activity, but it does seem to update status.. perhaps the headband reports "status" when a state change occurs. Zeo might be 'broadcasting' its state changes.

A key change that seems 'triggerable' other than 'pairing' is attaching the charger. The app status changes to 'charging' and this might be a good place to be monitoring when the zeo changes state.

On a different laptop with a WIDCOMM chipset.. and that bluetooth stack, I noticed whenever plugging or unplugging the icon for the zeo would change from red to green briefly. While WIDCOMM is old an venerable the tools to work with it are few. But appeared to indicate a state change had occurred.. such as at least the device had established a connection, then disconnected.