Modifying lte_ble_gateway to connect with nRF52DK

[jake11212]

I want to modify the lte_ble_gateway app (nRF connect SDK 1.6.0) to connect with the nRF52DK advertising through the ble_app_uart (nRF 17.0.2) application.  The lte_ble_gateway typically connects with the thingy52 but I wasn't able to find what files were being used to store the attributes to connect to the thingy52.  Is there more information on where these attributes are stored and the protocol used by the lte_ble_gateway app?  How do I go about changing the app to connect and receive data from the nRF52DK running ble_app_uart? 

The lte_ble_gateway connects to the thingy 52 based on its service and characteristic UUIDs.  Could I just change these UUID to the ble_uart service UUID and RX/TX UUID that ble_app_uart uses?  

The NUS_BASE_UUID is: 0x9E, 0xCA, 0xDC, 0x24, 0x0E, 0xE5, 0xA9, 0xE0, 0x93, 0xF3, 0xA3, 0xB5, 0x00, 0x00, 0x40, 0x6E

and its characteristics are:

BLE_UUID_NUS_TX_CHARACTERISTIC 0x0003
BLE_UUID_NUS_RX_CHARACTERISTIC 0x0002

Can I directly swap the NUS BASE UUID for the BT_UUID_THINGY in the lte_ble_gateway sample for the thingy52 to cause it to detect the nordic uart service?   For instance by changing this code in the ble.c file for lte_ble_gateway: And is there a UUID for the nRF52DK device?  

/* Thinghy advertisement UUID */
#define BT_UUID_THINGY                                                         \
	BT_UUID_DECLARE_128(0x42, 0x00, 0x74, 0xA9, 0xFF, 0x52, 0x10, 0x9B,    \
			    0x33, 0x49, 0x35, 0x9B, 0x00, 0x01, 0x68, 0xEF)

/* Thingy service UUID */
#define BT_UUID_TMS                                                            \
	BT_UUID_DECLARE_128(0x42, 0x00, 0x74, 0xA9, 0xFF, 0x52, 0x10, 0x9B,    \
			    0x33, 0x49, 0x35, 0x9B, 0x00, 0x04, 0x68, 0xEF)

/* Thingy characteristic UUID */
#define BT_UUID_TOC                                                            \
	BT_UUID_DECLARE_128(0x42, 0x00, 0x74, 0xA9, 0xFF, 0x52, 0x10, 0x9B,    \
			    0x33, 0x49, 0x35, 0x9B, 0x03, 0x04, 0x68, 0xEF)

 I also noticed that the NUS_BASE_UUID is 128 bits but the TX and RX characteristics are in a different format from the characteristics on the ble.c file.  How do I convert the TX/RX characteristics to be compatible in this format?

And what changes need to be made on the advertising side to allow it to be detected and send data through directed advertising?

Thanks!

[Einar Thorsrud]

Hi,

The lte_ble_gateway implementas all BLE related stuff in nrf\samples\nrf9160\lte_ble_gateway\src\ble.c. There you see it searches for a Thingy by looking for the BT_UUID_THINGY UUID in advertising packets. And it implements a simple service client with the Thingy service (BT_UUID_TMS) using a single characteristic, which is the Thingy orientation characteristic (BT_UUID_TOC). This is the only thing that is implemented with regard to BLE in this sample. Here, it enables notifications on the orientation characteristic, and handles that. This is al lit does.

Is there more information on where these attributes are stored and the protocol used by the lte_ble_gateway app?

You can see in on_received() in ble.c that the data (position) is provided as input to aggregator_put(). That is read by aggregator_get(), which is called by aggregator_get() from send_aggregated_data in alarm.c.

How do I go about changing the app to connect and receive data from the nRF52DK running ble_app_uart? 

If you want to use NUS instead, I suggest you refer to the NUS client and the Bluetooth: Central UART sample for the BLE related code. You would also have to modify the rest of the code and the cloud implementation in order to handle NUS data in a sensible way.

