BLE Voice

Pioneering advanced voice and Bluetooth technologies, enable global developers to achieve reliable, cost-effective embedded solutions with peak efficiency.

[blevoice]

JL Engineer's Work Log 3: Common Issues When Adding Custom Prompt Tones on Jieli AC6966B

Introduction When developing Bluetooth speakers with Jieli’s audio SoCs, adding custom prompt tones often brings up a few common issues – popping noises during power on/off, unsupported audio formats, etc. This guide walks through these issues and their solutions using the Jieli AC696N development board.

1. Pop/click noise when playing prompt tones during power on or off

First, listen to the original prompt tone file – is the noise already in the audio itself?

On the development board, the SDK code already includes the following two lines to handle this (add them if missing):

// Power on: disable PA before ramping up

// Power off: disable PA before shutdown

Explanation: When the speaker is powered on or off, the amplifier (PA) and speaker can produce a pop/click sound – this is normal behavior. The solution is to disable the power amplifier before the power‑on sequence, and also disable it before shutting down. The SDK example has these lines written by default. During debugging, you can verify whether the pop disappears after adding them.

2. Added prompt tones in different formats – MP3 works, but WTG doesn't

Double‑check the file format – don’t accidentally mix up extensions.

For WTG format, you need to enable the corresponding codec in the configuration tool.

Different tone formats require different encoder support. Enable the codec for WTG if you really need it. Recommendation: Stick with MP3 for prompt tones – it’s simpler and works out of the box.

Summary By understanding the power amplifier timing (to eliminate pops) and using MP3 format for tones, adding custom prompt tones on the Jieli AC696N platform becomes straightforward. All steps have been tested on the actual development board.

[blevoice]

JL Engineer's Work Log 2: Adding Custom Prompt Tones on Jieli Bluetooth Audio SoC (AC696N Series/AC6966B)

1. Introduction

The JL AC696N development board comes with predefined prompt tones. Since developers often need to add their own tones, this guide uses the AC6966B chip as an example to explain how to add custom prompt tones step by step.

2. Detailed Instructions

2.1 Configuration Tool

Custom prompt tones need to be added via the configuration tool. Typical path: ac696n_soundbox_sdk_v1.7.0_patch01_dev_board_v0.0.2\cpu\br25\tools\soundbox\standard

Open the configuration tool → select “Prompt Tone Configuration” → click “Add Prompt Tone” → click “Open”.

After clicking “Open”, choose your custom tone file – the tool will auto‑fill the file path.

Click “Save” – the configuration tool part is now complete.

2.2 Adding the Custom Tone File

Download or create your own tone file (e.g., water.mp3 or .wav). Add the file to the extra_tones folder (follow the same structure as existing tones). Use an English name for the file (e.g., water.*).

2.3 Code Modifications

In tone_player.h, add the custom tone name and path following the existing pattern. Example: #define TONE_RES_ROOT_PATH "tone/water.*"

In tone_table.c (inside the const char *tone_table[] array), add a new entry: [IDEX_TONE_WATER] = TONE_RES_ROOT_PATH"tone/water.*", where water matches your file name.

2.4 Playing the Tone

After the above steps, use the function from tone_player.c to play the tone. Example: tone_play(tone_table[IDEX_TONE_WATER], 1)

Summary

That's all the modification needed. The new tone can be triggered with a simple API call. This approach works on the AC696N series and similar Jieli audio SoCs.

[blevoice]

Engineer's Work Log: Implementing Button-Triggered Pairing for TWS Paired Speakers on Jieli AC696N

Issue A customer is developing TWS paired speakers using the Jieli AC696N development board. They need to implement a “button-triggered pairing” function, but are unsure which IO pin to connect the button to and how to configure it in the code.

Analysis & Reproduction When reviewing the Jieli AC696N TWS paired speaker example project, we found that pairing is typically triggered by an AD key or a regular GPIO key. The example project reserves the pairing button logic, but does not explicitly state the hardware connection or software configuration mapping. The correct setup requires cross-referencing the schematic diagram and the key scan module in the code.

Solution Open the TWS paired speaker example project and locate the key configuration section:

Hardware connection: It is recommended to connect the pairing button to PB4 (which is defined as an AD key channel in the Jieli AC696N factory firmware). Different buttons are distinguished by their AD sampling values.

Code configuration: In adkey_table.c (or the user key configuration table), find the macro KEY_TWS_SEARCH_REMOVE_PAIR (pairing function). Bind this macro to the specific AD key value.

Modification example: In the key mapping array, set the trigger event of the corresponding AD key to KEY_TWS_SEARCH_REMOVE_PAIR, and ensure the button press duration meets the default pairing trigger condition (e.g., long press for 3 seconds).

After completing the configuration, compile and burn the firmware. The button will then trigger TWS pairing.

Summary The customer reported “OK” after half an hour following the guidance. The AC696N TWS example project already contains a complete pairing flow. Developers only need to correctly bind the button event to the hardware IO. It is recommended to refer to the key configuration section and comments in the AC6966B TWS paired speaker example project, and to use AD keys to save IO pins. This is a common sticking point in TWS paired speaker development – recorded here for fellow engineers.

[blevoice]

JL JieLi AC696N Series Development GPIO Control Encyclopedia: Modes, APIs, and Special Pins

Introduction

GPIO configuration seems simple, but there are plenty of cases where things go wrong. If the drive strength isn't set correctly, an LED might be too dim or not light at all. Without proper pull-up/pull-down configuration, button detection can be erratic. The most troublesome is the USB pin—it might default to a regular GPIO, and if you forget to switch its function, your PC won't recognize the device.

The JL JieLi AC696N's GPIOs are quite versatile, with three drive strength levels (normal, strong, super strong) and various APIs. However, these functions are scattered throughout the documentation, and you often have to search for a while when using them. I've gone through the common GPIO configurations on the AC696N development board and organized them into a table, so you can quickly look them up when writing drivers.

I. GPIO Operating Modes

Input Mode: Can be configured as floating, pull-up, pull-down, or analog (for ADC). In input mode, output is disabled. The I/O status can be read via the input data register. Pull-up and pull-down input are straightforward—the default level is determined by the pull-up or pull-down. Floating input level is uncertain and depends entirely on the external input. Analog input is used for ADC sampling.

Output Mode: Output high/low level. Drive strength has three levels: normal, strong, and super strong.

Direction: Input, output. No open-drain.

Pull-up/down: All I/Os have pull-up/down resistors. Fixed resistance values, but differ between chips and pins (check datasheet). Pull-up/down only available in input mode.

Level: Output high (voltage close to VDDIO), output low (equivalent to ground, current sinking).

Drive strength: Normal, strong, super strong. Only very few I/Os support super strong.

State: Digital or analog. Analog state is used for AD detection in input mode.

Reading: In digital input mode, you can read the I/O voltage level. The voltage applied to an I/O must not exceed VDDIO; otherwise, reverse current may affect other I/Os.

II. Core API Function List

III. Special Pin: USB DP/DM

USB pins may default to regular GPIO. To switch them to USB function, call:usb_iomode(0); // parameter 0: switch to USB function

IV. Important Note

The output level of a GPIO is determined by the VDDIO supply voltage. If you need a specific I/O to output 3.0V, you must set the VDDIO supply to 3.0V.

Summary Memorize these few GPIO APIs, and you'll be covered for most tasks. A few common pitfalls:

USB pins: don't forget to call usb_iomode(0) to switch to USB function, otherwise the PC won't recognize the device.

ADC input pins: remember to use gpio_set_die() to disable digital function, otherwise readings will be inaccurate.

Drive strength: choose according to your needs. For driving an LED, strong drive is unnecessary; normal drive works fine and saves power.

I recommend trying each API on the AC696N development board, measuring the levels with a multimeter to confirm correct configuration before moving to your product board. This will avoid having to trace hardware issues back to software configuration later.

[blevoice]

JieLi AC6966B Development Board Peripheral Expansion: JL AC696N SPI Drives Flash, LCD, and RGB LEDs

Introduction

For products like Bluetooth speakers and headphones, the chip's built-in resources are rarely enough—you need external Flash to store prompt tones, an LCD to display status, and a few RGB LEDs for ambiance. These are common requirements. The JL JieLi AC696N's SPI interface is perfect for the job—it's fast enough and can even simulate some special timing. However, the configuration differs when driving different peripherals with SPI, especially for LEDs like WS2812, which have strict timing requirements. A slight deviation and the lighting pattern goes wrong.

I've recently gotten all three—Flash, LCD, and RGB LEDs—working on the AC696N development board. Here are the key configuration points, so you can directly reuse them when building your own products.

I. Basic SPI Configuration

In board_ac696x_demo.c, under SPI_PLATFORM_DATA_BEGIN, configure the SPI parameters: port group, clock, mode, and role (master).

II. Application 1: External SPI Nor Flash

Functionality: Enables external recording storage, independent prompt tone library, and file system partitions (FAT + TONE + REC).

Steps: Refer to the "Flash Recording (External) and Partition Operation Instructions" document, configure the Flash driver, and call the relevant APIs for read/write/erase operations.

III. Application 2: Driving an LCD Screen

Method: Send command and data sequences via SPI to control the LCD display. The driver must be written according to the specific LCD model.

Note: You may need to use GPIOs to control reset, backlight, and other pins.

IV. Application 3: Driving RGB Magic LEDs (e.g., WS2812)

Characteristics: These LEDs use a single-wire return-to-zero code protocol with strict timing requirements.

Steps:

Refer to the "Single-Wire Serial Control Magic LED" documentation.

Use the SPI MOSI line to simulate the specific data waveform.

Pay special attention to the "Code Notes" in the documentation, such as delays and buffer management.

Summary

Using SPI to interface with Flash is a common practice. The documentation is detailed, so following it usually works without issues.

LCD drivers depend heavily on the initialization sequence of the screen—different manufacturers vary greatly, but the SPI transmission logic is the same.

WS2812 is a bit trickier. I recommend starting on the AC696N development board by using SPI MOSI to simulate the waveform and get one or two LEDs working first. Once the timing is confirmed, you can increase the number of LEDs. Also, if multiple devices are connected to the same SPI bus, be sure to use separate chip select pins and set the clock frequency according to the slowest device. Otherwise, high-speed devices may work fine, but low-speed devices may not respond.

[blevoice]

JL Jieli AC696N Series Chip Debugging Tool: UART Serial Print Configuration and Online Tuning

Introduction

The serial port is truly the "eyes" of a developer – that statement is no exaggeration. In embedded debugging, if you can't get logs out, it's like working blindfolded.

The UART configuration on the JL Jieli AC696N is quite flexible. The debug print pin can be mapped arbitrarily, and the baud rate can be pushed up to 1M, making debugging very smooth. However, many beginners overlook one point: the serial port can not only output logs, but also connect to a PC tool for online tuning of audio effects. Parameters like EQ and DRC can be adjusted in real time without recompiling and flashing – you can hear the effect immediately.

After tinkering with the AC696N development board, I've sorted out the configuration for both functions so I don't have to dig through the code every time.

I. Configuring Serial Print

In the board-level configuration header file (e.g., board_ac696x_demo_cfg.h), locate the UART0 configuration.

Modify the following macros:#define TCFG_UART0_ENABLE ENABLE_THIS_MOUDLE // Enable #define TCFG_UART0_TX_PORT IO_PORTA_05 // TX pin (changeable) #define TCFG_UART0_BAUDRATE 1000000 // Baud rate (1Mbps)

In app_config.h, control the master print switch and verbosity level.

II. Implementing Online Tuning (No Recompilation Needed)

In lib_system_config.c, enable the effect tool and UART communication:#define TCFG_EFFECT_TOOL_ENABLE ENABLE_THIS_MOUDLE #define TCFG_COMM_TYPE COMM_UART

Specify the UART TX/RX pins for debugging.

Use the PC tool provided by Jieli to connect, and you can adjust EQ, DRC and other audio parameters in real time – the effect is immediate.

III. UART Communication Demo

The SDK provides a uart_test.c example that shows how to initialize an independent communication UART for data sending/receiving, which is very suitable for communicating with external MCUs or modules.

Summary

For serial print, I recommend setting the baud rate directly to 1M. The logs will stream quickly and debugging won't stutter.

The online tuning feature is a highlight of the Jieli solution. It's extremely efficient when developing audio products – tuning parameters while listening to the effect is far more efficient than modifying code, flashing, and listening repeatedly. It's best to use two separate UARTs for debug prints and tuning to avoid log messages interfering with tuning commands.

The default pin configuration on the AC696N development board can be used as a reference. But if you design your own PCB, remember to bring out the debug port – otherwise you'll be helpless when issues arise.

[blevoice]

JL JieLi AC696N Series Chip Development – Timer Detailed Explanation: Differences and Selection Between sys_timer and usr_timer

Introduction

Timers seem simple, but using them in the wrong place either increases power consumption or causes timing inaccuracies—and debugging can be quite troublesome. The JL JieLi AC696N SDK provides two sets of timers: sys_timer and usr_timer. When first getting started, it's easy to get confused—when to use which? Why does my timer become inaccurate after entering sleep? Can I perform work in the callback? I encountered all these issues while debugging low-power solutions on the AC696N development board. Here's a summary of the differences and selection logic, so you can directly reference it when writing code.

Chip Product Introduction

I. System Timer (sys_timer) – "Software Timer"

Features: Managed by the systimer thread, synchronous interface. The callback executes in the same thread where the timer was added.

Low Power: System can sleep; the timer will wake the system when it expires, without losing ticks.

Use Case: Suitable for general tasks that need periodic execution and can tolerate slight delays.

Interfaces: sys_timer_add, sys_timer_del, sys_timeout_add (one-shot)

II. User Timer (usr_timer) – "Hardware Timer"

Features: Driven by hardware timer, asynchronous interface, callback executes in interrupt context.

Priority Impact:

priority=1: System cannot enter low power, timing is precise

priority=0: System can sleep, but timing period may lengthen due to sleep

Use Case: Suitable for timing tasks requiring precision and fast response, or one-shot timeouts.

Interfaces: usr_timer_add, usr_timer_del, usr_timeout_add

III. Timer Applications

1) Timing Function

Example using led7_timer.c on AC696:

static void timer2_isr() { //local_irq_disable(); // Enable when extremely accurate timing is needed TIMER_CON |= BIT(14); // Clear interrupt flag // User custom code //...... //local_irq_enable(); // Enable when extremely accurate timing is needed } int led7_timer_init() { u32 prd_cnt; u8 index; printf("------------%s :%d", __func__, __LINE__); for (index = 0; index < (sizeof(timer_div) / sizeof(timer_div[0])); index++) { prd_cnt = TIMER_UNIT_MS * (APP_TIMER_CLK / 1000) / timer_div[index]; if (prd_cnt > MIN_TIME_CNT && prd_cnt < MAX_TIME_CNT) { break; } } __this->index = index; __this->prd = prd_cnt; TIMER_CNT = 0; TIMER_PRD = prd_cnt; //1ms request_irq(TIMER_VETOR, 6, timer2_isr, 0); //Highest priority 7, enable when extremely accurate timing needed TIMER_CON = (index << 4) | BIT(0) | BIT(3); printf("PRD : 0x%x / %d", TIMER_PRD, clk_get("timer")); return 0; }

2) Capture Function

• Reference Code

// Based on AC696 program. Some I/O pins may not support this function—test first, then design PCB!!!!!! #define TIMER5 7 // see irflt.h #define CATCH_TIMER TIMER5 #define CATCH_IRQ_TIME_IDX IRQ_TIME5_IDX #define CATCH_TIME_REG JL_TIMER5 #define CATCH_GPIO IO_PORTB_06 int num = 0; void timer_ms() { static int flag = 0; if(flag){ gpio_set_pull_down(IO_PORTA_02,0); gpio_set_pull_up(IO_PORTA_02,0); gpio_set_direction(IO_PORTA_02,1); flag = 0; } else{ gpio_set_pull_down(IO_PORTA_02,0); gpio_set_pull_up(IO_PORTA_02,0); gpio_set_direction(IO_PORTA_02,0); gpio_set_output_value(IO_PORTA_02,0); putchar('0'); flag = 1; } } __interrupt void timer_catch_isr(void) { CATCH_TIME_REG->CON |= BIT(14); u16 bCap1 = CATCH_TIME_REG->PRD; // Time from last interrupt to this one, can be used for timing CATCH_TIME_REG->CNT = 0; num++; // Count } void timer_100ms() { printf("num == %d\n",num); num = 0; } void timer_catch_init() { printf("timer_catch_init\n"); // I/O configuration gpio_irflt_in(CATCH_GPIO); gpio_set_direction(CATCH_GPIO, 1); gpio_set_die(CATCH_GPIO, 1); gpio_set_pull_up(CATCH_GPIO, 1); gpio_set_pull_down(CATCH_GPIO, 0); // Clock configuration SFR(JL_IOMAP->CON0, 5, 3, CATCH_TIMER); // TIMER5:7 in irflt.h CATCH_TIME_REG->CON = 0; CATCH_TIME_REG->CON |= (0b10 << 2); // Select crystal oscillator clock source: 24MHz CATCH_TIME_REG->CON |= (0b0001 << 4); // Clock source divide by 4 // Set period, initial value, timer mode CATCH_TIME_REG->PRD = OSC_Hz / (4 * 1000); CATCH_TIME_REG->CNT = CATCH_TIME_REG->PRD; CATCH_TIME_REG->CON |= BIT(14); CATCH_TIME_REG->CON |= (0b11 << 0); request_irq(CATCH_IRQ_TIME_IDX, 5, timer_catch_isr, 0); sys_timer_add(NULL, timer_100ms, 100); // Periodically read interrupt count sys_timer_add(NULL, timer_ms, 1); // Generate waveform for interrupt capture (not precise, not exactly 1ms) }

