Date   

Re: [Zephyr-users] Introducing west, Zephyr's meta-tool

Carles Cufi
 

Hi Luiz,

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Luiz Augusto von Dentz
Sent: 28 January 2019 21:00
Subject: Re: [Zephyr-devel] [Zephyr-users] Introducing west, Zephyr's
meta-tool

Hi Carles,

How about pull request, how does west deals with them? Or it doesn't and
which case we have to deal with individual git repositories and issue
git push ourselves? This looks like repo which I never liked.
You can see that dealing with Pull Requests is listed as an unresolved issue in the description here:
https://github.com/zephyrproject-rtos/zephyr/issues/6770

There are several possibilities to deal with this, but first and since that you mention Google repo let me make an important distinction. With repo you typically (though not always) track the tip of master on multiple repositories. With west, although that is also possible, we will require specific SHAs for all repos (projects) that are not the main zephyr repo (i.e. the manifest repo).

Options we have (informally, in calls and chats) considered:
1. Send 2 PRs to the 2 repos affected (say for example zephyr + mbedtls), where the branch name used matches. Then CI running in zephyr could look at all repositories listed in the manifest and check if an outstanding PR for it exists with the same GitHub username and branch name.
2. Send the PR to the external project (mbedtls in our example) and another PR to zephyr with the manifest modified so that it points to the fork and branch name of the project's PR. When those are merged, CI could then replace the contents of the manifest with the proper SHA.
3. Introduce some sort of per-PR ChangeId that CI knows how to parse.
4. GitHub adds support for cross-repository PRs. There have been multiple hints that this is coming, but obviously we cannot know when, if ever, this feature will be available.

Note that we have not at any point considered moving away from GitHub. The plan is to adapt to what the service offers and try to find a solution that works well with it. This is also one of the reasons we are first introducing west without actually splitting the ext/ folder into multiple external repos: we want to expose users to west before we start doing more radical changes.

Ideas and feedback welcome!

Thanks,

Carles


On Mon, Jan 28, 2019 at 10:43 AM Cufi, Carles
<carles.cufi@nordicsemi.no> wrote:

Hi all,

For a few months now we have been working on a meta-tool named west,
designed to act both as a command-line tool to build, flash an debug
Zephyr-based applications and also to manage the additional Git
repositories that Zephyr will require in order to build in the near
future.

West is written in Python 3, lives in its own repository [1] and its
bootstrapper is available on PyPi [2].
As soon as we merge the topic-west [3] branch into master (which
should happen in the next few days) you will need to install west in
order to flash and debug, since those commands will rely on havig west
present as part of your Zephyr workflow.

The updated west documentation will be online in the Zephyr
documentation website [4] as soon as the topic-west branch is merged
into master. In the meantime you can also look at the unrendered
documentation sources in the topic-west branch [5] and the existing
GitHub issues [6][7].

In order to install the west boostrapper (which you can do today) run:

# On Linux
pip3 install --user west

# On macOS and Windows
pip3 install west

Once the west bootstrapper is installed and the topic-west branch is
merged into master, you will have 2 choices to get a west main
installation.

1. Clone a new copy of the zephyr repository using west:

west init zephyrproject
cd zephyrproject
west update

2. Install west around an existing local zephyr clone:

Move the cloned zephyr/ repository to an empty enclosing folder (for
example zephyrproject/zephyr/), and from this enclosing folder
zephyrproject/ run:

west init -l zephyr/
west update
The -l <path to zephyr> parameter instructs west to use an existing
local copy instead of cloning a remote repository.

Feedback and patches are welcome, but note that the feature will
likely be merged as-is since we consider we have left ample time to
raise any major issues regarding the workflow and decisions taken during
the development of west. This is however only the beginning of west's
(hopefully) long existence as the Zephyr command-line meta-tool, and it
will certainly evolve and change considerably in the future with the
help of the community.

Please submit feedback in the form of GitHub issues on the west
repository itself [1] unless it affects features or functionality in the
zephyr repository directly.

I will reply to this email once the topic-west branch is merged into
master.

Thank you to everybody who has contributed so far!

Regards,

Carles

[1] https://github.com/zephyrproject-rtos/west
[2] https://pypi.org/project/west/
[3] https://github.com/zephyrproject-rtos/zephyr/tree/topic-west
[4] https://docs.zephyrproject.org/latest/tools/west/index.html
[5]
https://github.com/zephyrproject-rtos/zephyr/tree/topic-west/doc/tools
/west [6] https://github.com/zephyrproject-rtos/zephyr/issues/6205
[7] https://github.com/zephyrproject-rtos/zephyr/issues/6770



--
Luiz Augusto von Dentz


Re: [Zephyr-users] Introducing west, Zephyr's meta-tool

Luiz Augusto von Dentz
 

Hi Carles,

How about pull request, how does west deals with them? Or it doesn't
and which case we have to deal with individual git repositories and
issue git push ourselves? This looks like repo which I never liked.

On Mon, Jan 28, 2019 at 10:43 AM Cufi, Carles <carles.cufi@nordicsemi.no> wrote:

Hi all,

For a few months now we have been working on a meta-tool named west, designed to act both as a command-line tool to build, flash an debug Zephyr-based applications and also to manage the additional Git repositories that Zephyr will require in order to build in the near future.

West is written in Python 3, lives in its own repository [1] and its bootstrapper is available on PyPi [2].
As soon as we merge the topic-west [3] branch into master (which should happen in the next few days) you will need to install west in order to flash and debug, since those commands will rely on havig west present as part of your Zephyr workflow.

The updated west documentation will be online in the Zephyr documentation website [4] as soon as the topic-west branch is merged into master. In the meantime you can also look at the unrendered documentation sources in the topic-west branch [5] and the existing GitHub issues [6][7].

In order to install the west boostrapper (which you can do today) run:

# On Linux
pip3 install --user west

# On macOS and Windows
pip3 install west

Once the west bootstrapper is installed and the topic-west branch is merged into master, you will have 2 choices to get a west main installation.

1. Clone a new copy of the zephyr repository using west:

west init zephyrproject
cd zephyrproject
west update

2. Install west around an existing local zephyr clone:

Move the cloned zephyr/ repository to an empty enclosing folder (for example zephyrproject/zephyr/), and from this enclosing folder zephyrproject/ run:

west init -l zephyr/
west update
The -l <path to zephyr> parameter instructs west to use an existing local copy instead of cloning a remote repository.

Feedback and patches are welcome, but note that the feature will likely be merged as-is since we consider we have left ample time to raise any major issues regarding the workflow and decisions taken during the development of west. This is however only the beginning of west's (hopefully) long existence as the Zephyr command-line meta-tool, and it will certainly evolve and change considerably in the future with the help of the community.

Please submit feedback in the form of GitHub issues on the west repository itself [1] unless it affects features or functionality in the zephyr repository directly.

I will reply to this email once the topic-west branch is merged into master.

Thank you to everybody who has contributed so far!

Regards,

Carles

[1] https://github.com/zephyrproject-rtos/west
[2] https://pypi.org/project/west/
[3] https://github.com/zephyrproject-rtos/zephyr/tree/topic-west
[4] https://docs.zephyrproject.org/latest/tools/west/index.html
[5] https://github.com/zephyrproject-rtos/zephyr/tree/topic-west/doc/tools/west
[6] https://github.com/zephyrproject-rtos/zephyr/issues/6205
[7] https://github.com/zephyrproject-rtos/zephyr/issues/6770


--
Luiz Augusto von Dentz


USB ECM buffer size

nicolas lantz
 

Hi,

I am working on a demo using Ethernet Over USB on the nrf52840.

In subsys/usb/class/netusb/

I saw a misalignement probleme between the :
        .wMaxSegmentSize = sys_cpu_to_le16(1514),
        declared in function_ecm.c
and the :
        #define NETUSB_MTU 1500
        declared in netusb.h

As rx_buf & tx_buf are defined with a NETUSB_MTU size, this cause that the frames over 1500 bytes can not be received and are discarded.


Secondly, as fragmentation is not supported (for UDP and TCP datagram), I suggest to increase the  NETUSB_MTU to the maximum of the possible ethernet frame size :1522

These modifications give :
    in netusb.h : #define NETUSB_MTU 1522
    in function_ecm.c : .wMaxSegmentSize = sys_cpu_to_le16(NETUSB_MTU),


Attached a patch.

--
Cordialement,
Nicolas

Nicolas LANTZ
M : +33 (0)6 19 07 43 43
T : +33 (0)9 52 96 81 86
www.ubicore.net


Re: Get RSSI in DTM(Zephyr)

Tommy Lin (林志聰) <Tommy.Lin@...>
 

Hi Vinayak,

I find a sample code in tests/Bluetooth/shell , and it can seem to test BT DTM.

It will produce an error message about SRAM overflow (log is in attachment) , when I compile it.

 

 

Could you give us some suggestions.

 

Best regards,

Tommy

From: Chettimada, Vinayak Kariappa [mailto:vinayak.kariappa.chettimada@...]
Sent: Monday, January 14, 2019 3:45 PM
To: Isaac Chen (
陳尚航) <Isaac_Chen@...>; Tommy Lin (林志聰) <Tommy.Lin@...>; zephyr-devel@...
Cc: Hanyu.Hsu@...; Rung-Sheng Lee (
李榮盛) <Rung.Sheng.Lee@...>; Brent Tsai (蔡旻其) <Brent.Tsai@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>
Subject: RE: Get RSSI in DTM(Zephyr)

 

Hi Chen,

 

1.     As I know, BLE RSSI can’t be measured in standard DTM mode. Is it possible to add new feature in DTM to support BLE RSSI measurement?

[vich] Yes, this is possible, but the command will have to be proprietary as per your test requirements.

 

2.     If the answer to the above question is “no”, I still need your confirmation if other test modes exist that can measure RSSI except DTM mode.

In our experiences of other algorithm(LTE/WCDMA…etc.), RSSI usually can be detected easily in test mode via a CW tone. So it’s why we want

to double check this.

[vich] RSSI can be easily measured in nRF5x series chips during Radio Rx mode. Implementation will have to be as per your requirement, as standard DTM mode does not define any interface for RSSI in DTM mode.

 

3.     Do you have any customers who have experiences to measure conductive RSSI in factory or in lab? If so, can you share the methodology?

[vich] Other customers may be doing so, but I am not aware of unless the implementation is submitted upstream via a PR.

 

 

Regards,

Vinayak

 

From: Isaac Chen (陳尚航) <Isaac_Chen@...>
Sent: 14 January 2019 04:08
To: Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>; Tommy Lin (
林志聰) <Tommy.Lin@...>; zephyr-devel@...
Cc: Hanyu.Hsu@...; Rung-Sheng Lee (
李榮盛) <Rung.Sheng.Lee@...>; Brent Tsai (蔡旻其) <Brent.Tsai@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>
Subject: RE: Get RSSI in DTM(Zephyr)
Importance: High

 

Hi Vinayak,

 

Our customer requested us to test conductive BLE RSSI in factory for accuracy improvement.

Could you please clarify the following questions?

1.     As I know, BLE RSSI can’t be measured in standard DTM mode. Is it possible to add new feature in DTM to support BLE RSSI measurement?

[vich] Yes, this is possible, but the command will have to be proprietary as per your test requirements.

2.     If the answer to the above question is “no”, I still need your confirmation if other test modes exist that can measure RSSI except DTM mode.

In our experiences of other algorithm(LTE/WCDMA…etc.), RSSI usually can be detected easily in test mode via a CW tone. So it’s why we want

to double check this.

[vich] RSSI can be easily measured in nRF5x series chips during Radio Rx mode. Implementation will have to be as per your requirement, as standard DTM mode does not define any interface for RSSI in DTM mode.

3.     Do you have any customers who have experiences to measure conductive RSSI in factory or in lab? If so, can you share the methodology?

[vich] Other customers may be doing so, but I am not aware of unless the implementation is submitted upstream via a PR.

 

 

Best Regards

 

Isaac Chen

Quanta Computer Inc.

Business Unit 11 BL1

Tel  : +886-3-327-2345 Ext : 17585

 

