UART over BLE ?

[joseph_reveane]

Hi,

The current RPK stack provides a pre-defined set of services and characteristics for all its embedded sensors.

But, and unless I'm wrong, it does not provide UART/Serial Port Emulation over BLE.

Is there any plan to get this feature added in  the SDK and/or Rapid IOT studio ?

Regards.

/joseph

PS: on a side topic, I was not able to find a Rapid-IOT studio example using the UART block...

[ashokfair]

Hi Joseph,

have a look on this post Rapid IoT Kit - Wireless Uart Demo it may be helpful.

Thanks,

Ashok r

[joseph_reveane]

Hi Ashok,

Thanks a lot for this cool demo !

Regards.

/joseph

[estephania_mart]

Hello, 

The supported Bluetooth LE profiles supported by the KW41 (which it's the one in charge of the Bluetooth in the rapid IoT)  are the following

 

You can check this posts 

Rapid IoT Studio Project Example: Smart Air Conditioner 

https://community.nxp.com/docs/DOC-342109 

And maybe you could try developing your custom profile can help you with this to create something like the wireless uart example, but you will need to verify if this is possible to be done in the Rapid IoT. 

Regards, 

Estephania 

[joseph_reveane]

Hi Estephania,

Thanks for the pointers and the tips.

I had a look at the OOB projects code and figured out that there was no UART over service available.

There is no "official standard" specs for such a profile anyway although its seems that there is a

"de facto" one which allows to communicate with Android applications for example.

The main advantage of such a UART service IMHO is that it provides an easy mean to define the packets

format without having to modify/implement a new service within the BLE SOC.

Let's take this simple example:

- the RPK provides Accelerator, Gyroscope and Magnetometer sensors, which is very cool, and

their corresponding services.

- the application would  need to consume the data of these sensors but after some filtering/computation has

been applied to all of them on the RPK device side. This would be a compound service.

So, in order to support such a Use Case, the user would need either to:

- define a new BLE service

- define a packet format to exchange of the UART over BLE service if available.

I do understand that this kind of Use Case was probably not part of the initial requirements but a UART over BLE service

would open even more the range of applications which can be addressed by this Rapid-IOT kit IMHO.

Regards.

/joseph

[marcomerlin]

Hi Joseph,

> The main advantage of such a UART service IMHO is that it provides an easy mean to define the packets

format without having to modify/implement a new service within the BLE SOC.

I totally agree with you.

I have been playing with this for a few days now, and I was expecting (mistakenly) some sort of UART available.

I guess the "de facto standard" you mention is the nRF implementation

Nordic Semiconductor Infocenter 

for which several clients are available.

nRF UART 2.0 - App su Google Play 

An example implementation from SiLabs is descibed here:

https://www.silabs.com/community/thunderboard/knowledge-base.entry.html/2016/04/10/spp-over-ble_bgsc... 

NXP delivers its own UART implementation with the KW41 and QN9080 SDKs (example is called wireles_uart), and we have a client implementation available in the IoT toolbox application.

IoT Toolbox - Apps on Google Play 

I am not able to understand just by looking at the code whether this is an NXP custom implementation, or matches the nRF implementation. Nevertherless this might be the starting point to wrap an UART over BLE service to the Rapid IoT prototyping. Moreover, I was not able to get the wireless uart example working with QN9080 recently, even though I am sure I did use it in the past.

In the first place I was thinking I would have to implement the "right" protocol on the KW41 code (my aim was to implement a BLE-MIDI controller like described here https://www.novelbits.io/bluetooth-gatt-services-characteristics/ ). But the more I tried, the more I realized that is just not the way the Rapid IoT kit is thought to work: it does not seem you are really supposed to modify the code on the KW41, and to me it was not easy to manipulate the sensors form MCUXpresso (besides I do not like much playing with MCUXpresso). Really trying to write the K64 code seems a nightmare to me, as there are too many software layers (freeRTOS, ATMO, sensors), and the examples are not helping me much in even understanding the structure of the code. Therefore it seemed to me that the most reasonable option was to leverage the existing Rapid IoT IDE to wrap the sensor data into GATT service, and then implement a GATT client (in my case the aim is using a host PC), which eventually might implement a virtual com port.

I believe the "right way" to do that would be to develop a windows GATT application on visual studio, as descibed here

Bluetooth GATT Client - UWP app developer | Microsoft Docs 

but with time I grow allergic to MS Visual Studio...

Instead I have tried using python wrappers around existing libraries that expose the GATT protocol

GitHub - peplin/pygatt: Python wrapper for gatttool (from BlueZ) and the BGAPI for accessing Bluetoo... 

bleak · PyPI 

but it seems the frameworks I found are supposedly only working on on linux, and I was not able to make them run on my machine (pygatt hangs the python interpreter as soon as I try to open a connection. I might try to play with this a bit still but I am less enthusiastic than yesterday about it).

As an alternative that seems working in principle, I have currently being considering using a QN9080 DK board that I had laying around from my previous project ( QN9080DK: A highly extensible platform for application development of QN908x|NXP  ), running the ble_shell example. With this I was able to connect to the Rapid IoT kit over BLE, and communicate with the PC over the debug serial port ( I know using the debugger is a little bit cheating ), and reading data from the sensors. I believe the same example should be available also for the KW41 freedom board, and eventually the code should be relatively easily portable between the two ( FRDM-KW41Z |Bluetooth Low Energy/IEEE® 802.15.4 wireless enabled Freedom Development Kit|NXP  ). In perspective, I believe I can implement the GATT client on the QN9080, and even process the sensor data to translate the GATT messages into MIDI messages, then redirect the output to the serial debug port, and finally use some "standard" destop application to "virtually plug together" the serial debug port and a virtual MIDI input port.

I hope sharing those information might help you figure out what would be the best option for you too (and maybe suggest a path to add the UART over BLE to the Rapid IoT SDK).

Regards,

MM

[joseph_reveane]

Hi Marco,

Thanks for sharing all of this, this is very interesting.

You're right, I had the "NUS" private service in mind. It seems to me that it is "widely" used and 

finding Android applications code using it is easy.

Following Theophile advise, I've tried the easiest path (as compared to modify the KW41Z code) to get this UART service

running on a RPK node.

I've tried to hack the RPK OOB MCUxpresso project and had some kind of "success" with it:

- the RPK node was able to receive some short text messages from an Android UART over BLE application and display them on the console

- the RPK node was able to send short messages (pressure/temperature sensor values converted to strings) to the same Android Application.

Defining the new service and its characteristics UUIDs and get it "registered" on the KW41Z was easy, so was writing the small amount of code

which deals with the ability/trigger/callback/interrupt stuff. Most of the job was done by duplicating some of the existing code.

Of course, it was simply a POC and the code was not complete.

But the main problem with this approach is that it would remain a hack which:

- get lost each time the project is modified within Atmosphere

- can't be re-used within an other new project

I don't know what would be the cost to define and implement such an UART over BLE element into the on-line IDE

and the RPK firmware, but this would be the path to go with IMHO.

I guess that the RPK tool kit and its platform have not been designed with this kind of Use Case in mind, which is fine by me.

The RPK kit is really features rich anyway...

Regards.

Joseph

[marcomerlin]

Hi Joseph,

> I've tried to hack the RPK OOB MCUxpresso project and had some kind of "success" with it:

Ca you share what exactly did you have to modify ?

Was it just a matter of modifying the UUIDs of service and characteristics ?

I have been trying this path as well last week, but despite the fact that I am able to read the characteristics with android applications

Blue tooth LE GATT list - Apps on Google Play 

nRF Connect for Mobile - Apps on Google Play 

Any attempt to pair with functional application failed, as it seems I am not able to pair the RPK as a standard BT device.

I guess this might be related to this discussion.

https://community.nxp.com/thread/486678 

Thank you for sharing your experience!

Regards,

MM

[joseph_reveane]

Hi Marco,

What I did was really simple:

- added new service and characteristics UUIDs for the proprietary NUS service

- added the registration code

- tried to find out/cover all the places (trigger/handler/callbacks/interrupts) which could require

some specific code to get the NUS prototype working.

Once this has been done, I've been using mostly the LightBlue application on IOS 11.x.

I didn't face any pairing issue with this application but maybe this was because I had used the RPK node

with this IOS device before to connect to the Rapid-IOT on-line IDE ?

Unfortunately, I can't perform new tests at the moment since mt RPK node is out of order for now and needs

a re-flash of the 2 boot loaders...

Sorry, I've created a Zip archive which contains the files that I've modified for my POC but it sounds that there is no

way to get it attached to this post ?

Regards.

/joseph