Member | Action | Date | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
![]() |
Selected an answer for
EFR32FG1: non-monotonic TX power regulation
Hello Vladimir,
What you have observed is not unexpected behavior. The actual TX power level response to TX power setting is expected to be different between custom designs due to differences in on-board impendances. The SDK firmware built for this part is adjusted for the particular WSTK evaluation board used as the reference for the EFR32FG1V131F128GM32. Your custom hardware may or may not have similar power setting responses to the WSTK evalution module. To fine tune the power settings for custom hardware, the firmware developer can create custom power curves described in AN1127; You have already taken the first step by characterizing the TX power versus TX power setting on your custom hardware. Best regards, |
Sep 21 2020, 7:59 AM |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
Updated
KBA_BT_0911: MIDI over BLE on Knowledge Base
MIDI basicsThis article shows how a Blue Gecko can be used as a MIDI controller over Bluetooth Low Energy. At first we give some basic info about the MIDI standard then on the Apple Bluetooth Low Energy MIDI Specification. Finally, we highlight and explain the most important code snippets from the attached sample application which implements a very basic MIDI controller. The protocolMIDI is an industry standard music technology protocol that connects products from many different companies including digital musical instruments, computers, tablets and smartphones. MIDI is used everyday around the world by musicians, DJs, producers, educators, artists and hobbyists to create, perform, learn and share music and artistic works. Nearly every hit album, film score, TV show and theatrical production uses MIDI to connect and create. MIDI information is transmitted in "MIDI messages", which can be thought of as instructions which tell a music synthesizer how to play a piece of music. The synthesizer receiving the MIDI data must generate the actual sounds. Physical layerThe MIDI specification for the electrical interface is based on a fully isolated current loop. The MIDI OUT port nominally sources a +5 volt source through a 220 ohm resistor out through pin 4 on the MIDI OUT DIN connector, in on pin 4 of the receiving device's MIDI IN DIN connector, through a 220 ohm protection resistor and the LED of an optoisolator. The current then returns via pin 5 on the MIDI IN port to the originating device's MIDI OUT port pin 5, again with a 220 ohm resistor in the path, giving a nominal current of about 5 milliamperes. Despite the cable's appearance, there is no conductive path between the two MIDI devices, only an optically isolated one. The data rate on this system is a relatively slow (by today standards) 31,250 bits per second, logic 0 being current ON. The MIDI data stream is a unidirectional asynchronous bit stream with 10 bits transmitted per byte (a start bit, 8 data bits, and one stop bit). The MIDI data stream is usually originated by a MIDI controller, such as a musical instrument keyboard. MIDI controller and sound moduleA MIDI controller is a device which is played as an instrument, and it translates the performance into a MIDI data stream in real time (as it is played). The MIDI data output from a MIDI controller is transmitted via the devices' MIDI OUT connector. The recipient of this MIDI data stream is commonly a MIDI sound generator or sound module, which will receive MIDI messages at its MIDI IN connector, and respond to these messages by playing sounds. MIDI messagesThere are a number of different types of MIDI messages. See the https://www.midi.org for details. In the example code attached we implemented only Note On and Note Off messages. The Note On message is used for turning on MIDI notes. This is typically sent when a key pressed on keyboard. The Note Off message is used for turning off MIDI notes. This is typically sent when a key released on keyboard. MIDI over BLEThere are number of solutions where the standard DIN connector and physical layer changed to a more modern medium like USB or Ethernet. Apple defined a custom BLE service for MIDI support. This is now part of the MIDI standard. This specification can be found here: https://www.midi.org/specifications/item/bluetooth-le-midi To support MIDI over BLE the accessory has to fulfill a set requirements collected below. Connection intervalThe accessory shall request a connection interval of 15 ms or less. Apple recommends starting with a request for a connection interval of 11.25 ms and going to 15 ms if the connection request is rejected by the Apple product. Intervals higher than 15 ms are unsuitable for live playback situations. MTU negotiationThe accessory shall support MTU negotiation. See the MTU Size section in the Bluetooth Low Energy chapter of the Bluetooth Accessory Design Guidelines for Apple Products for implementation details. Multiple packet transmissionsThe accessory shall support sending and receiving the maximum number of Bluetooth Low Energy packets that can fit into the connection interval. MIDI minimum bandwidth requirements may not be met otherwise. Custom MIDI Service and CharacteristicThe GATT should contain the following service and characteristic
The MIDI I/O characteristics
Header and Timestamp fieldsAdditional Header and Timestamp fields has to be added before the standard MIDI message format
Note that the actual timestamp value is splitted between the Header and Timestamp fields. The 13-bit timestamp for a MIDI event in any given Bluetooth Low Energy packet is formed from the bottom 6 bits of the Header field and the bottom 7 bits of the Timestamp filed. Timestamps are in expressed in milliseconds, implying that the maximum timestamp range is 8192 ms. Timestamps shall be sent in monotonically increasing order. Example applicationThe attached application act as a very basic MIDI controller. It can send MIDI note on and MIDI note off messages when a button pressed or released on the WSTK. Pressing PB0 button repeatedly will play the Imperial March from Star Wars. Pressing PB1 is resetting the sequence so the melody can start from the beginning. The application is built upon the Simplicity Studio Bluetooth SDK ver. 2.11 and tested with the BGM13S Starter Kit (SLWSTK4305A) but it should work with other EFR32 based Bluetooth enabled targets with minimal changes. We going to highlight the most important steps which are needed for building a MIDI over BLE compatible device. GATT definitionThe GATT.xml file has to contain the MIDI service definition as it is showed below.
Enable the bonding before connection
Set the connection interval to the required 15 ms.
Setup CRYOTIMER for creating 1ms timer for the timestampThis timestamp has to be included to the MIDI message.
Setup GPIO interrupt for button pressHere is the PBB0_pressed function registered as a GPIO interrupt service routine and will be triggered for both rising and falling edges. The function is reading the GPIO state and sends a note on or note off message accordingly. The code snippet below shows the recommended way for registering the ISR.
Function to send a note on messageThe midi_note_on() function prepare and send a note on message. First the function gets the timestamp from the CRYOTIMER. The CRYTIMER provides a 32 bit counter but according to the specification we need only the lower 13 bit, so the rest of the bits are masked. Then the function fills the header and timestamp fields. The header byte is 0b10xxxxxx where xxxxxxx is top 6 bits of timestamp. The timestamp byte is 0b1xxxxxxx where xxxxxxx is lower 7 bits of timestamp. The status byte is 0x90 is 0b1sssnnnn where sss is message type and nnnn is the MIDI channel. The last two bytes contains the 2 byte long event field in this case it is the note and velocity. Finally the function sends the message with the gecko_cmd_GATT_server_send_characteristic_notification API function.
TestingOnce the application flashed to kit it starts advertise itself. After connection it pairs and bonds with just work method. The application tested with the following IOS apps:
References[2] https://www.midi.org/specifications/item/bluetooth-le-midi |
Jun 19 2019, 11:32 AM |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
Updated
KBA_BT_0911: MIDI over BLE on Knowledge Base
MIDI basicsThis article shows how a Blue Gecko can be used as a MIDI controller over Bluetooth Low Energy. At first we give some basic info about the MIDI standard then on the Apple Bluetooth Low Energy MIDI Specification. Finally, we highlight and explain the most important code snippets from the attached sample application which implements a very basic MIDI controller. The protocolMIDI is an industry standard music technology protocol that connects products from many different companies including digital musical instruments, computers, tablets and smartphones. MIDI is used everyday around the world by musicians, DJs, producers, educators, artists and hobbyists to create, perform, learn and share music and artistic works. Nearly every hit album, film score, TV show and theatrical production uses MIDI to connect and create. MIDI information is transmitted in "MIDI messages", which can be thought of as instructions which tell a music synthesizer how to play a piece of music. The synthesizer receiving the MIDI data must generate the actual sounds. Physical layerThe MIDI specification for the electrical interface is based on a fully isolated current loop. The MIDI OUT port nominally sources a +5 volt source through a 220 ohm resistor out through pin 4 on the MIDI OUT DIN connector, in on pin 4 of the receiving device's MIDI IN DIN connector, through a 220 ohm protection resistor and the LED of an optoisolator. The current then returns via pin 5 on the MIDI IN port to the originating device's MIDI OUT port pin 5, again with a 220 ohm resistor in the path, giving a nominal current of about 5 milliamperes. Despite the cable's appearance, there is no conductive path between the two MIDI devices, only an optically isolated one. The data rate on this system is a relatively slow (by today standards) 31,250 bits per second, logic 0 being current ON. The MIDI data stream is a unidirectional asynchronous bit stream with 10 bits transmitted per byte (a start bit, 8 data bits, and one stop bit). The MIDI data stream is usually originated by a MIDI controller, such as a musical instrument keyboard. MIDI controller and sound moduleA MIDI controller is a device which is played as an instrument, and it translates the performance into a MIDI data stream in real time (as it is played). The MIDI data output from a MIDI controller is transmitted via the devices' MIDI OUT connector. The recipient of this MIDI data stream is commonly a MIDI sound generator or sound module, which will receive MIDI messages at its MIDI IN connector, and respond to these messages by playing sounds. MIDI messagesThere are a number of different types of MIDI messages. See the https://www.MIDI.org for details. In the example code attached we implemented only Note On and Note Off messages. The Note On message is used for turning on MIDI notes. This is typically sent when a key pressed on keyboard. The Note Off message is used for turning off MIDI notes. This is typically sent when a key released on keyboard. MIDI over BLEThere are number of solutions where the standard DIN connector and physical layer changed to a more modern medium like USB or Ethernet. Apple defined a custom BLE service for MIDI support. This is now part of the MIDI standard. This specification can be found here: https://www.midi.org/specifications/item/bluetooth-le-midi To support MIDI over BLE the accessory has to fulfill a set requirements collected below. Connection intervalThe accessory shall request a connection interval of 15 ms or less. Apple recommends starting with a request for a connection interval of 11.25 ms and going to 15 ms if the connection request is rejected by the Apple product. Intervals higher than 15 ms are unsuitable for live playback situations. MTU negotiationThe accessory shall support MTU negotiation. See the MTU Size section in the Bluetooth Low Energy chapter of the Bluetooth Accessory Design Guidelines for Apple Products for implementation details. Multiple packet transmissionsThe accessory shall support sending and receiving the maximum number of Bluetooth Low Energy packets that can fit into the connection interval. MIDI minimum bandwidth requirements may not be met otherwise. Custom MIDI Service and CharacteristicThe GATT should contain the following service and characteristic
The MIDI I/O characteristics
Header and Timestamp fieldsAdditional Header and Timestamp fields has to be added before the standard MIDI message format
Note that the actual timestamp value is splitted between the Header and Timestamp fields. The 13-bit timestamp for a MIDI event in any given Bluetooth Low Energy packet is formed from the bottom 6 bits of the Header field and the bottom 7 bits of the Timestamp filed. Timestamps are in expressed in milliseconds, implying that the maximum timestamp range is 8192 ms. Timestamps shall be sent in monotonically increasing order. Example applicationThe attached application act as a very basic MIDI controller. It can send MIDI note on and MIDI note off messages when a button pressed or released on the WSTK. Pressing PB0 button repeatedly will play the Imperial March from Star Wars. Pressing PB1 is resetting the sequence so the melody can start from the beginning. The application is built upon the Simplicity Studio Bluetooth SDK ver. 2.11 and tested with the BGM13S Starter Kit (SLWSTK4305A) but it should work with other EFR32 based Bluetooth enabled targets with minimal changes. We going to highlight the most important steps which are needed for building a MIDI over BLE compatible device. GATT definitionThe GATT.xml file has to contain the MIDI service definition as it is showed below.
Enable the bonding before connection
Set the connection interval to the required 15 ms.
Setup CRYOTIMER for creating 1ms timer for the timestampThis timestamp has to be included to the MIDI message.
Setup GPIO interrupt for button pressHere is the PBB0_pressed function registered as a GPIO interrupt service routine and will be triggered for both rising and falling edges. The function is reading the GPIO state and sends a note on or note off message accordingly. The code snippet below shows the recommended way for registering the ISR.
Function to send a note on messageThe MIDI_note_on() function prepare and send a note on message. First the function gets the timestamp from the CRYOTIMER. The CRYTIMER provides a 32 bit counter but according to the specification we need only the lower 13 bit, so the rest of the bits are masked. Then the function fills the header and timestamp fields. The header byte is 0b10xxxxxx where xxxxxxx is top 6 bits of timestamp. The timestamp byte is 0b1xxxxxxx where xxxxxxx is lower 7 bits of timestamp. The status byte is 0x90 is 0b1sssnnnn where sss is message type and nnnn is the MIDI channel. The last two bytes contains the 2 byte long event field in this case it is the note and velocity. Finally the function sends the message with the gecko_cmd_GATT_server_send_characteristic_notification API function.
TestingOnce the application flashed to kit it starts advertise itself. After connection it pairs and bonds with just work method. The application tested with the following IOS apps:
References[2] https://www.midi.org/specifications/item/bluetooth-le-midi |
Jun 19 2019, 11:19 AM |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
Updated
Bluetooth Knowledge Base Article List on Knowledge Base
IntroductionThis Knowledge Base Article (KBA) aims to act as a “master” KBA which keeps a curated index of all the Bluetooth related KBAs divided into logical categories for an easier and more convenient look-up. It may also include non-KBA content which is relevant for designing your Bluetooth application (e.g. app notes or web pages). If you are just getting started with Silicon Labs Bluetooth solutions then your starting point should be QSG139: Getting Started with Bluetooth® Software Development. At the end of that document you are presented with the flowchart below which shows what documents should be read and in which order. Additionally you can check out our Bluetooth Training page for more training material.
Knowledge Base Articles ListThe content listed below is grouped together into categories to make it easier for you to find what you are looking for. Want to know more about security, or looking for a peripheral example, then head down to the right section and see what KBAs or other relevant content has been created under those topics. Each category has an associated index number and each individual KBA has its own index number within the category. The KBA's are prefixed with KBA_BT_AABB where AA is the category index and BB is the KBA index within that category. The category index numbers are as follows:
The KBAs with attached example code are marked with this icon Note: Do you want to get automatic notifications when new content is added to the list? Just click the Follow button in upper right corner to subscribe to email notifications. We will make comments when new content is created to trigger those notifications. [01] Bluetooth General
[02] Bluetooth - Advertising
[03] Bluetooth - Stack features
[04] Bluetooth - Performance
[05] Bluetooth - Bluetooth Mesh
[06] Bootloading - General
[07] Bootloading - UART DFU
[08] Bootloading - OTA DFU
[09] Application Examples
[10] Peripheral Examples
Additional Resources
[11] Security
[12] Tools
Additional Resources[13] Hardware
Additional Resources
[14] Migration
[15] Mobile
[16] NCP |
Jun 19 2019, 11:18 AM |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
Updated
KBA_BT_0911: MIDI over BLE on Knowledge Base
MIDI over BLE with Wireless Gecko Soc-s and ModulesMIDI basicsThis article shows how a Blue Gecko can be used as a MIDI controller over Bluetooth Low Energy. At first we give some basic info about the MIDI standard then on the Apple Bluetooth Low Energy MIDI Specification. Finally, we highlight and explain the most important code snippets from the attached sample application which implements a very basic MIDI controller. The protocolMIDI is an industry standard music technology protocol that connects products from many different companies including digital musical instruments, computers, tablets and smartphones. MIDI is used everyday around the world by musicians, DJs, producers, educators, artists and hobbyists to create, perform, learn and share music and artistic works. Nearly every hit album, film score, TV show and theatrical production uses MIDI to connect and create. MIDI information is transmitted in "MIDI messages", which can be thought of as instructions which tell a music synthesizer how to play a piece of music. The synthesizer receiving the MIDI data must generate the actual sounds. Physical layerThe MIDI specification for the electrical interface is based on a fully isolated current loop. The MIDI OUT port nominally sources a +5 volt source through a 220 ohm resistor out through pin 4 on the MIDI OUT DIN connector, in on pin 4 of the receiving device's MIDI IN DIN connector, through a 220 ohm protection resistor and the LED of an optoisolator. The current then returns via pin 5 on the MIDI IN port to the originating device's MIDI OUT port pin 5, again with a 220 ohm resistor in the path, giving a nominal current of about 5 milliamperes. Despite the cable's appearance, there is no conductive path between the two MIDI devices, only an optically isolated one. The data rate on this system is a relatively slow (by today standards) 31,250 bits per second, logic 0 being current ON. The MIDI data stream is a unidirectional asynchronous bit stream with 10 bits transmitted per byte (a start bit, 8 data bits, and one stop bit). The MIDI data stream is usually originated by a MIDI controller, such as a musical instrument keyboard. MIDI controller and sound moduleA MIDI controller is a device which is played as an instrument, and it translates the performance into a MIDI data stream in real time (as it is played). The MIDI data output from a MIDI controller is transmitted via the devices' MIDI OUT connector. The recipient of this MIDI data stream is commonly a MIDI sound generator or sound module, which will receive MIDI messages at its MIDI IN connector, and respond to these messages by playing sounds. MIDI messagesThere are a number of different types of MIDI messages. See the https://www.MIDI.org for details. In the example code attached we implemented only Note On and Note Off messages. The Note On message is used for turning on MIDI notes. This is typically sent when a key pressed on keyboard. The Note Off message is used for turning off MIDI notes. This is typically sent when a key released on keyboard. MIDI over BLEThere are number of solutions where the standard DIN connector and physical layer changed to a more modern medium like USB or Ethernet. Apple defined a custom BLE service for MIDI support. This is now part of the MIDI standard. This specification can be found here: https://www.midi.org/specifications/item/bluetooth-le-midi To support MIDI over BLE the accessory has to fulfill a set requirements collected below. Connection intervalThe accessory shall request a connection interval of 15 ms or less. Apple recommends starting with a request for a connection interval of 11.25 ms and going to 15 ms if the connection request is rejected by the Apple product. Intervals higher than 15 ms are unsuitable for live playback situations. MTU negotiationThe accessory shall support MTU negotiation. See the MTU Size section in the Bluetooth Low Energy chapter of the Bluetooth Accessory Design Guidelines for Apple Products for implementation details. Multiple packet transmissionsThe accessory shall support sending and receiving the maximum number of Bluetooth Low Energy packets that can fit into the connection interval. MIDI minimum bandwidth requirements may not be met otherwise. Custom MIDI Service and CharacteristicThe GATT should contain the following service and characteristic
The MIDI I/O characteristics
Header and Timestamp fieldsAdditional Header and Timestamp fields has to be added before the standard MIDI message format
Note that the actual timestamp value is splitted between the Header and Timestamp fields. The 13-bit timestamp for a MIDI event in any given Bluetooth Low Energy packet is formed from the bottom 6 bits of the Header field and the bottom 7 bits of the Timestamp filed. Timestamps are in expressed in milliseconds, implying that the maximum timestamp range is 8192 ms. Timestamps shall be sent in monotonically increasing order. Example applicationThe attached application act as a very basic MIDI controller. It can send MIDI note on and MIDI note off messages when a button pressed or released on the WSTK. Pressing PB0 button repeatedly will play the Imperial March from Star Wars. Pressing PB1 is resetting the sequence so the melody can start from the beginning. The application is built upon the Simplicity Studio Bluetooth SDK ver. 2.11 and tested with the BGM13S Starter Kit (SLWSTK4305A) but it should work with other EFR32 based Bluetooth enabled targets with minimal changes. We going to highlight the most important steps which are needed for building a MIDI over BLE compatible device. GATT definitionThe GATT.xml file has to contain the MIDI service definition as it is showed below.
Enable the bonding before connection
Set the connection interval to the required 15 ms.
Setup CRYOTIMER for creating 1ms timer for the timestampThis timestamp has to be included to the MIDI message.
Setup GPIO interrupt for button pressHere is the PBB0_pressed function registered as a GPIO interrupt service routine and will be triggered for both rising and falling edges. The function is reading the GPIO state and sends a note on or note off message accordingly. The code snippet below shows the recommended way for registering the ISR.
Function to send a note on messageThe MIDI_note_on() function prepare and send a note on message. First the function gets the timestamp from the CRYOTIMER. The CRYTIMER provides a 32 bit counter but according to the specification we need only the lower 13 bit, so the rest of the bits are masked. Then the function fills the header and timestamp fields. The header byte is 0b10xxxxxx where xxxxxxx is top 6 bits of timestamp. The timestamp byte is 0b1xxxxxxx where xxxxxxx is lower 7 bits of timestamp. The status byte is 0x90 is 0b1sssnnnn where sss is message type and nnnn is the MIDI channel. The last two bytes contains the 2 byte long event field in this case it is the note and velocity. Finally the function sends the message with the gecko_cmd_GATT_server_send_characteristic_notification API function.
TestingOnce the application flashed to kit it starts advertise itself. After connection it pairs and bonds with just work method. The application tested with the following IOS apps:
References[2] https://www.midi.org/specifications/item/bluetooth-le-midi |
Jun 19 2019, 11:03 AM |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
Posted
KBA_BT_0911: MIDI over BLE on Knowledge Base
MIDI over BLE with Wireless Gecko Soc-s and ModulesMIDI basicsThis article shows how a Blue Gecko can be used as a MIDI controller over Bluetooth Low Energy. At first we give some basic info about the MIDI standard then on the Apple Bluetooth Low Energy MIDI Specification. Finally, we highlight and explain the most important code snippets from the attached sample application which implements a very basic MIDI controller. The protocolMIDI is an industry standard music technology protocol that connects products from many different companies including digital musical instruments, computers, tablets and smartphones. MIDI is used everyday around the world by musicians, DJs, producers, educators, artists and hobbyists to create, perform, learn and share music and artistic works. Nearly every hit album, film score, TV show and theatrical production uses MIDI to connect and create. MIDI information is transmitted in "MIDI messages", which can be thought of as instructions which tell a music synthesizer how to play a piece of music. The synthesizer receiving the MIDI data must generate the actual sounds. Physical layerThe MIDI specification for the electrical interface is based on a fully isolated current loop. The MIDI OUT port nominally sources a +5 volt source through a 220 ohm resistor out through pin 4 on the MIDI OUT DIN connector, in on pin 4 of the receiving device's MIDI IN DIN connector, through a 220 ohm protection resistor and the LED of an optoisolator. The current then returns via pin 5 on the MIDI IN port to the originating device's MIDI OUT port pin 5, again with a 220 ohm resistor in the path, giving a nominal current of about 5 milliamperes. Despite the cable's appearance, there is no conductive path between the two MIDI devices, only an optically isolated one. The data rate on this system is a relatively slow (by today standards) 31,250 bits per second, logic 0 being current ON. The MIDI data stream is a unidirectional asynchronous bit stream with 10 bits transmitted per byte (a start bit, 8 data bits, and one stop bit). The MIDI data stream is usually originated by a MIDI controller, such as a musical instrument keyboard. MIDI controller and sound moduleA MIDI controller is a device which is played as an instrument, and it translates the performance into a MIDI data stream in real time (as it is played). The MIDI data output from a MIDI controller is transmitted via the devices' MIDI OUT connector. The recipient of this MIDI data stream is commonly a MIDI sound generator or sound module, which will receive MIDI messages at its MIDI IN connector, and respond to these messages by playing sounds. MIDI messagesThere are a number of different types of MIDI messages. See the https://www.MIDI.org for details. In the example code attached we implemented only Note On and Note Off messages. The Note On message is used for turning on MIDI notes. This is typically sent when a key pressed on keyboard. The Note Off message is used for turning off MIDI notes. This is typically sent when a key released on keyboard. MIDI over BLEThere are number of solutions where the standard DIN connector and physical layer changed to a more modern medium like USB or Ethernet. Apple defined a custom BLE service for MIDI support. This specification can be found here: https://developer.apple.com/bluetooth/Apple-Bluetooth-Low-Energy-MIDI-Specification.pdf With the release of iOS 8 and OS X Yosemite, sending and receiving MIDI data is supported using Bluetooth Low Energy connections on any iOS device or Mac that has native Bluetooth Low Energy support. To support MIDI over BLE the accessory has to fulfill a set requirements collected below. Connection intervalThe accessory shall request a connection interval of 15 ms or less. Apple recommends starting with a request for a connection interval of 11.25 ms and going to 15 ms if the connection request is rejected by the Apple product. Intervals higher than 15 ms are unsuitable for live playback situations. MTU negotiationThe accessory shall support MTU negotiation. See the MTU Size section in the Bluetooth Low Energy chapter of the Bluetooth Accessory Design Guidelines for Apple Products for implementation details. Multiple packet transmissionsThe accessory shall support sending and receiving the maximum number of Bluetooth Low Energy packets that can fit into the connection interval. MIDI minimum bandwidth requirements may not be met otherwise. Custom MIDI Service and CharacteristicThe GATT should contain the following service and characteristic
The MIDI I/O characteristics
Header and Timestamp fieldsAdditional Header and Timestamp fields has to be added before the standard MIDI message format
Note that the actual timestamp value is splitted between the Header and Timestamp fields. The 13-bit timestamp for a MIDI event in any given Bluetooth Low Energy packet is formed from the bottom 6 bits of the Header field and the bottom 7 bits of the Timestamp filed. Timestamps are in expressed in milliseconds, implying that the maximum timestamp range is 8192 ms. Timestamps shall be sent in monotonically increasing order. Example applicationThe attached application act as a very basic MIDI controller. It can send MIDI note on and MIDI note off messages when a button pressed or released on the WSTK. Pressing PB0 button repeatedly will play the Imperial March from Star Wars. Pressing PB1 is resetting the sequence so the melody can start from the beginning. The application is built upon the Simplicity Studio Bluetooth SDK ver. 2.11 and tested with the BGM13S Starter Kit (SLWSTK4305A) but it should work with other EFR32 based Bluetooth enabled targets with minimal changes. We going to highlight the most important steps which are needed for building a MIDI over BLE compatible device. GATT definitionThe GATT.xml file has to contain the MIDI service definition as it is showed below.
Enable the bonding before connection
Set the connection interval to the required 15 ms.
Setup CRYOTIMER for creating 1ms timer for the timestampThis timestamp has to be included to the MIDI message.
Setup GPIO interrupt for button pressHere is the PBB0_pressed function registered as a GPIO interrupt service routine and will be triggered for both rising and falling edges. The function is reading the GPIO state and sends a note on or note off message accordingly. The code snippet below shows the recommended way for registering the ISR.
Function to send a note on messageThe MIDI_note_on() function prepare and send a note on message. First the function gets the timestamp from the CRYOTIMER. The CRYTIMER provides a 32 bit counter but according to the specification we need only the lower 13 bit, so the rest of the bits are masked. Then the function fills the header and timestamp fields. The header byte is 0b10xxxxxx where xxxxxxx is top 6 bits of timestamp. The timestamp byte is 0b1xxxxxxx where xxxxxxx is lower 7 bits of timestamp. The status byte is 0x90 is 0b1sssnnnn where sss is message type and nnnn is the MIDI channel. The last two bytes contains the 2 byte long event field in this case it is the note and velocity. Finally the function sends the message with the gecko_cmd_GATT_server_send_characteristic_notification API function.
TestingOnce the application flashed to kit it starts advertise itself. After connection it pairs and bonds with just work method. The application tested with the following IOS apps:
References[2] https://www.midi.org/specifications/item/bluetooth-le-midi |
Jun 19 2019, 10:55 AM |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
Posted
WGM110 Direct WiFi - Search and connect on
qna
We are currently exploring the potential of using the WGM110 module in a WiFi direct project. One scenario is there maybe multiple WGM110 devices. We assume the user has already connected to all of the devices and set everything up (for example one touch security). Based on their mac address etc... we could give each Direct WiFi Device a unique names. An android application could simply cycle through the list of WiFi direct devices detected and connect to them one by one in order query their functionality (Perhaps json, or a web page might be provided by the WiFi Direct device). Does this approach seem sensible? |
Nov 27 2018, 9:22 AM |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
Posted
Using Bluetooth security features in Silicon Labs Bluetooth SDK on Knowledge Base
Using Bluetooth security features in Silicon Labs Bluetooth SDKThis article introduces the Bluetooth security features and terms then summarizes the practical usage of GATT permissions and pairing processes using the Silicon Labs Bluetooth SDK. Bluetooth Security BasicsThe most common threats in wireless communications are:
Bluetooth defines 5 distinct security features against these threats:
These features implemented in different layers of the Bluetooth stack. Let's have a quick look on these. Pairing
Bluetooth uses Secure Simple Pairing (SSP) pairing model. The actual pairing process depends on the device I/O capabilities and the security requirements defined by the application.
More details can be found here in the Pairing Processes KBA. Bonding
Authentication
A characteristic may be allowed to be read by any device, but only written by an authenticated device. Similarly, if a characteristic can be written, it does not mean the characteristic can also be read. Each individual characteristic could have different security properties. Encryption
Notice: No encryption of broadcast data Attribute permissions
Security LevelsSecurity level is a property of a connection. Using different security features can lead to different security levels per connection. The different levels summarized below.
Privacy
Public address is fixed and unique to a device Random address can change over time and hides the public address from unwanted devices Bonded devices can resolve the public address Bluetooth 4.2 Security Features
Using security features in Silicon Labs Bluetooth SDKTo use the security features you need to do the following steps:
Set up attribute permissions in GATTThe characteristics access and security properties are defined in the gatt.xml file by the XML attribute properties and its parameters, which must be used inside the characteristic XML attribute tags. Alternatively, Visual GATT Editor can be also used for defining the GATT elements and their permissions. The table below describes the parameters that can be used for defining attribute permissions.
GATT ExamplesHere we have 3 example for setting up attribute permissions for a characteristic. Example 1 — No restrictionsIn this case properties ensure that reading and writing the characteristic is without any restriction. It does not require authentication or encrypted link. Any GATT client can read or write it. Example 2 — Encrypted writeNow let's set up the characteristic differently In this case reading the characteristic is without any restriction. But writing the characteristic requires encrypted link. Characteristics which requires encryption cannot be accessed without pairing. So writing this characteristic in the first time will trigger the pairing process. The pairing can be just works so it is allowed to not have MITM protection. Example 3 — Authenticated writeNow let's modify the characteristic properties again. In this case reading the reading the characteristic is without any restriction. But writing requires authentication. It means the remote device must be bonded with man in the middle (MITM) protection enabled. So the characteristic cannot be accessed in case of just works pairing used. Writing this characteristic in the first time will trigger the pairing process. Setting up the security managerThe application shall use the gecko_cmd_sm_configure(flags, io_capabilities) API to set up the security configuration. The io_capabilities and flagsparameters affect the security level with which the devices will use in connection and leads to different pairing mechanisms. The io_capabilities parameter informs the stack about the possible user input and output method that is available on the device. See the available options here below:
The flags parameter controls different application specific security requirements. This parameter gives flexibility to the application to decide how strictly use or not use at all the Bluetooth security features. The table below shows the different options:
If the flags parameter is 0, so no application specific requirement set, the pairing method depends only on the IO capabilities of the initiator and the responder device (shown as I and R on the table below).
If a device has application specific security requirements (flags parameter is not 0) then the used pairing method and security level of the connection will be different. MITM - bit 0Setting the bit 0 forces the MITM protection. In practice it means that our devices will not bond with devices which don't have the io capabilities at least for legacy pairing. Encryption - bit 1Setting the bit 1 forces link encryption. In practice it means that our devices will always use encrypted link with bonded devices. Note if the bonding table is full therefore the device can't save the new bond. LE Secure connections support - bit 2If both devices support LE Secure Connections, then the value of then bit 2 doesn’t matter. If either one of the devices doesn’t support secure connections i.e. it supports legacy pairing only, then bit 2 comes into play. If bit 2 set to 1, secure connection is enforced, and the pairing attempt will fail with error code 0x303 (pairing_fail_authentication_requirements error). This is essentially saying that we don’t want to pair with legacy devices. If bit 2 set to 0, the pairing will fall back to legacy pairing methods. Application level confirmation of bonding request - bit 3If bit 3 is set then bonding requests need to be confirmed by the application too. This feature gives additional control over incoming bond requests. So the application can reject devices which otherwise could bond. The application notified about the received bonding request by the sm_confirm_bondingstack event. The application shall accept or reject the bonding request with the cmd_sm_bonding_confirm command. Set up bonding (enabled/disable/delete)To enable secure connection (Security Level 2 and above) the application need to allow bonding. The stack provides the gecko_cmd_sm_set_bondable_mode API function to enable or disable the bonding. Please note if gecko_cmd_sm_configure(flags, io_capabilities) called with flags parameter where bit 1 is set then the bonding enabled automatically. During application development sometimes it is useful to delete all the bondings to trigger and test the pairing processes. It can be done by the cmd_sm_delete_bondings API. There are use cases when the application has to manage the bonding table directly. This is out of scope of this article. You can read more about this in a separate KBA. Increase security levelIf the GATT attribute permissions are set correctly the application don't have to increase the security level manually. The security level of the connection will be increased once there is access demand for GATT elements which requires higher security level. If the 2 devices not bonded yet the pairing process also triggered. However there can be use cases where the application handles the security level of the connections. In those cases it makes sense to call the cmd_sm_increase_security API function in the evt_le_connection_opened event handler. Handle security manager stack events by the applicationDuring the pairing process there are few stack events that the application has to handle otherwise the pairing and bonding will fail. These events are the following. evt_sm_passkey_display evt_sm_passkey_request If the passkey was valid and the bonding completed the stack raise a evt_sm_bonded event. If the passkey was invalid or the bonding failed because of any other reason the stack will raise a evt_sm_bonding_failed event. evt_sm_confirm_passkey evt_sm_bonded evt_sm_confirm_bonding evt_sm_bonding_failed References |
Nov 07 2018, 8:57 AM |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
Updated
How can I extend the Bluetooth examples with UART functionality? on Knowledge Base
Question How can I extend the Bluetooth examples with UART functionality? Answer There are 3 options: 1. Use the standard printf and get functions which are retargeted to one USART or LEUART peripheral. This option is very easy to use but you cannot send binary data with this. The easiest way to use printf is through the use of our retargetserial driver. To get started,
Now you can call printf() anywhere in the application and the output will be directed through the virtual COMPORT. Please remember that printf() can take somewhat long to execute so care should be taken in using it so that Bluetooth connections are not interrupted.
2. Use the em_usart or the em_leuart driver. These drivers are part of the emlib. They provide an API for the USART and LEUART MCU peripherals.You can find more about the API here: https://siliconlabs.github.io/Gecko_SDK_Doc/efr32bg1/html/group__USART.html https://siliconlabs.github.io/Gecko_SDK_Doc/efr32bg1/html/group__LEUART.html
3. Use the uartdrv driver. This driver is the most flexible from the available options. It is built on the top of emlib. The UART driver support both USART and LEUART peripherals. The driver is fully reentrant and multiple driver instances can coexist. The driver does not buffer or queue data, but it queues UART transmit and receive operations. Both blocking and non-blocking transfer functions are available. Non-blocking transfer functions report transfer completion with callback functions. Transfers are done using DMA. Simple direct/forced transmit and receive functions are also available. UART hardware flow control (CTS/RTS) is fully supported by the driver. UART software flow control (XON/XOFF) is partially supported. In this article we going to set up the uartdrv to use the USART peripheral in few steps. The attached example is demonstrating the initialization and the using of non-blocking RX/TX functions with implementing a simple echo functionality.
Setting up the uartdrv Step 1 – Add the necessary emlib source files to the project from the gecko SDK. These are the followings: platform\emlib\src\em_cmu.c platform\emlib\src\em_core.c platform\emlib\src\em_dma.c platform\emlib\src\em_emu.c platform\emlib\src\em_gpio.c platform\emlib\src\em_int.c platform\emlib\src\em_ldma.c platform\emlib\src\em_leuart.c platform\emlib\src\em_usart.c
Then add the necessary emdrv source files to the project from the gecko SDK. These are the followings: platform\emdrv\dmadrv\src\dmadrv.c platform\emdrv\gpiointerrupt\src\gpiointerrupt.c platform\emdrv\uartdrv\src\uartdrv.c
Step 2 – Update the include paths of the project. You need to add the emlib and emdrv include paths as listed below: platform\emlib\inc platform\emdrv\common\inc platform\emdrv\dmadrv\config platform\emdrv\dmadrv\inc platform\emdrv\gpiointerrupt\inc platform\emdrv\gpiointerrupt\inc platform\emdrv\uartdrv\inc platform\emdrv\uartdrv\config
In case using UART over J-Link CDC-on Silicon Labs boards you need the include path for the board and kit abstraction headers also. These headers containing the Virtual COM pin settings. The path for these are below: hardware\kit\\common hardware\kit\common\bsp hardware\kit\common\halconfig
Step 3 – Once the necessary files and include paths are added you need to switch of the automatic sleeping feature of the Bluetooth stack. This is needed because the USART peripheral is not working in EM2. It can be done by setting the gecko_configuration_t.sleep.flags to 0 as shown below.
Step 4 – On Silicon Labs kits you can use the UART over the J-Link CDC. For that you need to route the UART signals from the MCU to the board controller of the kit. This can be done by setting VCOM enable pin high. Most of the kits it can be done by setting a GPIO by software. But on some kits a 0 Ohm resistor must soldered additionally. Here is how you can enable VCOM by software.
Example The attached uart_echo.c and uart_echo.h implements terminal echo. It can be used in any Bluetooth SDK project once the steps described above are completed. Calling the UART_EchoInit(uint8_t vcom) sets the VCOM enable pin, configures the uartdrv then start to receive. Once a byte received the UART_rx_callback called by the uartdrv. The callback immediately transmits the received byte back and start to receive the next byte.
|
Aug 17 2018, 8:08 AM |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
Replied
to
How can I use uartdrv on BGM121 with Bluetooth SDK 2.9.2.0?
Hi, The project in the zip file is using the old SDK. But you can use the attached .c and .h files in newer SDKs.
-Balázs |
Aug 15 2018, 11:08 AM |