DEV Community: Lars Knudsen 🇩🇰

Using Gemini for Web Apps

Lars Knudsen 🇩🇰 — Tue, 23 Sep 2025 21:45:00 +0000

For many years, I've been developing web applications using the web platform as is.

Recently, as many others, I've looked at what possibilities would be to use AI to help generate templates, components and even whole apps.

In this post, I've decided to let Google's Gemini generate everything for a small web demo, using web components and see how it goes.

A simple data set

For data, I decided to ask Gemini to generate a JSON file containing a structured JSON of the top 100 classic novels:

Prompt: "Create a structured JSON file, containing a list of the top 100 classic novels, including author, title, release year and a short synopsis"

Within seconds, I received a JSON containing the following:

{
  "classic_novels": [
    {
      "author": "Homer",
      "title": "The Odyssey",
      "release_year": -800,
      "synopsis": "The epic tale of Odysseus, king of Ithaca, and his ten-year journey home after the Trojan War, facing mythical creatures and wrathful gods."
    },
    {
      "author": "Mary Shelley",
      "title": "Frankenstein",
      "release_year": 1818,
      "synopsis": "A young scientist, Victor Frankenstein, creates a sapient creature in an unorthodox scientific experiment, leading to tragic consequences for both."
    },
    {
      "author": "Jane Austen",
      "title": "Pride and Prejudice",
      "release_year": 1813,
      "synopsis": "The story of Elizabeth Bennet, who navigates issues of manners, upbringing, morality, education, and marriage in the society of the landed gentry of early 19th-century England."
    },
    {
      "author": "George Orwell",
      "title": "1984",
      "release_year": 1949,
      "synopsis": "In a dystopian superstate ruled by the totalitarian Party, Winston Smith secretly defies the regime, an act that leads him to question everything he knows."
    },
    {
      "author": "Harper Lee",
      "title": "To Kill a Mockingbird",
      "release_year": 1960,
      "synopsis": "Narrated by a young girl named Scout Finch, this novel explores themes of racial injustice and the loss of innocence in the American South during the Great Depression."
    },
...

Making it visible

Then Asking Gemini to generate a standalone HTML page, where it's possible to load the JSON and show it using only web standards, again within seconds, the output was presented:

Prompt: "now make a standalone web page (HTML), where it's possible to load this file and display it in a table, where it's possible for the user to sort by author, title or release year. No external dependencies should be used and the items should be shown as a card, rendered like an old school library card - using web components but only using pure web standards"

The web view:

Sorting works as expected - very cool :)

I then asked Gemini to modify the HTML to add a view transition on clicking a card to bring it into focus and again, within seconds the result was there:

Prompt: "can you change the html, so when a card is clicked, it will make a view transition to fill the screen and when clicked again, it will go back in the list"

Looking at the code

When looking through the produced HTML, it's nice to see how comments explain the reasoning behind functionality that I didn't explicitly ask for, but makes sense in the context of - in this case - visualization of publishing year:

// Helper to format year (e.g., -800 -> 800 BCE)
formatYear(year) {
    if (year < 0) {
        return `${Math.abs(year)} BCE`;
    }
    return year;
}

It's also nice to see how Gemini has chosen to make a sort function to handle both text (title and author) and numbers (publishing year):

function sortData(key) {
    if (!novelsData || novelsData.length === 0) return;

    novelsData.sort((a, b) => {
        if (typeof a[key] === 'string') {
            // Case-insensitive string comparison
            return a[key].localeCompare(b[key]);
        } else if (typeof a[key] === 'number') {
            // Numeric comparison
            return a[key] - b[key];
        }
        return 0;
    });
}

For browsers not supporting the View Transition API, there is even a fallback:

cardContainer.addEventListener('click', (event) => {
    const clickedCard = event.target.closest('library-card');
    if (!clickedCard) return;

    const isFocused = clickedCard.classList.contains('focused');

    // Use the View Transitions API
    if (document.startViewTransition) {
        document.startViewTransition(() => {
            toggleFocus(clickedCard, !isFocused);
        });
    } else {
        toggleFocus(clickedCard, !isFocused);
    }
});

In general, the produced JavaScript, CSS and HTML gets the job done and I am impressed.

Making a game

After seeing how well Gemini handled the task, I wanted to give it a slightly harder challenge: To create a small game with keyboard input, audio and all.

Prompt: "Using pure web standards, create a small game in a standalone HTML file, where it's possible to control a car seen from above, using the arrow keys on the keyboard. Also include realistic generated sound effects using web audio. It should be possible to "drive" the car around on the screen, collecting coins randomly placed. There should be a score number accumulated in the top right corner"

Within seconds, it delivered:

NOTE: Sound was not captured in the video, but you can try out the game here

Conclusion

It was quite fun and impressive to see how easy it was to create these fully functional web demos with a few simple requests to Gemini. Even if the output may not be exactly what was intended, the code is well structured and easy to read and modify.

The code produced can be found here

Enjoy :)

Web NFC and Broadcast Audio URIs

Lars Knudsen 🇩🇰 — Sun, 22 Jun 2025 12:09:52 +0000

Reducing Connection Friction

In a future world filled with wireless audio broadcasts, from public announcements at airports to silent TVs at the gym, finding and connecting to the right audio source can be a clumsy process. Remember, an Auracast™ assistant's job is to scan for broadcasts and provide a UI for users to join them. But how does the assistant know which of the dozens of potential broadcasts is the right one?

One elegant solution is the Broadcast Audio URI (BAU), a standardized link format designed to share information about an audio broadcast. While my previous posts have shown how this can be shared via QR codes, but here we will explore how a similar experience could be made, using Near Field Communication (NFC) and the Web NFC API.

Thanks to my friend Kenneth (link) who introduced me to Web NFC, where he was one of the main contributors to the spec.

Imagine this: you walk up to a screen, tap your phone on a small sticker, and your earbuds are instantly tuned to the correct audio stream.

A Quick Recap: The Broadcast Audio URI (BAU)

Before we look at the code, let's remember what a BAU is. It's a string that starts with BLUETOOTH:UUID:184F and contains key-value pairs with information like the Broadcast ID (BI), device address (AD), and the Broadcast Name (BN). This gives an assistant all the information it needs to find and synchronize to a specific broadcast stream.

A typical BAU might look like this:
BLUETOOTH:UUID:184F;BN:UHVibGljIE5ld3M=;BI:DE51E9;...

This tiny piece of text is the key to unlocking a specific audio broadcast. Now, let's put it on an NFC tag.

Reading the URI with Web NFC

The Web NFC API allows a web application, with the user's permission, to read from and write to NFC tags.

Note: In this post, we'll just cover how to the read the NFC tag.

The process involves two main steps:

Initiating a scan and waiting for the user to tap a tag.
Handling the reading event to process the data from the tag.

Let's build a simple function within a hypothetical web-based Auracast™ Assistant. This function will be triggered by a "Scan NFC" button.

async function scanForBroadcastURI() {
  const ndef = new NDEFReader();

  console.log("User activated NFC scan...");
  try {
    // Start scanning for NFC tags
    await ndef.scan();
    console.log("NFC Scan started. Please tap a tag.");

    // Add a one-time event listener for the 'reading' event
    ndef.addEventListener('reading', ({ message }) => {
      console.log("NFC tag read.");

      // Iterate over the records in the message
      for (const record of message.records) {
        if (record.recordType === "text" || record.recordType === "url") {
          const textDecoder = new TextDecoder();
          const uri = textDecoder.decode(record.data);

          // Check if it's a valid Broadcast Audio URI
          if (uri.startsWith("BLUETOOTH:")) {
            console.log(`Broadcast Audio URI found: ${uri}`);
            // Pass the URI to the assistant's connection logic
            tuneToBroadcast(uri);
            // We found what we needed, no need to process other records
            return;
          }
        }
      }
    }, { once: true }); // Use { once: true } to automatically stop listening after one read

  } catch (error) {
    console.error(`NFC Scan failed: ${error}`);
  }
}

function tuneToBroadcast(uri) {
  // This is where the assistant's logic would parse the URI
  // and instruct the underlying Bluetooth hardware to sync
  // to the broadcast source.
  console.log(`Tuning to broadcast with data: ${uri}`);
  // e.g., connectToAuracast(parseBAU(uri));
}

In this code, we start a scan and listen for a reading event. When a tag is successfully read, we decode its payload, check if there is a Broadcast Audio URI in the records, and then pass it off to another function to tune into the broadcast.

The Web NFC User Experience

With this implementation, the user journey becomes incredibly simple:

The user opens our web-based Broadcast Assistant on their phone.
They press a "Scan NFC" button, which calls the scanForBroadcastURI() function.
The user taps their phone against an NFC tag placed near the audio source (e.g., on a museum exhibit, a TV screen, or a conference hall door).
The web app instantly reads the Broadcast Audio URI and automatically tunes the user's connected earbuds to the correct stream.

Conclusion

By combining the simple, physical interaction of NFC with the standardized data format of the Broadcast Audio URI, we can create a powerful and intuitive user experience for Auracast™. The Web NFC API provides the final, critical piece of the puzzle, allowing developers to build these advanced, hardware-integrated experiences directly for the web platform.

This is yet another testament to how the modern web is closing the gap, enabling interactions that were once the exclusive domain of native applications.

Enjoy ;)

A Web based Broadcast Assistant

Lars Knudsen 🇩🇰 — Thu, 06 Mar 2025 07:30:00 +0000

Broadcast Assistants

From: the Bluetooth SIG page on Auracast:

Auracast™ assistants scan for Auracast™ advertisements and provide a user interface (UI) to enable users to select an Auracast™ broadcast to join, similar to the UI commonly used to connect to Wi-Fi networks in public spaces.

In the most normal setup, available in the market today, a user would need:

A pair of Auracast enabled earbuds (broadcast sinks)
A phone with Auracast assistant functionality
Being near one or more Auracast transmitters (broadcast sources)

As the number of phones including assistants is very limited at the moment - and those assistants having very limited functionality - it could be interesting to try to build one of our own to explore this new and interesting technology.

NOTE: For more details on this and LE Audio Broadcast and Unicast in general, Nick Hunn wrote an excellent book on LE Audio: Introducing Bluetooth LE Audio, 2nd Edition

Limitations in Android

Since Android 13, 3rd party applications have been prohibited from accessing LE Audio related Bluetooth GATT Services.

Looking at the list of these services, we see that the Broadcast Audio Scan Service (BASS) is included as one of the restricted services.

This means that if we want to create an application that acts as a broadcast assistant on a modern Android phone, we need to look for another solution.

Web and Zephyr for the Win!

Luckily, WebUSB, that works on both mobile and desktop browsers, can be used to communicate with external hardware doing all the Bluetooth LE communication (unrestricted), while a nice and functioning UI can then be made as a pure web application.

WebUSB is part of Project Fugu (Web Capabilities), consisting of a range of Web APIs, narrowing the gap between native apps and web. To learn more, check out this great showcase of what it can be used for: https://developer.chrome.com/docs/capabilities/fugu-showcase

As mentioned in an earlier post on building a broadcast audio source, the Zephyr RTOS contains some awesome Bluetooth LE Audio related samples. It also contains a Bluetooth LE Audio stack with great API support available to build a functioning broadcast assistant.

Again, using the Nordic Semiconductor nRF52840 Dongle for the Zephyr firmware part of the application, allows the user to get broadcast assistant functionality on any Android phone with a fairly recent browser and a small dongle attached via USB.

Modern Web

We decided to build the web application, using pure vanilla web technology (no frameworks) as things like Web Components, which is supported in all major browsers, make it very easy to build UI elements.

Also, being able to make custom classes, extending EventTarget, eliminates the need for any special framework based event system.

We also decided not to "build" (or minify) the code, as we would then be able to run the application directly from the source "as is", either using a local web server, or when hosted from github.

Some of the web technologies used:

Web Components for UI elements
WebUSB to connect to hardware
Web Share API to share details of detected sources
Barcode Detection API to read Broadcast Audio URIs

Using the Web Broadcast Assistant

When the web application is loaded, it prompts the user to connect to a USB device, running the assistant firmware, made with the Zephyr RTOS:

Click connect and select the device:

And after granting permission to connect, the app should look something like this:

Let's play some music!

Here, we will use the broadcast source described in detail in this previous post, where audio data is stored in flash on an nRF52840 Dongle, playing forever in a loop.

As a broadcast audio receiver, a pair of Samsung Galaxy Buds2 Pro are used.

First, scan for Auracast sources:

Then for receiver devices:

Connect the earbuds:

And press play to listen to the broadcast source in the connected earbuds:

Multiple subgroup support

The broadcast source used above is a simple, single-subgroup source, but as described in this previous post, the Zephyr RTOS stack supports multiple subgroups for both sources (transmitters), sinks (receivers) and assistants (check the BAP broadcast samples here).

Let's try to scan for sources, using the multi language source described here.

When the web assistant discovers a broadcast source with multiple subgroups, an extra selection layer becomes available:

Now, if you would like to hear the Spanish stream, just select it and press play:

Unfortunately, the earbuds used to listen to the single-subgroup source above, don't seem to support multiple subgroups yet (the sound doesn't seem to play at least - maybe with a future firmware update?).

However, if you want to try out a working setup, the BAP Broadcast Sink sample does actually support multiple subgroups. But that's a topic for another post.

Conclusion

Combining the Zephyr RTOS stack, running on an affordable nRF52840 Dongle with the power of modern web technologies turned out quite well and it has also allowed us to experiment with multiple subgroups, supported by the specs, but not yet by many devices in the market (at the time of writing at least - be sure to keep an eye out for that!).

Auracast and multiple subgroups

Lars Knudsen 🇩🇰 — Tue, 04 Mar 2025 01:10:00 +0000

Introduction

In this previous post on broadcast sources, we covered how to create a simple BAP broadcast source using Zephyr RTOS and a Nordic Semiconductor nRF52840 Dongle, broadcasting a single 16 kHz mono audio stream.

In this post, we will explore how to extend that to a more complex source, broadcasting several "tracks" in parallel.

BASE (Broadcast Audio Source Endpoint)

The Bluetooth Basic Audio Profile (BAP) spec, section 3.7.2.2 describes how to create a BASE (Broadcast Audio Source Endpoint) for the..

Broadcast source (Level 1 - BIG), which can contain..
One or more parallel groups (Level 2 - Subgroups) containing..
One or more streaming channels (Level 3 - BIS)

...with the possibility to specify various combinations of codec configuration and metadata on level 2 and 3.

The most common case, would be e.g. a TV or phone, broadcasting a simple stereo signal (one subgroup containing two streams) with some added metadata, e.g. the title of what's currently being broadcasted (in the ProgramInfo metadata field of the subgroup).

This is fine for simple streaming, but what if we could utilize the flexibility of the BASE structure to create broadcast sources covering some more interesting cases?

Multiple subgroups

One obvious case that could be interesting to look at, is a multi-language source, e.g. to be used for tourist attractions.

In this case, mono-channel audio (for each language) with 16 kHz sample rate should be sufficient and this would also allow for 5-7 "stream tracks" (subgroups with language metadata containing one mono stream each) to fit both in the BASE structure and airtime wise (the amount of data possible to send in a given timeframe has physical limitations).

Another interesting case, could be to have two subgroups with different sample rates, but otherwise same streaming content. This would allow for high-powered receivers to receive and playback high quality audio (e.g. 48 kHz), while more resource constrained devices (like hearing aids) to receive and playback standard quality audio (e.g. 24 kHz) - at the same time, from the same broadcast source.

Building with Zephyr

In order to explore these cases, a variant of the simple broadcast application used in a previous post was created: https://github.com/AstraeusLabs/multi-source

Different from the simple broadcast application, this one utilizes a range of pre-encoded, 1s sine wave audio snippets in 16/24/48 kHz sample rate and for each sample rate, various sine frequencies. This allows us to create a wide variety of combinations of subgroups and streams from the same application source.

5 different language tracks

In order to explore the first case with multiple languages, a customized source is created, containing 5 subgroups (distinguishable by different Language specified in the metadata for each subgroup), each containing a single mono channel stream.

Some highlights from the code to setup the broadcast source include the languages set for subgroups (English, German, French, Spanish and Italian):

...
struct bt_audio_codec_cfg subgroup_codec_cfg[CONFIG_BT_BAP_BROADCAST_SRC_SUBGROUP_COUNT];
char *lang[] = {"eng","deu","fra","spa","ita"};