This transmission is intended only for the use of the addressed recipient and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any use of this communication is strictly prohibited. If you have received this communication in error, please kindly notify the sender and delete this message immediately. 

 

From: Chettimada, Vinayak Kariappa [mailto:vinayak.kariappa.chettimada@...]
Sent: Wednesday, January 09, 2019 8:00 PM
To: Tommy Lin (
林志聰); zephyr-devel@...
Cc: Hanyu.Hsu@...; Isaac Chen (
陳尚航); Rung-Sheng Lee (李榮盛); Brent Tsai (蔡旻其); Ryan Hsu (徐振鋒)
Subject: RE: Get RSSI in DTM

 

Hi Tommy,

 

I don’t remember if DTM mode has any RSSI command in the Specification.

 

Could you please elaborate on your requirements?

 

Regards,

Vinayak

 

From: devel@... <devel@...> On Behalf Of Tommy Lin (???)
Sent: 08 January 2019 13:25
To: zephyr-devel@...
Cc: Hanyu.Hsu@...; Isaac Chen (
陳尚航) <Isaac_Chen@...>; Rung-Sheng Lee (李榮盛) <Rung.Sheng.Lee@...>; Brent Tsai (蔡旻其) <Brent.Tsai@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>
Subject: [Zephyr-devel] Get RSSI in DTM

 

Hi ,

We have a product using nRF51824 with zephyr.

We use hci_uart sample code and follow below link , and we can get other BT device’s RSSI.

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

 

We have a question , If it is in DTM(Direct Test Mode) , how can we get RSSI?

Could you give us some suggestions.

 

Best regards,

Tommy


bond information deleted #ble

nick.ward@...
 

Hi all,
I'm developing a system with Zephyr that has been configured to have 4 Bluetooth connections and 4 paired devices for a Nordic nRF52832 SoC.
 
CONFIG_BT_MAX_CONN=4
CONFIG_BT_MAX_PAIRED=4

I'm finding that when pairing/bonding with a phone the first is very smooth to go through the pairing/bonding process (passkey displayed on the Zephyr device and passkey entered on the mobile device).  Pairing the second device with the 1st connected is not as smooth and doesn't always succeed.
It should be noted that a notification (between 14 to 20 bytes) is being generated every 1s.

I've found that after creating a BLE bond and I connection and disconnect the mobile device 3 or 4 times the bond information is deleted on the mobile device (I'm testing with the Nordic nrf connect app and this information is in the log).  I'm currently not sure why this is happening and am I hoping it can be fixed as this behaviour would be very inconvenient for users of this device (constantly having to repair their mobile device bond).   I would imagine if I hadn't assigned enough tx/rx buffers for the Bluetooth stack the connection may be flaky but I wouldn't think the bond information would become lost.

If anyone could give some insight into what might be happening to causes this issue I would be very grateful.
Thanks.

Nick Ward




Introducing west, Zephyr's meta-tool

Carles Cufi
 

Hi all,

For a few months now we have been working on a meta-tool named west, designed to act both as a command-line tool to build, flash an debug Zephyr-based applications and also to manage the additional Git repositories that Zephyr will require in order to build in the near future.

West is written in Python 3, lives in its own repository [1] and its bootstrapper is available on PyPi [2].
As soon as we merge the topic-west [3] branch into master (which should happen in the next few days) you will need to install west in order to flash and debug, since those commands will rely on havig west present as part of your Zephyr workflow.

The updated west documentation will be online in the Zephyr documentation website [4] as soon as the topic-west branch is merged into master. In the meantime you can also look at the unrendered documentation sources in the topic-west branch [5] and the existing GitHub issues [6][7].

In order to install the west boostrapper (which you can do today) run:

# On Linux
pip3 install --user west

# On macOS and Windows
pip3 install west

Once the west bootstrapper is installed and the topic-west branch is merged into master, you will have 2 choices to get a west main installation.

1. Clone a new copy of the zephyr repository using west:

west init zephyrproject
cd zephyrproject
west update

2. Install west around an existing local zephyr clone:

Move the cloned zephyr/ repository to an empty enclosing folder (for example zephyrproject/zephyr/), and from this enclosing folder zephyrproject/ run:

west init -l zephyr/
west update
The -l <path to zephyr> parameter instructs west to use an existing local copy instead of cloning a remote repository.

Feedback and patches are welcome, but note that the feature will likely be merged as-is since we consider we have left ample time to raise any major issues regarding the workflow and decisions taken during the development of west. This is however only the beginning of west's (hopefully) long existence as the Zephyr command-line meta-tool, and it will certainly evolve and change considerably in the future with the help of the community.

Please submit feedback in the form of GitHub issues on the west repository itself [1] unless it affects features or functionality in the zephyr repository directly.

I will reply to this email once the topic-west branch is merged into master.

Thank you to everybody who has contributed so far!

Regards,

Carles

[1] https://github.com/zephyrproject-rtos/west
[2] https://pypi.org/project/west/
[3] https://github.com/zephyrproject-rtos/zephyr/tree/topic-west
[4] https://docs.zephyrproject.org/latest/tools/west/index.html
[5] https://github.com/zephyrproject-rtos/zephyr/tree/topic-west/doc/tools/west
[6] https://github.com/zephyrproject-rtos/zephyr/issues/6205
[7] https://github.com/zephyrproject-rtos/zephyr/issues/6770


Re: NFC support Zephyr voor LE OOB secured pairing...

Joakim Andersson
 

Hi Frank.

