@gpatel-fr Excellent! Many thanks. Will try that.

@gpatel-fr Thanks a lot for the feedback. I'm glad to know it's not specific to the Quintus.

The only thing I can tell is that I never had the same issue on my Pixel running Focal. It only connects on the Wifi at home, and occasionally uses mobile data, but it always keeps a reasonably accurate clock.

I wonder whether this could not be linked as well to the new support for VoLTE: could it be that the Pixel is able to get its time from the traditional GSM network, whereas VoLTE on Noble doesn't support that feature yet?

In any case, that's a bit problematic if you want to use your phone as alarm clock when you travel...

@gpatel-fr said:

@PhAndersson

I have something very similar with my FP5 and 24.04-1.3 stable.

Interestingly, I tried with 26.04 and it was better, I think that a bunch of updates have been to the Bluetooth stack to get it more up-to-date.

If you did not notice it, a back and forth 24-04 stable <-> 26.04 can be done in less than one hour, so if you can afford some downtime it's very doable.

That's an excellent suggestion -- I can certainly afford the downtime as the Quintus is only used for tests at the moment.

Can you explain how this version switch is done (or point me to the relevant doc), as I've not done that yet?

PhAndersson said:

Support request sent to Volla on May 18 via their online form.

Status update: discussion with Volla Support is still ongoing. No technical insight to report yet.

Volla Quintus received with 20.04/OTA-8 and upgraded to 24.04-1.3.

The system clock / date is correctly set only when the phone connects on a WiFi network (via NTP, I suppose). Maybe it would also synch over mobile data, but I can't confirm that.

When the phone is power-cycled and restarted in offline mode (i.e. both SIMs "logged in" in VoLTE mode but no WiFi and no mobile data), the clock is off by several weeks.

So it looks as if, during shutdown, the kernel fails to save the system clock to the hardware clock.

Has anyone else noticed that behaviour?

OK, yet another test. I just tried connecting the Quintus to my main UT phone (the Pixel 3a, Focal).

• during discovery, the Pixel appears in the list of neighbouring devices on the Quintus (and the Quintus on the Pixel)
• when I tap the Pixel in the list on the Quintus, I'm asked to confirm the PIN on both devices, which I did
• the Pixel then moves to the "Paired devices" section on the Quintus, shows connected for a few seconds then returns to "disconnected"
• on the Pixel, it remains in the list of neighbouring devices (and a notification is re-issued for the last received SMS, which was left unread)

Tapping the Pixel then tapping "connect" causes the following:

• the Pixel shows as connected for a few seconds on the Quintus, then it returns to its "disconnected" state
• nothing changes on the Pixel on the Bluetooth settings page, but a notification is re-issued for the last received SMS (strange, I know, but I got that same behaviour twice).

Just made a new test in the office, where I'm surrounded by an ocean of bluetooth devices.

Both when using bluetoothctl | scan on and when using the Bluetooth page of the Settings app, tons of neighbouring devices are detected, so the bluetooth stack itself seems functional. But requesting to connect to the laptop still times out.

I've also compared the output of bluetoothctl | show on the Quintus (Noble) and on the Pixel (Focal), but I've not noticed any difference there that seemed significant.

Support request sent to Volla on May 18 via their online form.

I tried connecting the phone to the laptop using bluetoothctl: same outcome (it fails).

The laptop (kermit) is still considered a paired device:

[bluetooth]# devices Paired
Device xx:xx:xx:xx:xx:xx kermit

Attempting to connect to it yields the following error message after a while:

[bluetooth]# Failed to connect: org.bluez.Error.Failed le-connection-abort-by-local

'journal' doesn't seem to contain any further information.

@jojumaxx I have a similar issue, maybe not absolutely identical:

I had to fiddle a lot to get my new Volla Quintus paired with my Linux laptop (tried several times, turned BT on and off on the phone), then eventually they accepted to pair.

Now, a few days later, the laptop is still listed as a paired device, but I can't get the phone to reconnect to it (I've not activated the auto-connect feature as that's not desired). I haven't tried bluetoothctl either, but I'll do and report back.

The Quintus is on 24.04-1.3, also no dual boot.

@gpatel-fr said:

@domubpkm

Well, if my calculation is correct that means about 2Mbits/s, it seems quite decent for Bluetooth.

Agreed.

@domubpkm said:

@phandersson I transferred a RAR file from UT smartphone to another with Volla OS, because no function to decompress RAR on UT. Did not work directly, extension not recognized. On the other hand, workaround by transforming the RAR extension into mp4: ok, worked. Then I put the RAR extension back in, and unzipped it without any problem. Just tested this.

Thanks for the feedback.

Make Ratatoskr recognize various extensions?

Well spotted -- the main app will accept incoming files of any type, but the SharePlugin only registers itself as handler for a limited number of file types. For no particular reason, as far as I know.

I've created the following issue to track this: https://github.com/petroniusniger/ratatoskr/issues/34

@domubpkm said:

@phandersson ok. I switched to dev channel and i tried to send a (big) file from my Volla 22 with UT to a Volla with volla OS with your last update : it works now. .

Excellent news -- thanks for the feedback.

But i found the transfer speed was very slow. Could it be improve or not ?

Could you be a bit more specific, please? From what I read online, typical Bluetooth transfer speeds are between 1 and 3 Mbps.

When I tested the app prior to releasing v0.1.1, I measured 1.3 Mbps when pushing a large file from my (Linux) laptop to the phone (Pixel 3a).

Do you get a comparable bandwidth, or something much lower? (to measure it, I simply time the transfer and divide it by the file size).

@domubpkm said:

@PhAndersson Can connect with bluetooth a Volla with Volla OS to a Volla 22 with UT noble.

There is currently a bug in Noble (up to 24.04-1.2) that prevents the OBEX daemon from starting.

The fix exists and is already merged. Here is the related MR: https://gitlab.com/ubports/development/core/ubuntu-touch-session/-/merge_requests/81. It is supposed to be part of the upcoming 24.04-1.3.

Based on earlier tests by @gpatel-fr, once this fix is available, 'ratatoskr' should work on Noble as well.

I need to amend the statement above. After further tests, the code that has been used to generate the packages is the correct one, so all the latest functionalities are present, and both sending and receiving files should work.

The only problem is that the wrong version string has been used when building.

Sure, Tweak Tool, of course -- sorry.

I just checked on my phone and it shows there, yes. Just look under the name 'Ratatoskr' (that's the actual name I gave the app -- "Bluetooth file transfer" is only a description).

It's the first UT app I built, so I'm not familiar yet with all the intricacies of the dev. workflow.

In any case, it seems there was a mixup, as the packages that were pushed on the server are v0.1.0, not v0.1.1. The "file sending" functionality may not be functional in that version (the receiving one should be).

I'll try to get this fixed tomorrow.

@domubpkm said:

@PhAndersson Should the app be shown in UT TT apps ? I don't see anything on my Volla 22.

I'm sorry, I guess I'm a bit slow tonight, but I'm not clear on what 'TT' means in this context. Can you clarify?

What should be the names of the cache config data directories ?

The app cache is in ~/.cache/ratatoskr.petroniusniger/. This is where incoming files are kept -- but there is no config data there (the app doesn't store any configuration data at this stage).

OK -- replying to my own post

To resolve the issue, I decided to revive the old 'ubtd' app. Its new incarnation has passed the code review and v0.1.1 is now available on the OpenStore.

You will find it under the name "Ratatoskr (Bluetooth file transfer)", in the "Utilities" category.

If you install it, may I suggest that you check the README here: https://github.com/petroniusniger/ratatoskr/tree/main for a brief description of how to use it most effectively?

Also, should you discover any bug, please report them here: https://github.com/petroniusniger/ratatoskr/issues

Final status update: the app has passed the code review and v0.1.1 is now available on the OpenStore.

You will find it under the name "Ratatoskr (Bluetooth file transfer)", in the "Utilities" category.

If you install it, may I suggest that you check the README here: https://github.com/petroniusniger/ratatoskr/tree/main for a brief description of how to use it most effectively?

Also, should you discover any bug, please report them here: https://github.com/petroniusniger/ratatoskr/issues

Status update:

'ratatoskr' source code has just been reviewed by @bhdouglass (OpenStore team), and two issues have been identified that should be resolved before allowing publication of the .click packages:

• https://github.com/petroniusniger/ratatoskr/issues/12 (new one)
• https://github.com/petroniusniger/ratatoskr/issues/6 (known issue)

I'll work on resolving those 2 issues and release a v0.1.1 of the code before re-submitting it for publication.