Bluetooth watch and Maemo

    Surely respected% username%, keen on gadgets, at least once, but paid attention to such an everyday accessory, like a wrist bluetooth watch. It is on a bluetooth accessory, not a watch phone and the like. Convenient (in my opinion) auxiliary gadget.

    My adventures with a bluetooth watch began three or four years ago, the theme of such watches flickered in all kinds of near-gadget news feeds. Popular models then were SonyEricsson products, developed in conjunction with Fossil. By that time, I already had a Fossil Abacus Wirst PDA, and I decided to try again the products of this company: I purchased Fossil Abacus CallerID on Amazon.

    Fossil Abacus CallerID is a complete analogue of the SonyEricsson MBW-100. Among the possibilities are synchronization of time with the phone, display of an incoming call (the name of the caller on a small screen, vibration alert), and an “envelope” informing about the arrival of new messages. Both CallerID and MBW-100 are only compatible with a range of SonyEricsson models.

    At that moment in time, I used SE P1i as a work phone and almost did not bother with such limited compatibility. The watch did not publish any bluetooth profiles and did not really want to dig deeper then. So it went until the Nokia N900. At some point, I clicked that I was terribly lacking in the integration of watches with Maemo. Once again, I went through search engines in search of information about the protocol used by the watch ... Development boiled!



    There are several models of watches from different manufacturers with several different functions on the market, they can be divided into groups:
    - Fossil Abacus CallerID , SonyEricsson MBW-100 , MBW-150 and MBW-200 (the last two models from the point of view of User Expirience differ only in the presence multimedia controls).
    - The line of watches Citizen i: Virt and i: Virt-M , designed for the domestic market of Japan. In my opinion, this is the most interesting solution.
    - LG Prada Link , sold exclusively with the LG Prada phone and therefore quite rare and not of (for me) special interest.
    - Various Chinese watches and bracelets. Here we can note LM Technologies LM957, LM-958 and LM959, but I did not come across a single live instance. As for the bracelets, they differ in an extremely curved software implementation.

    Before turning to the story about my project, I want to note the projects of other developers that gave me in one form or another information that allowed me to develop:
    - Sic! BT-Watch for Symbian;
    - smartWatchM for Windows Mobile;
    - Cross-platform OpenWatch , the development of which moves in parallel with mine.

    What advantages does my project have over competitor projects?



    The main difference is the concept. My first requirement was support for User Expirience, which is implemented by each specific watch model, no more. That is, for example, if the watch has the function of displaying the caller’s number, this does not mean that you need to palm off the weather forecast instead. When interacting with a phone, the clock interface is represented by a set of business-level commands, rather than a presentation level.

    The second requirement is to cover the maximum number of watch functions. For example, Citizen i: Virt allows you to display incoming calls, disconnect a call and drop an incoming call, display a list of incoming messages, read incoming messages right on the watch, display and switch phone profiles, display operator names, phone battery level. Finally, they can show various notifications (while vibrating), news (sic!) And even release the camera shutter!

    The third and no less important requirement is a reasonably thought out and compact implementation of the code. My project is developed in C / C ++ only using the stdlib and glib fundamental libraries. STL, Boost, GlibMM and others like them were thrown out of the project at various times because of their gluttony.
    Do not forget that the process should work for months on a mobile device with limited resources of memory, processor, and even take into account the battery life. I am ready to pour a fly in the ointment on the OpenWatch project for wastefulness of resources, poor structure and low concept.

    How do watches work?



    It's funny, but despite the fact that initially it was not clear to me how this works at all, everything turned out to be quite simple. Without the invention of the bicycle.
    All developers of such devices adhere to the recommendations of the Bluetooth Group and ETSI - they use IFCOMM and AT commands for communication. Japanese Mobile Computing Promotion Consortium (MCPC) even published several specifications related to the implementation of BT-watches.

    Fossil and SonyEricsson require the phone to publish an SPP profile with a specific UUID. Other manufacturers adhere to the expansion of the HFP profile.
    Unfortunately, only the trunk version of the BlueZ bluetooth stack allows implementing external agents for AT commands; therefore, supporting the HFP profile is associated with some inconvenience: it is not possible to simultaneously implement support for various bluetooth audio and clocks. (In my implementation, I reduced this inconvenience to a minimum: HFP support is turned on with a “flag”, the Audio BlueZ plugin is disabled only for the duration of the program).

    The set of commands used by Fossil and SonyEricsson is well described in the documentation for different phones from the latter. It is enough just to look at the dump of exchanging hours and phone to decide which teams need to be supported. But here, all the same, not without a kick. Younger models without support for media player control have a full Unicode character generator, while older models only have ASCII, so the caller’s name should be displayed only in graphical form, drawing text on the phone and transmitting the raster to the clock. With the meta-information from the media player, the song is generally: you throw an event from the meta-information in the clock, and they reply to you with a command with the same text - draw it in a raster.

    Separate adventures with Citizen i: Virt. The Japanese are very closed. This watch is designed for the Japanese domestic market and works exclusively with Sharp Softbank and DisneyMobile phones. Here, part of the teams is covered by standard specifications, and for some part, you can find MCPC specifications. The main one is covered only by reverse engineering of dumps. At the current time, the commands for broadcasting news and controlling the camera remain unknown to me, I need to get a phone supporting these functions in my hands and take all traffic between devices for later analysis.

    Integration with Gnome Mobile and Maemo



    I specifically pointed out Gnome Mobile in the title of this section to emphasize the fact that the development of many Linux-based mobile platforms is based on this project. This fact allows you to easily port the application to other Linux-based platforms based on the Gnome Mobile project .

    My project actively uses the object model to implement functional components: A rather thin core is implemented that implements a communication layer with which agents interact - components that implement certain functional domains, such as integration with a modem or Telepathy .

    Direct integration with the modem. I had to implement it for the following reasons: for good, you need to display the status of registration on the network and the name of the operator, an incoming call on the modem appears much earlier than in Telepathy. In addition, I developed this component much earlier than mastered the implementation of Telepathy. The modem API on the N900 is closed, but everything you need can be learned from open sources based on BlueZ reverse engineering.

    Integration with the messaging service. At Maemo, all work with short messages and IM service messages is closely related to the RTCOMM system. RTCOMM provides persistent log storage, so it was logical to use the RTCOMM API to read incoming messages. In addition, rtcomm-event-logger notifies other processes of adding or modifying data using DBUS signals. Telepathy

    Integration. Gnome Mobile and Maemo have one great ability. This feature also corresponds to the concept of the development of 3GPP telephone services. This feature is that all CS-domain phone calls are equated to VoIP-services and IM, and their service is implemented through Telepathy. Since the integration with the messaging service and the modem was done earlier, integration with Telepathy in this case is necessary for servicing VoIP calls. Unfortunately, bindings for C are poorly documented in Telepathy itself, so I had to turn to Impathy source codes for help. The main "footcloth" of this component is GObject, which implements the Telepathy Observer interface.

    The multimedia player in Maemo is implemented using the MAFW framework, the Media Player app appears to be just the front-end for him. Playlist and volume control are implemented through MAFW.

    Basic specs for AT commands include reporting to the accessory status and battery charge. All this can be obtained through libhal. Profile management is implemented through libprofile. To synchronize the time between devices, I had to use libtime. Well, for drawing texts for the Fossil and SE watches - Cairo .

    Now about the most interesting. Receive notifications from the system, call control. All notifications in the system (yellow teasers, calendar, alarm clock, etc.) are implemented by the D-BUS interface org.freedesktop.Notificationsin the notification-daemon process. When you still need to browse or blink something, hildon-sv-notification-daemon (com.nokia.HildonSVNotificationDaemon) comes into action, to which notification-daemon makes the corresponding call. On incoming calls, the Phone application calls hildon-sv-notification-daemon directly.

    Accordingly, the facts of calling methods of these interfaces can be found by setting the appropriate message filters using the D-BUS low-level API. In both cases, it is important to know the handle issued by both daemons as a request. That is, it is necessary to track not only the DBUS messages of method_call, but also method_return, building a correlation between them. The matter is complicated by the fact that in the DBUS low-level API for method_return messages it is only possible to set a global filter, so the implemented monitor code must be very fast and ultra-compact so as not to burden the device with servicing this hook. In addition, I want to draw attention of those interested in defect 1719 to D-BUS. Its presence sets a limit on the ability to implement only one call monitor per process.

    Realized opportunities



    Abacus CallerID, SonyEricsson MBW-100:
    - incoming cellular and VoIP calls - number and name,
    - mute ringtone, reset incoming call,
    - incoming IM and SMS messages - “converter”.
    Sony Ericsson MBW-150, MBW-200:
    - incoming cellular and VoIP calls - number and name,
    - disabling the ringtone, resetting the incoming call,
    - incoming IM and SMS messages - “converter”,
    - volume and playback of the media player.
    Citizen i: Virt:
    - incoming cellular and VoIP calls - number and name,
    - mute ringtone, reset incoming call,
    - missed call log,
    - incoming IM and SMS messages - “converter”,
    - reading unread IM and SMS messages directly on the watch,
    - managing phone profiles - primary and quiet,
    - displaying the current profile,
    - displaying the operator’s name and battery level,
    - notifications of incoming e-mails, notification of the alarm clock and calendar, notification other applications.
    bracelets and stuff:
    ... all that can be of the above.

    In conclusion, I want to give a few videos that I shot during the development process. I apologize for the quality of the video.





    Many thanks to everyone who helped me with the publication on Habré!

    Also popular now: