Bluetooth Stack (was NRF52)

[patacongo]

On Wednesday, March 28, 2018 at 1:13:36 PM UTC-6, Alan Carvalho de Assis wrote: 

Thank you very much!

I'm looking at the branch you created, it is getting good shape.

The Bluetooth stack now compiles with no errors or warnings.  I brought the stack into the master because it is conditioned on CONFIG_EXPERIMENTAL so I think it is save.  This is the commit:

commit accef0ca9e96ced73ebe3e141975993edb52d42e

Author: Gregory Nutt <gn...@nuttx.org>
Date:   Thu Mar 29 12:35:41 2018 -0600

    This commit brings in the Bluetooth stack from the Intel/Zephyr arduino101_firmware_source-v1.tar package.

    NOTE: This selection is marked EXPERIMENTAL.  It is incomplete and, hence, untested.  It still lacks any low-level Bluetooth drivers and is missing the network interface driver.

    Squashed commit of the following: .. (lots omitted)

 

What do you suggest?  Maybe we need to test it using the same external
bluetooth chip that was used on Intel's Arduino board.

What chip is that?  Is it available on shield or some other module?  There is only one Bluetooth low-level driver.  It is a simple serial interface that, apparently, supports BLE over serial.

In the Intel tarball, there is a test case that could also be used.  This is not something that will ever come upstream, although I do plan to use it to help design the network interface.  Here is what I need to do for the complete job:

- Port the aforementioned BLE serial driver (using the Intel driver)

- Develop a Bluetooth network drivers (using the Intel sample app for guidelines)

- Develop a PF_BLUETOOTH socket family for transfer raw packets.

- Develop a Bluetooth loopback driver to test the PF_BLUETOOTH family

- There will also need to be some kind of application in apps/wireless/Bluetooth to scan and pair with a device.  But I am past my level of knowledge of what is required here.

That is as far as I am thinking now, but also eventually:

- Tie the 6LoWPAN stack into Bluetooth.

Please, anyone interested, jump in an contribute.  There is more than I can do well here.

Greg

[patacongo]

What do you suggest?  Maybe we need to test it using the same external
bluetooth chip that was used on Intel's Arduino board.

What chip is that?  Is it available on shield or some other module?  There is only one Bluetooth low-level driver.  It is a simple serial interface that, apparently, supports BLE over serial.

It looks like the Arduino 101 uses a Nordic Semi nRF51 from Bluetooth.  Further, the nRF51 has to be flashed with custom firmware.  I don't think that is a direction that I would like to go.  Sounds like a Rabbit hole. http://docs.zephyrproject.org/boards/x86/arduino_101/doc/board.html

[Lwazi]

The serial interface used here is documented under the UART Transport Layer, in the Bluetooth core spec. You can talk to a powered/enabled module through a standard serial driver with RTS-CTS flow control enabled. I have used a fork of this stack with BCM4330 (on MIPS Creator CI20), TiWI-BLE (on the Pandaboard ES), and the TI BOOST-CC2564MODA.

[patacongo]

The serial interface used here is documented under the UART Transport Layer, in the Bluetooth core spec. You can talk to a powered/enabled module through a standard serial driver with RTS-CTS flow control enabled. I have used a fork of this stack with BCM4330 (on MIPS Creator CI20), TiWI-BLE (on the Pandaboard ES), and the TI BOOST-CC2564MODA.

It is good to know that someone out there is familiar with it.  I am struggling with the basics.  It would be great to have an example that scans, pairs, and exchanges a few packets.  Do you know of any such thing?  The data exchange is the most opaque to me.  It appears that you have to setup a callback so that when data is received on a channel, you can receive that data.

My goal is to integrate this with the network so that this would all be reduced to a socket() and sendto() and recvfrom() calls.  I am developing the AF_BLUETOOTH sockets on the afbluetooth branch now but, as I said, I am struggling.

Greg

[Brennan Ashton]

I do not know of any Bluetooth chip that does not need a firmware ram patch applied. Most of them have a M0 or similar processor that runs the Link Manager and provides the HCI interface. Usually you upload a firmware patch over that interface to fix errata or enable more features. This is the way all CSR Broadcom/Cypress, TI, and Red Pine modules work.  If we don't want to support these blobs the value of working on this Bluetooth stack really goes down. 

Also Linux just made a big change on what the underlying device looks like to help attach gpio resources to some serial devices for things like power management and reset pins. It made the driver code so much cleaner. 

http://events17.linuxfoundation.org/sites/events/files/slides/serdev-elce-2017-2.pdf

--Brennan

[Lwazi]

I just went to look at the NetBSD stack and they seem to support AF_BLUETOOTH. I am not sure if they do BLE but maybe you can find inspiration in their stack. Are hci_socket.c, l2cap_socket.c doing what you want to do? Click the revision number to see the file contents.

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netbt/?only_with_tag=MAIN

Lwazi

[Brennan Ashton]

I would highly recommend getting the raw hci socket going first. On of the major advantages of this is it makes debugging the rest of the stack a lot easier. The last time I did this I wrote a small shim to pipe the HCI traffic over tcp so that I could parse it with btmon from bluez on another host and clearly see a human readable trace of what is going on. 

[patacongo]

 

I would highly recommend getting the raw hci socket going first. On of the major advantages of this is it makes debugging the rest of the stack a lot easier. The last time I did this I wrote a small shim to pipe the HCI traffic over tcp so that I could parse it with btmon from bluez on another host and clearly see a human readable trace of what is going on. 

The Bluetooth stack that I am porting does not currently support getting frames directly from the HCI layer so supporting  BTPROTO_HCI would require a little more design.  I think that would not be too difficult to do, but would probably defeat of the purpose of trying to get a stable, simple raw HCI socket interface going first. Only BTPROTO_L2CAP is more-or-less in place and is probably the most mature data path.

By the way, good to see your name pop up in the group.  It has been awhile!

Greg

[Brennan Ashton]

It has been a while. But you peaked my interest with the Bluetooth stuff.  I have been working on Bluetooth mesh technology for the last two years which took my time away from building stuff with Nuttx. I have been lurking all along. 

I have a few of these around, so I was thinking if time allows I might try and start bringing it up. It's a nice package with a bunch of sensors Bluetooth 5 and rfid. 

https://www.nordicsemi.com/eng/Products/Nordic-Thingy-52

--Brennan

[patacongo]

By the way, good to see your name pop up in the group.  It has been awhile!

It has been a while. But you peaked my interest with the Bluetooth stuff.  I have been working on Bluetooth mesh technology for the last two years which took my time away from building stuff with Nuttx. I have been lurking all along. 

I appreciate your comments.  Thanks for keeping me honest.  I knew nothing of consequence about Bluetooth when I started this.  The BSD licensed stack was pointed out to me and I thought it worth porting.  But Bluetooth has been pure OJT for me.  I am sure I will get a few things wrong.

That is part of the nature of developing an OS:  You have to know a little but about a lot of things, but not very much about most things.

Some things are still confusing me.  Like, for example, there appears to be two connections between each master and slave.  A public interface and a random (encrypted) interface.  So it is not clear to me how the socket layer knows which interface is should use.  Should this be a part of the sockaddr structure?

But then it is not even clear to me yet how the radio reports its own address.  I suppose this is part of all of those attributes that I have not yet dug into.  I will need to.

I have a few of these around, so I was thinking if time allows I might try and start bringing it up. It's a nice package with a bunch of sensors Bluetooth 5 and rfid. 

https://www.nordicsemi.com/eng/Products/Nordic-Thingy-52

Janne just contributed the NRF52xx support.  So I presume that it is working although it is still a little sparse.

Greg

 

--Brennan

[Brennan Ashton]

I appreciate your comments.  Thanks for keeping me honest.  I knew nothing of consequence about Bluetooth when I started this.  The BSD licensed stack was pointed out to me and I thought it worth porting.  But Bluetooth has been pure OJT for me.  I am sure I will get a few things wrong.

That is part of the nature of developing an OS:  You have to know a little but about a lot of things, but not very much about most things.

Some things are still confusing me.  Like, for example, there appears to be two connections between each master and slave.  A public interface and a random (encrypted) interface.  So it is not clear to me how the socket layer knows which interface is should use.  Should this be a part of the sockaddr structure?

I'm not clear what you are talking about for the public/random interface?  Are you talking about the addresses?

Are you asking how you know the address of the source device to supply to the socket addr?  What I usually see is people just supporting the first bluetooth adapter, in which case they just supply BDADDR_ANY as the src.  Otherwise you open a HCI socket on the device ID and then use that to get the device address.

Linux provides some helper functions that just wrap this

int hci_devinfo(int dev_id, struct hci_dev_info *di)

really just opens an HCI socket on dev_id and the uses the IOCTL HCIGETDEVINFO to return 

struct hci_dev_info {

__u16 dev_id;

char  name[8];

bdaddr_t bdaddr;

__u32 flags;

__u8  type;

__u8  features[8];

__u32 pkt_type;

__u32 link_policy;

__u32 link_mode;

__u16 acl_mtu;

__u16 acl_pkts;

__u16 sco_mtu;

__u16 sco_pkts;

struct hci_dev_stats stat;

};

There are other IOCTL that provides control over things like the Authentication, Encryption, MTU sizes, Scanning, and more.

High level look would be something like this:

http://people.csail.mit.edu/albert/bluez-intro/c404.html

 

note under any hci_ command is really just a HCI socket, so it is not really user space calling down into kernel internals.

[patacongo]

 Hi, Lwazi,

The serial interface used here is documented under the UART Transport Layer, in the Bluetooth core spec. You can talk to a powered/enabled module through a standard serial driver with RTS-CTS flow control enabled. I have used a fork of this stack with BCM4330 (on MIPS Creator CI20), TiWI-BLE (on the Pandaboard ES), and the TI BOOST-CC2564MODA.

I wrote a little dummy device for testing a made a little progress.  But I think I am going to have get some real hardware.  I see you mentioned some parts there.

Living in Costa Rica, my options for hardware are very limited locally.  I was able to get one of these and should have it by this afternoon:  ftp://imall.iteadstudio.com/IM120417010_BT_Shield_v2.2/DS_IM120417010_BTShield.pdf  It is based on an HC-05.

Will that work with BLE stack?  It appears to be okay.  It comes up in Data vs. AT mode, so I hope that means in "UART Transport Layer" mode.  Is that your understanding?

Otherwise, there will be some weeks to get parts here.

Thanks in advance,

Greg

 

[Lwazi]

It doesn't look like it will work. The Bluetooth 2.0 means there is no BLE. I am still reading.

Lwazi

[patacongo]

Living in Costa Rica, my options for hardware are very limited locally.  I was able to get one of these and should have it by this afternoon:  ftp://imall.iteadstudio.com/IM120417010_BT_Shield_v2.2/DS_IM120417010_BTShield.pdf  It is based on an HC-05.

Will that work with BLE stack?  It appears to be okay.  It comes up in Data vs. AT mode, so I hope that means in "UART Transport Layer" mode.  Is that your understanding?

It doesn't look like it will work. The Bluetooth 2.0 means there is no BLE. I am still reading.

Shows my ignorance!  I pay my ignorance with a few dollars and more useless hardware on the shelf.

Can you recommend a module, preferable an Shield, that I would be successful testing with?

Thanks in advance,

Greg

[patacongo]

The serial interface used here is documented under the UART Transport Layer, in the Bluetooth core spec. You can talk to a powered/enabled module through a standard serial driver with RTS-CTS flow control enabled. I have used a fork of this stack with BCM4330 (on MIPS Creator CI20), TiWI-BLE (on the Pandaboard ES), and the TI BOOST-CC2564MODA.

