You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Szymon Janc <sz...@codecoup.pl> on 2017/07/18 19:33:04 UTC
Merging bluetooth5 branch into master
Hi,
This is to give community a heads up that we are going to merge bluetooth5
branch [1] into master very soon. This is rather big feature so don't be
surprised about amount of new code.
Feature wise this includes:
- Channel Selection Algorithm #2
- High Duty non-connectable advertising
- LE 2M and LE coded (aka long range) PHYs
- Extended Advertising (both advertiser and scanner, no chaining support)
- multiple advertising instances (controller only)
Note that this branch also get rid of support for 1M clock and 32K clock is
not required for running nimBLE stack.
Note that controller is now optimized to work with low power 32768 Hz and
does not work with 1 MHz clock anymore. For details see existing BSP-s
which are already preconfigured for new clock or check updated
documentation.
--
pozdrawiam
Szymon K. Janc
Re: Merging bluetooth5 branch into master
Posted by Szymon Janc <sz...@codecoup.pl>.
Hi,
> This is to give community a heads up that we are going to merge bluetooth5
> branch [1] into master very soon. This is rather big feature so don't be
> surprised about amount of new code.
>
> Feature wise this includes:
> - Channel Selection Algorithm #2
> - High Duty non-connectable advertising
> - LE 2M and LE coded (aka long range) PHYs
> - Extended Advertising (both advertiser and scanner, no chaining support)
> - multiple advertising instances (controller only)
>
> Note that this branch also get rid of support for 1M clock and 32K clock is
> not required for running nimBLE stack.
>
>
> Note that controller is now optimized to work with low power 32768 Hz and
> does not work with 1 MHz clock anymore. For details see existing BSP-s which
> are already preconfigured for new clock or check updated documentation.
Pull request for this is now pending review:
https://github.com/apache/mynewt-core/pull/437
--
pozdrawiam
Szymon Janc
Re: Merging bluetooth5 branch into master
Posted by Simon Ratner <si...@proxy.co>.
Here's a config. It does not make bletiny crash, but it does return
corrupted adv data on scan (with BLE_EXT_ADV=1, more of the adv packet is
corrupted, which is probably why I was seeing crashes in my main app, while
without BLE_EXT_ADV i was only seeing data errors).
(simon/mynewt-1_2_0_rc1) ~>
$ newt target show bletiny
targets/bletiny
app=@apache-mynewt-core/apps/bletiny
bsp=@apache-mynewt-core/hw/bsp/rb-nano2
build_profile=optimized
syscfg=BLE_EXT_ADV=1:BLE_MAX_CONNECTIONS=32:MSYS_1_BLOCK_COUNT=96:MSYS_1_BLOCK_SIZE=80
So it is likely the same problem as what is being discussed in the other
parallel thread.
On Wed, Sep 6, 2017 at 3:31 PM, Łukasz Rymanowski <
lukasz.rymanowski@codecoup.pl> wrote:
> Hi Simon
>
> On 6 September 2017 at 23:27, Simon Ratner <si...@proxy.co> wrote:
> > This doesn't seem to be the case.
> >
> > With hci event size of 70 and msys1 block size of 80, I get segfaults.
>
> I think we need some more information on your target and scenario
> because I just set same values (70, 80) for my bletiny app and don't
> get any crashes when doing scan or adv. Here is what I use:
> app=@apache-mynewt-core/apps/bletiny
> bsp=@apache-mynewt-core/hw/bsp/nrf52840pdk
> build_profile=debug
> syscfg=BLE_EXT_ADV=1:BLE_HCI_EVT_BUF_SIZE=70:BLE_HS_DEBUG=
> 1:BLE_L2CAP_COC_MAX_NUM=1:BLE_LL_CFG_FEAT_LE_2M_PHY=1:BLE_
> LL_CFG_FEAT_LE_CODED_PHY=1:BLE_MONITOR_DEBUG=0:BLE_
> MONITOR_RTT=1:BLE_SM_LEGACY=1:BLE_SM_SC=1:LOG_LEVEL=1:MSYS_
> 1_BLOCK_SIZE=80:STATS_CLI=1:STATS_NAMES=1
>
> > Increasing both to 274 works ok -- I'll try to track down the actual
> > minimum, but someone more familiar with the changes that went in may have
> > an easier time with that.
>
> Imho there should not be required any special minimum for the block
> size. I mean 80 should be fine to start with.
> When it comes to HCI event size, I believe in transport syscfg, there
> is dependency done on BLE_EXT_ADV flag and BLE_HCI_EVT_BUF_SIZE is
> reconfigured to the max size of extended advertising allowed as per
> BT5 spec.
>
> >
> >
> > On 6 Sep. 2017 08:52, "Łukasz Rymanowski" <lukasz.rymanowski@codecoup.pl
> >
> > wrote:
> >
> >> Hi Simon
> >>
> >> On Sep 6, 2017 5:48 PM, "Simon Ratner" <si...@proxy.co> wrote:
> >>
> >> Perfect, this will do.
> >>
> >> I assume I need to enable BLE_EXT_ADV for these. Is it safe to
> >> reduce BLE_HCI_EVT_BUF_SIZE back to 70 if I am not using large
> >> advertisements?
> >>
> >>
> >> It should be Ok.
> >>
> >>
> >>
> >> On 5 Sep. 2017 23:43, "Szymon Janc" <sz...@codecoup.pl> wrote:
> >>
> >> > Hi Simon,
> >> >
> >> > On 6 September 2017 at 05:33, Simon Ratner <si...@proxy.co> wrote:
> >> > > Hi Szymon,
> >> > >
> >> > > I'd like to take you up on that offer of docs, or at least a
> pointer in
> >> > the
> >> > > right direction of where to find the new multi-adv hci commands.
> >> >
> >> > Those are standard HCI commands and events from Bluetooth Core Spec
> 5.0 :
> >> > LE Set Advertising Set Random Address Command
> >> > LE Set Extended Advertising Parameters Command
> >> > LE Set Extended Advertising Data Command
> >> > LE Set Extended Scan Response Data Command
> >> > LE Set Extended Scan Response Data Command
> >> > LE Advertising Set Terminated Event
> >> > LE Scan Request Received Event
> >> >
> >> > All those have 'advertising handle' which allows to configure multiple
> >> > instances (with both legacy or Ext Advertising PDUs).
> >> > Note that spec seems to a bit unclear on what are allowed values for
> >> > advertising handle (as it seems to be configured from
> >> > host side) - currently in Mynewt allowed values for those are 0 to
> >> > MAX_ADVERTISING_INSTANCES.
> >> >
> >> > You can find helpers for constructing those from host in
> >> ble_hs_hci_priv.h
> >> >
> >> > --
> >> > pozdrawiam
> >> > Szymon K. Janc
> >> >
> >>
>
Re: Merging bluetooth5 branch into master
Posted by Łukasz Rymanowski <lu...@codecoup.pl>.
Hi Simon
On 6 September 2017 at 23:27, Simon Ratner <si...@proxy.co> wrote:
> This doesn't seem to be the case.
>
> With hci event size of 70 and msys1 block size of 80, I get segfaults.
I think we need some more information on your target and scenario
because I just set same values (70, 80) for my bletiny app and don't
get any crashes when doing scan or adv. Here is what I use:
app=@apache-mynewt-core/apps/bletiny
bsp=@apache-mynewt-core/hw/bsp/nrf52840pdk
build_profile=debug
syscfg=BLE_EXT_ADV=1:BLE_HCI_EVT_BUF_SIZE=70:BLE_HS_DEBUG=1:BLE_L2CAP_COC_MAX_NUM=1:BLE_LL_CFG_FEAT_LE_2M_PHY=1:BLE_LL_CFG_FEAT_LE_CODED_PHY=1:BLE_MONITOR_DEBUG=0:BLE_MONITOR_RTT=1:BLE_SM_LEGACY=1:BLE_SM_SC=1:LOG_LEVEL=1:MSYS_1_BLOCK_SIZE=80:STATS_CLI=1:STATS_NAMES=1
> Increasing both to 274 works ok -- I'll try to track down the actual
> minimum, but someone more familiar with the changes that went in may have
> an easier time with that.
Imho there should not be required any special minimum for the block
size. I mean 80 should be fine to start with.
When it comes to HCI event size, I believe in transport syscfg, there
is dependency done on BLE_EXT_ADV flag and BLE_HCI_EVT_BUF_SIZE is
reconfigured to the max size of extended advertising allowed as per
BT5 spec.
>
>
> On 6 Sep. 2017 08:52, "Łukasz Rymanowski" <lu...@codecoup.pl>
> wrote:
>
>> Hi Simon
>>
>> On Sep 6, 2017 5:48 PM, "Simon Ratner" <si...@proxy.co> wrote:
>>
>> Perfect, this will do.
>>
>> I assume I need to enable BLE_EXT_ADV for these. Is it safe to
>> reduce BLE_HCI_EVT_BUF_SIZE back to 70 if I am not using large
>> advertisements?
>>
>>
>> It should be Ok.
>>
>>
>>
>> On 5 Sep. 2017 23:43, "Szymon Janc" <sz...@codecoup.pl> wrote:
>>
>> > Hi Simon,
>> >
>> > On 6 September 2017 at 05:33, Simon Ratner <si...@proxy.co> wrote:
>> > > Hi Szymon,
>> > >
>> > > I'd like to take you up on that offer of docs, or at least a pointer in
>> > the
>> > > right direction of where to find the new multi-adv hci commands.
>> >
>> > Those are standard HCI commands and events from Bluetooth Core Spec 5.0 :
>> > LE Set Advertising Set Random Address Command
>> > LE Set Extended Advertising Parameters Command
>> > LE Set Extended Advertising Data Command
>> > LE Set Extended Scan Response Data Command
>> > LE Set Extended Scan Response Data Command
>> > LE Advertising Set Terminated Event
>> > LE Scan Request Received Event
>> >
>> > All those have 'advertising handle' which allows to configure multiple
>> > instances (with both legacy or Ext Advertising PDUs).
>> > Note that spec seems to a bit unclear on what are allowed values for
>> > advertising handle (as it seems to be configured from
>> > host side) - currently in Mynewt allowed values for those are 0 to
>> > MAX_ADVERTISING_INSTANCES.
>> >
>> > You can find helpers for constructing those from host in
>> ble_hs_hci_priv.h
>> >
>> > --
>> > pozdrawiam
>> > Szymon K. Janc
>> >
>>
Re: Merging bluetooth5 branch into master
Posted by Simon Ratner <si...@proxy.co>.
This doesn't seem to be the case.
With hci event size of 70 and msys1 block size of 80, I get segfaults.
Increasing both to 274 works ok -- I'll try to track down the actual
minimum, but someone more familiar with the changes that went in may have
an easier time with that.
In either case, there should probably be an assert somewhere if the stack
implicitly relies on some minimum memblock size.
On 6 Sep. 2017 08:52, "Łukasz Rymanowski" <lu...@codecoup.pl>
wrote:
> Hi Simon
>
> On Sep 6, 2017 5:48 PM, "Simon Ratner" <si...@proxy.co> wrote:
>
> Perfect, this will do.
>
> I assume I need to enable BLE_EXT_ADV for these. Is it safe to
> reduce BLE_HCI_EVT_BUF_SIZE back to 70 if I am not using large
> advertisements?
>
>
> It should be Ok.
>
>
>
> On 5 Sep. 2017 23:43, "Szymon Janc" <sz...@codecoup.pl> wrote:
>
> > Hi Simon,
> >
> > On 6 September 2017 at 05:33, Simon Ratner <si...@proxy.co> wrote:
> > > Hi Szymon,
> > >
> > > I'd like to take you up on that offer of docs, or at least a pointer in
> > the
> > > right direction of where to find the new multi-adv hci commands.
> >
> > Those are standard HCI commands and events from Bluetooth Core Spec 5.0 :
> > LE Set Advertising Set Random Address Command
> > LE Set Extended Advertising Parameters Command
> > LE Set Extended Advertising Data Command
> > LE Set Extended Scan Response Data Command
> > LE Set Extended Scan Response Data Command
> > LE Advertising Set Terminated Event
> > LE Scan Request Received Event
> >
> > All those have 'advertising handle' which allows to configure multiple
> > instances (with both legacy or Ext Advertising PDUs).
> > Note that spec seems to a bit unclear on what are allowed values for
> > advertising handle (as it seems to be configured from
> > host side) - currently in Mynewt allowed values for those are 0 to
> > MAX_ADVERTISING_INSTANCES.
> >
> > You can find helpers for constructing those from host in
> ble_hs_hci_priv.h
> >
> > --
> > pozdrawiam
> > Szymon K. Janc
> >
>
Re: Merging bluetooth5 branch into master
Posted by Łukasz Rymanowski <lu...@codecoup.pl>.
Hi Simon
On Sep 6, 2017 5:48 PM, "Simon Ratner" <si...@proxy.co> wrote:
Perfect, this will do.
I assume I need to enable BLE_EXT_ADV for these. Is it safe to
reduce BLE_HCI_EVT_BUF_SIZE back to 70 if I am not using large
advertisements?
It should be Ok.
On 5 Sep. 2017 23:43, "Szymon Janc" <sz...@codecoup.pl> wrote:
> Hi Simon,
>
> On 6 September 2017 at 05:33, Simon Ratner <si...@proxy.co> wrote:
> > Hi Szymon,
> >
> > I'd like to take you up on that offer of docs, or at least a pointer in
> the
> > right direction of where to find the new multi-adv hci commands.
>
> Those are standard HCI commands and events from Bluetooth Core Spec 5.0 :
> LE Set Advertising Set Random Address Command
> LE Set Extended Advertising Parameters Command
> LE Set Extended Advertising Data Command
> LE Set Extended Scan Response Data Command
> LE Set Extended Scan Response Data Command
> LE Advertising Set Terminated Event
> LE Scan Request Received Event
>
> All those have 'advertising handle' which allows to configure multiple
> instances (with both legacy or Ext Advertising PDUs).
> Note that spec seems to a bit unclear on what are allowed values for
> advertising handle (as it seems to be configured from
> host side) - currently in Mynewt allowed values for those are 0 to
> MAX_ADVERTISING_INSTANCES.
>
> You can find helpers for constructing those from host in ble_hs_hci_priv.h
>
> --
> pozdrawiam
> Szymon K. Janc
>
Re: Merging bluetooth5 branch into master
Posted by Simon Ratner <si...@proxy.co>.
Perfect, this will do.
I assume I need to enable BLE_EXT_ADV for these. Is it safe to
reduce BLE_HCI_EVT_BUF_SIZE back to 70 if I am not using large
advertisements?
On 5 Sep. 2017 23:43, "Szymon Janc" <sz...@codecoup.pl> wrote:
> Hi Simon,
>
> On 6 September 2017 at 05:33, Simon Ratner <si...@proxy.co> wrote:
> > Hi Szymon,
> >
> > I'd like to take you up on that offer of docs, or at least a pointer in
> the
> > right direction of where to find the new multi-adv hci commands.
>
> Those are standard HCI commands and events from Bluetooth Core Spec 5.0 :
> LE Set Advertising Set Random Address Command
> LE Set Extended Advertising Parameters Command
> LE Set Extended Advertising Data Command
> LE Set Extended Scan Response Data Command
> LE Set Extended Scan Response Data Command
> LE Advertising Set Terminated Event
> LE Scan Request Received Event
>
> All those have 'advertising handle' which allows to configure multiple
> instances (with both legacy or Ext Advertising PDUs).
> Note that spec seems to a bit unclear on what are allowed values for
> advertising handle (as it seems to be configured from
> host side) - currently in Mynewt allowed values for those are 0 to
> MAX_ADVERTISING_INSTANCES.
>
> You can find helpers for constructing those from host in ble_hs_hci_priv.h
>
> --
> pozdrawiam
> Szymon K. Janc
>
Re: Merging bluetooth5 branch into master
Posted by Szymon Janc <sz...@codecoup.pl>.
Hi Simon,
On 6 September 2017 at 05:33, Simon Ratner <si...@proxy.co> wrote:
> Hi Szymon,
>
> I'd like to take you up on that offer of docs, or at least a pointer in the
> right direction of where to find the new multi-adv hci commands.
Those are standard HCI commands and events from Bluetooth Core Spec 5.0 :
LE Set Advertising Set Random Address Command
LE Set Extended Advertising Parameters Command
LE Set Extended Advertising Data Command
LE Set Extended Scan Response Data Command
LE Set Extended Scan Response Data Command
LE Advertising Set Terminated Event
LE Scan Request Received Event
All those have 'advertising handle' which allows to configure multiple
instances (with both legacy or Ext Advertising PDUs).
Note that spec seems to a bit unclear on what are allowed values for
advertising handle (as it seems to be configured from
host side) - currently in Mynewt allowed values for those are 0 to
MAX_ADVERTISING_INSTANCES.
You can find helpers for constructing those from host in ble_hs_hci_priv.h
--
pozdrawiam
Szymon K. Janc
Re: Merging bluetooth5 branch into master
Posted by Simon Ratner <si...@proxy.co>.
Hi Szymon,
I'd like to take you up on that offer of docs, or at least a pointer in the
right direction of where to find the new multi-adv hci commands.
Cheers,
simon
On Tue, Jul 18, 2017 at 3:48 PM, Szymon Janc <sz...@codecoup.pl>
wrote:
> Hi Simon,
>
> On Wednesday, 19 July 2017 00:31:55 CEST Simon Ratner wrote:
> > Thanks for the heads-up, Szymon.
> > How does the bt5 implementation of "multiple advertising instances"
> relate
> > to the corresponding vendor extension that's currently in master?
>
> I should mention that in my email, thanks for asking.
>
> Vendor extensions are removed in favour of using BT5 HCI commands.
> Porting from Android extensions should be fairy easy, if there is a need
> for
> documenting this I can add a page about it to our wiki.
>
> --
> pozdrawiam
> Szymon Janc
>
Re: Merging bluetooth5 branch into master
Posted by Szymon Janc <sz...@codecoup.pl>.
Hi Simon,
On Wednesday, 19 July 2017 00:31:55 CEST Simon Ratner wrote:
> Thanks for the heads-up, Szymon.
> How does the bt5 implementation of "multiple advertising instances" relate
> to the corresponding vendor extension that's currently in master?
I should mention that in my email, thanks for asking.
Vendor extensions are removed in favour of using BT5 HCI commands.
Porting from Android extensions should be fairy easy, if there is a need for
documenting this I can add a page about it to our wiki.
--
pozdrawiam
Szymon Janc
Re: Merging bluetooth5 branch into master
Posted by Simon Ratner <si...@proxy.co>.
Thanks for the heads-up, Szymon.
How does the bt5 implementation of "multiple advertising instances" relate
to the corresponding vendor extension that's currently in master?
--
simon
On Tue, Jul 18, 2017 at 12:33 PM, Szymon Janc <sz...@codecoup.pl>
wrote:
> Hi,
>
> This is to give community a heads up that we are going to merge bluetooth5
> branch [1] into master very soon. This is rather big feature so don't be
> surprised about amount of new code.
>
> Feature wise this includes:
> - Channel Selection Algorithm #2
> - High Duty non-connectable advertising
> - LE 2M and LE coded (aka long range) PHYs
> - Extended Advertising (both advertiser and scanner, no chaining support)
> - multiple advertising instances (controller only)
>
> Note that this branch also get rid of support for 1M clock and 32K clock is
> not required for running nimBLE stack.
>
> Note that controller is now optimized to work with low power 32768 Hz and
> does not work with 1 MHz clock anymore. For details see existing BSP-s
> which are already preconfigured for new clock or check updated
> documentation.
>
> --
> pozdrawiam
> Szymon K. Janc
>