For NFC support with Zephyr on the Nordic HW can you have a look at the nRF Connect SDK  (https://www.nordicsemi.com/Software-and-Tools/Software/nRF-Connect-SDK)

For OOB support in the Zephyr Bluetooth stack this part is missing so that will have to be added.
If you create an issue for this feature on the zephyr github project someone can pick this up, or you can contribute it yourself.

OOB would have to be input into the pairing procedure in a similar way as the passkey, so for prototyping your system maybe you could use passkey instead until OOB support has been added.


Re: NFC support Zephyr voor LE OOB secured pairing...

frv
 

Hi Johan,

I was already aware this part was missing... :(. 
Unfortunately for the moment we are on a very strict time schedule to come up with a BLE architecture for our near future wireless HealthCare solutions. Time to market has become crazy in the last years. More and more we need to rely on finished building blocks to implement our solutions. Just like playing with Lego :). 

In the last 4 months I have intensively compared and investigated different BLE HW (Nordic, Laird, uBlox, ...) and SW (QT BLE, BlueZ, Zephyr, Nordic ...). So far I'm still in the process of understanding BLE and especially its secrets regarding "security". So far my expertise was in wired solutions, VideoOverIp (10G fiber systems) with limited security requirements. 
 
So far it seems that only brand proprietary BLE solutions (E.g. Nordic)  support a complete solution that implements all our requirements. Especially security is high on our list of requirements for implementing wireless BT health care systems.
For prototyping regardless of security I came up with a BLE architecture based on Zephyr (for the BLE peripheral device)  and BlueZ/QT (for the BLE central device), as HW platform we will likely stick to/select Nordic. 

Best regards,
Frank

 


Re: NFC support Zephyr voor LE OOB secured pairing...

Johan Hedberg
 

Hi Frank,


On 22 Jan 2019, at 10.01, frv <F.Vieren@televic.com> wrote:

Hi Rodrigo,

Thanks for your valuable feedback. I will have a look at it and see how far I can get.
Note that the APIs Rodrigo referred to are for Mesh provisioning, not for pairing. Zephyr doesn’t currently expose any OOB APIs for pairing, except bt_le_oob_get_local(), which only returns the local connectable address. I don’t think anyone would object to extending the pairing API with full OOB support however, so if you’d like to work on it the contribution would be very welcome.

Johan


Re: NFC support Zephyr voor LE OOB secured pairing...

frv
 

Hi Rodrigo,

Thanks for your valuable feedback. I will have a look at it and see how far I can get.

Best regards,
Frank


Re: NFC support Zephyr voor LE OOB secured pairing...

Rodrigo Peixoto
 

Frank,
as far as I know, there are some functions that are being called during the provisioning process like "static int output_number(bt_mesh_output_action_t action, u32_t number)". This function (in my code at least) prints the OOB value for pairing. I would suggest you take a look if there are alternatives to that or maybe use this function to call your NFC tag writing one showing the OOB value to the provisioner. You can find some samples where people blink a led with the OOB value, it works as well. 

I hope it helps.

Best regards,
Rodrigo Peixoto
Co-founder and Technical advisor

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex




Em seg, 21 de jan de 2019 às 07:45, frv <F.Vieren@...> escreveu:

Hi Rodrigo,

No not yet...
So far I'm still in the process of trying to understand how the NFC message (as described by the Bluetooth SIG) gets into the Bluetooth SW stack for the OOB pairing process. 
Nor on Linux/BlueZ, nor on Zeyphyr/bluetooth this is clear to me.
 
Depending on the track we will take, honestly I would love to continue with Zephyr for our BLE architecture, I can focus more on the Zephyr solution if that is the way to go. 
The alternative is to go fully Nordic also for the BLE SW stack. 

Thanks for your feedback. 

Best regards,
Frank


Re: NFC support Zephyr voor LE OOB secured pairing...

frv
 

Hi Rodrigo,

No not yet...
So far I'm still in the process of trying to understand how the NFC message (as described by the Bluetooth SIG) gets into the Bluetooth SW stack for the OOB pairing process. 
Nor on Linux/BlueZ, nor on Zeyphyr/bluetooth this is clear to me.
 
Depending on the track we will take, honestly I would love to continue with Zephyr for our BLE architecture, I can focus more on the Zephyr solution if that is the way to go. 
The alternative is to go fully Nordic also for the BLE SW stack. 

Thanks for your feedback. 

Best regards,
Frank


Re: NFC support Zephyr voor LE OOB secured pairing...

Rodrigo Peixoto
 

Frank,
I have a piece of code that wakes up the MCU through NFC, but I could not write or read data from it yet. We are using only the HAL code. The only tricky is to register the interrupt with IRQ_CONNECT for avoiding spurious interrupts. Have you tried to use the HAL?

On Mon, 21 Jan 2019 at 06:07 frv <F.Vieren@...> wrote:

Hi all,


As far as I can see there is no real support for NFC in Zephyr. 

Correct?


I'm really getting stuck in the LE OOB pairing process... 


I would really feel a pity I will need to fallback to the Nordic proprietary SW stack for my entire BLE design.

Meaning running on the Linux board the Nordic PC BLE driver (serialization protocol) for setting up the BLE central application combined with Nordic BLE connectivity(UART H5) and running a Nordic API based BLE peripheral applic that has direct NFC support.


Best regards,

Frank

--
Rodrigo Peixoto
Co-founder and Technical guru

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex

.


NFC support Zephyr voor LE OOB secured pairing...

frv
 

Hi all,


As far as I can see there is no real support for NFC in Zephyr. 

Correct?


I'm really getting stuck in the LE OOB pairing process... 


I would really feel a pity I will need to fallback to the Nordic proprietary SW stack for my entire BLE design.

Meaning running on the Linux board the Nordic PC BLE driver (serialization protocol) for setting up the BLE central application combined with Nordic BLE connectivity(UART H5) and running a Nordic API based BLE peripheral applic that has direct NFC support.


Best regards,

Frank


Re: BLE OOB - pairing/bonding - local-oob - HCI UART Zephyr issue?

frv
 

Hi Johan,

Thanks for clarifying this one out, that is already a great relief. Honestly I'm a little bit stuck with what I want to do about security in my BLE architecture.
So far I was able to combine a number of technologies on different HW boards each running different SW stacks. 
However when trying to start implementing security I'm getting stucked. 

So what I had in mind as proof of concept for my setup:
  • On a BBB running Linux 4.20 I run a BLE central application based on QT BLE SW, connected to this BBB is a nRF52 DK running Zephyr and the hci_uart BLE connectivity stack.
  • On another nRF52 board I'm running the Zephyr  HR demo peripheral application. 
  • The BLE central application can successfully connect to the HR demo application and read out the simulated HR values.

Now I wanted to add security, so far QT BLE has not explicit way of providing this, so I'm having to do it outside the QT BLE stack (unfortunately...).
As I will not have any input or output device for verification, the idea is to implement NFC OOB unless you already say this is not an option. 

So the idea is first to tryout a setup without the NFC functionality for exchanging the data.
Thus my idea was first:
to readout the local OOB of both devices and to exchange them "manually" by running the remote oob command via the btmgmt tool of BlueZ.

However despite the SSP issue I wrongly thought needed to be set. I see that also the btmgmt complains when trying to readout de local oob data.
As mentioned in my previous post, the btmgmt throws an error saying it is not supported to Read Out Local OOB info.

So here ends my story for the moment...

Any "better" idea's how to continue from here.
Honestly I love the concept of the Zephyr BLE connectivity as it allows us to keep on the "open source" BlueZ track. Also being able to use QT for running the BLE stack is a great advantage and speeds up the development work and also the quality of the implementation.
Nevertheless also the Zephyr project is also great way to go in our BLE design we have in mind.  So keep up the good work, we love it!!! 

Thanks in advance for your help on this topic.

Best regards,
Frank

Best regards,
Frank


Re: samples: BLE Mesh : finding possibi lities to optimise onoff level lighting vnd app further ?

vikrant8051 <vikrant8051@...>
 

Hi,

I wanna clarify that Black box means implementation is based on Bluetooth Mesh specification release in 2017 but it is available in close source lib. At app level there are some limited APIs to access it & that's it.

There even it is difficult to answer
- how state binding has done ?
- how transition time related stuff has handled ?
- how data structures is designed as per Models described in various tables in specifications ?

etc. etc.

It doesn't mean what is behind that black boxes is perfect. After testing it is found that those black boxes (which are so called qualified/certified) don't even pass basic PTS test requirements :)

