Bluetooth watches and Maemo
Surely dear% username%, fascinated by gadgets, at least once, but drew attention to such a daily accessory, like a wrist bluetooth watch. It is on the bluetooth accessory, not the watch-phone and the like. Convenient (in my opinion) auxiliary gadget.
My adventures with a bluetooth clock began three or four years ago, the theme of such a clock flashed in all sorts of gadget news feeds. Popular models then were the products SonyEricsson, developed in conjunction with Fossil. By that time, I already had Fossil Abacus Wirst PDA, and I decided to try the products of this company again: I purchased Fossil Abacus CallerID on Amazon.
Fossil Abacus CallerID is a complete analogue of the SonyEricsson MBW-100. Of the possibilities - time synchronization with the phone, display of the incoming call (the name of the caller on a small screen, vibrating alert), and an “envelope” informing you of new messages. Both CallerID and MBW-100 are compatible only with a number of SonyEricsson models.
')
At that moment, I used the SE P1i as a working phone and almost did not strain on such limited compatibility. The watch did not publish any bluetooth profiles and I didn’t really want to dig deeper. So everything went before the appearance of the Nokia N900. At some point, I clicked that I was terribly lacking in the integration of watches with Maemo. Once again, I walked through the search engines in search of information about the protocol used by the clock ... Development has begun!
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 latter two models from the point of view of User Expirience differ from the first ones only by the presence of multimedia control).
- 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 representing (for me) much interest.
- Various Chinese watches and bracelets. Here we can mention LM Technologies LM957, LM-958 and LM959, but I did not come across a single live specimen. What swings bracelets, they differ extremely curve software implementation.
Before turning to the story about my project, I want to mention the projects of other developers, which 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.
The main difference is the concept. My first requirement was to support User Expirience, which is implemented by each particular model of watches, no more. That is, for example, if the watch has the function of displaying the number of the caller, this does not mean that you need to slip the weather forecast instead. When interacting with the phone, the clock interface is represented by a set of business-level commands, not a presentation level.
The second requirement is to cover the maximum number of functions of the clock. For example, Citizen i: Virt allows displaying incoming calls, disconnecting a call and dropping an incoming call, displaying a list of incoming messages, reading incoming messages directly on the clock, displaying and switching phone profiles, displaying the operator’s name, phone battery level. Finally, they can show various notifications (vibrate at the same time), news (sic!) And even release the camera shutter!
The third and equally important requirement is a well thought-out and compact implementation of the code. My project is being 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 certain points in time because of their voracity.
Do not forget that the process should work for months on a mobile device with limited resources of memory, processor, and even consider the battery life. I am ready to pour a fly in the ointment to the OpenWatch project for wastefulness of resources, poorly structured and low concept.
It's funny, but despite the fact that initially it wasn’t clear to me how it works at all, everything turned out to be quite simple. Without the invention of the bike.
All developers of such devices adhere to the recommendations of the Bluetooth Group and ETSI - use IFCOMM and AT commands for communication. The Japanese Mobile Computing Promotion Consortium (MCPC) even published several specifications related to the implementation of BT-hours.
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 BlueZ bluetooth trunk version allows you to implement external agents for AT commands, therefore the support for the HFP profile is associated with some inconveniences: it is impossible to simultaneously implement support for various bluetooth audio and clocks. (In my implementation, I have reduced this inconvenience to a minimum: HFP support is enabled by a “checkbox”, the Audio BlueZ plug-in is turned off only for the duration of the program).
The command set used by Fossil and SonyEricsson is well described in the documentation for different phones from the latter. It is enough to look only at the dump of the exchange of clocks and the telephone in order to decide which teams should be supported. But it is still not without a ticker. Younger models without media player control support have a full Unicode character generator, and older ones only have ASCII, so the caller’s name should be displayed only graphically, drawing text on the phone and passing the raster to the clock. With a meta-information from a media player in general, a song: you throw an event with meta-information at the clock, and they reply to you with a command with the same text - draw it into a raster.
Individual Adventures with Citizen i: Virt. The Japanese are very closed. These watches are designed for the domestic market of Japan and operate exclusively on Sharp Softbank and DisneyMobile phones. Here some of the commands are covered by standard specifications, for some parts you can find the MCPC specifications. The main is covered only by reverse engineering dumps. At the current time, there are no commands for me to broadcast news and control the camera, I need to get a phone that supports these functions, and sniff all traffic between devices for further analysis.
I specifically indicated Gnome Mobile in the title of this section to emphasize the fact that the development of a multitude of mobile platforms based on Linux is based on this project. This fact makes it easy enough to port the application to other Linux platforms based on the Gnome Mobile project.
My project actively uses the object model to implement functional components: Separately, a sufficiently thin core is implemented that implements the 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 registration status in the network and the name of the operator, the incoming call on the modem appears much earlier than in Telepathy. In addition, I developed this component much earlier than I mastered the implementation of Telepathy. The modem's API on the N900 is closed, but everything you need can be learned from open sources based on BlueZ reverse engineering.
Integration with messaging service. In Maemo, all work with short messages and IM services 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, the rtcomm-event-logger notifies other processes about adding or modifying data using DBUS signals.
Integration with Telepathy . Gnome Mobile and Maemo have one great ability. This feature also corresponds to the concept of the development of 3GPP telephone services. This peculiarity lies in the fact that all telephone calls of the CS-domain are equal to VoIP-services and IM-services and their service is realized through Telepathy. Since the integration with the messaging service and the modem was performed earlier, integration with Telepathy in this case is necessary for servicing VoIP calls. Unfortunately, the C options for C are rather poorly documented in Telepathy itself, so I had to contact the source code for the Impathy project 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 application is only a front end for it. Playlists playback and volume control is implemented through the MAFW.
Basic specifications for AT teams include reporting of status and battery charge accessories. All this can be obtained through libhal. Profile management is implemented through libprofile. To synchronize the time between devices, libtime had to be used. Well, for drawing texts under the watch Fossil and SE - 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.Notifications during the notification-daemon process. When you still need to blink or blink something, hildon-sv-notification-daemon (com.nokia.HildonSVNotificationDaemon) comes in, which the notification-daemon makes the appropriate call. For 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 demons for the request. That is, it is necessary to track not only DBUS messages method_call, but also method_return, building a correlation between them. The matter is further complicated by the fact that in DBUS low-level API for method_return messages it is possible to install only a global filter, so the implemented monitor code must be very fast and ultra-compact, so as not to load the device with the maintenance of this hook. Additionally, I would like to draw the attention of those who are interested in defect 1719 to D-BUS. Its presence sets a limit on the possibility of implementing only one call monitor per process.
Abacus CallerID, SonyEricsson MBW-100:
- incoming cellular and VoIP calls - number and name,
- disable the ring tone, reset the incoming call,
- incoming messages IM and SMS - "envelope".
Sony Ericsson MBW-150, MBW-200:
- incoming cellular and VoIP calls - number and name,
- disable the ring tone, reset the incoming call,
- incoming IM and SMS messages - "envelope",
- control the volume and playback of the media player.
Citizen i: Virt:
- incoming cellular and VoIP calls - number and name,
- disable the ring tone, reset the incoming call,
- log of missed calls,
- incoming IM and SMS messages - "envelope",
- reading unread IM and SMS messages right on the clock,
- phone profile management is basic and quiet,
- display of the current profile,
- display of the operator’s name and battery level,
- notifications about incoming e-mails, notifications of the alarm clock and calendar, notifications of other applications.
bracelets and stuff:
... all that they can from 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 all who helped me with the publication on Habré!
My adventures with a bluetooth clock began three or four years ago, the theme of such a clock flashed in all sorts of gadget news feeds. Popular models then were the products SonyEricsson, developed in conjunction with Fossil. By that time, I already had Fossil Abacus Wirst PDA, and I decided to try the products of this company again: I purchased Fossil Abacus CallerID on Amazon.
Fossil Abacus CallerID is a complete analogue of the SonyEricsson MBW-100. Of the possibilities - time synchronization with the phone, display of the incoming call (the name of the caller on a small screen, vibrating alert), and an “envelope” informing you of new messages. Both CallerID and MBW-100 are compatible only with a number of SonyEricsson models.
')
At that moment, I used the SE P1i as a working phone and almost did not strain on such limited compatibility. The watch did not publish any bluetooth profiles and I didn’t really want to dig deeper. So everything went before the appearance of the Nokia N900. At some point, I clicked that I was terribly lacking in the integration of watches with Maemo. Once again, I walked through the search engines in search of information about the protocol used by the clock ... Development has begun!
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 latter two models from the point of view of User Expirience differ from the first ones only by the presence of multimedia control).
- 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 representing (for me) much interest.
- Various Chinese watches and bracelets. Here we can mention LM Technologies LM957, LM-958 and LM959, but I did not come across a single live specimen. What swings bracelets, they differ extremely curve software implementation.
Before turning to the story about my project, I want to mention the projects of other developers, which 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 competing projects?
The main difference is the concept. My first requirement was to support User Expirience, which is implemented by each particular model of watches, no more. That is, for example, if the watch has the function of displaying the number of the caller, this does not mean that you need to slip the weather forecast instead. When interacting with the phone, the clock interface is represented by a set of business-level commands, not a presentation level.
The second requirement is to cover the maximum number of functions of the clock. For example, Citizen i: Virt allows displaying incoming calls, disconnecting a call and dropping an incoming call, displaying a list of incoming messages, reading incoming messages directly on the clock, displaying and switching phone profiles, displaying the operator’s name, phone battery level. Finally, they can show various notifications (vibrate at the same time), news (sic!) And even release the camera shutter!
The third and equally important requirement is a well thought-out and compact implementation of the code. My project is being 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 certain points in time because of their voracity.
Do not forget that the process should work for months on a mobile device with limited resources of memory, processor, and even consider the battery life. I am ready to pour a fly in the ointment to the OpenWatch project for wastefulness of resources, poorly structured and low concept.
How does the clock work?
It's funny, but despite the fact that initially it wasn’t clear to me how it works at all, everything turned out to be quite simple. Without the invention of the bike.
All developers of such devices adhere to the recommendations of the Bluetooth Group and ETSI - use IFCOMM and AT commands for communication. The Japanese Mobile Computing Promotion Consortium (MCPC) even published several specifications related to the implementation of BT-hours.
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 BlueZ bluetooth trunk version allows you to implement external agents for AT commands, therefore the support for the HFP profile is associated with some inconveniences: it is impossible to simultaneously implement support for various bluetooth audio and clocks. (In my implementation, I have reduced this inconvenience to a minimum: HFP support is enabled by a “checkbox”, the Audio BlueZ plug-in is turned off only for the duration of the program).
The command set used by Fossil and SonyEricsson is well described in the documentation for different phones from the latter. It is enough to look only at the dump of the exchange of clocks and the telephone in order to decide which teams should be supported. But it is still not without a ticker. Younger models without media player control support have a full Unicode character generator, and older ones only have ASCII, so the caller’s name should be displayed only graphically, drawing text on the phone and passing the raster to the clock. With a meta-information from a media player in general, a song: you throw an event with meta-information at the clock, and they reply to you with a command with the same text - draw it into a raster.
Individual Adventures with Citizen i: Virt. The Japanese are very closed. These watches are designed for the domestic market of Japan and operate exclusively on Sharp Softbank and DisneyMobile phones. Here some of the commands are covered by standard specifications, for some parts you can find the MCPC specifications. The main is covered only by reverse engineering dumps. At the current time, there are no commands for me to broadcast news and control the camera, I need to get a phone that supports these functions, and sniff all traffic between devices for further analysis.
Integration with Gnome Mobile and Maemo
I specifically indicated Gnome Mobile in the title of this section to emphasize the fact that the development of a multitude of mobile platforms based on Linux is based on this project. This fact makes it easy enough to port the application to other Linux platforms based on the Gnome Mobile project.
My project actively uses the object model to implement functional components: Separately, a sufficiently thin core is implemented that implements the 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 registration status in the network and the name of the operator, the incoming call on the modem appears much earlier than in Telepathy. In addition, I developed this component much earlier than I mastered the implementation of Telepathy. The modem's API on the N900 is closed, but everything you need can be learned from open sources based on BlueZ reverse engineering.
Integration with messaging service. In Maemo, all work with short messages and IM services 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, the rtcomm-event-logger notifies other processes about adding or modifying data using DBUS signals.
Integration with Telepathy . Gnome Mobile and Maemo have one great ability. This feature also corresponds to the concept of the development of 3GPP telephone services. This peculiarity lies in the fact that all telephone calls of the CS-domain are equal to VoIP-services and IM-services and their service is realized through Telepathy. Since the integration with the messaging service and the modem was performed earlier, integration with Telepathy in this case is necessary for servicing VoIP calls. Unfortunately, the C options for C are rather poorly documented in Telepathy itself, so I had to contact the source code for the Impathy project 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 application is only a front end for it. Playlists playback and volume control is implemented through the MAFW.
Basic specifications for AT teams include reporting of status and battery charge accessories. All this can be obtained through libhal. Profile management is implemented through libprofile. To synchronize the time between devices, libtime had to be used. Well, for drawing texts under the watch Fossil and SE - 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.Notifications during the notification-daemon process. When you still need to blink or blink something, hildon-sv-notification-daemon (com.nokia.HildonSVNotificationDaemon) comes in, which the notification-daemon makes the appropriate call. For 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 demons for the request. That is, it is necessary to track not only DBUS messages method_call, but also method_return, building a correlation between them. The matter is further complicated by the fact that in DBUS low-level API for method_return messages it is possible to install only a global filter, so the implemented monitor code must be very fast and ultra-compact, so as not to load the device with the maintenance of this hook. Additionally, I would like to draw the attention of those who are interested in defect 1719 to D-BUS. Its presence sets a limit on the possibility of implementing only one call monitor per process.
Realized Opportunities
Abacus CallerID, SonyEricsson MBW-100:
- incoming cellular and VoIP calls - number and name,
- disable the ring tone, reset the incoming call,
- incoming messages IM and SMS - "envelope".
Sony Ericsson MBW-150, MBW-200:
- incoming cellular and VoIP calls - number and name,
- disable the ring tone, reset the incoming call,
- incoming IM and SMS messages - "envelope",
- control the volume and playback of the media player.
Citizen i: Virt:
- incoming cellular and VoIP calls - number and name,
- disable the ring tone, reset the incoming call,
- log of missed calls,
- incoming IM and SMS messages - "envelope",
- reading unread IM and SMS messages right on the clock,
- phone profile management is basic and quiet,
- display of the current profile,
- display of the operator’s name and battery level,
- notifications about incoming e-mails, notifications of the alarm clock and calendar, notifications of other applications.
bracelets and stuff:
... all that they can from 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 all who helped me with the publication on Habré!
Source: https://habr.com/ru/post/111845/
All Articles