static int setup_broadcast_source(struct bt_bap_broadcast_source **source)
{
...
    struct bt_bap_broadcast_source_stream_param
        stream_params[CONFIG_BT_BAP_BROADCAST_SRC_STREAM_COUNT];
    struct bt_bap_broadcast_source_subgroup_param
        subgroup_param[CONFIG_BT_BAP_BROADCAST_SRC_SUBGROUP_COUNT];
    struct bt_bap_broadcast_source_param create_param = {0};
    int err;

    for (size_t i = 0U; i < ARRAY_SIZE(subgroup_param); i++) {

        memcpy(&subgroup_codec_cfg[i], &preset_16_mono.codec_cfg,
                       sizeof(struct bt_audio_codec_cfg));

        bt_audio_codec_cfg_meta_set_lang(&subgroup_codec_cfg[i], lang[i]);

        /* MONO is implicit if omitted */
        bt_audio_codec_cfg_unset_val(&subgroup_codec_cfg[i], BT_AUDIO_CODEC_CFG_CHAN_ALLOC);

        subgroup_param[i].params_count = 1;
        subgroup_param[i].params = &stream_params[i];
        subgroup_param[i].codec_cfg = &subgroup_codec_cfg[i];
    }
...

Also assignment of different 1s, 16 kHz sample rate, pre-encoded sine waves of varying frequency to each mono stream:

...
    for (size_t j = 0U; j < ARRAY_SIZE(stream_params); j++) {
        stream_params[j].data = NULL;
        stream_params[j].data_len = 0;
        samples_per_frame = 160;
        sdu = preset_16_mono.qos.sdu;
        switch(j) {
            case 0:
                streams[j].data_ptr = (uint8_t *)lc3_sine_0200_16;
                break;
            case 1:
                streams[j].data_ptr = (uint8_t *)lc3_sine_0320_16;
                break;
            case 2:
                streams[j].data_ptr = (uint8_t *)lc3_sine_0800_16;
                break;
            case 3:
                streams[j].data_ptr = (uint8_t *)lc3_sine_1000_16;
                break;
            case 4:
                streams[j].data_ptr = (uint8_t *)lc3_sine_1600_16;
                break;
        }

        printk("Reading LC3 header (%p)\n", streams[j].data_ptr);
        printk("======================\n");

        ret = lc3bin_read_header(&streams[j].data_ptr, &frame_us, &srate_hz, &nchannels, &nsamples);

        printk("Frame size: %dus\n", frame_us);
        printk("Sample rate: %dHz\n", srate_hz);
        printk("Number of channels: %d\n", nchannels);
        printk("Number of samples: %d\n", nsamples);

        /* Store position of start and end+1 of frame blocks */
        streams[j].start_data_ptr = streams[j].data_ptr;
        streams[j].end_data_ptr = streams[j].data_ptr + (nsamples / samples_per_frame) *
            (sdu + 2); // TBD

        streams[j].sdu = sdu;

        stream_params[j].stream = &streams[j].stream;
        bt_bap_stream_cb_register(stream_params[j].stream, &stream_ops);
    }
...

The full source for this configuration can be found here

Capturing the streams with blueSpy

As in the previous post, let's try to capture the broadcast source streams using the RFcreations mini-moreph together with the blueSpy software.

Immediately after starting the capture and selecting the broadcast device in the Filter Devices panel, it's clear that we have successfully built a broadcast source with 5 streams of 16 kHz audio:

full size

Looking closer at the Timeline it's also clear that each stream contains slightly different frequency wave data:

full size

Using the live playback function in the Audio Export for each stream also confirms this.

Selecting one of the entries with BASE information in the Summary panel and looking at the Details tab on the right side of the screen also shows, that the BASE contains 5 subgroups with different language indications in the metadata:

full size

Conclusion

Even though the first Auracast capable devices available in the market, currently only seem to support the simple case of "1 subgroup with stereo audio", it's still worth exploring other use cases like the ones mentioned above.

Also, it's really great to see that the RFcreations mini-moreph and blueSpy software was able to capture and render this slightly more advanced source and that it was possible to build using Zephyr RTOS and the nRF52840 Dongle.

The full repo containing a bunch of different source configurations can be found here.

Enjoy ;)

A simple Broadcast Audio Source

Lars Knudsen 🇩🇰 — Mon, 03 Mar 2025 21:55:00 +0000

Broadcast Audio Transmitters and Receivers

A simple BAP broadcast source (transmitter) that will be compatible with LE Audio broadcast receivers (e.g. some high-end earbuds available now) should advertise, including a field containing service data for the Broadcast Audio Announcement Service (0x1852) with a Broadcast ID as the data.
It also needs to provide LC3 encoded audio (the actual data) in isochronous channels which the periodic advertising train provides a pointer to.

LC3 is the new improved audio codec providing better quality with lower bandwidth.

Information about the source stream(s) is also provided through periodic advertising:

BIGinfo: Provides information needed by receivers to understand the stream (e.g. timings, possible encryption, etc.)
BASE (Broadcast Audio Source Endpoint): Contains information about the streams provided by the broadcast source, e.g. left/right channels, meta data like language and more

When a receiver is instructed to "tune in" to the broadcast (given Bluetooth LE address, Broadcast ID and Advertising Set ID), it will then be able to discover the correct broadcast source and synchronize to the broadcasted periodic advertising and eventually, decode and playback the audio broadcasted from the selected broadcast source (transmitter).

NOTE: This section only contains a very high level overview of the transmitter. For more details, Nick Hunn wrote an excellent book on LE Audio: Introducing Bluetooth LE Audio, 2nd Edition

Zephyr and LE Audio Broadcasting

The Zephyr RTOS contains some great Bluetooth LE Audio related samples. One of them is the Basic Audio Profile (BAP) Broadcast Source sample.

By default, this sample functions as a very simple broadcast transmitter, either transmitting (mock) sine wave audio or - if available and configured - functions as a USB sound card, transmitting audio provided through a USB interface (e.g. from a connected PC or phone).

Although this works well for some setups, for some test and development scenarios, it would be practical to have an array of broadcast sources, broadcasting (audible) different audio with minimal configuration and hardware needed.

nRF52840 Dongle and pre-encoded audio

As the sample already compiles and runs on the Nordic Semiconductor nRF52840 Dongle, it seemed reasonable to investigate if this dongle could be used for the purpose.

When building the bap_broadcast_source sample for the nRF52840 (with 1024 kB flash), memory usage is the following:

Memory region         Used Size  Region Size  %age Used
           FLASH:      260908 B      1020 KB     24.98%
             RAM:       62284 B       256 KB     23.76%
        IDT_LIST:          0 GB        32 KB      0.00%

This should leave around 750 kB of flash memory, which could be used to contain audio data.

The bap_broadcast_source sample supports on-the-fly encoding of uncompressed PCM audio samples to LC3 encoded packets for broadcasting. But if we pre-encode the audio in LC3 format and store it in flash memory, we can eliminate the encoding step while also saving memory.

Taking a closer look at the liblc3 module used to encode/decode audio in Zephyr, originating from https://github.com/google/liblc3, shows that it also contains practical command line tools to encode and decode *.wav files to/from LC3 format.

Encoding a *.wav file, containing just above 2 minutes of 16 kHz, mono audio (input16KHz.wav at 4016868 bytes):

.../liblc3/bin$ ./elc3 -b 32000 input16KHz.wav output16KHz.lc3

(32000 is the bitrate for 16 kHz LC3)

The result in output16KHz.lc3 is 527202 bytes of LC3 encoded audio data (including file and data packet headers), which is well below the limit of the 750 kB flash available.

For more information and full source code, look here

Capture with blueSpy

In an earlier post, I wrote about using the RFcreations mini-moreph together with the blueSpy software.

This time, it could be interesting to see what data it is able to capture from the nRF52840 Dongle, broadcasting 16 kHz (mono channel) audio.

Connecting the mini-moreph and starting capturing with the blueSpy software immediately finds the broadcast source with BT name Music and Broadcast name Hold on a Sec, which is chosen in the Filter Devices tab to focus on the advertising sent from the broadcast source dongle.

Looking at the timeline in the bottom, it's also possible to see the 16 kHz mono audio stream captured and correctly detected

full size

Now, if we select one of the entries in the summary pane, containing periodic advertising data and check out the Details pane, it's very easy to inspect both the BIGinfo:

full size

And the BASE, which correctly shows a single subgroup with a single mono-channel 16 kHz BIS:

full size

Another cool feature is in the Audio Export panel, where it's both possible to listen to a selected BIS through the PC speaker and exporting to a file.

full size

Here I noticed yet another very nice feature. By right-clicking on the entries of captured source streams in the Audio Export panel, it's possible to generate a Broadcast Audio URI (with QR code):

full size

By using the simple web test page, described in another post, I was able to verify the code:

full size

Conclusion

In this post, we've covered how to create a simple, affordable standalone BAP Broadcast Source, broadcasting music in a loop from a tiny nRF52840 Dongle and how to capture audio and verifying BIGinfo and BASE with the RFcreations mini-moreph.

The full source code for the simple BAP broadcast source is available here.

Enjoy ;)

Capturing the perfect (radio) wave

Lars Knudsen 🇩🇰 — Wed, 30 Oct 2024 18:58:24 +0000

Introduction

When developing and debugging bluetooth solutions, it is often necessary to know exactly what is communicated in the air between connected devices.

For this purpose, a Bluetooth Protocol Analyzer (or Bluetooth Sniffer) is needed and in this post, I’ll show you how to get started, using the RFcreations mini-moreph together with the blueSpy software, available for download on the RCcreations website.

The software is available for Linux, Windows and Mac. A big plus for me, as I am using Linux on my main development machine.

Getting started with Bluetooth sniffers

Even though I have been developing software in general for almost 40 years and wireless related for the last 10, only recently, I’ve been introduced to using Bluetooth protocol analyzers to debug Bluetooth solutions and this has been a great eye-opener for me (comparable to when I got my first oscilloscope after having done electronics “in the blind” for some years).

I am not an expert (yet) but find the blueSpy software very enjoyable to use and even though the RFcreations solution can capture and analyze very advanced stuff, I’m happy to see that the UI is snappy and the UX being very intuitive. This allows me to explore and learn while using the tool and not being required to look through a bunch of documentation at the same time.

Our first capture

I thought about what would be a good first capture, and remembered, I recently made a very simple Bluetooth Low Energy demo using Zephyr and Web, covered in an earlier post.

After powering up the Nordic Semiconductor nRF52840 Dongle, I connected the mini-moreph via USB and started the blueSpy software.

Initially, the screen looks like this:

Full size

NOTE: If the device is not automatically found and you are using Linux, remember to add a udev rule to allow userspace access to the device (see the PDF manual included with the software):

SUBSYSTEM=="usb", ATTRS{idVendor}=="2bbd", ATTRS{idProduct}=="00f3", MODE="0666"

Starting the capture

Click the red capture button to start capturing all traffic in the air. You should now see the “Filter devices” tab to the right quickly being filled with devices found around the analyzer. At first it can look a bit chaotic, but clicking the search button in the upper right corner allows you to write a partial name, which should quickly bring the device of interest to the top of the table.

NOTE: I’ve also disabled WiFi capture and a few others in this example (keeping the summary view clean and focused).

Full size

Now click the check mark in the “Shown” column for that device and see the filtered traffic starting to flow in the summary panel.

Full size

We quickly see a bunch of advertising data, emitted from the ‘Simple Web Zephyr’ dongle.

Connecting from Web

Now, from a phone, I open the test web page for the project and request a connection to the dongle. Then we see the following initial handshake in the capture summary, including discovery of the service requested from the web application.

Full size

If I try to press and release the button on the nRF Dongle, I see two notifications being sent from the dongle. The first with the payload value 0x01 (indicating "Pressed")...

Full size

...and the second with the payload value 0x00 (indicating "Released") - just as expected:

Full size

From the web application, I now select the color red (payload: [0xFF, 0x00, 0x00])…

Full size

…followed by blue (payload: [0x00, 0x00, 0xFF])…

Full size

Again, the data captured is as expected, but it’s nice to verify :)

Disconnecting the web application from the dongle lets the dongle firmware go back to advertising mode, which we verify in the summary pane.

Full size

Storing capture files

Sometimes, capture files can become quite large - especially if the capture was made in an area with a lot of wireless traffic. To help solve this problem, I found a very neat feature in the blueSpy software file menu, called “Save Advanced…”, which allows you to store just the packets shown in the current filtered summary.

Full size

In my case, this brought the capture file size down to ~2Mb (compared to ~90Mb for the full capture).

Conclusion

I had great fun, finally being able to see the Bluetooth traffic in the air after developing and debugging Bluetooth solutions “in the blind” for years - and blueSpy made it enjoyable.

In my next post, I’ll try to capture some LE Audio Broadcast sources to see how the analyzer handles those.

BarcodeDetector API for LE Audio

Lars Knudsen 🇩🇰 — Sun, 14 Jul 2024 19:22:55 +0000

As mentioned in my post on building a Broadcast Audio Source the Broadcast Audio URI (BAU) spec allows sharing information about broadcast sources through QR codes, NFC tags and more.

In this post, I'll show how you can make a web application that can read and parse the Broadcast Audio URI QR codes.

BarcodeDetector API

Reading barcodes directly in the browser is made possible with the introduction of the BarcodeDetector API and in this post, I will show an example of how it can be used to read the Broadcast Audio URI QR code with a few lines of JavaScript.

NOTE: The BarcodeDetector API is not yet available in all browsers. For this reason, a polyfill will be used where support is still missing.

Reading barcodes with this API is extremely simple. It only requires passing an image source to the detect() function, which returns a Promise that fulfills with an array of DetectedBarcode objects.

Even though we are only focused on QR codes in this post, the API supports many commonly used formats.

Lights, Camera, Action!

First, the camera needs to be switched on and streaming a video feed to an HTMLVideoElement:

...
<video id="camera"
       muted
       autoplay="autoplay"
       playsinline="playsinline">
</video>
...

and

...
const camera = document.querySelector('#camera');
const constraints = {video: true, audio: false};
let stream = await navigator.mediaDevices.getUserMedia(constraints);

camera.srcObject = stream;
...

We also need to make a barcode detector object:

const barcodeDetector = new window.BarcodeDetector();

In order for the detection to work as expected, the detect function needs to be called at regular intervals to scan images captured with the camera:

let lastCode = "";

async function decodeQr(){
  const barcodes = await barcodeDetector.detect(camera);

  if (barcodes?.length) {
    for (const barcode of barcodes) {
      // Try to parse the URI string
      const decoded = parseBroadcastURI(barcode.rawValue);

      if (decoded?.length) {
        // Avoid repainting if the data is already shown
        if (lastCode == barcode.rawValue) {
          break;
        }

        lastCode = barcode.rawValue;

        // Display the parsed info
        showBroadcastInfo(decoded);

        break; // Only use the first code found
      }
    }
  } else {
    lastCode = "";
  }

  // Try again in 100ms
  setTimeout(this.decodeQr, 100);
}

Parsing the Broadcast Audio URI

The scanned code should contain a string, starting with BLUETOOTH:, followed by a number of fields as listed in the Broadcast Audio URI spec.

A QR code example from the spec:

, containing the following data:

BLUETOOTH:UUID:184F;BN:SG9ja2V5;SQ:1;AT:0;AD:AABBCC001122;AS:1;BI:DE51E9;PI:F
FFF;NS:1;BS:1;;

roughly translates to:

"Related to the 0x184F UUID (Broadcast Audio Scan Service), there is a Standard Quality mono channel broadcast at addresss AA:BB:CC:00:11:22 with Broadcast ID 0x0E51E9 and the Broadcast name 'Hockey'"

For this PoC, I created a very simple function to parse the most common fields:

const BROADCAST_AUDIO_URI_SCHEME = 'BLUETOOTH:';

const parseBroadcastURI = (str) => {
  if (!str.startsWith(BROADCAST_AUDIO_URI_SCHEME)) {
    return [];
  }

  const result = [];

  // split sections (;)
  const sections = str.substring(BROADCAST_AUDIO_URI_SCHEME.length).split(';');

  sections.forEach(section => {
    const [key, value] = section.split(':');

    switch (key) {
      case 'UUID':
      result.push({
        type: key,
        name: 'UUID',
        value: `0x${value}`
      });
      break;
      case 'BI': // Broadcast ID
      result.push({
        type: key,
        name: 'Broadcast ID',
        value: `0x${value.padStart(6,0)}`
      });
      case 'BN': // Broadcast name
      result.push({
        type: key,
        name: 'Broadcast Name',
        value: new TextDecoder().decode(base64ToBytes(value))
      });
      break;
      // ... (more fields in full scouce)
    }
  });

  return result;
}