Zephyr own BLE & Mesh stack is robust & always gone through PTS test time to time to fulfill all its requirements. And it is only open source project which supports Bluetooth Mesh.

But those who want to build Mesh App on it could get confused if gone through specs.

So goal is to find some optimised & "standard" way to design any type of Models architecture defined in #MeshModelSpecs ( including upcoming Models under #Smarthome subgroup category).

Thanks & regards,
vikrant







On Fri 18 Jan, 2019, 12:31 PM Hedberg, Johan <johan.hedberg@... wrote:
I’m here on the mailing list as well, but I don’t have much knowledge of the “black boxes” of proprietary Mesh products that Vikrant was referring to.

Johan


> On 18 Jan 2019, at 7.34, wxzzzh <wxzzzh@...> wrote:
>
> Hi,  vikrant,
>
> You can go here: https://zephyrproject.slack.com/messages/C18PLHN8H/convo/C18PLHN8H-1547649579.774500/?cdn_fallback=1
> in general channel, talk to Johan Hedberg by @jhe, who's the leader of this project and should can help you.
>
>       
> wxzzzh
> wxzzzh@...
> 签名由 网易邮箱大师 定制
> On 1/17/2019 21:01,vikrant8051<vikrant8051@...> wrote:
> Hello,
>
> Available Bluetooth Mesh App layers (which are based on resp. Semiconductor
> manufacture BLE Mesh stack) are black boxes. So we can't mimic what they
> have implemented.
>
> So is there anyone(developer) who is behind those black boxes to optimise zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app further?
>
> (Please refer Bluetooth Mesh Model Specification Table 6.128 for details .
>  From my point of view, current implementation is pretty much stable or Okay
> & that makes me biased for it).
>
> Is there any one who has successfully implemented
> - Light HSL Server/Client models using Zephyr Mesh stack
> - which has clear all PTS test rquirements 😃
> - and have used something indigenous/superior way than proposed implementation
>    in mentioned app ? 
>
> Thanks & regards,
> vikrant
>
>


Re: BLE OOB - pairing/bonding - local-oob - HCI UART Zephyr issue?

Johan Hedberg
 

On 18 Jan 2019, at 21.00, Johan Hedberg <johan.hedberg@intel.com> wrote:
On the BlueZ-side you shouldn’t need to enable anything explicitly if you’re running bluetooth
I meant naturally bluetoothd (stupid auto-correct :)

Johan


