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! :)

  • Bjorn,

    I spent the weekend with the ble_app_hrs, and made good progress.

    Then I recognized that the ble_app_uart example in a parallel folder uses a vendor specific Service UUID

    I'm struggling to get that running - and I think the documentation may not be up to date

    Can you point me at a tutorial for the UART example that assumes the new toolchain that Nordic is offering - Segger?

    Thanks,

    Dave

Reply Children
  • Hi Dave,

    I would take a look at this link in the Nordic Infocenter. In addition, I can suggest you take a look at the Bluetooth Low Energy Characteristics, Services & Advertising beginner's tutorials (see link). This should definitely help you get started. In addition, Nordic has a great Youtube playlist for getting started with segger embedded studio. Hope that helps!

  • I've made progress.  And I would mark this issue "Answered" if it did not fail at runtime.

    I started with the Dev Kit's "examples\ble_peripheral\ble_app_template" application.

    I added MIDI-specific code as in https://www.novelbits.io/bluetooth-gatt-services-characteristics/

    The app compiles and links without error.

    At runtime, I debug to a failing line of code within 

    main(...)

    services_init(...)

    ble_midi_service_init(...)

    err_code = sd_ble_uuid_vs_add(&base_uuid, &p_midi_service->uuid_type);

    err_code should be 0 (NRF_SUCCESS)

    Instead, it is 4. Which I think is NRF_ERROR_NO_MEM in this case.

    sd_ble_uuid_vs_add(...) is defined in ble.h
    SVCALL(SD_BLE_UUID_VS_ADD, uint32_t, sd_ble_uuid_vs_add(ble_uuid128_t const *p_vs_uuid, uint8_t *p_uuid_type));
    
    (line 495 in ble.h)


    Where do I go with this type of issue. I could post the entire code, which is a combination of standard Dev Kit example code and a pair of c/h files from the novelbits tutorial.

    Are there a set of standard steps to evaluate with err_code = 4?
    My sense is that I need to explicitly make room in "the BLE stack's table" (from the documentation in ble.h).

    Any pointers?

  • I'm on to an answer.

    I think my problem generating the NRF_ERROR_NO_MEM error will track to resetting project linker parameters as in 

    this gitHub site from Bjorn Spockeli and search for "RAM"

    This tutorial has a step:

    Segger Embedded Studio(SES): Click "Project -> Edit Options", select the Common Configuration, then select Linker and then open the Section Placement Macros Section and modify RAM_START IRAM1 to 0x200020F0 and RAM_SIZE to 0xDF10, as shown in the screenshot below

    I've seen elsewhere how to determine the magic numbers that are used here... but I can't find that method now.

    I expect that this tutorial step  avoids a runtime error (that is not evident at compile/link time.)

    Question: after modifying a project to have more (or less I suppose) UUIDs - or other objects that affect RAM...  how do I determine the right numbers to set in Section Placement Macros?  Is it an output of compile/link that I need to reference, and then go update the Project Options?

    Thanks!

    later edit:

    This training video https://www.youtube.com/watch?v=uP8RYgYGRvI&hd=1&feature=youtu.be&t=254

    shows a way to discover proper settings for RAM_START and RAM_SIZE using the debugger.

    Is this the best practice for determining these values?

  • Hi David, I believe the youtube video shows one of the best ways to determine the RAM values. This link could also be helpful. It can be useful to check the softdevice specifications for more info.

Related