How about this one?  https://www.ebay.com/itm/Jinou-Bluetooth-4-1-Dual-Mode-Module-BLE-EDR-Serial-Module-TI-CC2564-Chip-New

That is a CC2564.  So that should work.  Is there any special FLASH configuration that has to be done on that part?

[Brennan Ashton]

Greg,

My plan (and I am going to need a week at least before I can start to jump on it), is to really get the HCI host part going if I can.  Partially because a lot of external modules support that as the full control interface.   These are usually over UART, SPI, or USB.  I really have only interest in the UART part.   The protocol is usually H4 or H3 (Three wire), some companies like TI add a slight tweak to the H4/3 protocol, but it is fairly standard.

I am not that interested right now in the Controller part of the Bluetooth stack (Zephyr supports two modes Host OR Controller).

I want to be very clear that what I am proposing next is not intended to be part of Nuttx, but rather assist in developing the host stack.  Two platforms I have a lot of are the ESP32 and the nRF52.  ESP32 can be built to expose a virtual HCI interface over UART via their IDF stuff.  Zephyr can also build the nRF52 with a HCI UART.   I do not see this as being part of Nuttx, although I will try and document was I do here.    This is just to get me a few easy to work with modules (including Bluetooth 5.0).

With these I would like to connect them to a Nuttx board or even the simulator, so that I can focus on the host side that actually interests me.

--Brennan

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lwazi]

This one looks like it needs some soldering but it should work. NuttX needs to send (matching) firmware patches (total 7000bytes) to the CC2564 module before using the stack.

[patacongo]

Actually, the TI BOOST-CC2564MODA is about the same price and is a complete solution for one endpoint.

But before I go that way, I need to make some additional decisions.  In order to do any live testing, I would need to have both a Master and a Slave endpoint.  I would be nice to just have someone BLE slave of opportunity and use that to verify the master only.

The BLE stack I am porting does support both slave and master (although is hardcoded only for master now.  A new interface would have to be created to bring up the slave).  But now I am thinking that this would all be more effort than I am willing to undertake.

Do you know of a good BLE slave device that would support basic testing of the master?  I am thinking that I should purchase one TI BOOST-CC2564MODA and some kind of test slave.  Any recommendations?

Greg

[Lwazi]

You could use an app to turn your phone/tablet into a beacon.

Before you get the BOOST-CC2564MODA take a look at the firmware patch license below:


TEXAS INSTRUMENTS TEXT FILE LICENSE
 
 
Copyright (c) 2008 – 2013 Texas Instruments Incorporated
 
All rights reserved not granted herein.
 
Limited License.  
 
Texas Instruments Incorporated grants a world-wide, royalty-free, non-exclusive 
license under copyrights and patents it now or hereafter owns or controls to make, 
have made, use, import, offer to sell and sell ("Utilize") this software subject 
to the terms herein.  With respect to the foregoing patent license, such license 
is granted solely to the extent that any such patent is necessary to Utilize the 
software alone.  The patent license shall not apply to any combinations which 
include this software, other than combinations with devices manufactured by or 
for TI (“TI Devices”).  No hardware patent is licensed hereunder.
 
Redistributions must preserve existing copyright notices and reproduce this license
(including the above copyright notice and the disclaimer and (if applicable) source 
code license limitations below) in the documentation and/or other materials provided 
with the distribution
 
Redistribution and use in binary form, without modification, are permitted provided 
that the following conditions are met:
 
*   No reverse engineering, decompilation, or disassembly of this software is permitted 
    with respect to any software provided in binary form.
 
*   any redistribution and use are licensed by TI for use only with TI Devices.
 
*   Nothing shall obligate TI to provide you with source code for the software 
    licensed and provided to you in object code.
 
If software source code is provided to you, modification and redistribution of the 
source code are permitted provided that the following conditions are met:
 
*   any redistribution and use of the source code, including any resulting 
    derivative works, are licensed by TI for use only with TI Devices.
 
*   any redistribution and use of any object code compiled from the source 
    code and any resulting derivative works, are licensed by TI for use only 
    with TI Devices.
 
Neither the name of Texas Instruments Incorporated nor the names of its suppliers 
may be used to endorse or promote products derived from this software without specific 
prior written permission.
 
DISCLAIMER.
 
THIS SOFTWARE IS PROVIDED BY TI AND TI’S LICENSORS "AS IS" AND ANY EXPRESS 
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES 
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN 
NO EVENT SHALL TI AND TI’S LICENSORS BE LIABLE FOR ANY DIRECT, INDIRECT, 
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY 
OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, 
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

[Lwazi]

On Thursday, 5 April 2018 15:47:57 UTC-4, patacongo wrote:

You could use an app to turn your phone/tablet into a beacon.

Before you get the module, take a look at the firmware license.

[patacongo]

Hi, Lwazi,

I still have not decided on a test platform.  This is turning out to be a difficult decision.  I am not ruling out the TI BOOST-CC2564MODA.

When you mention the 7Kb file to be downloaded, you are talking about these InitScripts/Service packs, right?  http://www.ti.com/tool/cc256xb-bt-sp

Before you get the BOOST-CC2564MODA take a look at the firmware patch license below:

Does this license really apply to the services packs.  I see no license restrictions with regard to the service packs.  But I am probably missing something.

Greg

[Lwazi]

You are asked to start by reading the license.
See the description on the CC256XC page http://www.ti.com/tool/cc256xc-bt-sp

[Alan Carvalho de Assis]

Hi Lwazi,

I'm trying to get HCI BLE working on nRF52832 to let Mr. Greg to test
the BLE stack.

I don't have the PCA10040 neither the nRF52-DK, but a low cost module,
this model:

https://www.ebay.com/itm/nRF52832-Bluetooth-4-1-BLE-Module-M4-Transparent-Transmission-CORTEX-M4-512KB-/332270581440

I tested using the Zephyr's uart-hci:

https://devzone.nordicsemi.com/b/blog/posts/nrf5x-support-within-the-zephyr-project-rtos

And with Mynewt's blehci:

http://mynewt.apache.org/os/tutorials/blehci_project/

None of these firmware worked on my nRF52832 module.

I connected the USB/Serial to this module this way:

nRF52 Module | USB/Serial PC
P0.5 (RTS) -> CTS
P0.6 (TXD) -> RXD
P0.7 (CTS) -> RTS
P0.8 (RXD) -> TXD

If someone here has the PCA10040 or nRF52-DK board and want to test I
can send my firmware, just to confirm it works.

BR,

Alan

[patacongo]

Just to close the loop.  Sorry to be such a nuisance on this one, but ordering the wrong hardware from Costa Rica is kind of a disaster.  After the best my research I ordered at BT860 HIC UART module (DVK-BT860-SA).  From my reading this should do the job quite nicely.  I also ordered a DFRobot TEL0085 iBeacon that should give me something to work with.  Thanks for helping me out.

This morning, I committed a custom HCI UART driver for the STM32.  It is basically just a variant of the standard serial TTY driver, with customized interfaces to support the HCI UART device and is optimized for packet transfers. 

[patacongo]

I have made a little progress with the Bluetooth LE stack.  I want to report that status (as part of the happy dance you always have to do after some success) and ask if anyone really knowledge-able has any insight or advice.

I am testing using a BT860 HCI UART (actually the DVK-BT860-SK with no antenna yet... I meant to order the SA with a PBC antenna).  That part was possibly not the best selection because it is a Broadcom part that fell into SiLabs lab (but with the Bluetooth software going to Lenovo?).  So, of course none of the documentation is where the links say you will find it.

I am testing using the STM32F4-Discovery with the hciuart configuration.  That configuration supports the Bluetooth tool at apps/wireless/Bluetooth/btsak.  That application uses AF_BLUETOOTH raw packets with the L2CAP protocol.

