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]

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.

[ovrebekk]

Hi 

If you are just using an uint8_t then I stand by my earlier answer: There is no difference between 02 and 2 in a uint8_t. They will both get the binary value 00000010. 

The difference must be down to how you interpret the result on the other side. 

To illustrate this you could always check the result of the variable in the debugger (after writing 02 or 2), or run a test like this:

uint8_t a = 2, b = 0x02;
if(a != b) 
{
    // If this code runs, something is seriously wrong.... 
}

Regardless, good to hear that you found a workaround

If you have some other issue in the future I would suggest opening a new ticket, unless the issue is closely related to what we have already discussed. 

Best regards
Torbjørn