BLE UART

[Pradeep_kshemin]

We have an NRF52833 connected to the host board(runs LINUX) through UART can anyone help us with the code that goes in the NRF module that can make it work as a transceiver module(just like BLE adaptor) like sending data received from BLE to UART and data received from the host board to BLE

The final solution we are looking for is as follows: Using python on the host board we should be able to use NRF as a BLE adaptor and connect to BLE devices like sensors and receive data from them. All the connection and scanning and reading data code should be controlled or written in python and NRF should act like a transceiver module 

Can it be done? or are we looking in the wrong direction? 

[Einar Thorsrud]

Hi,

There are several possible approaches here, which is best depends on your use case.

1. You can use Bluetooth: HCI UART on the nRF device to run the Bluetooth controller there, and use HCI over UART. On the LInux side, use BlueZ as the Bluetooth host layer. This way the nRF will seem like a generic Bluetooth dongle from Linux and you can use it with standard Bluetooth APIs. This will only work with hosts that support HCI, so Linux, but not Windows or Mac, for instance.

2. You can also use the Bluetooth shell form zephyr/tests/bluetooth/shell/ on the nRF, and interact with it from a script that sends shell commands and parse the output.

[Pradeep_kshemin]

Option 1 looks fine as we are using Linux. 

To implement it: 

1) for Bluez we can use pybluez - https://github.com/pybluez/pybluez

2) " HCI UART on the nRF device to run the Bluetooth controller "- Can you suggest an example code to start with? 

[Pradeep_kshemin]

we tried with the hciattach command you have given 

Our setup -> Nvidia Jetson nano dev kit -- NRF52dk 

1) hciattach outputs -> Device setup complete

2) btmon output

3) hciconfig command shows UART device with address 00:00:00:00:00 but its DOWN
4)sudo hciconfig hci0 up gives timeout error



NOTE: as u asked us to test the UART first we tested it with a UART echo bot it worked anything I type on nrf UART can be in the jetson UART serial monitor 
https://docs.zephyrproject.org/3.1.0/samples/drivers/uart/echo_bot/README.html

Few questions 

1) Instead of nrf connect sdk sample we are using the zephyr hci_uart sample is that okay?
https://docs.zephyrproject.org/2.7.0/samples/bluetooth/hci_uart/README.html

2) can you confirm after hciattach , hciconfig shows an hci device with MTU 0.0 because we read that MTU should not be 0.0?

3) if you are loading HCI UART sample how are you using /dev/ttyACM2 (this is for USB devices) are you using FTDI converter ?

4)we are using /dev/ttyTHS1 as per jetson UART1. can you give us a way to check what device to select for hciattach because dmesg in Linux shows nothing about a new device connected via GPIO pins I think we are attaching the wrong serial device. 

[Einar Thorsrud]

Hi,

Pradeep_kshemin said:

1) Instead of nrf connect sdk sample we are using the zephyr hci_uart sample is that okay?
https://docs.zephyrproject.org/2.7.0/samples/bluetooth/hci_uart/README.html

Yes, this is the right one and the one I use, and the one I use. But use it from the nRF Connect SDK, of which Zephyr is a part. What I tested and that worked for me was the Zephyr HCI UART sample included in nRF Connect SDK 2.3.0 (under zephyr/samples/bluetooth/hci_uart/).

Pradeep_kshemin said:

2) can you confirm after hciattach , hciconfig shows an hci device with MTU 0.0 because we read that MTU should not be 0.0?

I did not spot that in your screenshot, but you are right, that is yet another indication of an issue with your setup. On my end, I have this:

eith@eith-linux:~$ hciconfig
hci1:	Type: Primary  Bus: UART
	BD Address: 00:00:00:00:00:00  ACL MTU: 27:3  SCO MTU: 0:0
	UP RUNNING 
	RX bytes:552 acl:0 sco:0 events:44 errors:0
	TX bytes:274 acl:0 sco:0 commands:44 errors:0

Pradeep_kshemin said:

3) if you are loading HCI UART sample how are you using /dev/ttyACM2 (this is for USB devices) are you using FTDI converter ?

Yes, you are right. I don't have a serial port on my computer. I am using the onboard debugger on a DK as a USB-UART bridge.

Pradeep_kshemin said:

4)we are using /dev/ttyTHS1 as per jetson UART1. can you give us a way to check what device to select for hciattach because dmesg in Linux shows nothing about a new device connected via GPIO pins I think we are attaching the wrong serial device. 

That seems likely. Unlike with USB, there is no automatic detection of a device being connected to the serial pins, so you nee to know which it is connected to. I am not able to help you with that other than to suggest that you attempt to communicate with the nRF over UART in another way to ensure that you have the right serial port. Perhaps test a UART example on the device to see that you can write and get characters echoed back. Then you will know that the bi-directional communication is working, and also that you have the right device. You write that you did this though, so I assume that is good and that this was also with the same /dev/tty/*? If not, make sure you use the one you tested and found working.

[Pradeep_kshemin]

from your reply -> Yes, you are right. I don't have a serial port on my computer. I am using the onboard debugger on a DK as a USB-UART bridge.

we also did the same thing, loaded the hci_uart sample onto the DK and connected to our Linux computer 
using DK USB_UART bridge. It worked i got the MTU as 27.7 and was able to scan and connect using bluetoothctl

Now if it works with USB-UART bridge why it fails with jumper wires on TX(P0.06) and RX(P0.08) pins connected to our jetson UART pins (cross-connection rx-tx and tx-rx).

we thought our jumper wires are damaged but no we replaced them with a new set of wires many times still haciattach doesn't give an MTU reading to start with its always 0.0

can you tell us a way to change the tx rx pins of nrf in zephyr to make sure if the pins 6 and 8 are damaged for some reason?

our current overlay file is 

&uart0 {

    compatible = "nordic,nrf-uarte";

    current-speed = <1000000>;

    status = "okay";

    hw-flow-control;

};

[Einar Thorsrud]

Hi,

I see you have HW flow control enabled for uart0 in your overlay. Is that intentional? If so, you must connect the HW flow control pins to the serial port on the computer as well, and that must be configured to use flow control. To change UART pins etc you can create an overlay where you change the pinctrl configuration. See an example here.

[Pradeep_kshemin]

that is not intentional we directly loaded the sample, can we disable HW flow control and test the whole setup? 

[Pradeep_kshemin]

with flow control turned on we connected RTS CTS pins to jetson RTS CTS pins and ran hciattach.
1) a device can be found in hciconfig with MTU 27.7
2) it was DOWN we used btmgmt to set static-address
3) ran power on command successfully 
4) now hciconfig shows a device UP and running with MTU 27.7

but scanning in btmgmt is not working and also bluetoothctl cannot see any controller when we type SHOW or LIST

I think we are almost there and one step away from getting it fully working  

[Einar Thorsrud]

Hi,

I am glad to hear you have made progress. As you see the device up from hciconfig and got it working on the same Linux device with a USB-UART bridge all the basics should be in place, so I do unfortunately not have any specific suggestions at the moment.

Can you share what you have from bluetoothctl with show (though I understand it does not list any controllers) and hciconfig?