bluetooth 5 TCP application stream between nrf52840 DK and nrf52840 Dongle on debian stretch


I'm developing an application with the following hardware and software design components:

- nrf52840 DK with attached sensor

- nrf52840 USB dongle attached to debian stretch (i86 now, soon to be raspberry pi) platform

- Zephyr development environment for nrf52840 platforms (working well!)

-Need to implement application-level TCP stream between linux app and sensor readout code on nrf52840 DK

- hopefully run Bluetooth 5 (as opposed to ble 4.2)

Rather than jump into the particular problems I'm having, it might be worth asking what approach is best.

I assume that using IPSP over IPV6 is the right path to take.  I have built and run a Zephyr IPSP sample

test on the DK and can see it listening for a connection.  On the linux end, I have installed the dongle and

played a bit with nrfConnect.  The device shows up and can be downloaded - and can connect to the

DK nrf52 using the one of the nrfConnect programs.  So I can download (some) firmware and find the

far end nrf52.

However, when I try to finish the linux setup for IPSP, bluetoothctl does not find a bluetooth capable device.

I discovered that I need to load HCI-capable firmware into the dongle...fine.  One of the earlier notes on the

process described building and loading the Zepher HCI-USB sample code for this purpose.  Since the dongle

board is  supported in Zephyr (nrf52840_pca10059), I built the hex image and tried to load it using nrfConnect.

NrfConnect can access both the file and dongle; but will not load the firmware because it apparently starts at

address 0 (?).  Since image addresses are usually dictated by the board support config files, I assumed that

was taken care of in the board support files.  Am I missing something here?

Also, is there a path to accomplish what I'm after by using the softdevice (140 ?) driver.  I've read that the HCI

interface is not exposed, but as long as I can get a TCP socket, I don't really need to see that.

Looking for the cleanest implementation path with the fewest moving parts possible.


Chuck McP