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

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

Bjørn Kvaale — Thu, 01 Mar 2018 12:25:23 GMT

Great to hear that it worked it! Good luck with further development!

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

Bjørn Kvaale — Thu, 01 Mar 2018 12:24:57 GMT

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.

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

David Elvig — Mon, 19 Feb 2018 20:25:29 GMT

OK, I think I can mark this Answered.

I have follow-on questions, but the "Big Picture View" is clear to me now.

In summary:

I was able to get the nRF52 Dev Kit (PCA10040) programmed to advertise as a MIDI-over-BLE device (though not yet a complete one)

Components of the solution:

Mac OS 10.13.3
Segger Embedded Studio V3.34
SDK 14.2.0
NRF Connect 1.8.2
Apple's GarageBand

Key resources:

this gitHub site from Bjorn Spockeli
This training video https://www.youtube.com/watch?v=uP8RYgYGRvI&hd=1&feature=youtu.be&t=254

As a newcomer to BLE, the 50 hours spent, and the path taken in this thread, contributed to understanding the components and key resources above.

Other components of the larger solution will likely include an SPI interface between my chosen MCU and the nRF52.

Mange Tak to both Bjorns

Dave

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

David Elvig — Fri, 16 Feb 2018 23:58:38 GMT

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?

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

David Elvig — Fri, 16 Feb 2018 06:13:49 GMT

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?

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

Bjørn Kvaale — Mon, 12 Feb 2018 08:00:34 GMT

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!

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

David Elvig — Mon, 12 Feb 2018 03:31:32 GMT

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

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

David Elvig — Sat, 10 Feb 2018 22:38:00 GMT

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:

an analogous macro that uses BLE_UUID_TYPE_VENDOR_BEGIN rather than BLE_UUID_TYPE_BLE

or better yet
a full fledged Nordic example of a peripheral using a vendor Service UUID

Can you help?

Thanks, Dave

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

Bjørn Kvaale — Mon, 15 Jan 2018 09:27:53 GMT

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