Selection Guide

Need low power and low real-time requirements → Use sys_timer

Need precise timing or fast response, power consumption not the primary concern → Use usr_timer (priority=1)

Need one-shot timeout functionality → Use sys_timeout_add or usr_timeout_add

Summary

In simple terms, prioritize sys_timer in regular code—it doesn't affect sleep, is power-friendly, and covers most scenarios. If you need millisecond-level precision or the callback needs to handle urgent tasks, use usr_timer, but remember that when priority=1, the system cannot sleep, increasing power consumption—don't keep it running long-term in production. Both support one-shot timeouts; use whichever you prefer. I recommend trying both timers on the AC696N development board, printing the callback thread and sleep behavior via serial to intuitively understand the difference—then you won't hesitate when selecting timers.

[blevoice]

Smooth last-minute client rescue before CNY! 

Real-case tech support: A trader's smart device (MCU + Bluetooth + App + battery) was stuck because their Bluetooth module (AW318A2) wasn't discoverable. With Chinese New Year approaching, urgency was high. We recommended KT6368A dual-mode Bluetooth, delivered samples quickly, and the demo passed in under 24 hours.

The keys: 24/7 responsiveness, fast sampling, proven reliability, comprehensive documentation (manuals, schematics, FAQs), and strong technical support. We build solutions from the customer's perspective.

#EmbeddedSystems #Bluetooth #IoT #Hardware #Firmware #Engineering #CustomerSuccess #TechStory

[blevoice]

JieLi AC695N, AC696N Bluetooth Chip Hardware Design Specification - Circuit Design Guide (3)

1.4 DAC Anti-Interference Circuit Description

AC695N and AC696N support DACL/DACR differential mode and DACL/DACR/VCOMO stereo mode.

Schematic is as follows:

(1) It is recommended to reserve anti-interference circuits for the DAC section; if space is limited, only L4/L5/L6 can be reserved.

(2) For strict noise requirements, it is suggested to place AGND copper pour (or no pour) on both sides around the DAC circuit and solder points. Do not pour "digital GND" and keep away from "digital GND" to effectively eliminate high-frequency noise.

(3) L4/L5 should be fixed at 100nH or 120nH to effectively remove high-frequency TDD noise generated when a mobile phone is near the device during Bluetooth calls; L6 should be fixed at 220nH or 330nH to effectively remove high-frequency noise during music playback (try this method if LAYOUT is not optimal). Note: The reserved noise handling circuit on the DAC side increases cost. If the design is reasonable enough and noise requirements are not high, it can be omitted.

1.5 MIC Circuit Description

AC695N and AC696N support both analog silicon MIC and electret MIC.

Schematic is as follows:

Note:

For electret MIC solutions, AC695N requires a DC blocking capacitor on the MIC input. Pay attention to the difference from AC696N during design.

1.6 ESD Circuit Description

① Traces for analog sections like DACL, DACR, and related components are susceptible to ESD interference. Provide protection (e.g., increase spacing to GND, avoid GND pour under components).

② At the decoupling capacitor C1 for the DACVDD power supply, it is recommended to reserve a C2: 105 capacitor nearby to connect AGND and GND (can be omitted if design is reasonable).

Schematic is as follows:

[blevoice]

🌐 KT148A Voice Chip - International Application Case Study #innovation #...

[blevoice]

Guide to Adding BLE Connection Passcodes for the KT1025A Bluetooth Chip

Introduction

The BLE function of the KT1025A Bluetooth chip supports connection passcodes. By default, the passcode is fixed at 6 digits, and its length cannot be changed. In the default program, the passcode is set to 123456. Please note that each digit must be in the range 0–9 and must not exceed this range.

However, it is important to note a limitation of BLE: even with a passcode set, certain apps may bypass it.

Therefore, it is recommended to implement an interactive encryption mechanism between your app and the Bluetooth chip after a connection is established. For example, after a successful connection, the app can send a data frame to the Bluetooth chip, which then parses and replies according to a predefined protocol. If no correct reply is received, the device can be considered unauthorized.

AT Command Instructions

Set the passcode Command:  AT  +BN  Format:  AT  +BN[passcode]  (up to 6 digits) Example:  AT  +BN889988

Restore factory settings If you forget the passcode, you can reset the chip to factory defaults using: Command:  AT  +CW

Power-on notification When powered on, the chip will automatically report the current BLE connection passcode in the format:  TN  +[passcode]  Example:  TN  +889988

Query the passcode manually You can also actively query the current passcode. Refer to the example below:

