What is SonicloudTech/sonicloud_opensdk?

The repository is a hardware access kit, not a finished recorder app. It ships mobile SDKs, a Python desktop demo and a CB08 BLE protocol document, while the card hardware itself is a commercial product from Anhui Sonicloud.

Can I use SonicloudTech/sonicloud_opensdk commercially?

Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.

Is SonicloudTech/sonicloud_opensdk still maintained?

Yes. The repository last received commits 1 day ago.

What programming language is SonicloudTech/sonicloud_opensdk written in?

Mainly HTML, according to GitHub's language statistics.

Sonicloud Recorder Open SDK: BLE recorder setup guide

At a glance

What is it?: The repository is a hardware access kit, not a finished recorder app. It ships mobile SDKs, a Python desktop demo and a CB08 BLE protocol document, while the card hardware itself is a commercial product from Anhui Sonicloud.
Who is it for?: Adopt it if you are building a recorder app or integrating a card recorder into an existing product and you already have, or plan to buy, Sonicloud hardware. Do not adopt it if you need a working consumer app, a cloud transcription service, or a recorder that runs without vendor hardware.
Can I use it commercially?: Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?: Yes. The repository last received commits 1 day ago.
What is it written in?: Mainly HTML, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 18, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Hysen Labs Editorial · September 16, 2026 · SonicloudTech/sonicloud_opensdk

What the Sonicloud Recorder SDK actually solves

Most BLE recorder projects fail at the same place: the connection works, the first file downloads, and then a second chipset arrives with a different service UUID, a different frame layout and a different way of splitting packets. The Sonicloud Recorder Open SDK is aimed at that gap. The README describes it as a reference for connecting recorder hardware, and the repository is organised around a vendor adapter layer that absorbs the differences between Jieli, Lanxun, Juxin and BK chipsets behind one interface.

The intended users are hardware vendors, app teams and system integrators. The README lists meeting notes, interviews, classroom training, content creation, inspection records and corporate gift recorders as target scenarios. That is a broad list, but the code layout is narrower than the marketing: what you get is a set of SDK wrappers, a desktop demo and protocol documentation. There is no end-user application, no transcription service and no backend. The card records audio; the SDK moves bytes; your app owns decoding, storage, permissions and business logic.

The layered architecture: standard BLE commands plus a VendorAdapter

The README describes a five-layer stack: application layer, SDK core and state machine, standard BLE protocol layer, VendorAdapter layer, and hardware firmware. The standard layer defines a GATT service at 0xAE20, a write characteristic at AE21, a data notification characteristic at AE22 and a key notification characteristic at AE23. Frames follow the pattern MAGIC(0x5A) + SEQ + CRC-16/XMODEM + LEN + TYPE/CMD/PARAMS.

Notifications are where the real work sits. The protocol documentation states that data can arrive as half frames, multiple frames, noise or split across packets, and that the data notification and key notification channels use separate parsing buffers. The sender fragments by MTU and preserves frame order. The SDK caches by length, validates CRC, deduplicates, reassembles and correlates responses with requests.

Audio is delivered as raw Opus bytes at 16 kHz, mono, 40 bytes per frame, 20 ms per frame. The SDK does not decode Opus and does not write WAV headers. File downloads use a 4-byte little-endian offset, and the README advises checking file size and audio decodability after transfer. OTA is split: BLE sets the mode and environment, then firmware moves over Wi-Fi/TCP. That split is a design decision worth noting, because it means OTA cannot be tested with a BLE-only setup.

Running the desktop demo on Windows or macOS

The fastest way to see the protocol work is the Python demo in pnote-web-win&Mac-demo. It needs Python 3.10 or later, a working BLE adapter and a recorder card in connectable state. The README gives this sequence:

bash

cd pnote-web-win&Mac-demo
python -m venv .venv
source .venv/bin/activate                 # Windows PowerShell: .venv\Scripts\Activate.ps1
pip install -r requirements.txt
python main.py --web

After that, the browser console is at http://127.0.0.1:8000. The same README shows a command-line path through the REPL, where scan, connect 0, smoke, list, download 0 and transcribe 0 are the commands used to verify a device. The smoke command is the useful one for a first run: it exercises the connection and basic device checks before you commit to a full file download.

Transcription and the web console are optional. They install separately with pip install -r requirements-asr.txt and pip install -r requirements-web.txt. The README states that the first transcription downloads roughly 900 MB from ModelScope and runs offline afterwards. Protocol and device simulation tests are run with python -m unittest discover tests -v.

Mobile integration: AAR, static library, HAR and Flutter

Android integration copies pnote_20260728171001.aar into app/libs, adds a fileTree dependency plus RxJava, Retrofit and EventBus, then calls PNote.init(context, deviceDataListener), PNote.startSearch() and PNote.connectDevice(name, address). Callbacks deliver JSON device events, real-time recording OPUS data and file OPUS data.

iOS uses libPNote.a and PNode.h, with a WindBleDelegate implementation and calls to startSearch and connectDeviceAndAddress. HarmonyOS ships har_recordersdk.har, and the integration guide is written for HarmonyOS API 12 or later. One detail in the README matters for anyone debugging connection problems: the deviceId returned by the scan callback may be a system privacy random identifier, while address is display-only. Business results come back asynchronously through the DEVICE_DATA event.

