This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Big picture view of using nRF52 as a BLE MIDI add-on

I have the nRF52 Dev Kit running now on Mac OS with SES. (for reference to this topic: click here)

My end result is to use the nRF52 chip as part of a MIDI wind controller. I use the Teensy Arduino compatible MCU for the bulk of the wind controller, including creating MIDI messages that can be sent to a MIDI synthesizer over USB MIDI or via serial (UART).

I want to leverage the MIDI over BLE specified at MIGI.org

I expect I'll use BLE to communicate:

  • MIDI messages out to a synthesizer (e.g. Garageband on the iPhone or Mac)
  • Firmware updates in to the nRF52 chip and to the Wind Controller MCU from a Web App
  • Wind Controller battery status to a host (such as the iPhone)

I am assuming the following:

  • I need to incorporate the nRF52 chip into my board design (just the chip... no external antenna)
  • I need to flash the nRF52 with all of the needed BLE services and characteristics somehow - ideally, from the Teensy MCU

Questions

  • Am I on the right track above?
  • Can anyone recommend a consultant (paid or otherwise) who could coach me on this?
Parents
  • Hi David, seems like a cool project. This should definitely be possible, as someone has already gotten a very similar project working with an Arduino MCU (see link).

    Should definitely work to use BLE to communicate the MIDI messages out to a synthesizer via UART (see link). I would recommend using two nrf52 DK's, where you connect one of them to the Teensy MCU & you use the other one to communicate via BLE to your computer.

    Otherwise, you could also use one nrf52dk that communicates with the teensy mcu & use your iphone & the uart application on the nrf toolbox app for iOS. I guess you would need to make your own iOS app to be able to communicate via uart to the Garageband app. If you do not have much experience with iOS app programming, I am guessing it will be easier to do this via the mac instead. Not quite sure though.

    To communicate between the nrf52 & the Teensy MCU, you could use SPI for example.

    For firmware updates, I would definitely take a look at this great Secure DFU blogpost. You could for example upgrade the DFU via the nrf connect app on PC or via nrf Connect or nrf Toolbox on your smartphone.

    Lastly, to get the wind controller battery status, you could use a voltage divider & capacitor as explained in this blog post & measure the battery voltage via SAADC. As voltage is not a great indicator of battery status, I would then recommend doing a simple battery discharge & charge test (see link 1, link 2). Ideally, you want to get an Open Circuit Voltage vs State of Charge (SoC) relationship so that you can map a measured voltage to the SoC given as a %. I would recommend using a rechargeable Li-Ion battery for your wind controller. Make sure to get a battery with enough capacity & also with a great enough discharge current to be able to power the nrf52 & Teensy MCU.

    You will need an antenna to be able to communicate via BLE, so you could use either a PCB antenna, meander antenna or chip antenna (see link 1, link 2, link 3). Seeing as this is quite a complex project already, I would consider using one or two nrf52dk's to begin with to simplify the process at the beginning (depending on whether you want to connect to Garageband on your Mac or iPhone). You could always try to minimize the size of the wind controller at a later time.

    If you were to use an nrf52dk, it would be simple to flash the application to the dk. If you want to use the nrf52 chip instead, you can take a look at this devzone case. I am not sure if it is possible to program an nrf52 chip via the Teensy MCU.

    For consultants, I would recommend googling around a bit. Hope that helps! :)

  • Very helpful, Bjorn

    It is indeed an involved project.

    I think I've got the division of labor down:

    - Teensy does all of the MIDI Wind Controller work, and sends MIDI messages to the nRF52 using SPI.  I'll dig into the SPI example in examples/peripheral/spi.  Teensy will provide and manage power.

    - nRF52 on a 3rd-party breakout board with antenna for the the mid-term - Rigado uses the nRF52 seems like a good choice

    - BLE service only for MIDI - using the Apple-written, MIDI & BLE approved noted above.  This is currently the part I need help with.

    The MIDI over BLE Service uses as well-known Vendor UUID type.  Here's a snip from the spec I noted earlier.

    The following service and characteristic are defined:
    • MIDI Service (UUID: 03B80E5A-EDE8-4B33-A751-6CE34EC4C700)
    • MIDI Data I/O Characteristic (UUID: 7772E5DB-3868-4112-A1A9-F2669D106BF3)

    • write (encryption recommended, write without response is required)
    • read (encryption recommended, respond with no payload)
    • notify (encryption recommended)

    I'm using the examples\ble_peripheral\ble_app_hrs as a coding starting place.
    I've been able to strip out lots and keep it advertising an connecting.

    When assigning the Service, there is a macro used from BLE_TYPES:

    #define BLE_UUID_BLE_ASSIGN(instance, value) do {\
                instance.type = BLE_UUID_TYPE_BLE; \
                instance.uuid = value;} while(0)
    

    I could use your help with one of two things:

    1. an analogous macro that uses BLE_UUID_TYPE_VENDOR_BEGIN rather than BLE_UUID_TYPE_BLE

      or better yet

    2. a full fledged Nordic example of a peripheral using a vendor Service UUID

    Can you help?

    Thanks, Dave

Reply
  • Very helpful, Bjorn

    It is indeed an involved project.

    I think I've got the division of labor down:

    - Teensy does all of the MIDI Wind Controller work, and sends MIDI messages to the nRF52 using SPI.  I'll dig into the SPI example in examples/peripheral/spi.  Teensy will provide and manage power.

    - nRF52 on a 3rd-party breakout board with antenna for the the mid-term - Rigado uses the nRF52 seems like a good choice

    - BLE service only for MIDI - using the Apple-written, MIDI & BLE approved noted above.  This is currently the part I need help with.

    The MIDI over BLE Service uses as well-known Vendor UUID type.  Here's a snip from the spec I noted earlier.

    The following service and characteristic are defined:
    • MIDI Service (UUID: 03B80E5A-EDE8-4B33-A751-6CE34EC4C700)
    • MIDI Data I/O Characteristic (UUID: 7772E5DB-3868-4112-A1A9-F2669D106BF3)

    • write (encryption recommended, write without response is required)
    • read (encryption recommended, respond with no payload)
    • notify (encryption recommended)

    I'm using the examples\ble_peripheral\ble_app_hrs as a coding starting place.
    I've been able to strip out lots and keep it advertising an connecting.

    When assigning the Service, there is a macro used from BLE_TYPES:

    #define BLE_UUID_BLE_ASSIGN(instance, value) do {\
                instance.type = BLE_UUID_TYPE_BLE; \
                instance.uuid = value;} while(0)
    

    I could use your help with one of two things:

    1. an analogous macro that uses BLE_UUID_TYPE_VENDOR_BEGIN rather than BLE_UUID_TYPE_BLE

      or better yet

    2. a full fledged Nordic example of a peripheral using a vendor Service UUID

    Can you help?

    Thanks, Dave

Children
No Data
Related