Summary

While the KT1025A supports BLE connection passcodes for basic security, developers are encouraged to add an additional layer of protection through custom encryption after connection. This helps ensure that only trusted apps can communicate with the device.

Always remember to store your passcode securely. If lost, use the AT  +CW

[blevoice]

JieLi AC695N, AC696N Bluetooth Chip Hardware Design Specification - Circuit Design Guide (1)

Special Notes:

The input voltage on the VBAT power pin must not exceed 5.0V.

The voltage on the LDO_IN charging input pin must not exceed 5.5V.

A capacitor placement to ground must be reserved for LDO_IN.For speakers or headphones using the internal soft power-on/off solution, please use the PBI pin (low-level wake-up) for the power button.

To ensure product safety and reliability, please use batteries with protection circuits.

Test points must be provided for the programming pins (VBAT, USBDM, USBDP, VDDIO, VSSIO).

Note: The QFN package chip is small, which is not conducive to programming via test fixtures or manual methods. It is recommended to first mount the chip, then program it via PC.

1. Circuit Design Guide

1.1 Crystal Oscillator Selection Guide

Due to Bluetooth's high requirement for frequency offset, the quality of the crystal oscillator is crucial for Bluetooth performance. Consistency and stability of the crystal oscillator must be ensured during selection. The frequency deviation of the crystal oscillator must be ≤ ±10ppm, and a load capacitance (CL) of 12pF is recommended.

Recommended model:  If using crystal oscillators from other models, testing and verification are essential.

1.2 DCDC Selection and Circuit Description

① If the power consumption of the chip's internal LDO mode is acceptable for the application, the external DCDC can be omitted.

② DCDC chip selection: The switching frequency must be greater than 2M, output voltage 1.26V.

③ Use 1% precision resistors for DCDC feedback resistors R2 and R3.

Schematic is as follows:

[blevoice]

Jieli Bluetooth Smart Speaker Development: Common Issues with AC696N SoCs

During the development of Bluetooth smart speakers using Jieli's AC696N series SoCs, developers may encounter several common issues. This article summarizes these problems and provides corresponding solutions to help streamline the development process.

1. AC696N V1.7.0: Unable to Display SDK Version Number via Test Box When TWS is Enabled

Problem Description:

After enabling TWS (True Wireless Stereo) in AC696N V1.7.0 SDK, the test box cannot display the SDK version number.

Solution:

Register a new callback function to handle the SDK version information request.

// Re-register a callback function bt_testbox_ex_info_get_handle_register(TESTBOX_INFO_SDK_VERSION, user_bt_get_sdk_ver_info);

// Callback function example:

u8 user_bt_get_sdk_ver_info(u8 len)

{

y_printf("Getting version number\n");

const char *p = sdk_version_info_get();

if (len) {

*len = strlen(p);

}

log_info("sdk_ver:%s %x\n", p, *len);

return (u8 *)p;

}

After Modification:

The SDK version number will be correctly displayed by the test box (see Image below).

2. AC696N V1.7.0: Some Mobile Phones Unable to Connect After Enabling PINCODE Connection

Problem Description:

After enabling PINCODE (personal identification number) connection in AC696N V1.7.0, certain mobile phones cannot establish a connection.

Solution:

Modify the relevant code as shown in Image below.

3. AC696N V1.7.0: Frequency Shift Issue in Online Audio Effect Tuning

Scenario 1:

The customer enabled reverb and changed the sampling rate from 44.1K to 32K, causing a frequency shift issue.

Solution for AC696N:

1.Replace the library file and recompile.

Library file:  “AC696N_1.7.0_eq采样率更新无效导致的频偏问题修正”

(If opening WAV format causes compilation failure, add the following code as shown in Image below)

2.Modify the following configuration in  apps\soundbox\log_config\lib_media_config.c :

// Decoder output points per cycle, recommended range: 32 to 900.

// For example, 128 represents 128 pairs of points.

// If exceeding 128, the decoder needs to use malloc, e.g., config_wav_dec_use_malloc=1. const int WAV_DECODER_PCM_POINTS = 128;

// When output exceeds 128, if not using malloc, increase the corresponding buffer.

// Refer to the decoder's required size in the print output; generally, each additional output point increases by 4 bytes. int wav_mem_ext[(1336+3)/4] SEC(.wav_mem);

// Increase this array size if exceeding 128.

3.If the system asserts and crashes when playing WAV files from a USB drive after the above modifications, enable the following setting (see Image below):

const int config_wav_dec_use_malloc = 1;