The Flutter demo is the quickest cross-platform check. It runs with flutter pub get and flutter run, and the README insists on a real device for Bluetooth, recording, Wi-Fi and OTA testing. The core entry point is lib/provider_record_pen.dart. If you only read one file to understand the intended call flow, that is the one.

Where the SDK stops and your application has to start

The README is explicit that the SDK does not replace application-side Opus decoding, file storage, permission management or security control. That is not a small caveat. A 40-byte Opus frame at 20 ms means your decoder has to handle a continuous stream, and your app has to decide where recordings live, how they are named and when they are deleted. The SDK gives you bytes, offsets and events.

The OTA path has a hard precondition: Wi-Fi/TCP must be established, the version must actually need updating, and battery must be at least 20 percent. If either BLE or Wi-Fi drops during the upgrade, the README says to mark the task as failed and wait for recovery rather than blindly resending the whole firmware. Anyone who has shipped firmware updates knows how easy it is to get that wrong.

The repository also warns against hardcoding cloud ASR keys, device authorisation codes or real recordings, and asks that logs and packet captures be redacted. There is no built-in key management, so that discipline is on your team. Finally, the README notes that interface fields, command numbers and behaviour are governed by the latest SDK, firmware and protocol version plus real-device testing, which means the documentation in the repository is a starting point, not a contract.

Alternatives and the difference in approach

The closest alternative is to implement the BLE protocol directly against your chipset vendor's own SDK. If you only ever ship one hardware model, that is often simpler: you skip the adapter layer, you talk to the vendor's native API, and you avoid a dependency on Sonicloud's packaging and release cadence. The trade-off appears when you add a second chipset. At that point you either maintain two code paths in your app or you build the normalisation layer yourself, which is exactly what the VendorAdapter in this repository is for.

A second alternative is a recorder product with a cloud API rather than a BLE SDK. Those services typically give you an HTTP endpoint and a webhook, and they handle transcription, storage and device management. The difference is control and data path: with Sonicloud the audio crosses BLE and Wi-Fi to your own application, and you decide what happens next. With a cloud-first recorder, the vendor's servers sit in the middle. Neither is universally better; they fail in different ways. A BLE SDK fails when the radio environment is poor or the chipset changes. A cloud recorder fails when the vendor changes pricing, limits or availability.

Licence, maintenance and what the repository does not cover

The repository is MIT licensed, and the last push was on 2026-09-10. That is recent, and the repository is not archived. The README, however, draws a boundary that the licence file does not: the AAR, static library, HAR, firmware, device private protocol and some documents may contain proprietary content from Sonicloud or its chipset partners, and are not necessarily covered by the MIT grant. The README states that usage, redistribution and commercial scope follow the package notes and the commercial agreement. That is a legal question for your counsel, not something a licence header settles.

The hardware itself is a commercial product. The README directs readers to Anhui Sonicloud for hardware specifications, samples, the HarmonyOS SDK, the full protocol version and support materials, and asks that enquiries state the target platform, expected quantity and application scenario. There are no retrieved releases, so versioning is by SDK package and firmware rather than by tagged releases. Upgrading therefore means tracking the SDK package, the firmware version and the protocol document together. The repository does not document a rollback procedure for OTA, and the README does not describe a downgrade path.

Editorial conclusion

Adopt it if you are building a recorder app or integrating a card recorder into an existing product and you already have, or plan to buy, Sonicloud hardware. Do not adopt it if you need a working consumer app, a cloud transcription service, or a recorder that runs without vendor hardware. Before committing, verify that your target chipset appears in the VendorAdapter coverage, that the CB08 protocol document matches the firmware you will ship, and that the licence terms for the AAR, HAR and static libraries match your distribution plan, since the MIT licence covers the sample code but not necessarily the binaries.

Frequently asked questions

Is there a Sonicloud app?

The repository does not ship an end-user application. It provides Android, iOS, HarmonyOS and Flutter SDK wrappers, a Windows/macOS Python demo with a command-line REPL and a browser console, and protocol documentation. Any consumer-facing app is built by the integrator.

What is the Sonicloud Recorder Open SDK?

It is an open sample project around a recorder card, offering a BLE protocol SDK, cross-platform integration examples and a desktop demo. The README describes it as a reference for connecting recorder hardware, with a vendor adapter layer that normalises differences between Jieli, Lanxun, Juxin and BK chipsets.

How do I install the Sonicloud desktop demo?

The README requires Python 3.10 or later, a BLE adapter and a connectable recorder card. From pnote-web-win&Mac-demo you create a virtual environment, install requirements.txt, and run python main.py --web, then open http://127.0.0.1:8000. Transcription and the web console install separately from requirements-asr.txt and requirements-web.txt.

Does the Sonicloud SDK decode Opus audio or produce WAV files?

No. The README states that real-time recording and file callbacks deliver raw Opus bytes at 16 kHz, mono, 40 bytes per frame and 20 ms per frame, and that the SDK does not handle decoding or WAV header generation. That work belongs to the application.

Can Sonicloud OTA firmware updates run over BLE only?

No. The README describes OTA as a two-stage process: BLE first handles mode and environment control, then firmware transfers over Wi-Fi/TCP. It also requires a version that needs updating and battery at 20 percent or above, and says a dropped BLE or Wi-Fi link should be treated as a failure rather than retried by resending the full firmware.

Official sources

Community notes