Re: BLE OOB - pairing/bonding - local-oob - HCI UART Zephyr issue?

Johan Hedberg
 

Hi,

On 18 Jan 2019, at 18.20, frv <F.Vieren@televic.com> wrote:
It seems when trying to set the SSP (Secure Simple Pairing) via the btmgmt tool I also get the error message the SSP is not supported for this adapter.
So it seems when setting up a BLE connectivity with Zephyr HCI_UART, this important "security" capability is not available...

SSP is a BR/EDR feature, whereas Zephyr on Nordic MCUs only supports LE (known as a single-mode controller). So you’re not missing anything essential in this regard. The security feature in LE is called the Security Manager Protocol. On the BlueZ-side you shouldn’t need to enable anything explicitly if you’re running bluetooth (it should do everything necessary for you). If you’re not running bluetooth, or for some other reason want to do things manually, you’d need to enable at least “le” and “sc” with btmgmt.

Johan


Re: BLE OOB - pairing/bonding - local-oob - HCI UART Zephyr issue?

frv
 

Hi all, Carles,

It seems when trying to set the SSP (Secure Simple Pairing)  via the btmgmt tool  I also get the error message the SSP is not supported for this adapter. 
So it seems when setting up a BLE connectivity with Zephyr HCI_UART, this important "security" capability is not available... 

Also when running the oobtest provided by the BlueZ package, the error message Secure Simple Pairing is NOT supported. Here I do the test on my Ubuntu PC which has 2 BLE adapters the internal one and the external Zephyr HCI_UART/Nordic.

Any idea what is going wrong here? 

Thanks in advance,
Best regards,
Frank


BLE OOB - pairing/bonding - local-oob - HCI UART Zephyr issue?

frv
 

Hi all, Carles,


During the last months I have been doing a lot of research in BLE technologies.


Finally for implementing our use case we came up with the following BLE architecture:

- a Linux embedded device (with Linux Kernel V4.20), more precise a BBB to be used as demonstrator platform before moving to a board with iMX6, running a BLE central application based on the QT BLE framework, as BLE connectivity HW, a Nordic nRF52 DK board is used that runs the RTOS Zephyr (V1.13) HCI_UART SW stack. So between both board there is a HCI_UART connection.


- as demonstrator BLE peripheral I'm using another nRF52 DK board that runs the Zephyr HR peripheral sample applic.


So the BLE central application written in QT C++, monitors the heart rate value that is simulated by the HR peripheral application. 

So far so good...


However I'm now trying to add security to the BLE architecture.

So far QT BLE doesn't explicitly implement any security  for a BLE implementation, in other words no QT API is available (yet?).


My idea is to implement  the BLE pairing outside the QT framework as it is not supported via QT.

However I'm struggling with a number of "things" and possible concepts of OOB when doing the pairing process.


I would love to implement OOB as SSP with possible NFC as method for exchanging OOB info. 


BlueZ on Linux offers a tool like btmgmt.

The idea is before starting implementing code based on this tool or the Bluetooth mgmt socket, to do some fast prototyping with this btmgmt tool in a shell.


However when I run the btmgmt local-oob, I get this output:




So it seems for some reason the HCI stack does not support this.


Could this be related to the Zephyr HCI_UART implementation?


Any help on this topic is very welcome.


More information on the "demonstrator" setup I'm trying to implement is described here:

https://bugreports.qt.io/browse/QTBUG-72989


https://forum.qt.io/topic/98427/sometimes-connection-times-out-when-trying-connecting-qt-ble-central-applic-with-ble-peripheral-applic-if-no-long-term-key-is-loaded-at-central-side

forum.qt.io
Hi, I have made a simple BLE setup between two embedded boards both with BLE connectivity. On the Beagle Bone Black with LINUX OS I run a simplified QT BLE central application that connects with a heart rate peripheral application running on a nRF52 DK b...






I would really love to stick to all these technologies (Zephyr/QT BLE/BlueZ) in our BLE design. 

The nRF52 (DK) with the Zephyr as BLE connectivity and as standalone unit for running a peripheral applic based on Zephyr is awesome.



Best regards,

Frank


2421 - 2440 of 8041