Bluetooth Stacks

TinyCTSClient and TinyCTSServer have the same functions on all platforms. TinyCTS.h selects the Bluetooth stack from the board:

Platform	Stack	Needs
ESP32, nRF5	NimBLE-Arduino 2.x	the library
Arduino Nano 33 BLE, Nano RP2040 Connect, Portenta, Giga, Uno R4 WiFi, Nano 33 IoT, MKR WiFi 1010	ArduinoBLE	the library
Raspberry Pi Pico W / Pico 2 W	BLE library of the arduino-pico core (BTstack)	Tools -> IP/Bluetooth Stack -> IPv4 + Bluetooth
Linux	BlueZ over D-Bus	GLib/GIO (libglib2.0-dev)
macOS	CoreBluetooth	Xcode command line tools (experimental, not tested)
Windows 10/11	WinRT (C++/WinRT)	Visual Studio (experimental, not tested)

The choice can be forced with TINY_CTS_USE_NIMBLE, TINY_CTS_USE_ARDUINOBLE, TINY_CTS_USE_PICO_BLE, TINY_CTS_USE_BLUEZ, TINY_CTS_USE_COREBLUETOOTH or TINY_CTS_USE_WINRT.

Notes for the platforms

NimBLE-Arduino (ESP32, nRF5): begin() calls NimBLEDevice::init() if the stack is not started yet. Call TinyCTSServer::process() in loop() if you want periodic notifications.

ArduinoBLE: begin() starts the hardware (BLE.begin()) and process() calls BLE.poll(). ArduinoBLE can not refuse a write, so a refused time is restored. enableTimeSetting() makes the writable characteristics encrypted, and ArduinoBLE then asks for the encryption also when they are read. TinyCTSSystemSource is not available on the Uno R4 (no gettimeofday()).

Raspberry Pi Pico W: begin() starts the BLE hardware: do not call BLE.begin() yourself. The calls of the client block until they are done. The Bluetooth stack calls the time source of the server from its own context: it must be fast and must not block.

Linux (BlueZ): TinyCTSServer::process() must be called regularly: it handles the requests of BlueZ. The client has the additional functions scan(), getLastError() and setAdapter(). The adapter must be able to be a peripheral to serve the time. Link with the cmake target TinyCTS or use pkg-config --cflags --libs gio-2.0.

macOS (CoreBluetooth), experimental: macOS does not tell the Bluetooth address of a device: use the identifier that scan shows, or the name. A program that is not an app bundle needs an Info.plist with NSBluetoothAlwaysUsageDescription (the tool embeds one, see tools/tinycts/CMakeLists.txt), and the user has to allow Bluetooth for it.

Windows (WinRT), experimental: Windows advertises the name of the computer: the name of the server is ignored. The server needs a Bluetooth adapter that can be a peripheral (Windows 10 version 1703 or later).

On macOS and Windows the sources src/TinyCTS/desktop/TinyCTSCoreBluetooth.mm and src/TinyCTS/desktop/TinyCTSWinRT.cpp have to be part of the build: the cmake target TinyCTS adds them. The macOS and Windows code could not be compiled or run when it was written: please report problems.

Source layout

• src/TinyCTS/: the parts that are the same everywhere: TinyCTSTypes.h (encoding of the characteristics), TinyCTSTimeSource.h, TinyCTSServerBase.h / TinyCTSClientBase.h (the logic), TinyCTSConfig.h (selects the stack) and the headers TinyCTSServer.h / TinyCTSClient.h that include the right backend
• src/TinyCTS/mcu/: the backends for microcontrollers: NimBLE, ArduinoBLE, Pico W
• src/TinyCTS/desktop/: the backends for the desktop: BlueZ (Linux), CoreBluetooth (macOS), WinRT (Windows) and the classes TinyCTSClient / TinyCTSServer that use them