4. AC696N: External Flash Recording TCFG_NOR_REC Range Overflow Issue

Problem Description:

When using external flash for recording, the  TCFG_NOR_REC  configuration may cause a range overflow.

Solution:

Reduce the length by 8K as shown in Image below.

Summary

This article addressed four common issues encountered during AC696N SoC development:

1.TWS-enabled SDK version display problem

2.PINCODE connection compatibility issue

3.Frequency shift in online audio effect tuning

4.External flash recording range overflow

By applying these solutions, developers can resolve these issues efficiently and focus on other aspects of product development. Always ensure to test modifications thoroughly in your specific application context.

[blevoice]

Jieli Bluetooth Smart Speaker Development: Key Considerations for AC696N SoCs

When developing Bluetooth smart speakers based on Jieli's AC696N series of SoCs, paying attention to certain hardware and software details can significantly improve development efficiency and system stability. This article summarizes several key points, including RTC power supply, register debugging, AAC format support, and DAC fade-in settings.

1. Developing with RTC Functionality

Note:The RTCVDD pinmust be powered by an external power source, such as a button cell battery or IOVDD. Do not leave it floating or connect it to an inappropriate voltage rail.

2. Chip-Related Register Printing

ADDA Register Value Printing

The following functions can be used to dump the current state of the Audio DAC/ADC registers, which is invaluable for debugging audio issues.

Print all DAC and ADC registers:

void audio_adda_dump(void) {

printf("DAC_VL0:%x", JL_AUDIO->DAC_VL0);

printf("DAC_TM0:%x", JL_AUDIO->DAC_TM0);

printf("DAC_DTB:%x", JL_AUDIO->DAC_DTB);

printf("DAC_CON:%x", JL_AUDIO->DAC_CON);

printf("ADC_CON:%x", JL_AUDIO->ADC_CON);

printf("DAC RES: DA0:0x%x DA1:0x%x DA2:0x%x DA3:0x%x ,ADC RES:ADA0:0X%x ADA1:0X%x ADA2:0X%x ADA3:0X%x\n", \ JL_ANA->DAA_CON0, JL_ANA->DAA_CON1, JL_ANA->DAA_CON2, JL_ANA->DAA_CON3, \ JL_ANA->ADA_CON0, JL_ANA->ADA_CON1, JL_ANA->ADA_CON2, JL_ANA->ADA_CON3);

}

Print all ADC and DAC gain settings:

void audio_adda_gain_dump(void) {

u8 dac_again_fl = JL_ANA->DAA_CON1 & 0x1F;

u8 dac_again_fr = (JL_ANA->DAA_CON1 >> 5) & 0x1F;

u8 dac_again_rl = (JL_ANA->DAA_CON1 >> 10) & 0x1F;

u8 dac_again_rr = (JL_ANA->DAA_CON1 >> 15) & 0x1F;

u32 dac_dgain_fl = JL_AUDIO->DAC_VL0 & 0xFFFF;

u32 dac_dgain_fr = (JL_AUDIO->DAC_VL0 >> 16) & 0xFFFF;

u32 dac_dgain_rl = JL_AUDIO->DAC_VL1 & 0xFFFF;

u32 dac_dgain_rr = (JL_AUDIO->DAC_VL1 >> 16) & 0xFFFF;

u8 mic0_gain = (JL_ANA->ADA_CON0 >> 8) & 0x1F;

u8 mic0_db = (JL_ANA->ADA_CON4 >> 29) & 0x1;

// 0dB or 6dB u8 linein_r_gain = (JL_ANA->ADA_CON0 >> 4) & 0xF;

u8 linein_l_gain = JL_ANA->ADA_CON0 & 0xF;

printf("MIC_G:%d,MIC_0_6:%d, linein_gain:%d,%d,DAC_AG:%d,%d,%d,%d,DAC_DG:%d,%d,%d,%d\n", mic0_gain, mic0_db, linein_l_gain, linein_r_gain, dac_again_fl, dac_again_fr, dac_again_rl, dac_again_rr, dac_dgain_fl, dac_dgain_fr, dac_dgain_rl, dac_dgain_rr);

}

3. Enabling AAC Format Support

To add AAC audio decoding support to your project:

Enable the main macro definition in your configuration:

#define TCFG_BT_SUPPORT_AAC 1 // Enable AAC format support

Important: For AC696N Soundbox SDK versions (1.5.0 and above), you must also enable the following configuration in:  SDK\apps\soundbox\log_config\lib_media_config.c 

const int config_aac_dec_use_malloc = 1;

4. Disabling DAC Fade-In Function

