I do not receive notifications for SMS & MMS messages on dory. My phone is an Android One moto x4 running Android 9.0 and AsteroidOSSync 0.13. I receive all other notifications.

On another note, I tried to ssh into the watch to pull some logs for this post (using ceres and root @ the default IP address), but my connection keeps timing out. I took a pcap of the connection and it was all TCP Retransmissions.

I want to work on this though because I otherwise love AsteroidOS so far. :) Thanks for making!

This is mostly a question born from simple curiosity. I was wondering what would be needed to create a daemon application (say for Ubuntu Touch) that would provide the same function as the Android BTSync application for Asteroid. Would love to try my hand at creating a sync daemon for linux workstations and Ubuntu Touch, but I am unfortunately unsure to where I should begin. What Bluetooth protocols are used, and would it be possible to connect and communicate using a simple Bluez binding for my favorite language? Hell, I'll even take a nice pointing in the right direction as to what part of this and the Android project I should study.

Sorry, I just love how Asteroid is turning out, a little excited to breathe some new life into my G Watch and would like to try my hand working with it.

As mentioned before in the Matrix channel, on my old phone it happened regularly that when my watch connected, it lost connection right away. The AsteroidOS Sync android app would should show either 0% or 100% battery regardless of the actual battery and show the menus as if connected, but of course no syncing would actually happen.

@beroset recently seemed to have the same issue on his laptop, and might be able to debug more.

Moved from AsteroidOs issues.
I have now made further progress in tracking this error, I believe this to be a better repo to raise the issue.
The local services seem to be able to register correctly to the bluez stack, however on request from remote connections the service discovery results appear to cause the errors below.
This can be reproduced on any pairing and SD session and does not appear to be specific to AsteroidOSsync app.
My fedora based laptop using bluez5 & supported hardware also fails.
On the latest build for dory there seems to be an issue with Bluetooth connection failing. After
numerous attempts, it seemed to successfully pair but seems to fail then disconnect. logs show failure at negotiating services. bluetoothd also reports no cache for device address.
The link below has a gist with logs for hcitrace via btmon and journalctl logs with bluetoothd in DEBUG mode.

there is approximately one connection, pairing , and disconnect in the logs which can be found here:

https://gist.github.com/davnustratbac/e99e46c098cea85796fdb2a91b189a44

Packet dump file of same timeframe:

https://s3-eu-west-1.amazonaws.com/wireshark-bucket/journalctl-debug-bluetoothd-74-105.log

3 packet overview:

ACL Data RX: Handle 64 flags 0x02 dlen 9 #94 [hci0] 86.882368
ATT: Error Response (0x01) len 4
Read By Group Type Request (0x10)
Handle: 0x0001
Error: Unsupported Group Type (0x10)

ACL Data TX: Handle 64 flags 0x00 dlen 11 #95 [hci0] 86.882940
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0001-0xffff
Attribute type: Include (0x2802)

further back in time in the logs this request may be involved :

< ACL Data TX: Handle 64 flags 0x00 dlen 11 #89 [hci0] 78.332507
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0001-0xffff
Attribute group type: Secondary Service (0x2801)

Sometimes the device name from the previous device is shown instead of the currently connected name.

An example is probably the easiest way to explain this. Start with the watch disconnected from all bluetooth devices. Using bluetoothctl as the ceres user on the watch issue the devices command and if any devices are shown, remove them one by one until the list is empty.

If we have two Linux computers named alpha and beta, we can connect to the watch from alpha using bluetoothctl in the usual way (i.e. scan on and then connect). This connection works, the devices are paired and everything works just fine. If we then disconnect and then connect again the watch correctly shows "Disconnected" and then "Connected alpha."

Now if we disconnect again from alpha, and use bluetoothctl on beta, we do the same thing. First scan on and then connect. At this point we see a "Connected alpha" message again, which is incorrect because we're connected to "beta" and not "alpha."

There is a calendar branch in this repository, what kind of state is it in? I don't know enough c++ to tell what parts are incomplete, but it definitely looks like it's behind on a major restructuring of the codebase.