QR Scanner component

In order to make it possible for others to more easily embed the BAU QR scanner in a web application, I decided to create a web component that encapsulates the logic to control the video feed and display the information found in an overlay info box.

In order to use it in a page, just add the following:

<bau-scanner></bau-scanner>
<script type="module" src="./bau-scanner.js"></script>

The element has functions to start and stop the scanning (and camera feed), which can be hooked up to button events, e.g.:

...
<button id="start_scanner">Start scanner</button>
<button id='stop_scanner'>Stop scanner</button>
...

and

...
const startScan = document.querySelector('#start_scanner');
const stopScan = document.querySelector('#stop_scanner');

scanner = document.querySelector('bau-scanner');

startScan.addEventListener('click', scanner.startCamera);
stopScan.addEventListener('click', scanner.stopCamera);
...

An example index.html together with the bau-scanner.js component can be found here: https://github.com/larsgk/bau-source

See it in action

For demonstration purposes, I decided to use two QR codes from the Broadcast Audio URI spec plus a dynamic one, generated with the Broadcast Audio Source sample covered in another post.

Here is the scanner in action, running on a mobile phone:

You can try it yourself by opening this link, where the demo page is hosted: https://larsgk.github.io/bau-source/

Enjoy ;)

Broadcast Audio URI

Lars Knudsen 🇩🇰 — Thu, 06 Jun 2024 20:56:37 +0000

Audio sharing is caring

Until recently, most generic Bluetooth enabled speakers and headsets have been using Bluetooth Classic. With the introduction of Bluetooth LE Audio, a wide new range of solutions become possible and one of the most exciting ones is the possibility to broadcast audio, where the sender and receiver are no longer required to be connected (like the 1-1 Bluetooth Classic case - e.g a phone and a headset).

"LE Audio introduces broadcast audio to Bluetooth® technology, a new feature that enables an audio transmitter to broadcast to an unlimited number of nearby Bluetooth audio receivers. Broadcast audio opens significant new opportunities for innovation, including a powerful new capability, Auracast™ broadcast audio.

Auracast™ broadcast audio is a set of defined configurations of Bluetooth® broadcast audio which are specified within the Public Broadcast Profile (PBP) specification that enables new, globally interoperable audio experiences for consumers."

Read more about Auracast here: https://www.bluetooth.com/auracast/developers/

Sharing Links to Broadcasts

Even though it is possible to scan for nearby broadcasts using a Broadcast Audio Assistant, sometimes, it will be more practical for users to 'tune in' to Broadcast sources using a trusted link provided through other means.

The Broadcast Audio URI is an exciting new spec that allows just that: Information about a Broadcast Audio Source to be conveyed over an out-of-band (OOB) medium to a Broadcast Audio Assistant - or, if the Broadcast Sink supports it, directly by e.g. touching an NFC tag, containing the Broadcast Audio URI, with a speaker or earbuds.

An example from the spec:

This includes all the information for a Broadcast Sink to find the right broadcast. The data in the QR code is this text:

BLUETOOTH:UUID:184F;BN:SG9ja2V5;SQ:1;AT:0;AD:AABBCC001122;AS:1;BI:DE51E9;PI:F
FFF;NS:1;BS:1;;

Which roughly translates to:

Zephyr for the win!

The Zephyr RTOS is a very powerful OS for embedded devices and it also includes support for LE Audio. If this is the first time you hear about it, please check some of my other posts on getting started with Zephyr, e.g. Getting started with Zephyr and Web Bluetooth

In the Zephyr repo, there is a Broadcast Audio Source sample that was used as a starting point.

There is also great support for different displays, which we will need to display the Broadcast Audio URI in a QR code.

To my happy surprise, there was already QR code support in the LVGL module included in Zephyr so I implemented some minimal QR-Code functionality to expose the required data once the Broadcast source was ready on the device. As this is a PoC, the non-changing parameters are hardcoded:

void gui_update_qr_code(const bt_addr_t *addr, uint32_t broadcast_id, uint8_t *name)
{
    uint8_t addr_str[13];
    uint8_t name_base64[128];
    size_t name_base64_len;

    /* Address */
    snprintk(addr_str, sizeof(addr_str), "%02X%02X%02X%02X%02X%02X",
            addr->val[5], addr->val[4], addr->val[3],
            addr->val[2], addr->val[1], addr->val[0]);

    /* Name */
    base64_encode(name_base64, sizeof(name_base64), &name_base64_len, name, strlen(name));
    name_base64[name_base64_len + 1] = 0;

    /* Most fields hard coded for this demo */
    snprintk(qr_data, sizeof(qr_data),
         "BLUETOOTH:UUID:184F;BN:%s;SQ:1;AT:1;AD:%s;AS:0;BI:%06X;PI:FFFF;NS:1;BS:1;;",
         name_base64, addr_str, broadcast_id);

    lv_qrcode_update(qr_code, qr_data, strlen(qr_data));
    lv_task_handler();
}

The result is here:

Try it out!

Put together, here is a PoC of how a Broadcast Audio URI can be used to expose a dynamically generated QR code on an nRF5340 Audio DK with a screen attached.

Hardware used:

nRF5340 Audio DK

Adafruit 2.8" TFT Touch Shield

The code is available here: https://github.com/larsgk/bau-source

Connecting the board to the USB port of any host device supporting USB Audio (Windows, Linux, Mac, Android, ChromeOS, etc), will automatically make the connected board a Broadcast Audio Source, streaming whatever is played on the host device. If you have access to one of the latest Samsung mobile phones and Galaxy Buds2 Pro, you should be able to find and select the broadcast and hear it in the earbuds.

See it in action

Currently, there are no implementations of the full Broadcast Audio URI flow in any device available on the market, so I have been using a dedicated web based stand-alone broadcast assistant application, modified to read and parse the Broadcast Audio URI QR code (this will be covered in a future post). It's using the BarcodeDetector API on supported devices to read the QR code.

It allows a user to scan a Broadcast Audio URI QR code and add it directly to an attached Broadcast Sink (e.g earbuds able to receive broadcasts, like the Samsung Galaxy Buds2 Pro).

The result is here:

Credits to Nick Hunn, Hai Shalom and others on doing great work on the Broadcast Audio URI

Also, major credits to Emil Gydesen, maintainer of the LE Audio stack in Zephyr, that made this possible.

Handling files in enterprise web solutions

Lars Knudsen 🇩🇰 — Mon, 04 Mar 2024 17:20:00 +0000

Correct file handling can be cumbersome without proper system integration and selection of which applications can handle what types of files.

Web solutions have previously been disconnected from this because of limitations in the browser to system integration.

This is no longer the case, and this post will cover the key parts of making a solution that works.

To make things more concrete, we will look at how to create a simple GeoJSON viewer application that will automatically open and display GeoJSON files when double-clicking them (or selecting the app on "Open with...").

Note: This feature is desktop only

File Handling in manifest.json

In the file manager and the desktop view of most operating systems, there is a file handling UI that directs the user to use a certain app to handle the chosen file. Previously, this was limited to native app installations, but now, it's possible for web applications to register handlers tied to PWAs that will handle files matching certain extension patterns.

Thomas Steiner has created a great article about this here:

https://developer.chrome.com/docs/capabilities/web-apis/file-handling

What's needed

file_handlers entries in manifest.json
Code to handle loading the files
Installation of the web application

Let's look at these one by one.

`file_handlers` in manifest.json

Note: In order to make the web application 'installable', a manifest file needs to be present with minimal information as described here.

Inside the manifest file, create a section with the key file_handlers. This contains an array of the file types that the application can handle (accept), which URL to open (action, must be within the scope of the installed PWA), icons and launch_type, describing if new instances should be made for each file on "Open with..." selection.

...
"file_handlers": [
  {
    "action": "./?log=y",
    "accept": {
      "application/geo+json": [".geojson"]
    },
    "icons": [
      {
        "src": "./images/treasure-map-256.png",
        "sizes": "256x256",
        "type": "image/png"
      }
    ],
    "launch_type": "multiple-clients"
  }
]
...

In our case, we are interested in handling files with the .geojson extension and we will send it to our PWA with an additional query parameter to enable debug logging (log=y).

File loading handler(s)

