LTE_BLE_Gateway read and write in characteristic

[Thabet]

Hello,

I would like to know if it is possible to provide an example based on the lte_ble_gateway sample for writing and reading the characteristic!

I changed the example and I'm connecting with an nRF52840, but I'm not able to write or read the characteristics.

I noticed that many people also have difficulty in incrementing this in the example, so I think it would be very useful if they could demonstrate this in an example, most topics about this tell the user to base themselves on the nus_client example, but it's not that trivial, the code bases are very different and even based on this code I could not implement it successfully.

The tutorial in the link below demonstrates very well how to perform this implementation based on NUS, but I find a lot of incompatibility when I try to implement the functionality described in the tutorial for the lte_ble_gateway sample. Is it possible to implement this functionality in the sample? Could you give a very brief example of writing and reading the characteristics?

 Building a Bluetooth application on nRF Connect SDK - Contrasting to SoftDevice - Part 2 Central role 

I'm using NCS 2.0.0 and nRF9160DK!

Thank you.

[ovrebekk]

Hi 

Are there any particular issues you are experiencing when trying to add the NUS code into the lte_ble_gateway example? 

I can try to make this change on my end, but I won't be able to do this until next week at the earliest. 

Best regards
Torbjørn

[Thabet]

Hello ovrebekk ,

Were you able to try to start this implement?

Any suggestions on how to resolve these issues I'm encountering?

Thank you.

[Thabet]

Hello,

Perfect, I'm looking forward to it!

Thank you.

[ovrebekk]

Hi

I was able to replace the Thingy client with the NUS client in the example, and I shared the code here. 

The main application is more or less unchanged, I just added a bit of code to log any incoming NUS messages, and echo a reply back to the NUS peripheral whenever it sends a packet. 

As you can see I added a callback function to the ble_init function that will be used to handle incoming messages, and added a ble_data_send(..) function that you can use to send packets over NUS. 

The example has been through limited testing, and could benefit from some additional improvements (like a FIFO to store incoming and outgoing data), but hopefully it can prove useful for you to get started. 

Best regards
Torbjørn

[Thabet]

Hello,

Thank's for your time, but unfortunately this example does not allow me to advance anything! It's working basically the same as the modified example of lte_ble_gateway that I sent here... It works well to connect with a uart peripheral, I even managed to send something through ble to the peripheral, but I couldn't read the values ​​of the characteristics and no return on changing these. And it is also not possible to send any command via terminal to the nRF9160 so that this command is sent by the BLE, always get ERROR, exactly the same behavior I had when using the service filter in my code.

But as you can see from the beginning of the ticket, I need to filter by address to connect to a specific device! And when I change the filter in your code, I find exactly the errors I found in my firmware, duplicate connection attempts, one fails and the other connects.

[00:00:00.509,918] <inf> lte_ble_gw: LTE Sensor Gateway sample started
[00:00:00.510,131] <inf> lte_ble_gw: Initializing Bluetooth..
[00:00:01.225,097] <wrn> bt_hci_core: opcode 0x0000 pool id 3 pool 0x20015268 != &hci_cmd_pool 0x200152d0
[00:00:01.326,385] <inf> lte_ble_gw: Bluetooth ready
[00:00:01.326,385] <inf> lte_ble_gw: NUS Client module initialized
[00:00:01.339,874] <inf> lte_ble_gw: Scanning...
[00:00:05.879,119] <inf> lte_ble_gw: Device found: 38:31:AC:02:50:0D (public)
[00:00:05.892,700] <inf> lte_ble_gw: Device found: 38:31:AC:02:50:0D (public)
[00:00:05.892,700] <err> lte_ble_gw: Connection to peer failed!
[00:00:06.070,343] <inf> lte_ble_gw: Connected: 38:31:AC:02:50:0D (public)
[00:00:06.271,514] <inf> lte_ble_gw: MTU exchange done

[Thabet]