Can I directly swap the NUS BASE UUID for the BT_UUID_THINGY in the lte_ble_gateway sample for the thingy52 to cause it to detect the nordic uart service?

You can filter on the BT_UUID_NUS_SERVICE if that is part of the advertisement packet, as is done in the Central UART sample. This will allow you to scan for the device. You would also have to modify the code to do service discovery for the Nordic UART service. Again, the same sample demonstrate this.

And is there a UUID for the nRF52DK device?  

It all depends on the code that is running on it. But if it runs the NUS server/peripheral example, then BT_UUID_NUS_SERVICE will be advertised. 

 I also noticed that the NUS_BASE_UUID is 128 bits but the TX and RX characteristics are in a different format from the characteristics on the ble.c file.  How do I convert the TX/RX characteristics to be compatible in this format?

See definitions in nrf\include\bluetooth\services\nus.h.

And what changes need to be made on the advertising side to allow it to be detected and send data through directed advertising?

Directed advertising is not related to NUS (which is a service, i.e. is used in a connection). You can seach in the code for BT_LE_ADV_OPT_DIR_ADDR_RPA or BT_LE_ADV_OPT_DIR_MODE_LOW_DUTY to see examples of use.

[jake11212]

Einar Thorsrud said:

You can see in on_received() in ble.c that the data (position) is provided as input to aggregator_put(). That is read by aggregator_get(), which is called by aggregator_get() from send_aggregated_data in alarm.c.

So the aggregated data is where the received BLE data is stored to be sent over LTE-M, correct?  So if we want to bring in other data what processing needs to be done to it before it is sent over LTE-M?  Are there any guidelines for this? 

Einar Thorsrud said:

If you want to use NUS instead, I suggest you refer to the NUS client and the Bluetooth: Central UART sample for the BLE related code. You would also have to modify the rest of the code and the cloud implementation in order to handle NUS data in a sensible way.

So are you saying we should look to the Bluetooth: Central UART sample to determine how to modify the AWS IoT code to connect with our device?  AWS IoT requires programming the HCI low power UART to the 52840 which I assume is what handles the bluetooth connection with the second board right? Do we need to modify HCI at all or do all the changes just take place in the lte_ble_gateway file?  

Also where does the communication between the 52840 and 9160 take place in the code?  I want to understand what changes I need to make to send custom data between the chips.

[Einar Thorsrud]

Hi,

jake11212 said:

So the aggregated data is where the received BLE data is stored to be sent over LTE-M, correct?

Yes.

jake11212 said:

So if we want to bring in other data what processing needs to be done to it before it is sent over LTE-M?  Are there any guidelines for this? 

That would be application specific, depending on how different data is handled by your cloud service. Please open a new case for this topic if you need to dig deeper into that. 

jake11212 said:

So are you saying we should look to the Bluetooth: Central UART sample to determine how to modify the AWS IoT code to connect with our device?

Yes. You stated that you want to communicate with a nRF device using the NUS service, and then the NUS client (central) example demonstrates exactly how you handle the Bluetooth part of this. (Just changing the UUIDs like you suggested is not enough.)

jake11212 said:

AWS IoT requires programming the HCI low power UART to the 52840 which I assume is what handles the bluetooth connection with the second board right?

Yes. That is the controller (link layer) firmware which runs on the nRF52840, and communicates with the host on the nRF91.

jake11212 said:

Do we need to modify HCI at all or do all the changes just take place in the lte_ble_gateway file?

You should not need to modify the nRF52840 firmware for this, no. (It is required in some cases, but the default configuration is usually sensible for most applications).

jake11212 said:

Also where does the communication between the 52840 and 9160 take place in the code?

This is hidden by the BLE stack. You use high level Zephyr Bluetooth APIs, and in this case the stack is split between the nRF91 (host) and nRF52840 (controller) and the communication is using standard HCI. If you want to send other custom data without interfering with this it makes sense to use another interface.