{"id":14967236,"url":"https://github.com/ekspla/xoss_sync","last_synced_at":"2025-10-25T17:31:41.146Z","repository":{"id":247536154,"uuid":"826125389","full_name":"ekspla/xoss_sync","owner":"ekspla","description":"A python code to bring fit files from XOSS G+ cyclo-computer over BLE","archived":false,"fork":false,"pushed_at":"2024-10-25T00:27:12.000Z","size":954,"stargazers_count":3,"open_issues_count":0,"forks_count":1,"subscribers_count":2,"default_branch":"main","last_synced_at":"2024-10-25T00:39:14.307Z","etag":null,"topics":["aioble","bikecomputer","ble","bleak","bluetooth-low-energy","cycling","cycplus","desktop-pc","esp32","fit","fit-file","gps","micropython","python","python3","xoss"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ekspla.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-07-09T06:22:50.000Z","updated_at":"2024-10-25T00:27:15.000Z","dependencies_parsed_at":"2024-09-14T03:49:53.086Z","dependency_job_id":"315ff772-6794-4ba9-bdfd-1f0160f9ac20","html_url":"https://github.com/ekspla/xoss_sync","commit_stats":{"total_commits":146,"total_committers":1,"mean_commits":146.0,"dds":0.0,"last_synced_commit":"ca42021b603047f59ea018091e28fae81b343a3f"},"previous_names":["ekspla/xoss_sync"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ekspla%2Fxoss_sync","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ekspla%2Fxoss_sync/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ekspla%2Fxoss_sync/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ekspla%2Fxoss_sync/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ekspla","download_url":"https://codeload.github.com/ekspla/xoss_sync/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":238191481,"owners_count":19431433,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["aioble","bikecomputer","ble","bleak","bluetooth-low-energy","cycling","cycplus","desktop-pc","esp32","fit","fit-file","gps","micropython","python","python3","xoss"],"created_at":"2024-09-24T13:37:40.949Z","updated_at":"2025-10-25T17:31:41.139Z","avatar_url":"https://github.com/ekspla.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# xoss_sync\nPython (**CPython** and **MicroPython**) codes to fetch FIT files from **XOSS G+** cyclo-computer over bluetooth (BLE) for you.\nThe codes make you free from proprietary XOSS app/software on the cloud; you take full control of your gps track log files in FIT format.\n\n(C) 2024-2025 [ekspla](https://github.com/ekspla/xoss_sync)\n\n## Introduction\nA quick/preliminary version of code to use with XOSS G+ GPS cyclo-computer, inspired by [f-xoss project](https://github.com/DCNick3/f-xoss). \nThe code is a modified version of [cycsync.py](https://github.com/Kaiserdragon2/CycSync) for Cycplus M2, which does not work for my use case as is.\n\n**The PC \\(CPython\\) version** \\([xoss_sync.py](https://github.com/ekspla/xoss_sync/blob/main/xoss_sync.py)\\) was tested with XOSS G+ (Gen1), \nWindows 10 and 11 / Linux \\(BlueZ 5.56\\), TPLink USB BT dongle \\(UB400, v4.0, CSR8510 chip\\) / Intel Wireless \\(v5.1\\), Python-3.8.6/3.12.6 and Bleak-0.22.2.\n\n**The MicroPython \\(MPY\\) version** \\([mpy_xoss_sync.py](https://github.com/ekspla/xoss_sync/blob/main/mpy_xoss_sync.py)\\) was tested with \nMPY-1.23.0/1.24.0-preview on ESP32-WROOM-32E/ESP32-S3-WROOM-1, micro SD card, and aioble.  After a bit of modification \\(changes in the \npath to /sd\\), this code was also tested with a unix-port of MPY-1.23.0 (+ [PR#14006](https://github.com/micropython/micropython/pull/14006))\n/aioble on the same PC-Linux-x64 and TPLink UB400.\n\n## Disclaimer\nThese codes are **not based on reverse engineering of firmwares on the devices and/or their proprietary companion apps (aka XOSS App)**, but \non the detailed explanations already shown in official developer's web site \\(see [Appendix](#appendix)\\) \nas well as on [the well-known details of YMODEM protocol](reference/XMODEM-YMODEM-Protocol-Refrence.pdf?raw=true).\n\n## Features\nThese scripts allow you to:\n\n- Obtain a list of data files on your device,\n- Download data (in FIT fromat) from your device,\n- See free/usage of storage in your device.\n\n## Usage (PC version)\n1. Install bluetooth low energy interface / driver software on your PC.\n\n2. Check if your device and the PC can be connected.\n\n3. Install [Python](https://www.python.org/) (of course).\n\n4. Install [Bleak](https://pypi.org/project/bleak/):\n\n``` Shell\npip install bleak\n```\n\n5. Download and run the script `python xoss_sync.py`:\n\n```\nD:\\backup\\Bicycle\\XOSS\\python\u003epython xoss_sync.py\nScanning for Bluetooth devices...\nFound device: XOSS G-040989 - EC:37:9F:xx:yy:zz\nFound target device: XOSS G-040989 - EC:37:9F:xx:yy:zz\nConnected to XOSS G-040989\nNotifications started\nFree Diskspace: 684/8104kb\nSuccessfully wrote combined data to filelist.txt\nSkip: 20240713062144.fit\nSkip: 20240609141047.fit\nSkip: 20240504063456.fit\nSkip: 20240525060956.fit\nSkip: 20240511055922.fit\nSkip: 20240609130215.fit\nSkip: 20240608063049.fit\nSkip: 20240615062615.fit\nRetrieving 20240715062336.fit\nSuccessfully wrote combined data to 20240715062336.fit\nSkip: 20240420055014.fit\nSkip: 20240427061131.fit\nSkip: 20240502061739.fit\nSkip: 20240518060936.fit\nSkip: 20240707055411.fit\nSkip: 20240429060242.fit\nSkip: 20240622055813.fit\nSkip: 20240629073413.fit\nSkip: 20240506053748.fit\nSkip: 20240706062605.fit\nSkip: 20240601060515.fit\n\nD:\\backup\\Bicycle\\XOSS\\python\u003e\n```\n\nThough I tested this only with XOSS G+ (Gen1) and Windows (10 / 11) / Linux (BlueZ 5.56), combinations of the other XOSS device / OS may work. \nFor the other devices such as Cycplus, CooSpo and ROCKBROS, you may have to change the `TARGET_NAME` appropriately. \n[Issue #1](https://github.com/ekspla/xoss_sync/issues/1) might be useful for Cycplus M2 users.\nOn newer devices (e.g. XOSS NAV \u0026 G2+), the name of the track list has to be changed from `filelist.txt` to `workouts.json`. \n[Bleak](https://github.com/hbldh/bleak) supports Android, MacOS, Windows and Linux.\n\n6. Change settings: \n\nSettings of the device \\(e.g. timezone, backlight, autopause, etc.\\) can be modified via JSON file. In my case \\(XOSS-G+ gen1\\), \n\n a. Download the file.\n``` Python\nawait self.fetch_file(client, 'Setting.json')\n```\n b. Modify the file.\n\n c. Upload the modified file.\n``` Python\nawait self.send_file(client, 'Setting.json')\n```\nAfter the successful upload, you hear a short beep from the device. The filename might be `settings.json` on the other devices. \n\n\n## Usage (MicroPython version)\n1. Install SD card/interface on your ESP32 board.\n\n2. Install [MicroPython](https://micropython.org/) (of course).\n\n3. Install [aioble](https://github.com/micropython/micropython-lib/tree/master/micropython/bluetooth/aioble):\n\n``` Shell\nmpremote mip install aioble\n```\n\n4. Download/install and run the script:\n\n``` python\n\u003e\u003e\u003e import mpy_xoss_sync\n\u003e\u003e\u003e mpy_xoss_sync.start()\n```\n\nThough it works very well as PC version, this is an ad hoc implementation to MPY/aioble. \nThe code was also tested with MPY-1.24.0-preview/aioble on ESP32-S3 and with unix-port of MPY-1.23.0/aioble on PC-Linux-x64 (Core-i5).\n\nFor the other devices such as Cycplus, CooSpo and ROCKBROS, you may have to change the `_TARGET_NAME` appropriately.\n[Issue #1](https://github.com/ekspla/xoss_sync/issues/1) might be useful for Cycplus M2 users.\nOn newer devices (e.g. XOSS NAV \u0026 G2+), the name of the track list has to be changed from `filelist.txt` to `workouts.json`. \n\n5. Optional\n\nThroughput \\(see [Note 3](#note-3)\\) can be increased by specifying the optional connection parameters of \n*scan_duration_ms*, *min_conn_interval_us* and *max_conn_interval_us* [as described here](https://github.com/micropython/micropython/issues/15418). \nThese intervals can be reduced to the minimum value of 7_500 (7.5 ms) on ESP32-S3 and on PC-Linux-x64 using unix port.\n\nModify `async def _connect()` in `aioble/central.py`:\n``` Diff\n-           ble.gap_connect(device.addr_type, device.addr)\n+           ble.gap_connect(device.addr_type, device.addr, 5_000, 11_500, 11_500)\n```\n\nAlternatively, if you have installed the latest aioble after \n[commit 68e3e07](https://github.com/micropython/micropython-lib/commit/68e3e07bc7ab63931cead3854b2a114e9a084248), \n\nmodify `async def run()` in `mpy_xoss_sync.py`:\n``` Diff\n-               connection = await device.connect(timeout_ms=60_000)\n+               connection = await device.connect(timeout_ms=60_000, scan_duration_ms=5_000, min_conn_interval_us=11_500, max_conn_interval_us=11_500)\n```\n\nUpdate (MAR 2025): the default connection interval of `mpy_xoss_sync.py` has been changed to 7_500 micro sec.  If you have installed \naioble prior to [the commit 68e3e07](https://github.com/micropython/micropython-lib/commit/68e3e07bc7ab63931cead3854b2a114e9a084248), \nmodify the code appropriately.\n\n\n~~The look-up-table (256 elements) with Viper implementation of CRC16/ARC used in this version may be overkill.~~ \n~~For those working together with web client/server in memory constrained systems, I would suggest using CRC16 of either~~ \n~~the ordinary one (as shown in the CPython version) or~~ \n~~[LUT with index-width of four bits \\(16 elements\\)](reference/crc16_arc_table.py)~~.\n\n## Limitation\nBoth of the scripts work perfectly for my use case as shown above, but there are possible limitations due mainly to the implementation\nof YMODEM in part as followings.\n\n- The scripts expect a transport with ~~MTU of 23, 128-byte data per block, and~~ CRC16/ARC \\(not CRC16/XMODEM\\).  I am not sure\nif the SoC \\(seems to be nRF52832\\) / software in the XOSS device supports larger MTU or 1024-byte data \\(STX\\) in YMODEM \\(see, \n[Notes 1](#note-1) \u0026 [2](#note-2)\\).\n\n- Update (FEB 2025): STX in YMODEM is now supposed to work ~~only~~ in CPython version, though it's not well tested.\nIf you can control MTU size, 206 which is used in [f-xoss project](https://github.com/DCNick3/f-xoss) \n\\(see below\\) may be a good number because an STX block of 1029 bytes in YMODEM fits quite well in \n1030 = MTU\\*5.\n\n- Update (MAR 2025): STX is now supposed to work also in MicroPython version, though it's not well tested.\n\n## Notes\n\u003ca name=\"note-1\"\u003e\u003c/a\u003e\n1. My XOSS-G+ (Gen1) was found to be not changing MTU (23) / block data size (128) with Windows 11 and Bluetooth 5.1 interface, \nwhich always requests MTU of 527, while [f-xoss project](https://github.com/DCNick3/f-xoss) for XOSS-NAV used MTU of 206.\n\n\u003ca name=\"note-2\"\u003e\u003c/a\u003e\n2. The proprietary XOSS App on mobile phone itself seems to support larger MTU / block data size by DLE (data packet length extension) \nand STX.  See, for example [this Xingzhe's web site](https://developer.imxingzhe.com/docs/device/tracking_data_service/).\n\n\u003ca name=\"note-3\"\u003e\u003c/a\u003e\n3. Sync times (throughputs in parentheses) of G+ Gen1 using my FIT file of 235,723 bytes were as followings (as of 31 OCT 2024). \nThe connection intervals were measured by using \n[nRF Sniffer for BLE](https://www.nordicsemi.com/Products/Development-tools/nRF-Sniffer-for-Bluetooth-LE/Download) (nRF52840 dongle) and \n[Wireshark](https://www.wireshark.org/download.html).\n- Proprietary XOSS App\n    - Android-x86 and TPLink UB400, 00:07:27 (4.2 kbps).\n       - 50.0 ms connection interval (measured); this could not be changed \\(see [Note 5](#note-5)\\).\n- CPython/Bleak version\n    - Windows 10 and TPLink UB400, 00:03:45 (8.4 kbps).\n       - 15.0 ms connection interval (measured).\n    - Windows 11 and Intel Wireless, 00:08:41 (3.6 kbps).\n       - 60.0 ms connection interval (measured).\n    - Linux (BlueZ 5.56) and TPLink UB400, 00:07:08 (4.4 kbps).\n       - 50.0 ms connection interval (measured).\n- MPY/aioble version (hereafter: ESP32 = ESP32-WROOM-32E; ESP32-S3 = ESP32-S3-WROOM-1-N16R8; MPY-Linux = unix-port on PC-Linux-x64 / TPLink UB400)\n    - ESP32/aioble, 00:07:11 (4.4 kbps).\n       - 50.0 ms connection interval (measured).\n    - ESP32/modified aioble(conn_intervals=11.5 ms), 00:04:04 (7.7 kbps).\n       - 11.25 ms connection interval (measured).\n    - ESP32-S3/modified aioble(conn_intervals=11.5 ms), 00:03:46 (8.3 kbps).\n    - ESP32-S3/modified aioble(conn_intervals=7.5 ms), reduced NAK/ACK delays and no explicit garbage-collection (GC), 00:02:42 (11.6 kbps).\n       - Further optimization requires [a modified firmware with increased tick-rate in FreeRTOS](https://github.com/orgs/micropython/discussions/15594)\n; change `CONFIG_FREERTOS_HZ` from default value of 100 Hz \\[10 ms\\] to 1000 Hz \\[1 ms\\].\n    - ESP32-S3(`CONFIG_FREERTOS_HZ=1000`)/modified aioble(conn_intervals=7.5 ms), optimized delays and no GC, 00:02:05 (15.0 kbps).\n       - 7.5 ms connection interval (measured).\n       - While the client (mpy_xoss_sync.py) using `_thread` in `file.write()` improves a little, 00:02:00 (15.7 kbps), **the throughput is \ndetermined by the unresponsive peripheral** to the ACKs in YMODEM (i.e. no packets sent from XOSS-G+).  **Typically, 2-4 ACKs \n(using 2-4 connection events) are necessary irrespective of connection intervals**.  The theoretical limit of 3 connections/block, as shown below, \ndoes not occur because of the unresponsiveness.  See example sniffer logs of [7.5](reference/conn_intvl_7r5ms.png) and \n[50 ms](reference/conn_intvl_50ms.png) for details.  This strange issue, irrespective of the intervals, may be caused by \n[Nordic's SoftDevice](https://www.nordicsemi.com/products/nrf52832/) in XOSS-G+.\n    - MPY-Linux/modified aioble(conn_intervals=7.5 ms), optimized delays and no GC, 00:02:25 (13.0 kbps).\n       - 7.5 ms connection interval (measured).\n       - The throughput was a bit less than those of ESP32-S3, probably because of the difference in bluetooth stacks; \n[BTstack](https://github.com/bluekitchen/btstack) vs. [NimBLE](https://github.com/apache/mynewt-nimble).  Prior to the YMODEM-ACK an unnecessary \nempty packet is always sent from BTstack to XOSS-G+, while this is not the case in ESP32s (using NimBLE).\n    - Using [a pair of test codes](https://github.com/ekspla/micropython_aioble_examples) (`nus_modem_server.py`, `nus_modem_client.py`): \nMPY-Linux (server) --\u003e ESP32-S3 (client), 00:01:08 (27.7 kbps).\n       - 7.5 ms connection interval (measured).\n       - The throughput was significantly faster \n[without the strange unresponsive delays caused by XOSS-G+](reference/test_code_pair_7r5ms.png).  \n\n(c.f.)\nTheoretical limit using 11.5 ms connection interval and 128-byte data per block (SOH) on MPY/aioble:\n\n1 s / 11.5 ms = 87 connections; 1 connection = 6 packets \\* 20 bytes (MTU = 23);\nso, 133 bytes (data/block \\[128\\], header \\[3\\] and CRC \\[2\\]) == 2 connections + 1 connection for ACK in YMODEM.\n(The 6-packet limit in XOSS-G+ is, probably, required for compatibility to very old mobile phones.)\n\n87 connections/s \\* (128 data bytes / 3 connections) \\* 8 bits/byte = 29.7 kbps \\[this would be 45.5 kbps for 7.5 ms interval\\].\n\nOn Windows 11, the limits are 1.9, 5.7 and 22.8 kbps for *PowerOptimized* (180 ms), *Balanced* (60 ms) and *ThroughputOptimized* (15 ms) BLE settings, \nrespectively.  There is no API in Bleak on Windows to change this setting though.  The measured throughput of 3.6 kbps on Windows 11 using \nIntel Wireless adapter (as shown above) suggests *Balanced* setting, which agrees well with those of the measured value using the sniffer.\nOn Linux, the min/max connection intervals may be specified by the user \\(see [Note 5](#note-5)\\).\n\n\u003ca name=\"note-4\"\u003e\u003c/a\u003e\n4. Throughputs of newer devices.\n\nFrom an official review article \\(13 June 2023\\) linked in [Xingzhe's web site](https://www.imxingzhe.com/newsv2/list),\nthe estimated throughputs using XOSS app with the reviewer's mobile phone are as followings.  \n\n50 kB = 50 \\* 1000 = 50000 bytes; I am not quite sure if *kB* in the review means *1000* or *1024* bytes though.\n\n - G Gen1: 50000 bytes * 8 bit/byte / 21 s = 19 kbps.\n - G+ Gen2 (aka G2+): 50000 bytes * 8 bit/byte / 5 s = 80 kbps.\n\nThese throughputs of 19 and 80 kbps with Gen1 and Gen2 are, respectively, close to those with my G+ Gen1 shown in [Note 3](#note-3) \\(15.0 kbps\\) and \n[those using `STX` and `MTU=209` with MPY-Linux server and ESP32-S3 client](https://github.com/ekspla/micropython_aioble_examples#how-can-we-handle-successive-notified-packets-as-a-client-using-aioble) \\(94.3 kbps\\). \nThe reviewer's data suggests that G+ Gen2 uses `STX` and `increased MTU` \\(but without `2M PHY`\\).  \n\nIn the latest review article \\(22 July 2025\\) linked in [Xingzhe's web site](https://www.imxingzhe.com/newsv2/list), \nthe sync times of Gen2 and Gen3 were 10 and 6 seconds, respectively, for a 30 km ride data. The estimated throughput of Gen3 would be \n\\(10 s / 6 s \\) * 80 kbps = 130 kbps using the data in the previous review. The heigher throughput may be due to DLE (and/or 2M PHY).\n\n\u003ca name=\"note-5\"\u003e\u003c/a\u003e\n5. Conn_min_interval/conn_max_interval on Linux kernels.\n\nUnfortunately, changing the parameters did not work for the XOSS App / Android-x86 in my case.\n``` ShellSession\nx86:/ $ su\nx86:/ # cat /sys/kernel/debug/bluetooth/hci0/conn_min_interval\n40                                                                      # 40 * 1.25  = 50 ms\nx86:/ # cat /sys/kernel/debug/bluetooth/hci0/conn_max_interval\n56                                                                      # 56 * 1.25 = 70 ms\nx86:/ # echo 9 \u003e /sys/kernel/debug/bluetooth/hci0/conn_min_interval     # 9 * 1.25 = 11.25 ms\nx86:/ # echo 20 \u003e /sys/kernel/debug/bluetooth/hci0/conn_max_interval    # 20 * 1.25 = 25 ms\n```\n\n\u003ca name=\"note-6\"\u003e\u003c/a\u003e\n6. LE 2M PHY support of XOSS-G+.\n\nAlthough my G+ Gen1 shows `LE_2M_PHY = True` (BLE 5.0) in the feature response packet, [it stops communication silently and starts advertising again \nafter receiving a `LL_PHYS_REQ (preference of 2M PHY)` packet](reference/Test_LL_PHYS_REQ.png). \nIt seems that the client's request of changing from 1M to 2M is not handled appropriately in the XOSS-G+ software as specified in the Bluetooth Core \nSpec. This is similar to the case of unfunctional `Data Packet Length Extension (DLE) = True` (BLE 4.2) as described in \n[Notes 1](#note-1) \u0026 [2](#note-2). \n\n~~I am not sure if these issues are resolved in the latest models.~~ It seems that DLE is supported in XOSS NAV and Cycplus M2. \n\n\u003ca name=\"note-7\"\u003e\u003c/a\u003e\n7. XOSS app \\(YMODEM on Nordic UART Service\\) supported models.\n\n| Model | SoC | MTU | STX | DLE | 2M | Battery |\n| ----- | --- | --- | --- | --- | -- | ------- |\n| Sprint | nRF52832 | 23 fixed | NA | NA | NA | ? |\n| G Gen1 | nRF52832 | 23 fixed | NA | NA | NA | 503035 |\n| G Gen2 | nRF52833 | by negotiation | Yes | NA (?) | NA | 603030 |\n| G Gen3 | nRF52833 | by negotiation | Yes | Yes | NA (?) | 503040 |\n| NAV | nRF52840 | by negotiation | Yes | Yes | NA (?) | 503040 |\n| Cycplus M1 | nRF52832 | 23 fixed (?) | NA (?) | NA | NA | 603450 |\n| Cycplus M2 | nRF52832 | by negotiation | Yes | Yes | NA | 523450 |\n| Cycplus M3 | nRF52832 (?) | ? | ? | ? | ? | 604050 |\n| CooSpo BC102/107 series | nRF52832 | 23 fixed (?) | NA (?) | NA (?) | NA | 553346 |\n| CooSpo BC200 | nRF52840 | ? | ? | ? | ? | 603945 |\n\n\n## Appendix\n[A DIY Battery Replacement](reference/batt_replacement.md)  \n\nMake your device last longer.  \n\n[Section 5. YMODEM Service](reference/Section_5_YMODEM_Service.pdf?raw=true)  \n\nAs of APR 2025, they removed almost all of the explanations related to the file transfer from \n[their official online document](https://developer.imxingzhe.com/docs/device/tracking_data_service/) for some unknown reason. \nFor convenience to the readers I have uploaded an archive of its translated version as above.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fekspla%2Fxoss_sync","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fekspla%2Fxoss_sync","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fekspla%2Fxoss_sync/lists"}