Low-energy Bluetooth is widely recognized in the industry as a key technology for realizing the vision of the Internet of Things (IoT) application. In fact, the extremely low power consumption makes it the ideal wireless communication solution for battery-powered IoT products. Although the current low-power Bluetooth specification is limited to several specific applications, innovative solutions can make this Technology is extended to different application areas, such as multimedia streaming. In this development direction, this article introduces a low-energy Bluetooth device voice streaming application called BlueVoice.
This article introduces the BlueVoice application from the set of extended services required to support voice streaming services, and then evaluates the performance of BlueVoice on actual hardware devices. On selected hardware platforms, the BlueVoice app fully supports voice streaming services while avoiding wasted energy.
I. Foreword After experiencing rapid growth over the past few decades, the Internet has penetrated almost every aspect of everyday life in human society. In the future, the Internet will expand to the Internet of Everything, and billions or even tens of billions of unique "items" will interact with humans and the surrounding environment through wireless communication to perform advanced tasks. In this concept, "items" may be sensors, actuators, appliances, toys, and in general, any virtual or physical item that can be identified. This Internet evolution concept is called the Internet of Things (IoT).
The concept of the Internet of Things is to connect all product devices together to form a global network through standard protocol solutions (ie Internet Protocol) and wireless communication interfaces. Realizing the Internet of Everything, although the existing large number of RF communication technologies can be used, when the IoT product is an autonomous battery-powered device deployed in the field, low-power wireless communication technology is the most suitable communication solution. In this regard, Bluetooth LE [1] technology is considered the most effective IoT communication solution and is being integrated into the Internet world [2].
In today's IoT applications, low-energy Bluetooth solutions are primarily used for life parameter monitoring purposes. In addition to traditional surveillance services, the industry has begun to explore advanced applications based on other technologies in recent years. For example, reference [3] proposes and analyzes the network communication [4] based on IEEE802.15.4. In this respect, the transmission of multimedia data over low-energy Bluetooth is still in its infancy, and the lack of available solutions is mainly due to the fact that these applications were not originally considered (for example, applications such as medical and fitness were initially considered). This article explores how to address these technical limitations by taking the BlueVoice application that supports voice streaming services on Bluetooth devices with low power consumption as an example. Let's take a look at the low-energy Bluetooth technology, then detail the extended service set needed to support the new application concept, then introduce the application design, and finally test the actual performance on the STM32 Nucleo L476 board.
The content of this article is arranged as follows: Chapter 2 introduces the working principle of low-energy Bluetooth, first describes the entire working stack; then introduces the concept of Profiles. The third chapter introduces the application design, describes its low-energy Bluetooth configuration file, and then introduces its design principles, design implementation and actual performance. The fourth chapter is the conclusion.
M. Gentili and R. Sannino are with AST Audio/Sensors Platforms R&D and Audio SW Ecosystem, STMicroelectronics, Agrate Brianza, Italy (e-mail: [maurizio.gentilijroberto.sannino]@st.com).
M. Petracca is with Scuola Superiore Sant'Anna di Pisa and National Inter-University Consortium for Telecommunications, Pisa, Italy (e-mail:matteo.) .
II. Low-Power Bluetooth Technology Overview The BLE Low-Power Bluetooth specification was written to the Bluetooth 4.0 core specification in 2010. Although similar to basic Bluetooth, the low-power Bluetooth specification is designed for ultra-low-power applications. There are very few potential applications for connecting battery-powered devices through low-power Bluetooth technology, and medical, fitness and smart homes are just a few examples.
Figure 1. Low-power Bluetooth protocol stack
As shown in Figure 1, the overall structure of the low-power Bluetooth protocol stack is mainly composed of two parts: the controller and the host. The application software uses the services provided by the protocol of the protocol stack host layer. The host layer is divided into five layers: Logical Link Control and Adaptation Protocol (L2CAP), Attribute Protocol (ATT), Common Attribute Profile (GATT), Security Management Protocol (SM), and Generic Access Profile (GAP). The controller part has only two layers: the physical layer (PHY) and the link layer (LL). As shown in Figure 1, the host-controller (HCI) interface is the communication channel between the controller and the host.
The physical layer is responsible for bit modulation and sends and receives data over the wireless channel. The maximum data rate is 1 Mb/s and the typical communication distance is tens of meters.
The link layer specifies the function of two-way communication between two devices. Low-power Bluetooth nodes have two roles: master and slave. Typically, a master device (eg, a laptop, a smartphone) searches for a slave device (eg, a somatosensory device); if necessary, the slave device transmits data to the master device. The slave device is usually in a sleep state and wakes up at regular intervals to be searched by the master device.
Above the link layer, the Logical Link Control and Adaptation Protocol (L2CAP) has two main functions. The main function of the protocol is to provide multiplexed functions, package and convert top-level multi-protocol data according to the standard low-energy Bluetooth packet data format. Security Management Protocol (SM) and Generic Access Profile (GAP) provide data security and service management capabilities, respectively. In detail, the security management protocol defines how the key is generated, and how to exchange keys between two devices (master and slave devices) to establish a secure encrypted communication channel, while the universal access profile specifies how the two devices are at the bottom. Interoperability Attribute Protocol (ATT) and Common Attribute Profiles are two protocol components that need to be considered when developing new applications. The attribute protocol is a stateless client/server protocol: regardless of whether the underlying role of the device is a master or a slave, each device can be set to a server, client, or client-server. The client requests server data to send data, the server sends data to the client, the data is stored in the server as attributes, each attribute contains GATT managed data, and the data is assigned a Universally Unique Identifier (UUID). Through an L2CAP dedicated channel, the attribute protocol establishes a communication channel between the server properties and the client. The Generic Attribute Profile (GATT) adds a data abstraction model at the attribute protocol layer that is responsible for searching the data held by the attribute protocol and exchanging features between the two devices. Each low-energy Bluetooth device has a set of possible attributes (storage services) and characteristics (properties related to the storage service). If you are creating a new application on a low-power Bluetooth stack, you must define attributes and characteristics. The characteristics, attributes, and underlying specifications of a particular application are collectively referred to as profiles, and standard profiles ensure that products of different brands can be interconnected.
III. BLUEVOICE APPLICATIONS Below we introduce the BlueVoice application, which first defines the voice communication low energy Bluetooth profile and then discusses the communication roles, audio processing and compression options, data packet issues and bandwidth requirements of the devices involved. We propose two different system configurations for audio acquisition and power consumption to meet different application requirements. The final part of this chapter introduces the BlueVoice application implemented on an actual hardware device and then compares and discusses the actual measured application performance, such as power consumption, memory footprint, processing performance requirements, and automatic speech recognition (ASR) performance.
A. Service Definition Considering that the audio stream use case is not a low-energy Bluetooth standard profile, the BlueVoice application defines a “vendor-specific profile†called BlueVoice Service (BVS) on the low-power Bluetooth protocol stack for voice streaming services. , specifies how the voice data is exchanged between the server and the client. In addition, considering the need for special design choices for half-duplex communication, this issue is discussed in detail later in this chapter.
As mentioned above, the attribute protocol ATT is a transport protocol for exchanging data between different devices by the common attribute configuration file GATT. The attribute is the smallest entity defined by the ATT, and is an addressable information segment (built-in UUID identification code), which may contain User data or meta information about the schema of the property itself, such as permissions, encryption, and authorization properties. The GATT server attributes form a sequence of services in a specific order, with the beginning of the sequence being the service declaration attribute followed by one or more features and possible descriptors. Each feature is a disclosed attribute. In addition to the standard profile UUID, in custom applications, developers can develop new services with their own features using unique and vendor-specific UUIDs, as is the case with BlueVoice applications. Considering the asymmetry of the one-way audio streaming system, the server discloses the data type and format and access method to the client through the BVS configuration file. The BVS service contains the following properties, as shown in Figure 2.
Service Statement (Handle 0x0010)
– UUID: Standard 16-bit UUID for the main service announcement (0x2800).
– Permissions: Read – Value: Unique 128-bit BVS UUID.
Feature Declaration (Handle 0x0011)
– UUID: Standard 16-bit UUID for feature declaration (0x2803).
– Permissions: Read – Value: Unique 128-bit audio UUID, for notification only, Handle: 0x012.
Feature data (Handle 0x0012)
– UUID: Unique 128-bit audio UUID.
– Permissions: None – Value: Actual audio data Feature declaration (Handle 0x0014)
– UUID: Standard 16-bit UUID for feature declaration (0x2803).
– Permissions: Read – Value: Unique 128-bit synchronous UUID, for notification only, Handle: 0x0015.
Feature data (Handle 0x0015)
– UUID: Unique 128-bit synchronous UUID.
– Permissions: None – Value: Actual Synchronization Data According to this standard, the main service declaration is the first attribute of the service, and its numeric field contains the UUID definition introduced by the declaration. The BlueVoice app declares a 128-bit unique UUID (BVS UUID). BVS contains two features called Audio and Sync. In the low-energy Bluetooth specification, each feature contains at least two attributes, a feature declaration and a feature value. Feature declarations define their properties in the form of metadata, and feature values ​​contain actual feature data. In the BlueVoice case, both the audio and sync features contain a single attribute defined by a unique 128-bit UUID (AudioData and SyncData UUID) that contain the actual audio data and side information sync values, respectively. The audio and sync feature declarations define the AudioData and SyncData properties as "notification only", without the read and write permissions of the client, indicating that the audio data and sync data are only transmitted in the form of notifications, and the server does not reply to the client. Consistent with the layered architecture of low-energy Bluetooth services, other features may be added to future releases of BlueVoice applications.
Figure 2. BlueVoice Service (BVS) definition
B. Application Design This chapter introduces (i) low-energy Bluetooth communication (ii) audio processing for BlueVoice application design.
1) Low-power Bluetooth communication According to the low-energy Bluetooth protocol, communication can be multicast or point-to-point. The BlueVoice application link layer uses a connected communication mode to establish a permanent point-to-point connection between two devices that play two different roles: the central device and the peripheral devices. Central devices, also known as master devices, support complex functions associated with peripheral devices (slave devices). The central device initiates a communication connection, performs adaptive frequency hopping, data encryption, manages communication timing, and defines a data exchange mode between devices. This role assignment is in line with the asymmetric design of Bluetooth with low energy consumption, and assigns fewer tasks to devices with high energy efficiency requirements. Battery-powered portable devices are usually slave devices, however, it must be stated that according to the specification [1], each device can send data separately when each connection event occurs, and the role does not impose restrictions or priorities on data throughput. . Considering half-duplex communication, BlueVoice applications can run on autonomous battery-powered wireless sensing devices with microphones (and final scalar sensors, such as the ubiquitous surveillance application in the typical IoT concept), so Role assignments are no longer related to the send and receive functions.
Above the link layer, the GATT layer defines the client and server roles of the interactive device, independent of the master and slave devices described above. A server is a device that provides information, and a client is a device that requests or receives the latest information. Considering that the one-way audio stream is an asymmetric system, the microphone-equipped device is the only device with voice information, so it can be regarded as a communication server, and the other device is a client, sending a request for information to the server, and receiving the server-initiated content. Update information of voice data. In a two-way communication system, voice data is bidirectionally transmitted, the architecture is symmetrical, and both the central device and peripheral devices are equipped with microphones, which can act as servers and output audio data in any attribute format. At the same time, the server can also act as a client, send information requests, and accept updates sent by another device.
The two-way voice data stream is based on the server sending notifications to the client at regular intervals, without the need for the receiving device to send a request or reply signal. The slave device enters the broadcast mode during the power-on phase, transmits the broadcast data packet at a low frequency, and the master device enters the search mode to scan whether other devices exist, and vice versa. Upon receipt of the broadcast packet, the master device discovers the relevant slave device, and then the master device sends a connection request. After the connection establishment process ends, the asynchronous notification data packet containing the audio data is sent from the server to the client at regular intervals according to the selected communication transmission direction: the central device to the peripheral device or the surrounding device-central device. Figure 3 shows the role assignment of BlueVoice at the GATT layer.
Figure 3: BlueVoice Profile Role Assignment
2) Audio Processing The purpose of BlueVoice's audio processing is to obtain a target audio sample of 8 kHz or 16 kHz on the receiving end selected by the application. In fact, for applications where the low power requirements are extremely stringent but the sound quality is not critical, for example, the automatic speech recognition service input audio is not required, and an 8 kHz sampling rate may be a good choice.
Compressing low-energy Bluetooth audio transmission signals using an adaptive differential pulse code modulation algorithm allows audio signals to be applied to existing data transmission rates while minimizing RF transmission time and power consumption. We use digital MEMS microphones to design an all-digital solution with features such as size and sound quality that make it suitable for wireless sensor devices. Figure 4 shows the complete speech processing chain at 16 kHz sampling rate. The solution first acquires a 1 MHz 1-bit Pulse Density Modulation (PDM) signal generated by a digital MEMS microphone and converts it into a 16 kHz 16-bit Pulse Code Modulation (PCM) sample, which is then sampled at 16,000 samples per second. The rate is then compressed into a 4-bit ADPCM sampled signal and ready to be transmitted.
In addition, the side information synchronization data set is transmitted at a lower frequency, and the required bandwidth is the sum of 64 kbps audio data and 300 bps synchronization information data, totaling 64.3 kbps. For an 8 kHz sampling rate, the final ADPCM sampling rate is 8000 samples/second, resulting in a 31.3 kbps bandwidth requirement, including side information. The following sections provide an in-depth introduction to the above modules.
Figure 4: BlueVoice data transmission chain in 16kHz configuration
The analog signal generated by the capacitive sensor of the MEMS microphone is amplified and sampled at a high rate, and then processed by an internal sigma-delta modulator integrated with quantization and noise trimming operations. The output data is a single high sampling rate PDM format bit. PCM conversion is an intermediate part of the entire processing chain that sends compressed audio data from PDM to the wireless channel. In order to convert the PDM stream into PCM data, a decimation filter and two separately configurable filters (low pass filter and high pass filter are required. The processing module outputs a 16-bit PCM format sample stream. According to the selected sampling frequency A different configuration of the decimation filter is used to obtain 16-bit PCM data samples.
The ADPCM encoding module compresses PCM samples, reduces transmission bandwidth, saves transmission bandwidth, and reduces power consumption. As mentioned earlier, ADPCM is a compression algorithm for lossy waveform coding. The basic principle is to predict the current value based on the previous value. Only the difference between the actual value quantized by the adaptive quantization step and the predicted value is transmitted. There are many alternative compression standards, but the ADPCM standard is chosen solely because it is based on a waveform coding method that is more suitable for sensor network devices (usually based on microcontrollers) than complex solutions based on vocoders. In the BlueVoice application, each 16-bit PCM sample is compressed into 4-bit ADPCM data, which requires an application transmission bandwidth of 32 kbps or 64 kbps. The specific rate depends on the sampling frequency and is compatible with low-power Bluetooth streaming.
As mentioned earlier, the overall bandwidth requirement for BlueVoice applications is higher than the theoretical value of 32 kbps or 64 kbps, because BlueVoice adds additional information when transmitting data over the channel to improve communication robustness. The 16 kHz configuration uses a 10 ms connection interval, while the 8 kHz configuration uses a 25 ms connection interval. In fact, if the amount of data being transferred is small, the connection interval value can be increased, thereby saving energy. To make the most of each packet's existing payload as much as possible, the voice packet is sent 20 bytes.
Therefore, in a 16 kHz configuration, voice data is sent 4 packets every 10 ms, while in an 8 kHz configuration, voice data is sent 4 packets every 20 ms, resulting in a transmission bandwidth of 64 kbps and 32 kbps, respectively. The sender's side information is sent at a lower frequency, sending a 6-byte add-on packet every 160 ms, corresponding to 16 or 8 connection intervals. Figure 5 depicts the overall data packet strategy on a low-power Bluetooth protocol stack. Through the audio feature, 4 voice packets (20 bytes per packet) are transmitted every 10 ms or 20 ms connection interval, and the transmitter side information is transmitted, and an additional data packet is transmitted every 160 ms interval by the synchronization feature.
Figure 5: BlueVoice data grouping mechanism
C. Implementing the application on actual hardware In order to evaluate the feasibility of BlueVoice on a non-complex hardware wireless sensor network platform that supports low-energy Bluetooth communication, we implemented the application described in Part B of the third chapter on the actual hardware device. The full functionality of the software. The hardware platform of choice is STMicroelectronics' STM32 Nucleo L476 development board [5], an open development platform based on the STM32L476 80 MHz 32-bit ARM Cortex-M4 microcontroller. The reason we chose the STM32 Nucleo development board is that the performance of the onboard microcontroller is higher than that of the conventional wireless sensor network platform, while also providing high flexibility and versatility. The development board is equipped with a lot of interfaces and extended pin headers. Plugging the dedicated expansion board to expand the board is simple and easy, allowing designers to research, develop and validate new ideas. In particular, the STM32L4 microcontroller features market-leading low-power features with built-in digital filters and Sigma-Delta Modulator (DFSDM) peripherals for PDM to PCM format conversion in Figure 4. Features make it ideal for BlueVoice applications. By plugging a low-power Bluetooth connectivity board and a microphone expansion board on the STM32Nucleo development board, the BlueVoice central module and peripheral modules can form a symmetric hardware configuration based on STM32Nucleo, showing a half-duplex communication channel. The low-power Bluetooth connectivity board is based on ST's BlueNRG [6], an ultra-low-power, low-power Bluetooth single-mode network processor that is compatible with the Bluetooth specification version 4.0 and can be set to master and slave modes when low energy When the Bluetooth protocol stack is started, the maximum data transfer current is 8.2 mA, which can be reduced to 1.7 uA. An additional microphone expansion board is used to acquire speech signals based on ST's MP34DT01 [7] digital universal MEMS microphone with an acoustic overload point of 120 dBSPL, a signal-to-noise ratio of 63 dB and a sensitivity of -26 dBFS. The MP34DT01 uses a capacitive sensor and an integrated circuit with a built-in sigma-delta modulator and noise trimming mechanism to provide a PDM output of 1-3.25 MHz.
Figure 6 is a block diagram of the actual hardware device: The STM32 microcontroller captures the PDM sample output of the microphone through the DFSDM module connected to the peripheral module DMA, through a dedicated application programming interface (API) and serial peripheral interface (SPI). Communicating with the BlueNRG module, the modular architecture is symmetrical for both the central module and the peripheral modules. There is also a USB audio interface in the block diagram that provides the reconstructed audio signal to the PC. Figure 7 is an actual prototype of a hardware device.
D. Performance We used the actual system described in Part C of Chapter 3 as an experimental platform to evaluate the functionality, memory footprint, performance requirements, and ASR recognition rate of BlueVoice applications. In particular, considering the application scenarios of a series of miniature wireless microphone modules deployed on site and the asymmetry of low-power Bluetooth itself (slave-peripheral modules must be compact and consume very low power), the performance evaluation discussed in this chapter focuses on 8 kHz. Power consumption, memory footprint, and performance requirements for slave-peripheral modules in both 16 kHz configurations. In addition, the ASR performance measured at the receiving end is another performance evaluation indicator. In fact, this parameter may be an important sound quality indicator for voice communication, which is of great significance for emerging voice control applications (remote control, IoT products).
Figure 6. BlueVoice block diagram
Figure 7: Transmitter and Receiver Prototype
1) Power consumption, memory footprint and performance requirements As mentioned earlier, we implemented the BlueVoice application on a hardware device that uses STMicroelectronics' STM32 Nucleo development board as the host and uses the low-power Bluetooth network module as a control. equipment. Table 1 lists the power consumption values ​​of the host and control devices (STM32 and BlueNRG) in the three different states of Broadcast, Connection and Transmission of BlueVoice. These data are measured at 3.3 V operating voltage and are compared for the 8 kHz and 16 kHz configurations. It must be emphasized that the power consumption of the microcontroller is completely dependent on the hardware characteristics and low power configuration, so the microcontroller power is the platform-dependent value added to the total power consumption when calculating the total power consumption.
The values ​​listed in this table can be considered as an indicative reference value and may vary depending on the application.
Table I: BLUEVOICE Power Consumption
According to the low-energy Bluetooth standard, before the connection is established between two nodes, the slave device is in broadcast mode, and the master device enters scan mode. When the master device receives the broadcast packet and discovers that the slave device exists, it immediately establishes a connection. In the BlueVoice solution, considering the communication of a peripheral module to the central module, the peripheral node is the sender (server) and the central node is the receiver (client): the server sends notifications to the client at a fixed periodicity. In the 8 kHz configuration, during the broadcast phase, the transmitter peripheral module (STM32 + BlueNRG) has a very low average power consumption of only 3.50 mW, and when the connection is established, the power consumption is 3.98 mW. For the 16 kHz configuration, the broadcast phase consumes 8.22 mW and the connection phase is 9.48 mW. It should be emphasized here that the power consumption during the connection phase is closely related to the connection interval selection, which is the main difference between the 8 kHz and 16 kHz configurations (20 ms and 10 ms respectively). In both cases, the connection interval is set to be close to the standard minimum (7.5 ms) to ensure minimum transmission delay. Once the connection is established, the BlueVoice application enters the transfer state immediately. The average power consumption of the 8 kHz configuration is 10.07 mW, and the average power consumption of the 16 kHz configuration is 19.84 mW. Therefore, based on the STM32 + BlueNRG IoT node, the battery capacity is assumed to be 200 mAh. The theoretical endurance of the two configurations is approximately 65 hours and 33 hours, respectively, when the data stream is continuously transmitted. These power consumption values ​​indicate that the BlueVoice method is suitable for audio streams with low-power Bluetooth as a carrier, especially in an 8 kHz configuration, which can significantly reduce power consumption.
In addition to analyzing power consumption, we also evaluated the feasibility of the application by considering the memory footprint. As shown in Table II, the BlueVoice application software occupies the same flash space (21.85 kB), but the 8 kHz configuration occupies 13.32 kB of RAM space, while the 16 kHz configuration occupies only 7.86 kB of RAM space. The reason the two configurations take up different RAM space is that to reduce the overhead and power consumption of the solution, audio processing steps (PDM to PCM and ADPCM compression) are performed every 20 ms and 10 ms at 8 kHz and 16 kHz, respectively, resulting in The 8 kHz configuration grows larger data between two consecutive steps. In both cases, these values ​​are well within the constraints of resource-constrained systems.
Table II
Transmitter BLUEVOICE memory occupancy 2) ASR performance BlueVoice's feasibility in terms of power consumption, processing performance and memory footprint does not guarantee that the voice signal quality will reach an acceptable level at the receiving end. At the end of the BlueVoice solution performance evaluation, we utilize A network ASR service performs a large number of transmission tests and measures ASR performance at the receiving end. The 16 kHz USB microphone and the 8 kHz/16 kHz BlueVoice system record several audio samples containing known English words in parallel (as a reference) and transmit them to the ASR engine. Table III lists the word recognition for different solutions. Rate comparison test results. Test results show that ADPCM compression does not degrade signal quality, so it is suitable for ASR applications: BlueVoice 16 kHz configuration performance is very close to USB microphone, while 8 kHz system performance is slightly reduced (18%), suitable for low power consumption requirements application. In fact, the 8 kHz system achieves the same ASR performance with 50% power consumption in a 16 kHz configuration.
Table III
B LUEVOICE ASR performance
IV. Conclusion This article describes a solution for delivering audio streams over low-energy Bluetooth. First, we introduce a vendor-specific half-duplex communication low-energy Bluetooth profile, then introduce the BlueVoice application design and discuss the communication roles involved in the device. , audio processing and compression coding options, data packet and bandwidth requirements. The BlueVoice application consists of a central node and a peripheral node that act as low-power Bluetooth servers and clients, respectively, according to the selected communication direction. After the connection is established, the server sends a notification to the client on a fixed period. We compared the two configurations of 8 kHz and 16 kHz. On the transmitter node, the digital PDM format output signal of the MEMS microphone is acquired and converted into PCM format, then compressed into ADPCM data, and finally on the low energy Bluetooth link. Produces 32 or 64 kbps of Bluetooth bandwidth. The configuration file also defines a low-frequency side information mechanism that, although requiring some extra bandwidth, improves error suppression. To evaluate the performance of the solution, BlueVoice is implemented on the actual hardware device. The device is an all-digital system consisting of a MEMS microphone and an STM32 microcontroller with a network module, the former acting as a host and the latter acting as a low-power Bluetooth controller. The performance evaluation of this paper shows that our proposed solution is suitable for low-power voice streaming applications in terms of power consumption, processing performance and memory footprint. In particular, the power consumption measurements of the sensor devices during the 8 kHz and 16 kHz audio streaming are 10.07 mW and 19.84 mW, respectively, and the memory footprint and performance requirements are fully acceptable. In addition, we also measured the audio quality indicator ASR performance, the word recognition rate of the 8 kHz configuration and the 816 kHz configuration reached 67% and 82%, respectively, while the recognition rate of the 16 kHz USB microphone reached 85%, indicating that the BlueVoice application can be at the receiving end. A very high sound quality and very low power consumption.
Stator and rotor laminations are an important part of motors and generators. For large-size and small-batch punching sheets, we usually use the notching method to produce them. The advantages of notching are that the cost of the notching die is low and the production cycle of the notching die is short. It is suitable for producing large size laminations, usually the outer diameter is from 500mm-1250mm. The slot size is more accurate than Laser Cutting.
Stator And Rotor Lamination By Single Notching,Stator Core Laminations,Generator Stator Laminations,Electric Motor Rotor Laminations
Henan Yongrong Power Technology Co., Ltd , https://www.hnyongrongglobal.com