After some time working on the code I managed to evolve a little... The errors mentioned were not resolved, but even with them I was able to send data to the peripheral, filtering by address!

But I couldn't use the function you created "ble_data_sent", it is not implemented right? Now using the ble_send_data function I managed to send the data, but when my peripheral responds I can't get the data and it goes into an infinite loop, although the peripheral only sent the data once, it seems that the on_ble_received function is called at fixed intervals indefinitely.

[00:00:06.102,966] <inf> lte_ble_gw: Device found: 38:31:AC:02:50:0D (public)
[00:00:06.117,919] <inf> lte_ble_gw: Device found: 38:31:AC:02:50:0D (public)
[00:00:06.117,919] <err> lte_ble_gw: Connection to peer failed!
[00:00:06.291,320] <inf> lte_ble_gw: Connected: 38:31:AC:02:50:0D (public)
[00:00:06.492,492] <inf> lte_ble_gw: MTU exchange done
[00:00:07.642,395] <inf> lte_ble_gw: Service discovery completed
[00:00:07.642,578] <inf> lte_ble_gw: Enviar dado
[00:00:07.844,848] <inf> lte_ble_gw: Data received (3 bytes):
[00:00:07.944,854] <inf> lte_ble_gw: Data received (3 bytes):
[00:00:08.044,799] <inf> lte_ble_gw: Data received (3 bytes):
[00:00:08.144,866] <inf> lte_ble_gw: Data received (3 bytes):
[00:00:08.244,842] <inf> lte_ble_gw: Data received (3 bytes):
[00:00:08.344,879] <inf> lte_ble_gw: Data received (3 bytes):
[00:00:08.444,885] <inf> lte_ble_gw: Data received (3 bytes):
[00:00:08.544,891] <inf> lte_ble_gw: Data received (3 bytes):
[00:00:08.644,866] <inf> lte_ble_gw: Data received (3 bytes):
[00:00:08.744,934] <inf> lte_ble_gw: Data received (3 bytes):

[ovrebekk]

Hi 

The ble_send_data(..) function is implemented, yes, but I recommend only calling it from a thread or work item, not from an interrupt. 

The way my example is set up it will send the string "Packet received!" as a response every time it receives a packet from the connected peripheral. If you connect using a standard peripheral_uart device all you need to do is to wait for the devices to connect, send anything from the peripheral side (remember to press enter at the end of your message), and see if the "Packet received!" message appears on the peripheral_uart side. Are you saying this will not work?

Best regards
Torbjørn

[Thabet]

Hi ovrebekk ,

ovrebekk said:

The ble_send_data(..) function is implemented, yes, but I recommend only calling it from a thread or work item, not from an interrupt. 

Yes this function is implemented, I'm using it! The ble_data_sent function is not there, I think there was just confusion when indicating the function.

ovrebekk said:

The way my example is set up it will send the string "Packet received!" as a response every time it receives a packet from the connected peripheral. If you connect using a standard peripheral_uart device all you need to do is to wait for the devices to connect, send anything from the peripheral side (remember to press enter at the end of your message), and see if the "Packet received!" message appears on the peripheral_uart side. Are you saying this will not work?

That's not what I meant, actually I'm not using the peripheral and I'm not interested in using it, my peripheral is a custom hardware, a sensor. My interest is only in the central, but from your description I found that the loop that was occurring in the notify, was due to the return of the central to the peripheral, programmed in this example that you built. I managed to remove it.

The only thing I really wanted to report is that the behavior of this example is the same as my previous example regarding the scan, as it finds the same device twice, and tries to connect twice too, with one failing and another working. I had thought this was a bug in my firmware, but I realized that it also occurs in the example. Is this expected see below?