What would it take to update the current calendar branch and finish it? I am ready to test my additions to AsteroidOSSync (AsteroidOSSync#89) but of course, that's kinda hard when my watch doesn't support it.

Apps rely on asteroid-btsyncd to fetch data from external sources. Currently, btsyncd only gets data from a Bluetooth Low Energy connection with a phone app.

However, some watches have WiFi capabilities and could potentially be connected to the internet. In that case, it would be very useful if common btsyncd services (e.g: weather & time) could get data from the Internet.

Since the support of Wifi in Asteroid watches is not a priority for v1.0, this task can be postponed for another release. (eg: v1.1 ?) However, anyone can start working on it right away from QEMU where the network card can already be configured to access the internet.

The problem

According to the current Bluetooth core specification, in Volume 3, Part F, section 3.2.9, it says:

The maximum length of an attribute value shall be 512 octets.

Since a screenshot is typically many kilobytes, our API does not appear to conform. At the moment, we have two characteristics:

Screenshot Service (UUID: 00006071-0000-0000-0000-00A57E401D05)

Screenshot Request Characteristic (UUID: 00006001-0000-0000-0000-00A57E401D05)

This characteristic can be written by the client to any value (for example one byte set to 0) to trigger a byte stream on the Screenshot Content Characteristic.

Screenshot Content Characteristic (UUID: 00006002-0000-0000-0000-00A57E401D05)

This characteristic can be used to be notified of a screenshot content. After a write to the Screenshot Request Characteristic, the first value signaled by the Screenshot Content Characteristic should be made of four bytes containing the size of the data to be transmitted and can be used to show a progress bar during the screenshot download time. The rest of the transmission is made of chunks of raw data to be concatenated by the client in a buffer to reconstruct a screenshot of the watch's screen. The complete buffer should be a valid JPEG file but other formats could also be considered in the future.

While the request characteristic is fine, the Content is always going to be bigger than 512 bytes. I think the way to handle this is to change the API to use multiple characteristics.

Proposed new API

1. Request - initiate a request for a screenshot (as it is now)
2. Size - 4-byte value representing the size of the most recently captured screenshot (or 0 if none)
3. Chunk Offset - the offset in bytes to the beginning of a chunk
4. Chunk Content - contains the chunk corresponding to the Chunk Offset

If each Chunk were a fixed 16 bytes long, this would allow a 4-byte offset to be communicated with each chunk.

Reading a Chunk Content with a Chunk Offset outside the range indicated by size would simply return zero bytes (not even including an offset). Reading a Chunk Content that was a last partial Chunk (e.g. the end of the file) would return a valid Chunk but with only as many bytes as actually exist to the end of the file.

Potential drawbacks

• If a new screenshot were requested before the last one was entirely retrieved, there is nothing in the proposed API that would indicate that this had happened.
• Getting a screenshot would take more overhead than the existing scheme
• No integrity checking. The proposed API doesn't include a CRC or cryptographic hash to allow the receiver to validate that the screenshot was correctly received. We could add one, or perhaps make it part of the Size characteristic.

Potential advantages

• The updated spec would conform to Bluetooth specifications
• The mechanism may be more reliable (reliability problems with the existing implementations were what led me to investigate this)
• Even devices implementing older specifications should be able to use this API

Dear AsteroidOS Team,

I really want to add the Health Device Profile for my sportswatch.
https://www.bluetooth.com/specifications/assigned-numbers/health-device-profile/
(Heart BPM)

• How is your workflow for the development on asteroid-btsyncd? IDE, tools and others.
  • What do i have to setup for developing on btsyncd? I got Windows and Linux.
• How do i test against the smartwatch BLE Profiles?
  • Or what do you recommend?
• Any other recommendations on this topic?

Not sure if it is important. I baught the LG Watch Urbane W150 and im familiar with bitbake due to a lot yocto development in my job.

Currently, transferring data between the watch and paired device requires a dedicated BLE profile. This is a steep learning curve for app developers, as an understanding of BLE and asteroid-btsyncd is needed.

Hi all,

I'm trying to create a unofficial UWP connector for AsteroidOS smartwatches and I've recently encountered a problem with the (amazing documented) BLE exposed services, in particular with the Screenshot Content Service.

The Request's characteristic operation has always successful result, the application can receive the notifications by Content's characteristic, read the first 4-bytes that determines the image size as int32 but after a few chunks of raw bytes, the Smartwatch (in my case a Sony "tetra" SR50) stop sending data.

The strange fact I observed is sent data is always 10 times lower than expected size.

I think that both SR50 and my phone (Lumia 950XL), that are respectively BT 4.0 and BT 4.1, can't manage a chunk bigger than 23 bytes because of SOC's specification/hardware limitations.

I also noticed in this repo that the max output size sent by AsteroidOS GATT server is actually 200 bytes (I'm not a Qt developer but I read the official Qt documentation for QFile.read method).

 while (!f.atEnd()) {
        m_value = f.read(200);
        emit valueChanged();
        emitPropertiesChanged();
    }
f.close();

I think that is higher of dimensions supported by average consumer devices

I found this through a different bug, but I have figured out that this bug is much more than the one bug. I accidentally was sending an invalid year in trying to implement AsteroidOS support for Gadgetbridge, which led to me sending a technically negative number (> 127). When this is added to 1900 in the year for TimeService, this is subtracted instead, giving a completely invalid year, which crashes the daemon.

QByteArray is apparently a fancy wrapper around const char*, but not const unsigned char*, so many values are incorrectly cast with signedness in mind.

This is done in timeservice.cpp:31, many times in weatherservice.cpp (mainly in the temperature stuff), in mediaservice.cpp:171 and a few others.

I can start writing a fix, but I have no clue how to upload and test this daemon on my watch/emulator, so some guidance there would be appreciated.