Principle:Prevent the DAC from ramping the volume down to zero when stopping. This may lead to a perceptible increase in background noise, depending on your hardware design.

Call this function before playing audio:

audio_dac_vol_mute_lock(1);

Note: Due to hardware design constraints, the DAC fade-out function cannot be disabled. Compare the DAC output with this switch toggled on and off to evaluate the impact on your specific design.

By keeping these points in mind—proper RTC power, utilizing register dump functions, correctly enabling AAC, and managing DAC behavior—you can avoid common pitfalls and streamline your development process for AC696N-based smart speaker products.

[blevoice]

JL701N Chip Powering Next Gen Smart Home Interfaces #innovation #embed...

[blevoice]

AC6965E for Versatile Magic Sound Toy #innovation #iot #toys #embeddedsy...

[blevoice]

Case Study | Application of KT142C Voice Chip in Smart Crosswalk Auditory Guidance System

I. Application Background

With the development of urban intelligent transportation, accessibility facilities are receiving increasing attention. For visually impaired individuals, relying solely on visual traffic signals is insufficient for safe street crossing. To address this, we have developed acrosswalk auditory guidance system for traffic light intersectionsbased on theKT142C voice chip, which uses audible cues to guide visually impaired pedestrians safely across streets.

II. Solution Overview

The system is installed on traffic light poles and operates in sync with pedestrian signals:

During green light: Plays rhythmic prompts to guide crossing.

During red light: Plays a different rhythmic pattern to indicate waiting.

Light-sensitive smart adjustment: Automatically switches between "daytime" and "nighttime" modes based on ambient brightness to avoid noise disturbance at night.

Volume and modes can be flexibly configured via serial commands or configuration files to adapt to different intersection requirements.

III. Advantages of KT142C in This Solution

1.Built-in storage, no external Flash required

The chip features320KB of built-in storage, capable of storing multiple audio prompts directly without requiring external SPI Flash, resulting in simpler hardware design.

2.Supports direct audio updates via USB

When connected to a PC via USB, the chip appears as a virtual USB drive, allowing prompt audio updates at any time without dedicated programming tools, making maintenance convenient.

3.Flexible playback control

Supports serial command control (e.g., playing specific audio, adjusting volume, looping playback).

Supports IO trigger playback, enabling direct interfacing with traffic light control boards.

Supports combined playback for seamless transitions between multiple audio segments.

4.Low-power design

The chip supports low-power mode (as low as 2µA), suitable for intersection devices operating continuously year-round. It can also be controlled via light sensors for on/off management.

5.Selectable audio output modes

PWM direct drive for speakers (0.5W/8Ω).

DAC output for external amplifiers (e.g., HAA2018), suitable for higher-power scenarios.

IV. Technical Implementation Details

✅ Audio File Planning

001.mp3 : Green light prompt tone (frequency 300–500Hz, 160ms on, 500ms off).

002.mp3 : Red light prompt tone (frequency 300–500Hz, 200ms on, 300ms off).

003.mp3 : Green light final 3-second prompt tone (accelerated rhythm).

Configuration file  config.txt  sets trigger modes, volume, output mode, etc.

✅ Brightness Sensing Control

An external light sensor detects ambient brightness, processed by an MCU:

Brightness > 200 LUX for 60 seconds → Daytime mode (volume ≤ 65 dB).

Brightness < 200 LUX for 60 seconds → Nighttime mode (volume ≤ 45 dB).

Nighttime mode persists for 180 minutes → Mute mode activated.

✅ Integration with Traffic Light Control System

IO level triggers playback of corresponding prompt tones.

Serial commands can also receive traffic light status instructions for more complex auditory guidance logic.

V. Measured Parameter Table

VI. Testing and Validation

We used:

Digital oscilloscope → to detect output waveform and frequency.

Spectrum analyzer → to analyze audio frequency range.

Sound level meter → to measure actual sound pressure levels.

Serial debug assistant → to verify command responses.

Test results show that the KT142C performs stably under continuous operation, temperature variations, and voltage fluctuations, meeting the long-term operational requirements of crosswalk guidance devices.

VII. Customer Benefits

Easy Integration: Simple peripheral circuitry—only two capacitors required for operation.

Convenient Maintenance: USB-based audio updates, no device disassembly needed.

Smart Control: Supports light-sensing and timing control for balanced guidance and environmental protection.

High Reliability: Industrial temperature range suitable for harsh outdoor environments.

VIII. Technical Support and Resources

For more detailed design materials, schematics, configuration file examples, and other resources related to the KT142C in this application, visit our official resource repository.