When the PWA is opened by the OS via an "Open with..." action, the file(s) selected will be available through the launchQueue interface:

if ('launchQueue' in window && 'files' in LaunchParams.prototype) {
  launchQueue.setConsumer(async (launchParams) => {
    if (!launchParams.files.length) {
      return;
    }
    for (const fileHandle of launchParams.files) {
      // Handle the file.
      const file = await fileHandle.getFile();
      this.loadGeoJSONFile(file);
    }
  });
} else {
  console.log("File Handling API NOT supported");
}

Installation and usage

Open the application in a supported browser and click the install icon in the address bar.

Then go to the file explorer, right click a GeoJSON file (with the .geojson extension) and see how the freshly installed PWA is now registered to handle GeoJSON files.

On first launch, the user is prompted to check if this should be the default behavior:

When the PWA starts, the GeoJSON is loaded, passed to the map and immediately displayed:

Note: The collapsible activity log in the bottom of the screen is activated because of the additional log=y passed to the application.

Windows and Edge

The section above describes how the flow looks when using Chrome and Ubuntu. Here we will go through the same flow, but using Edge on Windows.

Credit: @kennethrohde

Installation:

Open .geojson file with the PWA:

Loading GeoJSON:

OpenLayers

In order to display the GeoJSON features on a map, we will use OpenLayers, which is a very powerful open-source mapping library that is also very simple to use.

In this post, we will not dive into all the details, so I will just show the snippets related to initializing the map and adding the GeoJSON data on top:

...
// Init map
this.#map = new ol.Map({
  layers: [
    new ol.layer.Tile({
      source: new ol.source.OSM(),
    }),
    this.#vectorLayer,
  ],
  target: this.#mapEl,
  view: new ol.View({
    center: [0, 0],
    zoom: 2,
  }),
});

...

// Load GeoJSON
plotGeoJSON(obj) {
  const features = new ol.format.GeoJSON({
    featureProjection: 'EPSG:3857'
  }).readFeatures(obj);

  const vectorSource = new ol.source.Vector({ features });

  this.#vectorLayer.setSource(vectorSource);

  setTimeout(() => {
    this.#map.getView().fit(vectorSource.getExtent(), { duration: 1000 });
  }, 500);
}

Creating GeoJSON files

Inside the project repository, there are a few GeoJSON samples generated with the awesome GeoJSON editor here: geojson.io. This web application let's you create features by drawing on a map and the features are then immediately reflected in a GeoJSON format on the right side of the screen.

TIL GitHub has a nice GeoJSON viewer built-in:

Conclusion

Having the option of adding file handling on a system level is a very powerful feature and also extremely useful, e.g for enterprise tools to optimize workflows.

The effort involved in adding the feature in a PWA is close to nothing and personally I enjoyed experimenting with this very much.

The code is available here: https://github.com/larsgk/filehandling-geojson

The application is hosted here: https://larsgk.github.io/filehandling-geojson

Enjoy ;)

Getting started with Zephyr and Web Bluetooth

Lars Knudsen 🇩🇰 — Mon, 04 Dec 2023 22:05:57 +0000

For this post, I wrote the embedded firmware and accompanying test web page in an afternoon - and I want everyone to know that they can too.

I did cheat a bit, as I am standing on the shoulders of giants, using the Zephyr RTOS on the embedded side and using APIs in the browser that has taken quite some energy to perfect (credits go to @reillyeon@toot.cafe, @Vincent_Scheib, @quicksave2k and more ).

Anyway, let's get to work!

What this thing does

The firmware exposes a GATT service with a few characteristics:

Setting the color of the primary RGB LED
Setting an ID, which will be appended to the BT name (convenient when in a workshop with multiple devices)
Being notified of button presses

It also enables logging over USB, if the board supports it.