[00:00:01.482,421] <inf> lte_ble_gw: Scanning...
[00:00:01.514,556] <inf> lte_ble_gw: Device found: C1:47:F5:93:8A:D6 (random)
[00:00:01.528,350] <inf> lte_ble_gw: Device found: C1:47:F5:93:8A:D6 (random)
[00:00:01.528,381] <err> lte_ble_gw: Connection to peer failed!
[00:00:01.613,647] <inf> lte_ble_gw: Connected: C1:47:F5:93:8A:D6 (random)
[00:00:01.814,727] <inf> lte_ble_gw: MTU exchange done
[00:00:02.764,709] <inf> lte_ble_gw: Service discovery completed

My current doubt is referring to sending bytes with 0 on the left, for example when I send 0x02, the peripheral receives only 2, but when I send 0x12, the peripheral receives 12. I always have the 0 on the left ignored. I'm sending this as below:

    uint8_t send[1];
	
	send[0] = 0x02;
	
	uint16_t sizeofsend = (uint16_t)sizeof(send);

	ble_send_data(&send, sizeofsend);

Thank you.

[ovrebekk]

Hi

Yes, my plan was just to provide a basic example that you could modify as needed. 

Thabet said:

I had thought this was a bug in my firmware, but I realized that it also occurs in the example. Is this expected see below?

That is interesting, I don't see this issue on my end. Does this happen consistently every time, or only once in a while?

Can you confirm that you are running a standard nRF52840DK running the peripheral_uart sample on the peripheral side?

Thabet said:

My current doubt is referring to sending bytes with 0 on the left, for example when I send 0x02, the peripheral receives only 2, but when I send 0x12, the peripheral receives 12. I always have the 0 on the left ignored.

This is just down to how you display the number. 0x02, 0x2 and 2 is exactly the same value, only displayed in different ways. 

Best regards
Torbjørn

[Thabet]

Hi,

ovrebekk said:

That is interesting, I don't see this issue on my end. Does this happen consistently every time, or only once in a while?

Can you confirm that you are running a standard nRF52840DK running the peripheral_uart sample on the peripheral side?

This happens every time without exception, I can confirm that I am running the peripheral_uart sample without any modification, using an nRF52840, however I am not using Nordic's DK, but ublox's EVK-NINA-B302!

I can observe this behavior on both my custom hardware and EVK.

ovrebekk said:

This is just down to how you display the number. 0x02, 0x2 and 2 is exactly the same value, only displayed in different ways. 

My problem is not related to the display but to the sending of commands. Because the peripheral needs to receive 02 to respond properly to me, and when it receives only 2 it is identified as an invalid command, this is easily proven through the nRF Connect application. The leading 0's are being ignored on submission, that's the point!

[ovrebekk]

Hi 

Thabet said:

I can observe this behavior on both my custom hardware and EVK.

You don't have an nRF52840DK to test with I assume?

Would you be able to capture a Bluetooth sniffer trace when this issue occurs? 
If you have access to an nRF52840 dongle or DK you can use the free Nordic sniffer, described here.

Thabet said:

The leading 0's are being ignored on submission, that's the point!

My bad, I thought you were assigning 02 to a variable, converting that to a number, and sending it. If I understand you correctly you are basically trying to send the string "02" ?

If the leading 0's are somehow being ignored that sounds like a problem with the string assignment/conversion. Can you share the code where you create the TX string?

Best regards
Torbjørn 

[Thabet]

Hello ovrebekk ,

I ended up not implementing the sniffer, but I found that it was only getting 2 instead of 02 from what the peripheral was getting.

I'm not sending a string but a uint8_t which is what the ble_send_data function expects to receive. I got around this problem by sending 2 bytes, 0x0 and 0x2 later, like below:

	uint8_t send[2];
	
	send[0] = 0x0;

	send[1] = 0x2;

	uint16_t sizeofsend = (uint16_t)sizeof(send);

	ble_send_data(&send, sizeofsend);

Sorry for the delay, I just got back to work on this code today. I'm going to implement the sending part to our cloud through LTE and if there are more doubts I'll send them here, if not I'll check your answer that gave me the base code!

Thank you very much.