Below is the output.  Here are a couple questions/observations:

1. Is bnep0 an appropriate name for the an Bluetooth network device.  When accessed by the network, Bluetooth devices will need to have a network name (such as eth0 for Ethernet and wpan0 for IEEE 802.15.4, etc.).  I could not find the definitive naming of Bluetooth devices but I did see some reference to bnep0 devices.  But I think that is not what I want.

2. As you an see, even the scan works!  I have only my Bluetooth speakers in my office and the scan apparently finds those speakers multiple times (there is a command option to suppress duplicates but I did not select it).  The question is in the name of the device:  I consistently see öïrBÔصù0 but the rest of the scan data seems plausible.  Everything else seems consistent (the RSSI is very high because the BT860 is right over the speakers and can't missing the speakers.. even with no antenna).

Greg

NuttShell (NSH) NuttX-7.24
nsh> help
help usage:  help [-v] [<cmd>]

  [           dirname     help        mh          rmdir       umount
  ?           dd          hexdump     mount       set         unset
  basename    df          kill        mv          sh          usleep
  break       echo        ls          mw          sleep       xd
  cat         exec        mb          ps          test
  cd          exit        mkdir       pwd         time
  cp          false       mkfatfs     reboot      true
  cmp         free        mkrd        rm          uname

Builtin Apps:
  bt
nsh> bt bnep0 help

Usage:

        bt <ifname> <cmd> [option [option [option...]]]

Where <cmd> [option [option [option...]]] is one of:

        help
        info            [-h]
        features        [-h] [le]
        scan            [-h] <start [-d]|get|stop>
        advertise       [-h] <start|stop>
        security        [-h] <addr> <addr-type> <level>
        gatt            [-h] <cmd> [option [option [option...]]]

Use the -h option on any command to get more info.
nsh> bt bnep0 info
Device: bnep0
BDAddr: 9f:f3:49:a4:16:00
Flags:  0000
Free:   20
  ACL:  20
  SCO:  0
Max:
  ACL:  64
  SCO:  0
MTU:
  ACL:  70
  SCO:  70
Policy: 0
Type:   0
nsh> bt bnep0 features
Page 0:
        bf fe cf fe  db ff 7b 87
Page 1:
        00 00 00 00  00 00 00 00
Page 2:
        00 00 00 00  00 00 00 00
nsh> bt bnep0 features le
Page 0:
        ff 00 00 00  00 00 00 00
Page 1:
        00 00 00 00  00 00 00 00
Page 2:
        00 00 00 00  00 00 00 00
nsh> bt bnep0 scan start
nsh> bt bnep0 scan get
Scan result:
536907628.      name:        öïrBÔصù0
        addr:           4d:0d:14:09:60:54 type: 0
        rssi:            -95
        response type:   2
        advertiser data:
                         03 03 9f fe 17 16 9f fe 02 74 70 4e 72 4f 5a 78
                         4e 4c 43 41 00 00 01 62 da 0e 68 d4
536907734.      name:        öïrBÔصù0
        addr:           4d:0d:14:09:60:54 type: 0
        rssi:            -95
        response type:   2
        advertiser data:
                         03 03 9f fe 17 16 9f fe 02 74 70 4e 72 4f 5a 78
                         4e 4c 43 41 00 00 01 62 da 0e 68 d4
536907840.      name:        öïrBÔصù0
        addr:           4d:0d:14:09:60:54 type: 0
        rssi:            -94
        response type:   2
        advertiser data:
                         03 03 9f fe 17 16 9f fe 02 74 70 4e 72 4f 5a 78
                         4e 4c 43 41 00 00 01 62 da 0e 68 d4
536907946.      name:        öïrBÔصù0
        addr:           4d:0d:14:09:60:54 type: 0
        rssi:            -99
        response type:   2
        advertiser data:
                         03 03 9f fe 17 16 9f fe 02 74 70 4e 72 4f 5a 78
                         4e 4c 43 41 00 00 01 62 da 0e 68 d4
536908052.      name:        öïrBÔصù0
        addr:           4d:0d:14:09:60:54 type: 0
        rssi:            -94
        response type:   2
        advertiser data:
                         03 03 9f fe 17 16 9f fe 02 74 70 4e 72 4f 5a 78
                         4e 4c 43 41 00 00 01 62 da 0e 68 d4
nsh> bt bnep0 scan stop
nsh>

[patacongo]

....  Here are a couple questions/observations:

1. Is bnep0 an appropriate name for the an Bluetooth network device.  When accessed by the network, Bluetooth devices will need to have a network name (such as eth0 for Ethernet and wpan0 for IEEE 802.15.4, etc.).  I could not find the definitive naming of Bluetooth devices but I did see some reference to bnep0 devices.  But I think that is not what I want.

2. As you an see, even the scan works!  I have only my Bluetooth speakers in my office and the scan apparently finds those speakers multiple times (there is a command option to suppress duplicates but I did not select it).  The question is in the name of the device:  I consistently see öïrBÔصù0 but the rest of the scan data seems plausible.  Everything else seems consistent (the RSSI is very high because the BT860 is right over the speakers and can't missing the speakers.. even with no antenna).

Well, most of that crazy device name output was due to a bad printf statement.  The following is the output when that printf is fixed and demonstrates disabling of duplicates.  Now the name is just blank... possible it is in wide characters and so is terminated too soon?

Greg

nsh> bt bnep0 scan -h
scan:  Scan commands:
Usage:

        bt <ifname> scan [-h] <start [-d]|get|stop>

Where the options do the following:

        start   - Starts scanning.  The -d option enables duplicate
                  filtering.
        get      - Shows new accumulated scan results
        stop    - Stops scanning
nsh> bt bnep0 scan start -d

nsh> bt bnep0 scan get
Scan result:

1.      name:

        addr:            4d:0d:14:09:60:54 type: 0
        rssi:            -94
        response type:   2

        advertiser data: 03 03 9f fe 17 16 9f fe 02 46 38 76 38 5f 58 49
                         61 70 72 30 00 00 01 62 da 3c 2f 94

[patacongo]

Well, I think I have done about as much testing and development of the BLE stack with my limited knowledge of Bluetooth.  A lot has been accomplished:  The port is complete and partially tested, it certainly initializes and communicates well with a BLE HCI UART.  There is a good test tool in place at apps/wireless/Bluetooth btsak.  So I have reason to believe that the port is very close to being usable.

But I don't have enough expertise to actually fully verify the port:  I don't know how to pair with the device (I understand this has something to do with GATT commands?).  I don't know how to communicate with a task running on the BLE slave device.  While a lot of testing has been done, there is no testing of this core functionality!

I believe that I will have to wait for an interested party to pick up some work here and integrate the stack into a real world environment.  If you are that party then let me know, I will help you all that I can.

Greg

[Embedded Systems]

Hello Mr. Gregory,

After I add few more drivers in the IMXRT1050 port , I will work on Bluetooth. So far i was going to use nRF52810 based module which would be connected with Imxrt via Uart, but I would be interested to test the nuttx Bluetooth stack. Can you please tell me with what kind of module would you suggest me to use for that task?

Best regards,

Ivan Ucherdzhiev

--
You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Kind regards,

Ivan Ucherdzhiev

Team Lead @ Barin Sports

Bulgaria

skype: ipy_44

tel: +359888927760

[patacongo]

After I add few more drivers in the IMXRT1050 port , I will work on Bluetooth. So far i was going to use nRF52810 based module which would be connected with Imxrt via Uart, but I would be interested to test the nuttx Bluetooth stack. Can you please tell me with what kind of module would you suggest me to use for that task?

I have been using a BT860 because it is so easy to work with.  Specifically, I have been using the DVK-BT860-ST (-SA would have been better).  Alan is just starting to look at Bluetooth using a TI CC2564 BOOST.  Be he is not so far along yet.

Greg