In the root of the repository, there is a very simple self contained HTML file (so it doesn't require a web server when loaded as a file locally) to interact with the hardware via Web Bluetooth.

A simple GATT service

In order to enable easy control from a web application using Web Bluetooth, a simple GATT service must be created.

First, we need to create UUIDs to be used for the service and characteristics.

static struct bt_uuid_128 simple_io_service_uuid = BT_UUID_INIT_128(
    BT_UUID_128_ENCODE(0x13e779a0, 0xbb72, 0x43a4, 0xa748, 0x9781b918258c));

static const struct bt_uuid_128 simple_io_rgb_uuid = BT_UUID_INIT_128(
    BT_UUID_128_ENCODE(0x4332aca6, 0x6d71, 0x4173, 0x9945, 0x6653b6c684a0));

static const struct bt_uuid_128 simple_io_id_uuid = BT_UUID_INIT_128(
    BT_UUID_128_ENCODE(0xb749d964, 0x4efb, 0x408a, 0x82ad, 0x7495e8af8d6d));

static const struct bt_uuid_128 simple_io_button_uuid = BT_UUID_INIT_128(
    BT_UUID_128_ENCODE(0x030de9cf, 0xce4b, 0x44d0, 0x8aa2, 0x1db9185dc069));

The UUIDs are the unique identifiers used by the central device (in this case, the web application) to find the correct services and characteristics in BLE devices. Some are short, officially assigned, 16bit values - the Battery service (= 0x180F) or Heart Rate service (= 0x180D) - but for custom services and characteristics like these, a custom 128bit UUID must be provided.

For UUID generation, I'd recommend using one of the many online tools.

Defining the GATT service structure in Zephyr:

/* Simple IO Service Declaration */
BT_GATT_SERVICE_DEFINE(simple_io_svc,
    BT_GATT_PRIMARY_SERVICE(&simple_io_service_uuid),
    BT_GATT_CHARACTERISTIC(&simple_io_button_uuid.uuid,
                   BT_GATT_CHRC_NOTIFY,
                   BT_GATT_PERM_NONE,
                   NULL, NULL, NULL),
    BT_GATT_CCC(button_ccc_cfg_changed,
            BT_GATT_PERM_READ | BT_GATT_PERM_WRITE),
    BT_GATT_CUD("Button(s)", BT_GATT_PERM_READ),
    BT_GATT_CHARACTERISTIC(&simple_io_rgb_uuid.uuid,
                BT_GATT_CHRC_WRITE,
                BT_GATT_PERM_WRITE,
                NULL, write_rgb, NULL),
    BT_GATT_CUD("RGB", BT_GATT_PERM_READ),
    BT_GATT_CHARACTERISTIC(&simple_io_id_uuid.uuid,
                BT_GATT_CHRC_WRITE,
                BT_GATT_PERM_WRITE,
                NULL, write_id, NULL),
    BT_GATT_CUD("Device ID", BT_GATT_PERM_READ),
);

This structure defines a GATT service containing the needed characteristics. For the sake of keeping things simple, a characteristic can be seen like a 'property' (or variable) made available over the air with a specified combination of write, read and/or notify capabilities (Note: there are more advanced options but for now, just focus on these three).

We have the following defined:

A button characteristic: Will notify on button presses.
An rgb characteristic: To allow writing an RGB value.
A device id characteristic: To allow writing an ID.

When a connected device writes an RGB color value (e.g. via Web Bluetooth), the write_rgb function is called:

static ssize_t write_rgb(struct bt_conn *conn, const struct bt_gatt_attr *attr,
            const void *buf, uint16_t len, uint16_t offset, uint8_t flags)
{
    uint8_t val[3];

    printk("%s: len=%zu, offset=%u\n", __func__, len, offset);

    if (offset != 0) {
        return BT_GATT_ERR(BT_ATT_ERR_INVALID_OFFSET);
    } else if (len != sizeof(val)) {
        return BT_GATT_ERR(BT_ATT_ERR_INVALID_ATTRIBUTE_LEN);
    }

    (void)memcpy(&val, buf, len);

    if (simple_io_cbs->set_rgb) {
        simple_io_cbs->set_rgb(val[0], val[1], val[2]);
    }

    return len;
}

This basically checks that 3 bytes are sent and if a set_rgb callback is registered, this will be called using the 3 bytes as red, green and blue values.

The full source can be found here.

Advertising

Correctly discovering Bluetooth Low Energy devices requires them to advertise information about who they are, what services they provide or something else to allow unique or filtered identification. You have probably seen this when trying to pair with a new set of earbuds, keyboard or other type of device from e.g. a mobile device.

In our case, we are interested in providing two things:

The UUID of our custom service
The name of the device

This is primarily done in two steps. First, we define the advertising payload containing the service UUID:

static const struct bt_data ad[] = {
    BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
    BT_DATA_BYTES(BT_DATA_UUID128_ALL, BT_UUID_SIMPLE_IO_SERVICE),
};

After the bluetooth stack is enabled and ready, we start advertising, including the name (will be added automatically by the Zephyr stack):

static void bt_ready(void)
{
    int err;

    printk("%s: Bluetooth initialized\n", __func__);

    if (IS_ENABLED(CONFIG_SETTINGS)) {
        settings_load();
    }

    bt_simple_io_register_cb(&io_cbs);

    err = bt_le_adv_start(BT_LE_ADV_CONN_NAME, ad, ARRAY_SIZE(ad), NULL, 0);
    if (err) {
        printk("%s: Advertising failed to start (err %d)\n", __func__, err);
        return;
    }

    printk("%s: Advertising successfully started\n", __func__);
}

The full source for the main application can be found here.

Cloning, building and flashing

Before cloning the application repository, go to The Zephyr getting started guide and install all dependencies (I'd recommend following the path with the virtual python environment).

This repository contains a stand alone Zephyr application that can be fetched and initialized like this:

west init -m git@github.com:larsgk/simple-web-zephyr.git --mr main my-workspace

Then use west to fetch dependencies:

cd my-workspace
west update

Go to the app folder:

cd simple-web-zephyr

There are a few scripts for building and flashing the Nordic Semiconductor nRF52840 Dongle - run them in this order:

compile_app.sh
create_flash_package.sh
flash_dongle.sh

Note: You'll need to get the dongle in DFU mode by pressing the small side button with a nail. The dongle should then start fading a red light in and out.

Web Bluetooth test page

In order to connect to a BLE device using Web Bluetooth, first scan for the device, using a filter. In this case, we look for the advertising of our custom service UUID:

const SIMPLE_IO_SERVICE = '13e779a0-bb72-43a4-a748-9781b918258c';

...

const scan = async () => {
    try {
        const device = await navigator.bluetooth.requestDevice({
            filters: [{ services: [SIMPLE_IO_SERVICE] }]
        });

        await openDevice(device);
    } catch (err) {
        // ignore if we didn't get a device
    }
}

After connecting to the device, find the GATT service and hook up the characteristics:

const openDevice = async (device) => {
    const server = await device.gatt.connect();

    try {
        const service = await server.getPrimaryService(SIMPLE_IO_SERVICE);

        await startButtonNotifications(service);
        await fetchRGBCharacteristic(service);

        console.log('Connected to device', device);
        statusElement.innerHTML = `Connected to ${device.name}`

        device.ongattserverdisconnected = _ => {
            console.log(`Disconnected ${device.id}`);
            statusElement.innerHTML = "Not Connected";
        };
    } catch (err) {
        console.warn(err);
    }
}

Start listening for button change notifications...

const startButtonNotifications = async (service) => {
    const characteristic = await service.getCharacteristic(SIMPLE_IO_BUTTON_CHAR);
    characteristic.addEventListener('characteristicvaluechanged', (evt) => {
        const value = evt.target.value.getUint8(0);
        console.log(`Button = ${value}`);
        statusElement.innerHTML = `Button ${value === 0 ? "released" : "pressed"}`;
    });
    return characteristic.startNotifications();
}

...and connect the RGB characteristic to allow the application to set a color:

const fetchRGBCharacteristic = async (service) => {
    rgbCharacteristic = await service.getCharacteristic(SIMPLE_IO_RGB_CHAR);
}

...

const setRGB = (r, g, b) => {
    if (rgbCharacteristic) {
        rgbCharacteristic.writeValueWithoutResponse(new Uint8Array([r, g, b]));
    }
}

The full source for the web application is available here

Working together

Let's try to connect the web application to an nRF52840 dongle flashed with the Zephyr application.

First, connect the dongle to a power source (e.g. a PC USB port):

The dongle should start flashing blue.

NOTE: Spiderman wanted to make sure the dongle was properly web enabled but he is not strictly needed (please don't tell him)

Then open the web application in a Web Bluetooth capable browser.

You should see something like this:

Now, press the CONNECT button and a connect dialog should appear, listing the devices found that satisfies the filter given to the requestDevice function. Select the Simple Web Zephyr device and click pair:

After successfully connecting, the page should look like this:

Now try to push the button on the dongle to see the status message change:

This should show the page reacting to button press and release notifications sent from the device.

Try to open the color picker and select e.g. red:

When the light on the dongle magically changes to red, more friends come to watch the fun:

Final remarks

I hope you enjoyed this introduction to Zephyr and Web Bluetooth.

Try to expand the Zephyr application with more services or maybe start adding a bit more functionality to the simple web page (e.g. try to make the RGB light change color on button presses).

The full source code is here: https://github.com/larsgk/simple-web-zephyr

Direct link to the test page is here: https://larsgk.github.io/simple-web-zephyr/single_page.html

Remember: if you download the page file, you can also just load it directly in the browser, make changes and reload.

Enjoy :)

Creating a Web Thermometer

Lars Knudsen 🇩🇰 — Fri, 11 Aug 2023 00:15:00 +0000

Spiderman has joined some LEGO spacemen in a quest to web enable a BLE GATT temperature sensor and display the readings on their 1x1cm brick display...

While they're working on that, I'll share what's under the hood :)

Temperature Sensor in Thingy:52

The Thingy:52 by Nordic Semiconductor has a lot of built-in sensors (temperature, humidity, pressure, air quality, color, accelerometer, gyroscope, and more).

First, switch it on:

In our case, we are interested in reading values from the temperature sensor, so let's take a look in the documentation for the device:

Note: The xxxx in the base UUID should be replaced with numbers from the same column for service and characteristic(s).

From this, we can see two 128bit UUIDs we need:

ef680200-9b35-4933-9b10-52ffa9740042 - the "Weather station service"
ef680201-9b35-4933-9b10-52ffa9740042 - the "Temperature characteristic"

It's also a good idea to fetch the battery level, which follows the officially assigned 16bit UUID for battery service:

Connecting to the Thingy:52 from a web application is quite easy, just remember to list the services that might be required for your app in the list of optionalServices:

const THINGY_CONFIGURATION_SERVICE_UUID = 'ef680100-9b35-4933-9b10-52ffa9740042';
const WEATHER_STATION_SERVICE_UUID      = 'ef680200-9b35-4933-9b10-52ffa9740042';
...
const device = await navigator.bluetooth.requestDevice({
    filters: [{ services: [THINGY_CONFIGURATION_SERVICE_UUID] }],
    optionalServices: [
        'battery_service',
        WEATHER_STATION_SERVICE_UUID
    ]
});

Temperature data

The temperature data is made available under the Weather Station Service and in order to read the data, you'll need to subscribe to the temperature updates on the Temperature Characteristic:

const TEMPERATURE_CHARACTERISTIC_UUID   = 'ef680201-9b35-4933-9b10-52ffa9740042';
...
async #startThermometerNotifications(server) {
    const service = await server.getPrimaryService(WEATHER_STATION_SERVICE_UUID);
    const characteristic = await service.getCharacteristic(TEMPERATURE_CHARACTERISTIC_UUID);
    characteristic.addEventListener('characteristicvaluechanged', this.#onThermometerChange.bind(this));
    return characteristic.startNotifications();
}

Whenever there is an update, read out the values:

_onThermometerChange(event) {
    const target = event.target;

    const integer = target.value.getInt8(0);
    const decimal = target.value.getUint8(1);

    const celsius = Number.parseFloat(`${integer}.${decimal}`);

    const temperature = {
        celsius,
        fahrenheit: celsius * 9 / 5 + 32,
        kelvin: celsius + 273.15
    }

    this.dispatchEvent(new CustomEvent('thermometer', {
        detail: temperature
    }));
}

Thermometer Web Component

We'll need some visualization for the thermometer, and I found a very nice thermometer made in pure css by Mircea Georgescu, which will be a good base for a simple thermometer web component.

Disclaimer: I am definitely not a CSS expert, so sorry Mircea for the hacks I made :)

For the purpose of this demo, I have hacked the linear-gradient used for the positioning of the level and the position of the temperature reading:

_handleTemperature({detail}) {
    this.#celsius.innerHTML = `${detail.celsius.toFixed(1)}&deg;C`;
    this.#celsius.style.transform = `translateY(${-detail.celsius/2}px)`;

    const perc = 50 - (detail.celsius * 0.32);
    this.#thermometer.style.background = `linear-gradient(#fff 0%, #fff ${perc}%, #d00 ${perc}%, #d00 100%)`
}

The full source of the component is here.

Building the application

Handling the connection to the Thingy:52 will be done with a scaled down variant what I did in another post: Generic Sensors and Thingy:52. It injects a small widget in the page that handles connectivity and shows battery levels.

Besides that (the thingy52-widget), the application only consists of the new thermometer UI component:

<body>
    <thingy52-widget></thingy52-widget>
    <div class="flex-container">
        <div class="content">
            <div class="col">
                <h2>Web Thermometer</h2>
                <thermometer-ui></thermometer-ui>
            </div>
        </div>
    </div>
</body>

All working together

Repo: https://github.com/larsgk/web-thermometer
Demo: https://larsgk.github.io/web-thermometer

Feedback, requests, issue reports and PRs are very welcome!

Enjoy ;)

Generic Sensors and Thingy:52

Lars Knudsen 🇩🇰 — Sun, 30 Jul 2023 20:29:49 +0000

Sensor APIs

For many years, mobile phones have contained a wide range of sensors - primarily to help provide a good user experience when using the device. E.g.

Proximity sensors, to detect if the user is holding the phone close to the face, preventing accidental input
Ambient light sensors, to adjust the screen backlight
Accelerometers to automatically switch orientation or silence the device on orientation change
GPS receivers and magnetometers to support maps and navigation

During the early days of modern web browsers on these devices, different approaches have been made to make a subset of these sensors available to web applications.

Around 2015, primarily driven by Intel, an effort was done to standardize sensor APIs to provide a consistent way for web applications to retrieve sensor data. The result is the Generic Sensor API spec.

Today, a wide range of sensors are made available using this API, some are behind a flag and more proposals are on the way, e.g. the TemperatureSensor.

Developer Experience

On desktop computers, these sensors are (usually) not available. This requires developers to have a target phone connected, to run - on target - to get proper sensor data while testing the application under development. It's also possible to spoof the data by using sensor emulation in e.g. Chrome DevTools.

Sometimes neither of these approaches are convenient. E.g. what if you want to interact with the screen UI while emulating accelerometer based control of a game or maybe the phone you have available just doesn't provide all the sensors you want to test with.

A third approach proposed here, is to introduce a module that allows the developer to connect to an external device to get live sensor data, while still being able to develop and test on a desktop.

Ideally, this could be provided inside e.g. DevTools as an extension to the emulation, by capturing sensor data from a connected mobile phone and injecting the data in the application under development. Until that happens, because of hardware connectivity APIs like Web Bluetooth, Web USB and the Serial API, it's possible to build such a solution already today.

Thingy:52

The Thingy:52 by Nordic Semiconductor is a very powerful little unit, packing a lot of onboard sensors and actuators (Audio, button, temperature, humidity, pressure, air quality, color, light, accelerometer, gyroscope, compass/magnetometer, RGB LED and NFC). which are all exposed over BLE GATT.

The GATT protocol documentation for the device is available here.

Connecting to the Thingy:52 from a web application is quite easy, just remember to list the services that might be required for your app in the list of optionalServices:

const device = await navigator.bluetooth.requestDevice({
    filters: [{ services: ['ef680100-9b35-4933-9b10-52ffa9740042'] }],
    optionalServices: [
        "battery_service",
        "ef680200-9b35-4933-9b10-52ffa9740042",
        "ef680300-9b35-4933-9b10-52ffa9740042",
        "ef680400-9b35-4933-9b10-52ffa9740042",
        "ef680500-9b35-4933-9b10-52ffa9740042"
    ]
});

Hardware driver

In order to make it easily possible to extend the solution with different hardware devices in the future, a simple 'hardware driver' is created.

I decided to make a singleton instance of a class that extends EventTarget and then add the Web Bluetooth hardware access calls inside the class. This allows any component subscribing to the driver instance (using Thingy52Driver.addEventListener(...)) to receive sensor data updates without having any knowledge of the underlying Bluetooth APIs and GATT protocol.

E.g. on Thermometer GATT characteristic updates, an event is emitted:

_onThermometerChange(event) {
    const target = event.target;

    const integer = target.value.getUint8(0);
    const decimal = target.value.getUint8(1);

    const celsius = Number.parseFloat(`${integer}.${decimal}`);

    const temperature = {
        celsius,
        fahrenheit: celsius * 9 / 5 + 32,
        kelvin: celsius + 273.15
    }

    this.dispatchEvent(new CustomEvent('thermometer', {
        detail: temperature
    }));
}

The full implementation is available here

Hijacking the local sensor classes

To make things easy for developers, I decided to make a simple mechanism that allows for specific sensor classes to be 'hijacked', receiving data from a connected Thingy:52 and not from potential local sensors. This is done by replacing the sensor classes available on the global object with hybrids that expose the same API but retrieve sensor data via Web Bluetooth.

The developer only needs to inject the following (between the comments) in the top of the main html file (usually index.html):

<!DOCTYPE html>
<!-- BEGIN GenericSensor Thingy52 initialization -->
<script type="module" >
    import './src/genericsensor-thingy52.js';
    import { replaceSensors } from './src/sensors.js';

    replaceSensors([
        'Accelerometer',
        'AmbientLightSensor',
        'Gyroscope',
        'Magnetometer',
        'TemperatureSensor'
    ]);
</script>
<!-- END GenericSensor Thingy52 initialization -->

<html>
...

To connect, disconnect and to see battery level of the Thingy:52, a small controller widget is injected in the lower left corner of the web application.

A small demo app is provided with the repo containing the driver.

When connected and up and running, it looks something like this:

Final thoughts

Having an option to only fetch and expose sensor data from a connected device - without the need to also run the full application on the target device would be a nice addition to DevTools. However, I was pleased to see how easy it was to build this solution by using off the shelf hardware like the Thingy:52 combined with the Web Bluetooth API.

A link to the repo is here: https://github.com/larsgk/genericsensor-thingy52

A link to the simple live demo page is here: https://larsgk.github.io/genericsensor-thingy52/

Feedback, request, issue reports and PRs are very welcome!

Enjoy ;)

DEV Community: Lars Knudsen 🇩🇰

Using Gemini for Web Apps

A simple data set

Making it visible

Looking at the code

Making a game

Conclusion

Web NFC and Broadcast Audio URIs

Reducing Connection Friction

A Quick Recap: The Broadcast Audio URI (BAU)

Reading the URI with Web NFC

The Web NFC User Experience

Conclusion

A Web based Broadcast Assistant

Broadcast Assistants

Limitations in Android

Web and Zephyr for the Win!

Modern Web

Using the Web Broadcast Assistant

Let's play some music!

Multiple subgroup support

Conclusion

Auracast and multiple subgroups

Introduction

BASE (Broadcast Audio Source Endpoint)

Multiple subgroups

Building with Zephyr

5 different language tracks

Capturing the streams with blueSpy

Conclusion

A simple Broadcast Audio Source

Broadcast Audio Transmitters and Receivers

Zephyr and LE Audio Broadcasting

nRF52840 Dongle and pre-encoded audio

Capture with blueSpy

Conclusion

Capturing the perfect (radio) wave

Introduction

Getting started with Bluetooth sniffers

Our first capture

Starting the capture

Connecting from Web

Storing capture files

Conclusion

BarcodeDetector API for LE Audio

BarcodeDetector API

Lights, Camera, Action!

Parsing the Broadcast Audio URI

QR Scanner component

See it in action

Broadcast Audio URI

Audio sharing is caring

Sharing Links to Broadcasts

Zephyr for the win!

Try it out!

See it in action

Handling files in enterprise web solutions

File Handling in manifest.json

What's needed

file_handlers in manifest.json

File loading handler(s)

Installation and usage

Windows and Edge

OpenLayers

Creating GeoJSON files

Conclusion

Getting started with Zephyr and Web Bluetooth

What this thing does

A simple GATT service

Advertising

Cloning, building and flashing

Web Bluetooth test page

Working together

Final remarks

Creating a Web Thermometer

Temperature Sensor in Thingy:52

Temperature data

Thermometer Web Component

Building the application

All working together

`file_handlers` in manifest.json