Re: [DISCUSS] Release Apache Mynewt 1.12.0-rc1 and Apache NimBLE 1.7.0-rc1

[Łukasz Rymanowski]

+1

On Fri, 29 Mar 2024 at 16:01, Jerzy Kasenberg 
wrote:

> +1
>
>
> śr., 27 mar 2024 o 14:57 Szymon Janc  napisał(a):
>
> > Hi all,
> >
> > This thread is for any and all discussion regarding the release of
> > Apache Mynewt 1.12.0 and Apache NimBLE 1.7.0.  All feedback is welcome.
> >
> > --
> > pozdrawiam
> > Szymon K. Janc
> >
> >
> >
>

Re: Restricting access from one bonded central

[Łukasz Rymanowski]

Hi Davis,

Once you have a remote device bonded you should stop advertising with
general advertisement and use only directed advertisement. This means you
need to reconfigure your advertising instance.
In this way, only the bonded device will be able to reconnect.

Most probably, you would like to start advertising only when the device is
disconnected.

Also to make sure that connected device is the one you bond previously, you
probably would like to enable encryption just after connection.
If the encryption fails, you can apply your policy - either disconnect the
device (ble_gap_terminate is fine), or allow it to pair again.

Hope that helps.

Best
Łukasz







On Mon, 16 Oct 2023 at 08:05, Davis  wrote:

> Hello!
>
> What is the proper way in NimBLE to restrict all access to a BLE
> peripheral - the peripheral should be accessible only from a single
> previously bounded central?
>
> I want to disable all anonymous access, as well as the ability to make any
> new pairings or bondings.
> This should be done in a security aware way (that cannot be bypassed by
> violating BLE protocol, sending custom packets etc.).
>
> Currently I have the following questions:
> 1. In the BLE_GAP_EVENT_CONNECT handler I have added
> "ble_gap_security_initiate(event->connect.conn_handle);" (without quotes).
> Is this the proper way to disable all anonymous access (except reading
> information that is broadcasted in the advertisements)?
> 2. What is the proper way to disable any new bondings and pairings (all
> connections that aren't using keys loaded into memory by calls to
> ble_store_write_our_sec(), ble_store_write_peer_sec(),
> ble_store_write_cccd())?
> In the BLE_GAP_EVENT_PASSKEY_ACTION add
> "ble_gap_terminate(event->passkey.conn_handle, BLE_ERR_AUTH_FAIL);"
> (without quotes).
> In the BLE_GAP_EVENT_REPEAT_PAIRING handler add "return
> BLE_GAP_REPEAT_PAIRING_IGNORE;" (without quotes).
> In the BLE_GAP_EVENT_IDENTITY_RESOLVED handler add calls
> to ble_gap_conn_find() and ble_store_read_peer_sec() that check
> whether ble_store_read_peer_sec() can find the key for peer_id_addr from
> the ble_gap_conn_desc filled by ble_gap_conn_find(). In case the key cannot
> be found, "ble_gap_terminate(event->identity_resolved.conn_handle,
> BLE_ERR_AUTH_FAIL);" (without quotes) is called.
> Are these things the correct way to disable all new pairings and bondings?
> Does anything else need to be done to disable all new pairings and
> bondings?
> 3. Is calling ble_gap_terminate() the proper way to terminate a
> rogue connection?
> 4. Is there anything else that needs to be done to secure the NimBLE based
> peripheral from any kind of access that is not coming from the previously
> bonded central?
>
> P.S. I am using a fork (
>
> https://github.com/InfiniTimeOrg/InfiniTime/tree/main/src/libs/mynewt-nimble
> ), however my questions are about NimBLE in general (about how it
> should work).
>
> Br,
> Davis
>

Re: [VOTE] Release Apache Mynewt 1.11.0-rc1 and Apache NimBLE 1.6.0-rc1

[Łukasz Rymanowski]

+1 (binding)

On Mon, 21 Aug 2023 at 20:28,  wrote:

> +1 (binding)
>
> --- Original Message ---
> On Friday, August 11th, 2023 at 8:07 AM, Szymon Janc <
> szymon.j...@codecoup.pl> wrote:
>
>
> >
> >
> > Hello all,
> >
> > I am pleased to be calling this vote for the source release of
> > Apache Mynewt 1.11.0 and Apache NimBLE 1.6.0.
> >
> > Apache Mynewt is a community-driven, permissively licensed open source
> > initiative for constrained, embedded applications. Mynewt provides a
> > real-time operating system, flash file system, network stacks, and
> > support utilities for real-world embedded systems.
> >
> > Apache NimBLE is Bluetooth Low Energy 5.4 stack from Apache Mynewt.
> >
> > This release is coordinated release of Apache Mynewt and NimBLE. Future
> > NimBLE releases may be released separately depending on needs.
> >
> > For full release notes for both Mynewt and NimBLE, please visit the
> Apache
> > Mynewt Wiki:
> > https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
> >
> > Apache Mynewt and Apache NimBLE release candidates were tested as
> follows:
> > 1. Manual execution of the Mynewt test plan:
> >
> >
> https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan
> > The test results can be found at:
> > https://cwiki.apache.org/confluence/display/MYNEWT/1.11.0+Test+Results
> > 2. Manual execution of the NimBLE test plan:
> >
> >
> https://cwiki.apache.org/confluence/display/MYNEWT/Apache+NimBLE+Test+Plan
> > The test results can be found at:
> >
> >
> https://cwiki.apache.org/confluence/display/MYNEWT/NimBLE+1.6.0+Test+Results
> >
> > Note that this testing is not yet complete and more results will show
> > while
> > voting is ongoing.
> >
> > 2. The full unit test suite for both releases was executed via "newt test
> > all"
> > with no failures. This testing was performed on the following
> > platforms:
> > * Fedora Linux 38
> >
> > The release candidate to be voted on is available at:
> > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.11.0/rc1/
> > https://dist.apache.org/repos/dist/dev/mynewt/apache-nimble-1.6.0/rc1/
> >
> > The commits under consideration are as follows:
> > blinky:
> > repos: https://github.com/apache/mynewt-blinky
> > commit 223f0b3f8859c77cc0a41038a21e8d0f348e992e
> > core:
> > repos: https://github.com/apache/mynewt-core
> > commit 6de871dfa7306a06df4219470205af69c569c0d9
> > newt:
> > repos: https://github.com/apache/mynewt-newt
> > commit 2215fc6201d7c7c376b9d6733bd35a10b5691aae
> > newtmgr:
> > repos: https://github.com/apache/mynewt-newtmgr
> > commit 5086b90977bc0782b1f36eaebacabeb694d19cb5
> > nimble:
> > repos: https://github.com/apache/mynewt-nimble
> > commit df0718d7eacf414b2f4ed1e28f866250d92cadcb
> >
> > In addition, the following newt and newtmgr convenience binaries are
> > available:
> > linux:
> >
> >
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.11.0/rc1/apache-mynewt-newt-bin-linux-1.11.0.tgz
> >
> >
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.11.0/rc1/apache-mynewt-newtmgr-bin-linux-1.10.0.tgz
> >
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newtmgr-bin-linux-1.11.0.tgz
> >
> >
> > osx:
> >
> >
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.11.0/rc1/apache-mynewt-newt-bin-osx-1.11.0.tgz
> >
> >
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.11.0/rc1/apache-mynewt-newtmgr-bin-osx-1.11.0.tgz
> >
> > windows:
> >
> >
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.11.0/rc1/apache-mynewt-newt-bin-windows-1.11.0.tgz
> >
> >
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.11.0/rc1/apache-mynewt-newtmgr-bin-windows-1.11.0.tgz
> >
> > The release candidate is signed with a GPG key available at:
> > https://dist.apache.org/repos/dist/dev/mynewt/KEYS
> >
> > The vote is open for at least 72 hours and passes if a majority of at
> > least three +1 PMC votes are cast.
> >
> > [ ] +1 Release this package
> > [ ] 0 I don't feel strongly about it, but don't object
> > [ ] -1 Do not release this package because...
> >
> > Anyone can participate in testing and voting, not just committers,
> > please feel free to try out the release candidate and provide your
> > votes.
> >
> > A separate [DISCUSS] thread will be opened to talk about this release
> > candidate.
> >
> > --
> > pozdrawiam
> > Szymon K. Janc
>

Re: [VOTE] Release Apache Mynewt 1.10.0-rc1 and Apache NimBLE 1.5.0-rc1

[Łukasz Rymanowski]

+1 (binding)

Best
Łukasz

On Sat, 30 Apr 2022 at 09:58, Jerzy Kasenberg
 wrote:
>
> +1 (binding)
>
> best regards
> Jerzy
>
> pt., 29 kwi 2022 o 11:49 Szymon Janc  napisał(a):
> >
> > +1 (binding)
> >
> > There are couple of issues mentioned in release notes but those can be
> > fixed in point release.
> >
> >
> > On Mon, 25 Apr 2022 at 00:45, Szymon Janc  wrote:
> >
> > > Hello all,
> > >
> > > I am pleased to be calling this vote for the source release of
> > > Apache Mynewt 1.10.0 and Apache NimBLE 1.5.0.
> > >
> > > Apache Mynewt is a community-driven, permissively licensed open source
> > > initiative for constrained, embedded applications. Mynewt provides a
> > > real-time operating system, flash file system, network stacks, and
> > > support utilities for real-world embedded systems.
> > >
> > > Apache NimBLE is Bluetooth Low Energy 5.3 stack from Apache Mynewt.
> > >
> > > This release is coordinated release of Apache Mynewt and NimBLE. Future
> > > NimBLE releases may be released separately depending on needs.
> > >
> > > For full release notes for both Mynewt and NimBLE, please visit the Apache
> > > Mynewt Wiki:
> > > https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
> > >
> > > Apache Mynewt and Apache NimBLE release candidates were tested as follows:
> > >   1. Manual execution of the Mynewt test plan:
> > >
> > > https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan
> > >  The test results can be found at:
> > >
> > > https://cwiki.apache.org/confluence/display/MYNEWT/1.10.0+Test+Results
> > >   2. Manual execution of the NimBLE test plan:
> > >
> > > https://cwiki.apache.org/confluence/display/MYNEWT/Apache+NimBLE+Test+Plan
> > >  The test results can be found at:
> > >
> > > https://cwiki.apache.org/confluence/display/MYNEWT/NimBLE+1.5.0+Test+Results
> > >
> > >  Note that this testing is not yet complete and more results will show
> > > while
> > >  voting is ongoing.
> > >
> > >   2. The full unit test suite for both releases was executed via "newt
> > > test all"
> > >  with no failures. This testing was performed on the following
> > > platforms:
> > >* Fedora Linux 35
> > >
> > > The release candidate to be voted on is available at:
> > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/
> > > https://dist.apache.org/repos/dist/dev/mynewt/apache-nimble-1.5.0/rc1/
> > >
> > > The commits under consideration are as follows:
> > > blinky:
> > >   repos: https://github.com/apache/mynewt-blinky
> > >   commit d2dcd79fb9fad8fb6cb63b0e338cb81b995fc0f9
> > > core:
> > >   repos: https://github.com/apache/mynewt-core
> > >   commit 71c228891d02891a6be765d53e7a3874edc59074
> > > newt:
> > >   repos: https://github.com/apache/mynewt-newt
> > >   commit 874afdfa6f4738646bad29d9d7119a68dc7b0128
> > > newtmgr:
> > >   repos: https://github.com/apache/mynewt-newtmgr
> > >   commit c3cc444a278471b5ca5293607526e05295ded0e4
> > > nimble:
> > >   repos: https://github.com/apache/mynewt-nimble
> > >   commit 21d59b8b40c232d6746778dda6b91cf0c0edba83
> > >
> > > In addition, the following newt and newtmgr convenience binaries are
> > > available:
> > >   linux:
> > >
> > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newt-bin-linux-1.10.0.tgz
> > >
> > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newtmgr-bin-linux-1.10.0.tgz
> > >
> > >   osx:
> > >
> > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newt-bin-osx-1.10.0.tgz
> > >
> > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newtmgr-bin-osx-1.10.0.tgz
> > >
> > >   windows:
> > >
> > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newt-bin-windows-1.10.0.tgz
> > >
> > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newtmgr-bin-windows-1.10.0.tgz
> > >
> > > The release candidate is signed with a GPG key available at:
> > > https://dist.apache.org/repos/dist/dev/mynewt/KEYS
> > >
> > > The vote is open for at least 72 hours and passes if a majority of at
> > > least three +1 PMC votes are cast.
> > >
> > > [ ] +1 Release this package
> > > [ ]  0 I don't feel strongly about it, but don't object
> > > [ ] -1 Do not release this package because...
> > >
> > > Anyone can participate in testing and voting, not just committers,
> > > please feel free to try out the release candidate and provide your
> > > votes.
> > >
> > > A separate [DISCUSS] thread will be opened to talk about this release
> > > candidate.
> > >
> > > --
> > > pozdrawiam
> > > Szymon Janc
> >
> >
> >
> > --
> > pozdrawiam
> > Szymon K. Janc

Re: NimBLE stops working after ~24h

[Łukasz Rymanowski]

Hi JF,

Yes, this is expected if you set the duration to 3 minutes :)

I guess you want to reproduce your original problem now, having debug lines
connected and getting HCI logs from BLE_MONITOR_RTT.

Best
Łukasz


On Wed, 11 Aug 2021 at 21:09,  wrote:

> Hi,
>
> > I need to admit that I totally missed the part that you are on FreeRTOS
> > but
> > I see DEBUG lines that work for you.
> > On the first picture you see radio activity every advertising interval
> > and
> > on the second one you see a single advertising event - all looks good.
>
> Good to know that when it works, it works well :-)
>
> > Anyway, the question now is why BLE_GAP_EVENT_ADV_COMPLETE is sent with
> > a
> > timeout. Did you try to debug it by setting breakpoint at
> > ble_gap_adv_finished?
>
> This is probably because advertising is started with a timeout of 3
> minutes :
>
>  ble_gap_adv_start(addrType, NULL, 18, _params,
> GAPEventCallback, this);
>
> Isn't that expected?
>
> Anyway, here's the callstack when the BLE_GAP_EVENT_ADV_COMPLETE event
> is received:
>
> Breakpoint 2, Pinetime::Controllers::NimbleController::OnGAPEvent
> (this=0x200019e0 , event=0x20006b44 ) at
> /home/jf/git/PineTime/src/components/ble/NimbleController.cpp:137
> 137   NRF_LOG_INFO("Advertising event :
> BLE_GAP_EVENT_ADV_COMPLETE");
> (gdb) bt
> #0  Pinetime::Controllers::NimbleController::OnGAPEvent (this=0x200019e0
> , event=0x20006b44 ) at
> /home/jf/git/PineTime/src/components/ble/NimbleController.cpp:137
> #1  0xe7c4 in GAPEventCallback (event=,
> arg=) at
> /home/jf/git/PineTime/src/components/ble/NimbleController.cpp:47
> #2  0x000177cc in ble_gap_adv_finished (instance=instance@entry=0
> '\000', reason=reason@entry=13, conn_handle=conn_handle@entry=0,
> num_events=num_events@entry=0 '\000') at
> /home/jf/git/PineTime/src/libs/mynewt-nimble/nimble/host/src/ble_gap.c:802
> #3  0x00017aba in ble_gap_slave_timer () at
> /home/jf/git/PineTime/src/libs/mynewt-nimble/nimble/host/src/ble_gap.c:1970
> #4  0x00017d5e in ble_gap_timer () at
> /home/jf/git/PineTime/src/libs/mynewt-nimble/nimble/host/src/ble_gap.c:2044
> #5  0x00014a60 in ble_hs_timer_exp (ev=) at
> /home/jf/git/PineTime/src/libs/mynewt-nimble/nimble/host/src/ble_hs.c:407
> #6  0xb748 in ble_npl_event_run (ev=) at
>
> /home/jf/git/PineTime/src/libs/mynewt-nimble/porting/npl/freertos/include/nimble/nimble_npl_os.h:115
> #7  nimble_port_run () at /home/jf/git/PineTime/src/main.cpp:266
>
> > Also could you share btsnoop logs?
>
> Do you mean the HCI logs from BLE_MONITOR_RTT I get using btmon ? I'll
> let it run overnight to get fresh logs.
>
> Thanks,
> JF
>
>
> Le 06/08/2021 10:45, Łukasz Rymanowski a écrit :
> > Hi JF,
> >
> > I need to admit that I totally missed the part that you are on FreeRTOS
> > but
> > I see DEBUG lines that work for you.
> > On the first picture you see radio activity every advertising interval
> > and
> > on the second one you see a single advertising event - all looks good.
> >
> > Anyway, the question now is why BLE_GAP_EVENT_ADV_COMPLETE is sent with
> > a
> > timeout. Did you try to debug it by setting breakpoint at
> > ble_gap_adv_finished?
> > Also could you share btsnoop logs?
> >
> > Bes
> > Łukasz
> >
> >
> > On Tue, 3 Aug 2021 at 20:37,  wrote:
> >
> >> > If you have nrf52 you could trace radio activity with some debug pins
> >> > BLE_PHY_DBG_TIME_ADDRESS_END_PIN
> >> > BLE_PHY_DBG_TIME_WFR_PIN
> >> > BLE_PHY_DBG_TIME_TXRXEN_READY_PIN
> >> >
> >> > Here you can find a description of those.
> >> >
> >>
> https://github.com/apache/mynewt-nimble/blob/master/nimble/drivers/nrf52/syscfg.yml#L35
> >>
> >> Thanks Łukasz! I've connected my logic analyzer (saleae logic 8) on 3
> >> pins, and I've also enabled the logging feature of nimble.
> >> When BLE is working fine and start advertising, I can see this in the
> >> logs :
> >>
> >>  app: GAP procedure initiated: advertise;
> >>  app: disc_mode=2
> >>  app:  adv_channel_map=0 own_addr_type=0 adv_filter_policy=0
> >> adv_itvl_min=0 adv_itvl_max=0
> >>  app:
> >>
> >> And when it stops, after 3 minutes:
> >>
> >>  app: Advertising event : BLE_GAP_EVENT_ADV_COMPLETE
> >>  app: advertise complete; reason=13n status=13
> >>
> >> See ble-adv1.png and ble-adv2.png for screenshots of the capture of
> >> the
> >> 3 pins.
> >>
> >> I left the device running during the whole day and in the evening, I
> >> tried to restart the advertising (with a push button) and... the logs
> >> are exactly the same (as if it was advertising correctly for 3 minutes
> >> and then complete) but... nothing on the 3 debug pins, they were just
> >> flat on low level. Obviously, the device was not found by my ble
> >> scanner.
> >>
> >> Sooo... any ideas :p ?
> >>
> >> Thanks!
> >>
> >> JF
>

Re: NimBLE stops working after ~24h

[Łukasz Rymanowski]

Hi JF,

I need to admit that I totally missed the part that you are on FreeRTOS but
I see DEBUG lines that work for you.
On the first picture you see radio activity every advertising interval and
on the second one you see a single advertising event - all looks good.

Anyway, the question now is why BLE_GAP_EVENT_ADV_COMPLETE is sent with a
timeout. Did you try to debug it by setting breakpoint at
ble_gap_adv_finished?
Also could you share btsnoop logs?

Bes
Łukasz


On Tue, 3 Aug 2021 at 20:37,  wrote:

> > If you have nrf52 you could trace radio activity with some debug pins
> > BLE_PHY_DBG_TIME_ADDRESS_END_PIN
> > BLE_PHY_DBG_TIME_WFR_PIN
> > BLE_PHY_DBG_TIME_TXRXEN_READY_PIN
> >
> > Here you can find a description of those.
> >
> https://github.com/apache/mynewt-nimble/blob/master/nimble/drivers/nrf52/syscfg.yml#L35
>
> Thanks Łukasz! I've connected my logic analyzer (saleae logic 8) on 3
> pins, and I've also enabled the logging feature of nimble.
> When BLE is working fine and start advertising, I can see this in the
> logs :
>
>  app: GAP procedure initiated: advertise;
>  app: disc_mode=2
>  app:  adv_channel_map=0 own_addr_type=0 adv_filter_policy=0
> adv_itvl_min=0 adv_itvl_max=0
>  app:
>
> And when it stops, after 3 minutes:
>
>  app: Advertising event : BLE_GAP_EVENT_ADV_COMPLETE
>  app: advertise complete; reason=13n status=13
>
> See ble-adv1.png and ble-adv2.png for screenshots of the capture of the
> 3 pins.
>
> I left the device running during the whole day and in the evening, I
> tried to restart the advertising (with a push button) and... the logs
> are exactly the same (as if it was advertising correctly for 3 minutes
> and then complete) but... nothing on the 3 debug pins, they were just
> flat on low level. Obviously, the device was not found by my ble
> scanner.
>
> Sooo... any ideas :p ?
>
> Thanks!
>
> JF

Re: BLE GATTS Chatacteristic Long Read

[Łukasz Rymanowski]

Hi,

Did you try ble_gattc_read_long() ?
Example of usage is here:
https://github.com/apache/mynewt-nimble/blob/master/apps/btshell/src/main.c#L1633
Best
Łukasz

On Sun, 25 Jul 2021 at 03:46, matt001k  wrote:
>
> Hello there,I was curious on how to handle long reads requests from a GATT 
> Client as it seems that long reads have to be handled by the application? 
> Forgive me if I'm wrong but I am just confused on this and cannot seem to 
> make sense of it. I've been struggling with this issue for a couple of days 
> now and cannot seem to pinpoint where it is occurring at.Get back to me at 
> your earliest convenience!Thanks,Matthew Krause

Re: [DISCUSS] Release Apache Mynewt 1.9.0-rc1 and Apache NimBLE 1.4.0-rc1

[Łukasz Rymanowski]

+1

On Thu, 25 Mar 2021 at 02:20, Vipul  wrote:

> +1
>
> Have tried the latest mynewt build on nRF5340 along with mcuboot. Seems to
> be working fine.
>
> On Wed, Mar 24, 2021 at 5:03 PM Szymon Janc  wrote:
>
> > Hi all,
> >
> > This thread is for any and all discussion regarding the release of
> > Apache Mynewt 1.9.0 and Apache NimBLE 1.4.0.  All feedback is welcome.
> >
> > --
> > pozdrawiam
> > Szymon Janc
> >
> >
> >
>
> --
>
> Regards,
> Vipul Rahane
>

Re: ACL Data Packet size

[Łukasz Rymanowski]

Hi Switi,

Your understanding is about right. In Nimble controller it is by default
255, but in general host gets this value using hci le read buffer size.
Nimble Host reads it on startup and later expose it by
ble_hs_hci_max_acl_payload_sz()

To undertand more data exchange between host and the controller over HCI I
suggest to use use btmon as described here:
https://www.codecoup.pl/blog/support-for-btmon-in-mynewt/

Best
Łukasz


On Wed, 6 Jan 2021 at 18:35, Sweety Mhaiske  wrote:

> Hi,
>
> As the data between host and controller or vice versa is sent using ACL
> data packet, right?
> So does the size of the ACL data packet is fixed (i.e. 255 bytes) ?
>
> Say MTU is 512 bytes,
> which means the controller will get the data packet of 512 bytes( including
> header + actual data ), however when this 512 bytes of data will be sent to
> the host then it will get fragmented into 255 bytes  each i.e 3 packets
> will be sent ( 2 packets of 255 and 1 packet of remaining data and header )
>
> I want to confirm my understanding for the further development of my
> project.
> Waiting for your reply.
>
> Thanks & Regards,
> Switi.
>

Re: mynewt roadmap and future

[Łukasz Rymanowski]

Hello All,

Just wanted to say that there are people here to review and apply
patches. As Brian wrote - there is more love needed and that comes
from contributors - therefore please do not hesitate to upstream your
code as much as possible.

Codecoup cares about Mynewt and especially Nimble, where we keep contributing.

Best
Łukasz

On Tue, 8 Dec 2020 at 09:47, Brian Wyld  wrote:
>
> Hi all,
>
> I worked at Wyres SAS based in France, and we started using MyNewt on our 
> STM32L1 LoRa boards beginning of 2019. We got into it because it was 
> recommended by another French LoRa company (Kerlink) who use it as the base 
> OS for their LowPower-Iot LoRa Reference Design for lora objects.
> Initially for a student project to get experience with it, then integrated 
> into a CD/CI-build chain integrated with our gitlab/jenkins servers (to align 
> with our existing backend java dev CI). One of the major points in the favour 
> of MyNewt was the newt+yml build tools and the structure allowing a lot of 
> flexibility in the dev architecture
>
> We used it in our most recent product releases start 2020 (although Wyres has 
> now been absorbed by Kerlink and this product range is no longer available).
>
> As part of our dev, we aimed to build 'useful' blocks as repos on top of 
> MyNewt to help the application development
>  - simpler logging/error handling integrated with the assert/reboot cycle to 
> help with debug
>  - some basic utilities (circular buffers, gps nema parsing, cbor) forked in 
> from other projects
>  - a lorawan stack wrapper with an api suited to async operation
> -  blocks to homogenise/manage config, time, gpios, leds, low power, uart 
> access, ble and gps operations
>  - state machine framework to structure the application around a state 
> machine event-based pattern
>  - core application framework as a generic state machine that fits a lot of 
> IOT device operations (so the core device operation and message format is 
> very stable across mulltiple products) and a plugin 'module' architecture for 
> product specific operations (eg doing sensor reading, or accessing a GPS).
> The config framework offered by mynewt via the pgk.yml and syscfg.yml was 
> critical to being able to structure and make independant the framework - it 
> helps a lot for the re-use design!
>
> --publicity alert--
> all of this code is released under an open source apache license, runs 
> directly on MyNewt, and is available on github here:
> https://github.com/wyres/mynewt-generic-base
> https://github.com/wyres/mynewt-generic-app
> (as well as the BSP for our lora card)
> --end alert--
>
> MyNewt is not perfect, there are rough edges or overly complex bits (IMHO!) 
> which make some functionality hard to use (we rolled our own device driver 
> code and config apis for example)
> Wish list?
> Improve the newt build speed:
> - have the 'newt' tool be more intelligent about which yml files it parses 
> (currently every one it finds, rather than those referenced by the target 
> being build)
> - move the BSP modules into separate repos, to lighten the mynewt-core repo 
> and increase build speeds (and also change updates that reference BSPs that I 
> don't care about!)
> Add control of the low power operation (alert bsp/app to low power entry, 
> allow selection of low power 'level' by app, etc)
>  - we added some features to a fork of the core for this for our MCU (but 
> haven't managed to make this a viable/acceptable PR yet...)
>
> As a final point, it seems like FreeRTOS and Zephyr are getting a lot more of 
> the 'visibility' right now (due to integration with some big names) - I think 
> the biggest risk for MyNewt is falling behind in the BSP/MCU support race and 
> not getting the love it deserves!
>
> I see I have written a lot more than I intended - sorry about that - hope 
> some of it helped!
>
> A+
>
> Brian
>
> 
> De : Vipul Rahane 
> Envoyé : lundi 7 décembre 2020 22:49
> À : dev@mynewt.apache.org 
> Objet : Re: mynewt roadmap and future
>
> Hello Mike and others,
>
> I have started working for Proxy Inc recently and it gives me
> immense pleasure to mention that Proxy has been using mynewt since a few
> years and have deployed a lot of products using the same. We would be
> contributing a few drivers, middleware modules and BLE related
> functionality to mynewt in 2021. While I am a bit of an active maintainer
> of mynewt, we should see more soon :-). Others using mynewt, please chime
> in.
>
> On Tue, Dec 1, 2020 at 2:10 PM Aditi Hilbert 
> wrote:
>
> > Hi Mike,
> >
> > We used Mynewt OS + NimBLE in our first connected product offering at Juul
> > Labs. We decided to use it on our next connected device as well. In the
> > process we worked on and submitted PRs for the NimBLE controller + host
> > code that runs on a new Dialog chip. We hope to get that Bluetooth SIG
> > certified in the next few months. NimBLE has been ported to Linux,
> > FreeRTOS, Riot as well - 

Re: missing "newtmgr/newtmgr.h"

[Łukasz Rymanowski]

Hi Ondrej,

I think you should look into apache-mynewt-core/mgmt/smp
I think it is now smp_transport_init() but I'm not sure.

Best
Łukasz

On Fri, 14 Aug 2020 at 10:48, Ondrej Pilat  wrote:

> Hi Łukasz,
>
> Is there a porting manual from newtmgr API to mcumgr?
>
> We are using nmgr_transport_init and newtmgr_process what are mcumgr
> equivalents?
>
> Regards
>
> Ondrej
> Dne 8/14/2020 v 9:46 AM Łukasz Rymanowski napsal(a):
>
> Hi Ondrej,
>
> Newtmgr has been removed as we moved to mcumgr (
> https://github.com/apache/mynewt-mcumgr) , which is basically an
> extracted version of newtmgr.
> It is in release notes:
> https://cwiki.apache.org/confluence/display/MYNEWT/RN-1.8.0
>
> Best
> Łukasz
>
>
> On Fri, 14 Aug 2020 at 09:32, Ondrej Pilat 
> wrote:
>
>> Hi all,
>>
>> we used newtmgr in application for image update and its management. When
>> we upgrade apache-mynewt-core to the latest version 1.8.0 newtmgr.h and
>> newtmgr.c is missing. What we should use instead or why newtmgr support was
>> removed from the 1.8.0?
>>
>> We need to upgrade apache-mynewt-core because 1.7.0 isn't compatible with
>> the latest changes in the tinyusb repo (nrf52 USB API changed).
>>
>> Best regards
>>
>> Ondrej Pilat
>> --
>>
> --
>

Re: missing "newtmgr/newtmgr.h"

[Łukasz Rymanowski]

Hi Ondrej,

Newtmgr has been removed as we moved to mcumgr (
https://github.com/apache/mynewt-mcumgr) , which is basically an
extracted version of newtmgr.
It is in release notes:
https://cwiki.apache.org/confluence/display/MYNEWT/RN-1.8.0

Best
Łukasz


On Fri, 14 Aug 2020 at 09:32, Ondrej Pilat  wrote:

> Hi all,
>
> we used newtmgr in application for image update and its management. When
> we upgrade apache-mynewt-core to the latest version 1.8.0 newtmgr.h and
> newtmgr.c is missing. What we should use instead or why newtmgr support was
> removed from the 1.8.0?
>
> We need to upgrade apache-mynewt-core because 1.7.0 isn't compatible with
> the latest changes in the tinyusb repo (nrf52 USB API changed).
>
> Best regards
>
> Ondrej Pilat
> --
>

Re: Nimble on NRF52 : connectivity issue with Android, stack seems to freeze

[Łukasz Rymanowski]

Hi Mo Chen,

I'm actually using Mynewt OS where OTA is supported when using MCUBoot.
Maybe worth considering using MCUBoot?

Best
Łukasz

On Mon, 15 Jun 2020 at 17:19, Mo Chen  wrote:

> Hi Lukasz,
>
> We are also trying FreeRTOS + Nimble on nrf52. Have you realized DFU OTA
> via BLE with FreeRTOS? We are not sure if this is something doable.
>
> Thanks,
>
> On Sun, Jun 14, 2020 at 4:19 PM Łukasz Rymanowski <
> lukasz.rymanow...@codecoup.pl> wrote:
>
> > Hi,
> >
> > so indeed your logs show that after trying to read include services from
> > GATT service, something bad happened. Controller was able to ACK 2
> > following master packets then it stopped to send ACKs.
> > Do you have a console available? If so, does it show anything
> interesting?
> >
> > For further debugging I suggest to look at BLE_MONITOR_RTT to grab hci
> logs
> > (https://www.codecoup.pl/blog/support-for-btmon-in-mynewt/)
> > With this we will know if response is still in the host or is in the
> > controller.
> >
> > Then we could check some stats e.g. ble_ll_stats - maybe that could show
> us
> > something interesting - but first let us see where it stuck.
> >
> > Best
> > Łukasz
> >
> > On Sun, 14 Jun 2020 at 21:06,  wrote:
> >
> > > Hi,
> > >
> > > It looks like the attachements were dropped somewhere... You can
> > > download them on my seafile instance :
> > > https://seafile.codingfield.com/d/64d53a6ca6b44ae6b5d7/
> > >
> > > It seems to fail during the discovery of the characteristics on the
> > > device. From what I understand, it happens during the discovery of
> > > Generic Access Profile and Generic Attributes Profile, which are
> handled
> > > by nimble.
> > > I may be wrong, I'm a beginner with BLE and nimble!
> > > Maybe the captures will make more sens to you?
> > >
> > > Yeah, it's very strange that it works when the code is supposed to run
> > > slower... It makes me think of a timing or memory issue, but I couldn't
> > > find it...
> > >
> > > Thanks,
> > > JF
> > >
> > > Le 14/06/2020 20:46, Łukasz Rymanowski a écrit :
> > > > Hi,
> > > >
> > > > Thanks for the report, however looks like attachments are missing.
> > > >
> > > > First of all you need to understand what read fails i.e check handle
> > > > and
> > > > make sure that your application responds correctly.
> > > > It is very suspicious that read works with -Og, but still I would
> focus
> > > > on
> > > > that failing read first.
> > > >
> > > > Thanks
> > > > Lukasz
> > > >
> > > >
> > > > On Sun, Jun 14, 2020, 20:25  wrote:
> > > >
> > > >> Hello,
> > > >>
> > > >> I'm working on a firmware for the Pinetime, a smartwatch based on
> the
> > > >> NRF52832. The code is written in C/C++ and uses FreeRTOS.
> > > >> I've recently switched from the Nordic Softdevice to NimBLE as BLE
> > > >> stack. I used the freertos port from the 'porting' folder of the
> > > >> source
> > > >> code of nimble.
> > > >>
> > > >> I did many test using my PC on Linux : it can connect and
> communicate
> > > >> with the NRF52 without issue.
> > > >> However, things are not that easy when I try to connect using
> Android
> > > >> phone (I tried with a Huawei Psomething and my old Nexus5) : the
> > > >> connection fails most of the time.
> > > >>
> > > >> I did a lot of debugging, logging, sniffing,.. and I still cannot
> > > >> understand why it's not working as expected. Here are some of my
> > > >> observations:
> > > >>
> > > >>   - When Android successfully connects, I receive the following GAP
> > > >> events : BLE_GAP_EVENT_CONNECT and then BLE_GAP_EVENT_CONN_UPDATE 2
> > > >> times. The first update sets the connection interval to 6, the
> second
> > > >> one to 40.
> > > >>   - When it fails, I receive only the BLE_GAP_EVENT_CONNECT event
> and
> > > >> the
> > > >> 1st BLE_GAP_EVENT_CONN_UPDATE.
> > > >>   - Using the sniffer, I noticed that the last packet is a read
> > > >> request
> > > >> from the phone. It looks like the NRF52 never respond to this last
> > > &

Re: Nimble on NRF52 : connectivity issue with Android, stack seems to freeze

[Łukasz Rymanowski]

Hi,

so indeed your logs show that after trying to read include services from
GATT service, something bad happened. Controller was able to ACK 2
following master packets then it stopped to send ACKs.
Do you have a console available? If so, does it show anything interesting?

For further debugging I suggest to look at BLE_MONITOR_RTT to grab hci logs
(https://www.codecoup.pl/blog/support-for-btmon-in-mynewt/)
With this we will know if response is still in the host or is in the
controller.

Then we could check some stats e.g. ble_ll_stats - maybe that could show us
something interesting - but first let us see where it stuck.

Best
Łukasz

On Sun, 14 Jun 2020 at 21:06,  wrote:

> Hi,
>
> It looks like the attachements were dropped somewhere... You can
> download them on my seafile instance :
> https://seafile.codingfield.com/d/64d53a6ca6b44ae6b5d7/
>
> It seems to fail during the discovery of the characteristics on the
> device. From what I understand, it happens during the discovery of
> Generic Access Profile and Generic Attributes Profile, which are handled
> by nimble.
> I may be wrong, I'm a beginner with BLE and nimble!
> Maybe the captures will make more sens to you?
>
> Yeah, it's very strange that it works when the code is supposed to run
> slower... It makes me think of a timing or memory issue, but I couldn't
> find it...
>
> Thanks,
> JF
>
> Le 14/06/2020 20:46, Łukasz Rymanowski a écrit :
> > Hi,
> >
> > Thanks for the report, however looks like attachments are missing.
> >
> > First of all you need to understand what read fails i.e check handle
> > and
> > make sure that your application responds correctly.
> > It is very suspicious that read works with -Og, but still I would focus
> > on
> > that failing read first.
> >
> > Thanks
> > Lukasz
> >
> >
> > On Sun, Jun 14, 2020, 20:25  wrote:
> >
> >> Hello,
> >>
> >> I'm working on a firmware for the Pinetime, a smartwatch based on the
> >> NRF52832. The code is written in C/C++ and uses FreeRTOS.
> >> I've recently switched from the Nordic Softdevice to NimBLE as BLE
> >> stack. I used the freertos port from the 'porting' folder of the
> >> source
> >> code of nimble.
> >>
> >> I did many test using my PC on Linux : it can connect and communicate
> >> with the NRF52 without issue.
> >> However, things are not that easy when I try to connect using Android
> >> phone (I tried with a Huawei Psomething and my old Nexus5) : the
> >> connection fails most of the time.
> >>
> >> I did a lot of debugging, logging, sniffing,.. and I still cannot
> >> understand why it's not working as expected. Here are some of my
> >> observations:
> >>
> >>   - When Android successfully connects, I receive the following GAP
> >> events : BLE_GAP_EVENT_CONNECT and then BLE_GAP_EVENT_CONN_UPDATE 2
> >> times. The first update sets the connection interval to 6, the second
> >> one to 40.
> >>   - When it fails, I receive only the BLE_GAP_EVENT_CONNECT event and
> >> the
> >> 1st BLE_GAP_EVENT_CONN_UPDATE.
> >>   - Using the sniffer, I noticed that the last packet is a read
> >> request
> >> from the phone. It looks like the NRF52 never respond to this last
> >> read.
> >>   - It fails in the discovery steps (when the android phone discover
> >> all
> >> the services, characteristics and attributes) but not always at the
> >> same
> >> place.
> >>   - I noticed that the tasks (ll task and host task are not in
> >> deadlock
> >> BUT it looks like the radio ISR (ble_phy_isr() in ble_phy.c) is not
> >> called anymore.
> >>   - When I build the very same code in DEBUG (-Og instead of -O3), it
> >> works perfectly!
> >>
> >> You'll find in attachements 2 captures I did with Wireshark and the
> >> NRF
> >> Sniffer (running on a NRF52-DK), one failed and one successful attempt
> >> to connect.
> >>
> >> I'm running out of idea to debug this further. Is there a
> >> configuration
> >> issue (there are so many parameters in syscfg.h)? What could I try?
> >> Where should  I search ? Do you need more info to understand the
> >> issue?
> >>
> >> Could you help me fix this issue?
> >>
> >> Thanks,
> >>
> >> JF
>

Re: Nimble on NRF52 : connectivity issue with Android, stack seems to freeze

[Łukasz Rymanowski]

Hi,

Thanks for the report, however looks like attachments are missing.

First of all you need to understand what read fails i.e check handle and
make sure that your application responds correctly.
It is very suspicious that read works with -Og, but still I would focus on
that failing read first.

Thanks
Lukasz


On Sun, Jun 14, 2020, 20:25  wrote:

> Hello,
>
> I'm working on a firmware for the Pinetime, a smartwatch based on the
> NRF52832. The code is written in C/C++ and uses FreeRTOS.
> I've recently switched from the Nordic Softdevice to NimBLE as BLE
> stack. I used the freertos port from the 'porting' folder of the source
> code of nimble.
>
> I did many test using my PC on Linux : it can connect and communicate
> with the NRF52 without issue.
> However, things are not that easy when I try to connect using Android
> phone (I tried with a Huawei Psomething and my old Nexus5) : the
> connection fails most of the time.
>
> I did a lot of debugging, logging, sniffing,.. and I still cannot
> understand why it's not working as expected. Here are some of my
> observations:
>
>   - When Android successfully connects, I receive the following GAP
> events : BLE_GAP_EVENT_CONNECT and then BLE_GAP_EVENT_CONN_UPDATE 2
> times. The first update sets the connection interval to 6, the second
> one to 40.
>   - When it fails, I receive only the BLE_GAP_EVENT_CONNECT event and the
> 1st BLE_GAP_EVENT_CONN_UPDATE.
>   - Using the sniffer, I noticed that the last packet is a read request
> from the phone. It looks like the NRF52 never respond to this last read.
>   - It fails in the discovery steps (when the android phone discover all
> the services, characteristics and attributes) but not always at the same
> place.
>   - I noticed that the tasks (ll task and host task are not in deadlock
> BUT it looks like the radio ISR (ble_phy_isr() in ble_phy.c) is not
> called anymore.
>   - When I build the very same code in DEBUG (-Og instead of -O3), it
> works perfectly!
>
> You'll find in attachements 2 captures I did with Wireshark and the NRF
> Sniffer (running on a NRF52-DK), one failed and one successful attempt
> to connect.
>
> I'm running out of idea to debug this further. Is there a configuration
> issue (there are so many parameters in syscfg.h)? What could I try?
> Where should  I search ? Do you need more info to understand the issue?
>
> Could you help me fix this issue?
>
> Thanks,
>
> JF

Re: [VOTE] Release Apache Mynewt 1.8.0-rc2 and Apache NimBLE 1.3.0-rc2

[Łukasz Rymanowski]

+1 (binding)

On Thu, 2 Apr 2020 at 12:52, Andrzej Kaczmarek
 wrote:
>
> +1 (binding)
>
> /a.
>
> On Thu, Mar 26, 2020 at 5:27 PM Szymon Janc  wrote:
>
> > Hello all,
> >
> > I am pleased to be calling this vote for the source release of
> > Apache Mynewt 1.8.0 and Apache NimBLE 1.3.0.
> >
> > Apache Mynewt is a community-driven, permissively licensed open source
> > initiative for constrained, embedded applications. Mynewt provides a
> > real-time operating system, flash file system, network stacks, and
> > support utilities for real-world embedded systems.
> >
> > Apache NimBLE is Bluetooth Low Energy 5.1 stack from Apache Mynewt.
> >
> > This release is coordinated release of Apache Mynewt and NimBLE. Future
> > NimBLE releases may be released separately depending on needs.
> >
> > For full release notes for both Mynewt and NimBLE, please visit the Apache
> > Mynewt Wiki:
> > https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
> >
> > Comparing to rc1 only licensing issues were sorted out and there were no
> > code
> > changes.
> >
> > Apache Mynewt and Apache NimBLE release candidates were tested as follows:
> >   1. Manual execution of the Mynewt test plan:
> >
> > https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan
> >  The test results can be found at:
> >  https://cwiki.apache.org/confluence/display/MYNEWT/1.8.0+Test+Results
> >   2. Manual execution of the NimBLE test plan:
> >
> > https://cwiki.apache.org/confluence/display/MYNEWT/Apache+NimBLE+Test+Plan
> >  The test results can be found at:
> >
> > https://cwiki.apache.org/confluence/display/MYNEWT/NimBLE+1.3.0+Test+Results
> >   3. The full unit test suite for both releases was executed via "newt
> > test all"
> >  with no failures. This testing was performed on the following
> > platforms:
> >* OS X 10.15
> >* Fedora Linux 32
> >
> > Note that this testing is not yet complete and more results will show while
> > voting is ongoing.
> >
> > The release candidate to be voted on is available at:
> > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.8.0/rc2/
> > https://dist.apache.org/repos/dist/dev/mynewt/apache-nimble-1.3.0/rc2/
> >
> > The commits under consideration are as follows:
> > blinky:
> >   repos: https://github.com/apache/mynewt-blinky
> >   commit 34e9aae78f3ab4a4307bf99b4e25be11060aa526
> > core:
> >   repos: https://github.com/apache/mynewt-core
> >   commit cb9df4273aac1c8e627ff4df67b866ba9a22b018
> > newt:
> >   repos: https://github.com/apache/mynewt-newt
> >   commit 725740e08825a4a15d6270cccd7ff45fdd928312
> > newtmgr:
> >   repos: https://github.com/apache/mynewt-newtmgr
> >   commit 15c6a24d57d6dbdcf33646df365b2c64a12de251
> > nimble:
> >   repos: https://github.com/apache/mynewt-nimble
> >   commit 97ce3eacaaa79e8ed6cf71717149ced4f5328ee7
> >
> > In addition, the following newt and newtmgr convenience binaries are
> > available:
> >   linux:
> >
> > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.8.0/rc2/apache-mynewt-newt-bin-linux-1.8.0.tgz
> >
> > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.8.0/rc2/apache-mynewt-newtmgr-bin-linux-1.8.0.tgz
> >
> >   osx:
> >
> > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.8.0/rc2/apache-mynewt-newt-bin-osx-1.8.0.tgz
> >
> > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.8.0/rc2/apache-mynewt-newtmgr-bin-osx-1.8.0.tgz
> >
> >   windows:
> >
> > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.8.0/rc2/apache-mynewt-newt-bin-windows-1.8.0.tgz
> >
> > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.8.0/rc2/apache-mynewt-newtmgr-bin-windows-1.8.0.tgz
> >
> > The release candidate is signed with a GPG key available at:
> > https://dist.apache.org/repos/dist/dev/mynewt/KEYS
> >
> > The vote is open for at least 72 hours and passes if a majority of at
> > least three +1 PMC votes are cast.
> >
> > [ ] +1 Release this package
> > [ ]  0 I don't feel strongly about it, but don't object
> > [ ] -1 Do not release this package because...
> >
> > Anyone can participate in testing and voting, not just committers,
> > please feel free to try out the release candidate and provide your
> > votes.
> >
> > A separate [DISCUSS] thread will be opened to talk about this release
> > candidate.
> >
> > --
> > pozdrawiam
> > Szymon Janc
> >
> >
> >

Re: sensorhub bsp phase out proposal

[Łukasz Rymanowski]

It is actually really intereseting what that sensorhub is but if nobody has
an idea about that, let us remove it.
+1

On Thu, Nov 14, 2019, 16:49 Vipul Rahane  wrote:

> +1 it is
>
> On Thu, Nov 14, 2019 at 1:42 AM Fabio Utzig  wrote:
>
> >
> > On Thu, Nov 14, 2019, at 4:58 AM, Jerzy Kasenberg wrote:
> > >
> > > I propose to drop whatever support we have for this BSP so it will not
> be
> > > available in the next release.
> >
> > +1
> >
> --
>
> Regards,
> Vipul Rahane
>

Re: NimBLE: Optional support of mbedTLS instead of tinycrypt

[Łukasz Rymanowski]

Hi Prasad,

This is good idea however I think we need bit more for that than
syscfg flag. I think we could come up with some crypo API in ble_npl
so then anybody can add its own backend.

Best
Łukasz

On Fri, 27 Sep 2019 at 08:56, Prasad  wrote:
>
> Hi all,
>
> I am thinking of adding optional `mbedTLS` support for crypto instead of
> `tinycrypt`. I have basic framework in place, the idea is by default
> `tinycrypt` will be used, but any vendor who is already using or want to
> use `mbedTLS` can enable this option. Any inputs on how to make the
> option configurable (syscfg ?) and how to maintain upstream `mbedTLS` in
> mynewt framework (submodule ?) would be really helpful.
>
> Regards
>
> Prasad
>

Re: getting rid of ble_hs_dbg.c

[Łukasz Rymanowski]

Hi

On Mon, 23 Sep 2019 at 15:34, Andrzej Kaczmarek <
andrzej.kaczma...@codecoup.pl> wrote:

> Hi,
>
> On Wed, Sep 11, 2019 at 3:40 PM Szymon Janc 
> wrote:
>
> > Hi,
> >
> > Since we have BLE_MONITOR support which is far superior copmaring to
> > ble_hs_dbg.c... how about getting rid of that file?
> >
>
> I'm all for it and also for removing other "decoders" we have - these are
> likely not up to date with new features anyway.
>
>
> > Are there any active users relying on HCI events debugging via logs?
> >
>
> I never used it since it's just hard to follow - this was main reason why
> monitor interface was added to make analyzing HCI stream much easier.
>
>
I agree, however we need a way to grab HCI logs not only on Linux machines.
Maybe we could have some tool for Windows and maybe Macs which would store
logs from monitor interface?
Such logs could be easily read by btmon or wireshark.


>
> > --
> > pozdrawiam
> > Szymon Janc
> >
>
> Best,
> Andrzej
>

Best
Łukasz

Re: NimBLE library

[Łukasz Rymanowski]

Hi,

In Bluetooth LE you can read and set Channel Map from/to the controller.
Nimble has it implemented and application can make use of it by including
ble_hs_hci.h file.

Here are the functions you are looking for:
int ble_hs_hci_set_chan_class(const uint8_t *chan_map)
int ble_hs_hci_read_chan_map(uint16_t conn_handle, uint8_t *out_chan_map);

Best
Łukasz

On Tue, 20 Aug 2019 at 20:02, Elivander Judas Tadeu Pereira <
elivan...@mtel.inatel.br> wrote:

> Greetings,
>
> My name is Elivander J. T. Pereira and I'm an engineer from the
> telecommunications department of the National Institute of
> Telecommunications (INATEL - Brazil). I'm student of the Master's degree
> course in this College.
>
> I'm working with Cognitive Radio and Spectrum Sensing, to evaluate some
> projects in cooperative spectrum sensing we are trying to implement a
> project through the AFH protocol from the Bluetooth stack. However, since
> we had difficult to find how to use the channel map information data from
> the controller layer. Is this information possible to be accessed from the
> NimBLE code by other applications? I started to look the library this week
> and my perception is that the AFH protocol is implemented on the HCI code,
> is this correct?
>
> I appreciate any help, documentation or collaboration that can auxiliate
> us.
>
> Thanks and regards!
>
> Elivander J. T. Pereira
>

Re: Deprecate "install" and "sync" commands?

[Łukasz Rymanowski]

Hi Chris,

I'm with you on 3)

Best
Łukasz

On Mon, 5 Aug 2019 at 22:59, Fabio Utzig  wrote:
>
>
> On Mon, Aug 5, 2019, at 3:30 PM, Szymon Janc wrote:
> > Hi Chris,
> >
> > Yes!  I'm also for option 3. Lets deprecate for next (1.8) release (make
> > those print proper warning info when used) and just remove for 1.9.
>
> +1

Re: [VOTE] Release Apache Mynewt 1.7.0-rc2 and Apache NimBLE 1.2.0-rc2

[Łukasz Rymanowski]

+1 (binding)

On Wed, 31 Jul 2019 at 18:33, Vipul Rahane  wrote:
>
> +1 (binding)
>
> On Wed, Jul 31, 2019 at 8:56 AM Miguel Azevedo 
> wrote:
>
> > +1 (binding)
> >
> > On Wed, 31 Jul 2019, 16:54 Fabio Utzig,  wrote:
> >
> > > On Mon, Jul 29, 2019, at 8:39 AM, Szymon Janc wrote:
> > >
> > > > I am pleased to be calling this vote for the source release of
> > > > Apache Mynewt 1.7.0 and Apache NimBLE 1.2.0.
> > >
> > > > [ ] +1 Release this package
> > > > [ ]  0 I don't feel strongly about it, but don't object
> > > > [ ] -1 Do not release this package because...
> > >
> > > +1 (binding)
> > >
> >
> --
>
> Regards,
> Vipul Rahane

Re: Asking for help - Having trouble on PHY

[Łukasz Rymanowski]

Hi Silvia,

If it is getting back to 1M during transmission that means remote side did
it, however if you use Mynewt on both sides that would be odd as
Nimble controller does not change PHYs if not requested by Host.

In btshell, the `phy-set` command takes TX and RX mask, did you try to mask
out other PHYs and set just 2M on your connection?

Also it would be useful to see HCI logs so we know more what host is doing.
One of the way to grab them is described here:
https://www.codecoup.pl/blog/support-for-btmon-in-mynewt/

Best
Łukasz

On Thu, 9 May 2019 at 09:09, 林詩芸  wrote:

> Hi everyone,
>
> I'm new to mynewt and I'm trying to increase throughput using btshell and
> bleprph example app.
> The default PHY is 1M. Does someone know how to change PHY to 2M?
> I used ble_phy_mode_set(), but it seems that the PHY will get back to 1M
> during data transmission.
>
> Silvia
>

Re: Mynewt Nimble OOB pairing

[Łukasz Rymanowski]

Hi Amr,

yes this is the Android side issue. Actually when you look at  btsnoop you
can see Pairing Request showing OOB flag is 0.

 SMP: Pairing Request (0x01) len 6
IO capability: KeyboardDisplay (0x04)
OOB data: Authentication data not present (0x00)
Authentication requirement: Bonding, MITM, Legacy, No Keypresses
(0x05)
Max encryption key size: 16
Initiator key distribution: EncKey IdKey Sign (0x07)
Responder key distribution: EncKey IdKey Sign (0x07)

So having legacy paring you will not end up with using OOB as you also
concluded in your email.

However in logs I cannot see SMP Pairing Response, but I should see it if
you would use NoInputNoOutput on Nimble side as you said in previous email.
Could you confirm that you used different IO capabilities for this test?

Best
Łukasz

On Mon, 29 Apr 2019 at 20:20, Amr Bekhit  wrote:

> After some further research and debugging, I believe I've been chasing a
> red herring.
>
> Debugging the mynewt device during the pairing process shows that the
> requester (Android phone) does not have its OOB bit set (this can be seen
> in ble_sm_lgcy_io_action). This explains why OOB was failing. It turns out
> the pairing over NFC OOB was only added the Android in version 7 Nougat
> (see
>
> https://devzone.nordicsemi.com/b/blog/posts/nrf52832-and-android-nougat-simple-and-secure-touc
>  and https://devzone.nordicsemi.com/b/blog/posts/the-art-of-pairing). The
> Android device I'm using to test runs Android 6.
>
> So this explains why things aren't working as expected.
>
> On Mon, 29 Apr 2019 at 19:38, Amr Bekhit  wrote:
>
> > Hi  Łukasz,
> >
> > I've sent you the Android Bluetooth HCI log separately to your email.
> >
> > The log was saved while the following events took place:
> >
> >- With my device in idle mode, I used my phone to read the device's
> >NFC tag. I configured the NFC tag to represent a Bluetooth Carrier
> >Configuration Record, and included in it is the device address, role
> and my
> >hard-coded TK value. You can see the contents of the NFC tag as read
> by
> >Android below
> >
> > ▪▪ FORMAT ▪▪
> > Media (0x02)
> > Defined by RFC 2046
> >
> > ▪▪ TYPE ▪▪
> > application/vnd.bluetooth.le.oob
> >
> > ▪▪ PAYLOAD (30 bytes) ▪▪
> > 0x08 0x1B 0xAD 0x02 0x4B 0x8E 0x1B 0xFB 0x00 0x02 0x1C 0x00 0x11 0x10
> 0x01
> > 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F
> 0x10
> >
> >
> >- When the NFC tag is read, the device starts advertising.
> >- The Android device responds to the tag by bringing up a pop up
> >dialog asking if I would like to pair with the device. When I tap on
> yes,
> >the Android device attempts to pair.
> >- At this point, BLE_GAP_EVENT_PASSKEY_ACTION is called in the device.
> >However, the contents of event->passkey.params.action is
> BLE_SM_IOACT_DISP
> >and not BLE_SM_IOACT_OOB.
> >- The pairing fails.
> >
> > For your information, the Android device I'm using only goes up to BLE
> > 4.1, so I believe it only supports Legacy Pairing. If that is the case,
> > then according to
> >
> https://www.bluetooth.com/blog/bluetooth-pairing-part-2-key-generation-methods/
> ,
> > both requester and responder need to have their OOB flags set. I have a
> > feeling that the Android phone doesn't and as such, the device is falling
> > back to passkey pairing.
> >
> > Would you able to confirm this?
> >
> > On Sat, 27 Apr 2019 at 01:04, Łukasz Rymanowski <
> > lukasz.rymanow...@codecoup.pl> wrote:
> >
> >> Hi Amr,
> >>
> >> please ignore my last email, as it will not work.
> >>
> >> You should actually get BLE_GAP_EVENT_PASSKEY_ACTION with
> >> action=BLE_SM_IOACT_OOB, so there must be some bug I guess.
> >> You said you are doing your test with Android - could you send btsnoop
> >> from
> >> your Android device or take btmon logs from Mynewt side (
> >> https://www.codecoup.pl/blog/support-for-btmon-in-mynewt/)
> >>
> >> Best
> >> Łukasz
> >>
> >> On Fri, 26 Apr 2019 at 23:04, Łukasz Rymanowski <
> >> lukasz.rymanow...@codecoup.pl> wrote:
> >>
> >> > Hi Amr,
> >> >
> >> > I would call it on gap connected event. Then OOB data are stored and
> SM
> >> > can present/use OOB flag during pairing.
> >> >
> >> > Best
> >> > Lukasz
> >> >
> >> > On Fri, Apr 26, 2019, 18:57 Amr Bekhit  wrote:
> >> >
> >>

Re: Mynewt Nimble OOB pairing

[Łukasz Rymanowski]

Hi Amr,

I would call it on gap connected event. Then OOB data are stored and SM can
present/use OOB flag during pairing.

Best
Lukasz

On Fri, Apr 26, 2019, 18:57 Amr Bekhit  wrote:

> Hi  Łukasz,
>
> Thanks for your reply. Where and when should the call to ble_sm_inject_io
> take place? In my current setup, I had configured my device to use passkey
> pairing, but for testing purposes, was hardcoding the passkey. The BLE
> stack was requesting the passkey by calling the GAP event callback with
> event->type = BLE_GAP_EVENT_PASSKEY_ACTION. I was then passing the passkey
> as follows:
>
> if (event->passkey.params.action == BLE_SM_IOACT_DISP) {
> pk.action = event->passkey.params.action;
> pk.passkey = 123456;
> rc = ble_sm_inject_io(event->passkey.conn_handle, );
> dprintf("ble_sm_inject_io result: %d\n", rc);
> }
>
> In order to support OOB, I've changed my BLE syscfg configuration to the
> following (modified SM_IO_CAP, SM_OOB_DATA_FLAG and SM_MITM):
>
> BLE_ROLE_CENTRAL: 0
> BLE_ROLE_OBSERVER: 0
>
> BLE_SM_LEGACY: 1
> BLE_SM_SC: 1
> BLE_SM_IO_CAP: BLE_HS_IO_NO_INPUT_OUTPUT
> BLE_SM_OOB_DATA_FLAG: 1
> BLE_SM_MITM: 1
> BLE_SM_BONDING: 1
> BLE_SM_OUR_KEY_DIST: BLE_SM_PAIR_KEY_DIST_ENC | BLE_SM_PAIR_KEY_DIST_ID |
> BLE_SM_PAIR_KEY_DIST_SIGN | BLE_SM_PAIR_KEY_DIST_LINK
> BLE_SM_THEIR_KEY_DIST: BLE_SM_PAIR_KEY_DIST_ENC | BLE_SM_PAIR_KEY_DIST_ID |
> BLE_SM_PAIR_KEY_DIST_SIGN | BLE_SM_PAIR_KEY_DIST_LINK
> BLE_STORE_CONFIG_PERSIST: 1
>
> I've tried replacing the code in BLE_GAP_EVENT_PASSKEY_ACTION with the
> following code to load in a hard-coded TK:
>
> if (event->passkey.params.action == BLE_SM_IOACT_OOB) {
> pk.action = event->passkey.params.action;
> uint8_t tk[16] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};
> memcpy(pk.oob, tk, sizeof(tk));
> rc = ble_sm_inject_io(event->passkey.conn_handle, );
> dprintf("ble_sm_inject_io result: %d\n", rc);
> }
>
> However, it appears that BLE_GAP_EVENT_PASSKEY_ACTION is now not being
> called anymore.
>
> So the question is, at what point and where would I call ble_sm_inject_io
> to insert the TK value?
>
> Amr
>
>
> On Fri, 26 Apr 2019 at 14:16, Łukasz Rymanowski <
> lukasz.rymanow...@codecoup.pl> wrote:
>
> > Hi Amr,
> >
> > Nimble does  support OOB for Legacy and Secure Connections Pairing.
> > In both cases you just need to provide OOB (TK)  data exchanged by other
> > means e.g. NFC to the NimBLE stack  using "int ble_sm_inject_io(uint16_t
> > conn_handle, struct ble_sm_io *pkey)".
> >
> > For Secure Connection make sure to set MYNEWT_VAL BLE_SM_SC to 1.
> >
> > Hope that helps
> >
> > Best
> > Łukasz
> >
> >
> >
> > On Thu, 25 Apr 2019 at 22:19, Amr Bekhit  wrote:
> >
> > > Hello all,
> > >
> > > I'm interested in using OOB pairing over NFC to connect my peripheral
> > > device to a master (an Android phone in this case). The NFC Forum has a
> > > specification (
> > >
> > >
> >
> https://nfc-forum.org/our-work/specifications-and-application-documents/application-documents/
> > > )
> > > which dictates how two NFC-capable BLE devices can exchange key
> > > information. As far as I can tell from the specification, for BLE, the
> > > peripheral can send its temporary key (TK) via NFC to the central.
> > > Presumably, both parties would then enter that key into their Bluetooth
> > > stacks and continue the connection process from that point on using
> just
> > > BLE.
> > >
> > > Regarding this, I have the following question. Using the nimble stack,
> > how
> > > can we get the peripheral to
> > > a) generate a TK and then enter that TK into the stack.
> > > b) continue the connection from that point forwards?
> > >
> > > I noticed that the aforementioned specification document doesn't seem
> to
> > > mention BLE Secure Connections - the TK is an aspect of BLE legacy
> > pairing.
> > > Does anyone know if there is a version of the standard that works with
> > BLE
> > > Secure Connection keys? Perhaps the assumption is that NFC pairing
> > provides
> > > the required identify verification and MITM protection that is provided
> > by
> > > BLE SC and so BLE Legacy can be used with the same level of security?
> > >
> > > Amr
> > >
> >
>

Re: Mynewt Nimble OOB pairing

[Łukasz Rymanowski]

Hi Amr,

Nimble does  support OOB for Legacy and Secure Connections Pairing.
In both cases you just need to provide OOB (TK)  data exchanged by other
means e.g. NFC to the NimBLE stack  using "int ble_sm_inject_io(uint16_t
conn_handle, struct ble_sm_io *pkey)".

For Secure Connection make sure to set MYNEWT_VAL BLE_SM_SC to 1.

Hope that helps

Best
Łukasz



On Thu, 25 Apr 2019 at 22:19, Amr Bekhit  wrote:

> Hello all,
>
> I'm interested in using OOB pairing over NFC to connect my peripheral
> device to a master (an Android phone in this case). The NFC Forum has a
> specification (
>
> https://nfc-forum.org/our-work/specifications-and-application-documents/application-documents/
> )
> which dictates how two NFC-capable BLE devices can exchange key
> information. As far as I can tell from the specification, for BLE, the
> peripheral can send its temporary key (TK) via NFC to the central.
> Presumably, both parties would then enter that key into their Bluetooth
> stacks and continue the connection process from that point on using just
> BLE.
>
> Regarding this, I have the following question. Using the nimble stack, how
> can we get the peripheral to
> a) generate a TK and then enter that TK into the stack.
> b) continue the connection from that point forwards?
>
> I noticed that the aforementioned specification document doesn't seem to
> mention BLE Secure Connections - the TK is an aspect of BLE legacy pairing.
> Does anyone know if there is a version of the standard that works with BLE
> Secure Connection keys? Perhaps the assumption is that NFC pairing provides
> the required identify verification and MITM protection that is provided by
> BLE SC and so BLE Legacy can be used with the same level of security?
>
> Amr
>

Re: switching to mcuboot

[Łukasz Rymanowski]

Hi again,

On Fri, 12 Apr 2019 at 11:00, Łukasz Rymanowski <
lukasz.rymanow...@codecoup.pl> wrote:

> Hi Szymon,
>
> Like the idea - I think we also need newt tool to point to some mcuboot
> version right?
>
Ah nevermind, all is in the mentioned PR :)


>
> Best
> Łukasz
>
>
Łukasz


> On Fri, 12 Apr 2019 at 10:50, Szymon Janc  wrote:
>
>> Hi,
>>
>> As discussed on several occasions we want to move away from bootutils and
>> start using mcuboot project directly.
>>
>> PR implementing this is here
>> https://github.com/apache/mynewt-core/pull/1763
>> It is not yet ready to be merged due to some issues with tests on mcuboot
>> side
>>
>> Open points for this PR which I'd like to get some feedback on:
>>  - fixing (or removing?) tests that are executed with newt test all
>>  - should newt create-image default to new image header version (-2
>> option)
>> once we switch to mcuboot?
>>  - which mcuboot version should core track? Since it is external project I
>> suggest that master
>>   tracks 1-latest and when we release we stick to latest released version
>> at that time (eg core 1.7.0 would depend on mcuboot 1.3.0, 1.8 on 1.4.0 if
>> released etc)
>>
>>
>> --
>> pozdrawiam
>> Szymon K. Janc
>>
>

Re: switching to mcuboot

[Łukasz Rymanowski]

Hi Szymon,

Like the idea - I think we also need newt tool to point to some mcuboot
version right?

Best
Łukasz

On Fri, 12 Apr 2019 at 10:50, Szymon Janc  wrote:

> Hi,
>
> As discussed on several occasions we want to move away from bootutils and
> start using mcuboot project directly.
>
> PR implementing this is here
> https://github.com/apache/mynewt-core/pull/1763
> It is not yet ready to be merged due to some issues with tests on mcuboot
> side
>
> Open points for this PR which I'd like to get some feedback on:
>  - fixing (or removing?) tests that are executed with newt test all
>  - should newt create-image default to new image header version (-2 option)
> once we switch to mcuboot?
>  - which mcuboot version should core track? Since it is external project I
> suggest that master
>   tracks 1-latest and when we release we stick to latest released version
> at that time (eg core 1.7.0 would depend on mcuboot 1.3.0, 1.8 on 1.4.0 if
> released etc)
>
>
> --
> pozdrawiam
> Szymon K. Janc
>

Re: [VOTE] Release Apache Mynewt 1.6.0-rc2 and Apache NimBLE 1.1.0-rc2

[Łukasz Rymanowski]

+1 (binding)

On Wed, 3 Apr 2019 at 13:18, Michał Narajowski <
michal.narajow...@codecoup.pl> wrote:

> +1 (binding)
>
> śr., 3 kwi 2019 o 12:39 Miguel Azevedo  napisał(a):
> >
> > +1 binding
> >
> > On Wed, 3 Apr 2019, 11:31 Fabio Utzig,  wrote:
> >
> > > > [ ] +1 Release this package
> > > > [ ]  0 I don't feel strongly about it, but don't object
> > > > [ ] -1 Do not release this package because...
> > >
> > > +1 (binding)
> > >
>

Re: MYNEWT_VAL(...) invalid syntax ?

[Łukasz Rymanowski]

Hi Markus,

If master is used on mynewt-core then master branch of newt tool should be
used. Please try this and let us know of it works for you

Best
Lukasz


On Tue, Jan 8, 2019, 06:18 markus  'been away for a few months and I can't build my projects anymore. I
> updated repos/apache-mynewt-core to the latest master branch (59912fc02)
> and it seems I'm running the latest newt tool, 1.5.0
>
> Executing `newt build ...` gives me an error for each package in
> apache-mynewt-core:
>
> * Warning: Parsing pkg @apache-mynewt-core/boot/boot_serial config:
>   strconv.ParseInt: parsing
>   "MYNEWT_VAL(BOOT_SERIAL_SYSINIT_STAGE_MAIN)": invalid syntax;
>   ignoring package.
>
>
> I couldn't find anything in the release notes - any clues as to what
> I'm doing wrong would be much appreciated.
>
> Thanks,
> Markus
>

Re: NimBLE Extended Scan

[Łukasz Rymanowski]

Hi Marc,

You do receive ext adv:

> HCI Event: LE Meta Event (0x3e) plen 78#339 26.976500
  LE Extended Advertising Report (0x0d)

Best
Łukasz

On Wed, 10 Oct 2018 at 19:00, Marc BT  wrote:
>
> Hi Łukasz,
>
> The bad, my mistake, I took the wrong app  (starting with blehci helps).
>
> To conclude, I can monitor the events using RTT, however the events (EXT ADV) 
> are not visible on the HCI  (all event masks are enabled Events, Events Page2 
>  Events).
>
> Kind regards,
> Marc
> 
> From: Marc BT 
> Sent: Wednesday, October 10, 2018 5:50 PM
> To: Łukasz Rymanowski
> Cc: dev@mynewt.apache.org
> Subject: Re: NimBLE Extended Scan
>
> Hi Łukasz,
>
> The good: the RTT is working  ...
> > HCI Event: LE Meta Event (0x3e) plen 78#339 
> > 26.976500
>   LE Extended Advertising Report (0x0d)
> Num reports: 1
> Entry 0
>   Event type: 0x0001
> Props: 0x0001
>   Connectable
> Data status: Complete
>   Address type: Public (0x00)
> ..
>
> I grabbed the following repo's from (I hope these are the correct ones, e.g. 
> newt is now 1.5.0-dev):
>
>   *   https://github.com/apache/mynewt-core.git
>
>   *   https://github.com/apache/mynewt-nimble.git
>   *   
> https://github.com/apache/mynewt-newt.gi<https://github.com/apache/mynewt-newt.git>t
>
> The bad: When I plug in the device in my test environment I unable to connect 
> to it through Python (pyserial), even when recompiling and setting the 
> BLE_HCI_UART_BAUD variable (115200). This worked with the images build using 
> the release version (newt 1..4.1 & nimble 1.0.0).
>
> Kind regards,
> Marc
> 
> From: Łukasz Rymanowski 
> Sent: Wednesday, October 10, 2018 9:15 AM
> To: bt_m...@outlook.com
> Cc: dev@mynewt.apache.org
> Subject: Re: NimBLE Extended Scan
>
> Hi Marc,
>
> So it means you are on release tags and in that time this RTT channel
> was called monitor instead of btmonitor
> But I suggest you to move to master on apache-mynewt-nimble and also
> on apache-mynewt-core.
>
> There was quite a lot of fixes for ext scan/advertising done after
> release, and whatever issue you find we will want you to retest on
> master anyway :)
>
> Best
> Łukasz
> On Tue, 9 Oct 2018 at 18:02, Marc BT  wrote:
> >
> >
> > Hi Łukasz,
> >
> > There still seems to be a discrepancy between the, BTW nice, tutorial and 
> > what I have.
> >
> > I've tried the set-scan-opts ignore_legacy=1 but returned me rc=2 (I 
> > haven't looked in the code yet).
> >
> >
> > These are my settings (for what it is useful):
> >
> > I'm using Linux Mint 19 / latest updates (I had some issues with Mint 
> > 18.x), moved to a real PC instead of a Virtual PC (VMWare) to run Linux.
> > I'm having a Nordic nRF5284PDK and a nRF5284DK. The last one I'm using for 
> > the RTT.
> > I used the newt target amend btshell syscfg= to generate the 
> > targets/btshell/syscfg.yml file
> >
> > $ arm-none-eabi-gcc -v
> > Using built-in specs.
> > COLLECT_GCC=arm-none-eabi-gcc
> > COLLECT_LTO_WRAPPER=/usr/bin/../lib/gcc/arm-none-eabi/7.3.1/lto-wrapper
> > Target: arm-none-eabi
> > Configured with: 
> > /build/gcc-arm-none-eabi-2DWmz3/gcc-arm-none-eabi-7-2018q2/src/gcc/configure
> >  --target=arm-none-eabi 
> > --prefix=/build/gcc-arm-none-eabi-2DWmz3/gcc-arm-none-eabi-7-2018q2/install-native
> >  
> > --libexecdir=/build/gcc-arm-none-eabi-2DWmz3/gcc-arm-none-eabi-7-2018q2/install-native/lib
> >  
> > --infodir=/build/gcc-arm-none-eabi-2DWmz3/gcc-arm-none-eabi-7-2018q2/install-native/share/doc/gcc-arm-none-eabi/info
> >  
> > --mandir=/build/gcc-arm-none-eabi-2DWmz3/gcc-arm-none-eabi-7-2018q2/install-native/share/doc/gcc-arm-none-eabi/man
> >  
> > --htmldir=/build/gcc-arm-none-eabi-2DWmz3/gcc-arm-none-eabi-7-2018q2/install-native/share/doc/gcc-arm-none-eabi/html
> >  
> > --pdfdir=/build/gcc-arm-none-eabi-2DWmz3/gcc-arm-none-eabi-7-2018q2/install-native/share/doc/gcc-arm-none-eabi/pdf
> >  --enable-languages=c,c++ --enable-plugins --disable-decimal-float 
> > --disable-libffi --disable-libgomp --disable-libmudflap 
> > --disable-libquadmath --disable-libssp --disable-libstdcxx-pch 
> > --disable-nls --disable-shared --disable-threads --disable-tls 
> > --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes 
> > --with-python-dir=share/gcc-arm-none-eabi 
> > --with-sysroot=/build/gcc-arm-none-eabi-2DWmz3/gcc-ar

Re: NimBLE Extended Scan

[Łukasz Rymanowski]

0x01 (1) (SCANNED_PHY_1M)
>  AdvSid : 0x0A (10)
>  TxPower: 0x7F (127)
>  RSSI   : 0xCB (203)
>  DirectAddrType : 0xFF (255) (ADDRTYPE_NONE)
>  DirectAddr : 00:00:00:00:00:00
>  PeriodicAdvInt : 0x (0)
>  DataLength : 0x0034 (52)
>  Data   : 19:09:48:65:6C:6C:6F:2C:20:49:27:6D:20:61:64:76:
>   65:72:74:69:73:69:6E:67:20:31:19:09:48:65:6C:6C:
>   6F:2C:20:49:27:6D:20:61:64:76:65:72:74:69:73:69:
>   6E:67:20:32
> Dump(Rx):
> :04 FF 53 13 06 00 00 00 40 00 01 00 11 22 33 44 ..S.@"3D
> 0010:55 66 01 01 0A 7F CB FF 00 00 00 00 00 00 00 00 Uf..
> 0020:34 00 19 09 48 65 6C 6C 6F 2C 20 49 27 6D 20 61 4...Hello, I'm a
> 0030:64 76 65 72 74 69 73 69 6E 67 20 31 19 09 48 65 dvertising 1..He
> 0040:6C 6C 6F 2C 20 49 27 6D 20 61 64 76 65 72 74 69 llo, I'm adverti
> 0050:73 69 6E 67 20 32   sing 2
> 
>
> Nordic (from the putty window):
> 551229 Extended adv: 'conn' complete rssi=-52 txpower=127, pphy=1, sphy=1, 
> sid=10, addr_type=0 addr=66:55:44:33:22:11
> 551232  length_data=52 
> data=0x19:0x09:0x48:0x65:0x6c:0x6c:0x6f:0x2c:0x20:0x49:0x27:0x6d:0x20:0x61:0x64:0x76:0x65:0x72:0x74:0x69:0x73:0x69:0x6e:0x67:0x20:0x31:0x19:0x09:0x48:0x65:0x6c:0x6c:0x6f:0x2c:0x20:0x49:0x27:0x6d:0x20:0x61:0x64:0x76:0x65:0x72:0x74:0x69:0x73:0x69:0x6e:0x67:0x20:0x32
>  fields:
> 551240 name(complete)=Hello, I'm advertising 2
>
> Thanks & Kind regards,
> Marc
> 
> From: Łukasz Rymanowski 
> Sent: Tuesday, October 9, 2018 1:28 PM
> To: dev@mynewt.apache.org
> Subject: Re: NimBLE Extended Scan
>
> Hi Marc,
>
> On Tue, 9 Oct 2018 at 09:59, Marc BT  wrote:
> >
> > Hi Łukasz,
> >
> > Thanks for quick reply and a quick update.
> >
> > I followed the guideline ...got a bit confused on the logging of the 
> > rtt2pty tool:
> > ../tools-rtt2pty/rtt2pty -b btmonitor
> > Using jlinkarm found at /opt/SEGGER/JLink/libjlinkarm.so
> > Connected to:
> >   J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 12 2018 11:44:41
> >   S/N: 683623237
> > Searching for RTT control block...
> > Failed to find matching up-buffer
> >
>
> That would mean BLE_MONITOR_RTT: 1 is not set as in the tutorial.
> Could you please double check, rebuild, flash and try one more time?
>
> > Running it without the -b btmonitor I could get a pty port.
> >
> > Monitoring showed some logging, not like the one from the codecoup btmon 
> > link but a starting point.
> >
> > 021819 Extended adv: 'conn' incomplete rssi=-60 txpower=127, pphy=1, 
> > sphy=1, sid=10, addr_type=0 addr=66:55:44:33:22:11
> > 021822  length_data=229 
> > data=0x19:0x09:0x48:0x65:0x6c:0x6c:0x6f:0x2c:0x20:0x49:0x27:0x6d:0x20:0x61:0x64:0x76:0x65:0x72:0x74:0x69:0x7
> > 
> > 021853 Extended adv: 'conn' complete rssi=-60 txpower=127, pphy=1, sphy=1, 
> > sid=10, addr_type=0 addr=66:55:44:33:22:11
> > 021856  length_data=15 
> > data=0x69:0x6e:0x67:0x20:0x39:0x19:0x09:0x48:0x65:0x6c:0x6c:0x6f:0x2c:0x20:0x49
> >  fields:
> > 021859
> > 021859 Extended adv: 'conn' incomplete rssi=-53 txpower=127, pphy=1, 
> > sphy=1, sid=10, addr_type=0 addr=66:55:44:33:22:11
> > 021862  length_data=229 
> > data=0x19:0x09:0x48:0x65:0x6c:0x6c:0x6f:0x2c:0x20:0x49:0x27:0x6d:0x20:0x61:0x64:0x76:0x65:0x72:0x74:0x69:0x7
> > 
> > 
> > 021861 received advertisement; event_type=4 rssi=-82 addr_type=1 
> > addr=f1:80:b4:61:d2:c6 length_data=29 
> > data=0x02:0x0a:0x04:0x19:0x09:0x45:0x78:0x70:0x65:0x72:0x74:0x26:0x4d:0x69:0x6c:0x6b:0x5f:0x46:0x31:0x38:0x30:0x42:0x34:0x36:0x31:0x44:0x32:0x43:0x35
> >  fields:
> > 021868 name(complete)=Expert_F180B461D2C5
> > 021869 tx_pwr_lvl=4
> >
> > Time to start further debugging
> >
>
> Note that printing lot of data on the console might break your
> scanning, especially long chaining.
> Have a look at command  `set-scan-opts` which can help you to limit
> number of bytes to print out.
> Also there is an option to filter out legacy advertising.
>
>
> > Thank,
> > Marc
>
> Best
> Łukasz
>
> >
> > >Hello Marc,
> > >
> > >There is no additional configuration needed as long as you are using 1M 
> > >PHY.
> > >Would be good to get some logs and best would be to have btmon logs:
> > >https://www.codecoup.pl/blog/support-for-btmon-in-mynewt/
> > >
> > >Best
> > >Łukasz
> > >>On Mon, 8 Oct 2018 at 12:29, Marc BT

Re: NimBLE Extended Scan

[Łukasz Rymanowski]

Hi Marc,

On Tue, 9 Oct 2018 at 09:59, Marc BT  wrote:
>
> Hi Łukasz,
>
> Thanks for quick reply and a quick update.
>
> I followed the guideline ...got a bit confused on the logging of the rtt2pty 
> tool:
> ../tools-rtt2pty/rtt2pty -b btmonitor
> Using jlinkarm found at /opt/SEGGER/JLink/libjlinkarm.so
> Connected to:
>   J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 12 2018 11:44:41
>   S/N: 683623237
> Searching for RTT control block...
> Failed to find matching up-buffer
>

That would mean BLE_MONITOR_RTT: 1 is not set as in the tutorial.
Could you please double check, rebuild, flash and try one more time?

> Running it without the -b btmonitor I could get a pty port.
>
> Monitoring showed some logging, not like the one from the codecoup btmon link 
> but a starting point.
>
> 021819 Extended adv: 'conn' incomplete rssi=-60 txpower=127, pphy=1, sphy=1, 
> sid=10, addr_type=0 addr=66:55:44:33:22:11
> 021822  length_data=229 
> data=0x19:0x09:0x48:0x65:0x6c:0x6c:0x6f:0x2c:0x20:0x49:0x27:0x6d:0x20:0x61:0x64:0x76:0x65:0x72:0x74:0x69:0x7
> 
> 021853 Extended adv: 'conn' complete rssi=-60 txpower=127, pphy=1, sphy=1, 
> sid=10, addr_type=0 addr=66:55:44:33:22:11
> 021856  length_data=15 
> data=0x69:0x6e:0x67:0x20:0x39:0x19:0x09:0x48:0x65:0x6c:0x6c:0x6f:0x2c:0x20:0x49
>  fields:
> 021859
> 021859 Extended adv: 'conn' incomplete rssi=-53 txpower=127, pphy=1, sphy=1, 
> sid=10, addr_type=0 addr=66:55:44:33:22:11
> 021862  length_data=229 
> data=0x19:0x09:0x48:0x65:0x6c:0x6c:0x6f:0x2c:0x20:0x49:0x27:0x6d:0x20:0x61:0x64:0x76:0x65:0x72:0x74:0x69:0x7
> 
> 
> 021861 received advertisement; event_type=4 rssi=-82 addr_type=1 
> addr=f1:80:b4:61:d2:c6 length_data=29 
> data=0x02:0x0a:0x04:0x19:0x09:0x45:0x78:0x70:0x65:0x72:0x74:0x26:0x4d:0x69:0x6c:0x6b:0x5f:0x46:0x31:0x38:0x30:0x42:0x34:0x36:0x31:0x44:0x32:0x43:0x35
>  fields:
> 021868 name(complete)=Expert_F180B461D2C5
> 021869 tx_pwr_lvl=4
>
> Time to start further debugging
>

Note that printing lot of data on the console might break your
scanning, especially long chaining.
Have a look at command  `set-scan-opts` which can help you to limit
number of bytes to print out.
Also there is an option to filter out legacy advertising.


> Thank,
> Marc

Best
Łukasz

>
> >Hello Marc,
> >
> >There is no additional configuration needed as long as you are using 1M PHY.
> >Would be good to get some logs and best would be to have btmon logs:
> >https://www.codecoup.pl/blog/support-for-btmon-in-mynewt/
> >
> >Best
> >Łukasz
> >>On Mon, 8 Oct 2018 at 12:29, Marc BT  wrote:
> >>
> >> Hello all,
> >>
> >> I'm trying to configure two Nordic nRF52840-DK boards, one as advertiser 
> >> (Extended Advertise),
> the other as scanner (Extended Scan).
> >>
> >> Compile settings (newt target amend ):
> >>
> >>   *   BLE_EXT_ADV = 1
> >>   *   BLE_EXT_ADV_MAX_SIZE = 700
> >>
> >>  I've used a TI kit to verify the existence of Extended Advertising.
> >>
> >> The  board configured as Extended Advertiser works, the advertising 
> >> packets can be seen
> on the TI board.
> >> The board configured as Extended Scanner doesn't return any advertising 
> >> events.
> >>
> >> The HCI commands to setup the Extended Scan don't return any status error.
> >>
> >> Am I missing some compile switches ?
> >>
> >> Kind regards,
> >> Marc
>
> 
> From: Marc BT
> Sent: Monday, October 8, 2018 12:13 PM
> To: dev@mynewt.apache.org
> Subject: NimBLE Extended Scan
>
> Hello all,
>
> I'm trying to configure two Nordic nRF52840-DK boards, one as advertiser 
> (Extended Advertise), the other as scanner (Extended Scan).
>
> Compile settings (newt target amend ):
>
>   *   BLE_EXT_ADV = 1
>   *   BLE_EXT_ADV_MAX_SIZE = 700
>
>  I've used a TI kit to verify the existence of Extended Advertising.
>
> The  board configured as Extended Advertiser works, the advertising packets 
> can be seen on the TI board.
> The board configured as Extended Scanner doesn't return any advertising 
> events.
>
> The HCI commands to setup the Extended Scan don't return any status error.
>
> Am I missing some compile switches ?
>
> Kind regards,
> Marc

Re: NimBLE Extended Scan

[Łukasz Rymanowski]

Hello Marc,

There is no additional configuration needed as long as you are using 1M PHY.
Would be good to get some logs and best would be to have btmon logs:
https://www.codecoup.pl/blog/support-for-btmon-in-mynewt/

Best
Łukasz
On Mon, 8 Oct 2018 at 12:29, Marc BT  wrote:
>
> Hello all,
>
> I'm trying to configure two Nordic nRF52840-DK boards, one as advertiser 
> (Extended Advertise), the other as scanner (Extended Scan).
>
> Compile settings (newt target amend ):
>
>   *   BLE_EXT_ADV = 1
>   *   BLE_EXT_ADV_MAX_SIZE = 700
>
>  I've used a TI kit to verify the existence of Extended Advertising.
>
> The  board configured as Extended Advertiser works, the advertising packets 
> can be seen on the TI board.
> The board configured as Extended Scanner doesn't return any advertising 
> events.
>
> The HCI commands to setup the Extended Scan don't return any status error.
>
> Am I missing some compile switches ?
>
> Kind regards,
> Marc

Re: NimBLE host GAP event listeners

[Łukasz Rymanowski]

Hi
On Fri, 7 Sep 2018 at 21:12, Andrzej Kaczmarek <
andrzej.kaczma...@codecoup.pl> wrote:

> Hi Chris,
>
> On Fri, Sep 7, 2018 at 8:00 PM Christopher Collins 
> wrote:
>
> > Hello all,
> >
> > TL;DR: Proposal for registration of GAP event listeners in the NimBLE
> > host.  Currently, GAP event callbacks are specified by the code which
> > creates a connection.  This proposal allows code to listen for GAP
> > events without creating a connection.
> >
> > The NimBLE host allows the application to associate callbacks with GAP
> > events.  Callbacks are configured *per connection*.  When the
> > application initiates a connection, it specifies a single callback to
> > be executed for all GAP events involving the connection.  Similarly,
> > when the application starts advertising, it specifies the callback to
> > use with the connection that may result.
> >
> > This design provides some degree of modularity.  If a package
> > independently creates a connection, it can handle all the relevant GAP
> > events without involving other packages in the system.  However, there
> > is a type of modularity that this does not provide: *per event*
> > callbacks.  If a package doesn't want to initiate any GAP events, but
> > it wants to be notified every time a connection is established (for
> > example), there is no way to achieve this.  The problem here is that
> > there is only a single callback associated with each connection.  What
> > we really need is a list of callbacks that all get called whenever a
> > GAP event occurs.
> >
> > My proposal is to add the following to the NimBLE host API:
> >
> > struct ble_gap_listener {
> > /*** Public. */
> > ble_gap_event_fn *fn;
> > void *arg;
> >
> > /*** Internal. */
> > STAILQ_ENTRY(ble_gap_listener) next;
> > };
> >
> > /**
> >  * @brief Registers a BLE GAP listener.
> >  *
> >  * When a GAP event occurs, callbacks are executed in the following
> >  * order:
> >  * 1. Connection-specific GAP event callback.
> >  * 2. Each registered listener, in the order they were registered.
> >  *
> >  * @param listener The listener to register.
> >  */
> > void ble_gap_register(struct ble_gap_listener *listener);
> >
> > /**
> >  * @brief Unregisters a BLE GAP listener.
> >  *
> >  * @param listener The listener to unregister.
> >  *
> >  * @return  0 on success;
> >  *  BLE_HS_ENOENT if the listener is
> >  *  not registered.
> >  */
> > int ble_gap_unregister(struct ble_gap_listener *listener);
> >
> > Initially, I thought this functionality could be achieved with a new
> > package implemented on top of the host (call it `blemux`).
> > Unfortunately, I think there are some issues that make such an approach
> > unwieldy for the user.  I imagined such a package would be used as
> > follows:
> >
> > 1. The `blemux` package exposes a GAP callback (call it
> >`blemux_gap_event`).
> > 2. Elsewhere in the sytem, for each GAP function call, the caller
> >specifies `blemux_gap_event` as the callback.
> > 3. Each package that is interested in GAP events registers one or
> >more listeners via `blemux_register()`.
> > 4. When a GAP event occurs, `blemux_gap_event` is executed.  This
> >callback executes every registered listener.
> >
> > The problem is that packages have no guarantee that the app is using
> > blemux.  A package can depend on `blemux` and can register listeners,
> > but it really only works if every other BLE-aware package in the system
> > also uses `blemux`.  If any package doesn't use `blemux`, then the GAP
> > procedures that it initiates won't be reported to the `blemux`
> > listeners.  A secondary problem is that this just feels like a clumsy
> > API.  It is confusing and error prone to need to specify
> > `blemux_gap_event` as the GAP event callback.
> >
> > So, I think this functionality should be implemented directly in the
> > host.
> >
>
>
Like the idea. We could use it for mesh as well - for now we have dedicated
API for Mesh to register for GAP events.
With this change we could get rid of it.


> Sounds exactly like something I wrote some time ago, so I can only agree
> with above :-)
> Typical scenario here (and what I was doing) is that external package, like
> service, wants to be notified about connection or characteristic
> subscription state. Currently we do this by exposing extra API from package
> which app needs to call from GAP callbacks in order to everything work
> properly. It works, but it's really clunky. Hooks provided by host are imo
> good way to handle this.
>
> I did not finish my service so forgot to send a PR with NimBLE changes, but
> here they are for reference - I can create PR if they look ok.
>
> 

Re: [VOTE] Release Apache Mynewt 1.4.1-rc1

[Łukasz Rymanowski]

Hi

On Fri, Jun 22, 2018, 16:14 Szymon Janc  wrote:

> Hello all,
>
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.4.1.
>
> Apache Mynewt is a community-driven, permissively licensed open source
> initiative for constrained, embedded applications. Mynewt provides a
> real-time operating system, flash file system, network stacks, and
> support utilities for real-world embedded systems.
>
> This is a bugfix only release fixing BLE connection creation in central
> role
> on Nordic nRF51, flashing issues on Nordic nRF52840 and building errors on
> Windows for newt and newtmgr tools.
>
> For full release notes, please visit the Apache Mynewt Wiki:
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
>
> This release candidate was tested as follows:
>   1. Manual execution of the Mynewt test plan:
>  https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test
> +Plan
>  The test results can be found at:
>  https://cwiki.apache.org/confluence/display/MYNEWT/1.4.1+Test+Results
>
>  Note that only features affected by bugfixes were tested for this
> release. If you feel more testing is needed please provide your results
> here.
>
>   2. The full unit test suite for this release was executed via "newt
>  test all" with no failures.  This testing was performed on the
>  following platforms:
>* OS X 10.13
>* Ubuntu Linux 18.04
>
>
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.1/rc1/
>
> The commits under consideration are as follows:
> blinky:
>   repos: https://github.com/apache/mynewt-blinky
>   commit bb43247a7e28a1f5e5d869f1088cb4ae53a1
> core:
>   repos: https://github.com/apache/mynewt-core
>   commit f0ce13e45c51825c35963fb13f2562d5911ef1ed
> newt:
>   repos: https://github.com/apache/mynewt-newt
>   commit ac0db20a10ea042e253012c30b6261d722e11093
> newtmgr:
>   repos: https://github.com/apache/mynewt-newtmgr
>   commit 4d5d517d2a99c2f2c4b322e872714ea702c1a88f
>
> In addition, the following newt convenience binaries are available:
>   linux:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.1/
> rc1/apache-mynewt-newt-bin-linux-1.4.1.tgz
> 
>   osx:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.1/rc1/
> apache-mynewt-newt-bin-osx-1.4.1.tgz
> 
>
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
>
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ X] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
>

+1 (binding)

Best
Łukasz


> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes.
>
> A separate [DISCUSS] thread will be opened to talk about this release
> candidate.
>
> --
> pozdrawiam
> Szymon Janc
>
>
>
>
>

Re: Apache Mynewt Passkey Authentication

[Łukasz Rymanowski]

Hi,

Please have a look on
https://mynewt.apache.org/network/ble/btshell/btshell_GAP/  at Security part

Regarding your questsion:

1) yes
2) In example below my device is peripheral with iocapa=DisplayOnly. We are
already connected with connection handle = 1.

* security-set-data mitm_flag=1 io_capabilities=0 our_key_dist=7
their_key_dist=7 bonding=1 sc=1
* security-start conn=1

After this you should see on the console:
` passkey action event; action=3'

Here is actually a place where we should improve with documentation.
Action=3 means Display, but btshell does not generate passkey for you.
Instead you need to provide it by calling:
auth-passkey conn=1 action=3 key=

Then provide same on your phone and you are done.

BTW. Action types you can find in ble_sm.h

Hope that helps

\Łukasz




On Thu, 7 Jun 2018 at 11:54, Aditya Xavier  wrote:

> Hi all,
>
> I wanted to create an application which would request a Mobile connecting
> to it a Passkey which when provided correctly would allow the gatt
> connections to work.
>
> 1. Is this even possible ?
> 2. How do I achieve this, I have gone through several examples like
> btshell etc but could not figure out the direction.
>
>
> Thanks,
> Aditya Xavier.

Re: [RFC] Mesh uses multi advertising instances.

[Łukasz Rymanowski]

Hi Aditya,
On Wed, 23 May 2018 at 09:43, Aditya Xavier <adityaxav...@me.com> wrote:

> Hi Łukasz,
>
>
> Just saw a PR which you raised, does this fix the problem we were
> discussing ?
>

I don't think it fixes it.  I will put info on the issue you created once
it is done.

>
> Also, the example I gave you has Device Address being generated Randomly.
> Is it possible to use Mesh with a Public BLE Address ?
>

Yes, you just need to set it using  MYNEW_VAL with address you like: e.g.
BLE_PUBLIC_DEV_ADDR: ((uint8_t[6]){0x11, 0xaa, 0xbb, 0xcc, 0xdd, 0xee})
and then use it. You can check cmd_mesh_init() in shell.c file how we do it.


>
> Thanks,
> Aditya Xavier.
>
> Best
\Łukasz

>
> > On 19-May-2018, at 7:41 PM, Aditya Xavier <adityaxav...@me.com> wrote:
> >
> > Hi Łukasz,
> >
> > Thanks for looking into it.
> >
> > Have raised an issue in Github for the same.
> >
> > Thanks,
> > Aditya Xavier.
> >
> >
> >> On 19-May-2018, at 6:05 PM, Łukasz Rymanowski <
> lukasz.rymanow...@codecoup.pl> wrote:
> >>
> >> Hi,
> >>
> >>
> >> On Sat, May 19, 2018, 14:21 Aditya Xavier <adityaxav...@me.com> wrote:
> >>
> >>> Hi Michał / Łukasz,
> >>>
> >>> Were you able to identify the issue ? Do let me know if you need any
> >>> further testing from my end.
> >>>
> >>
> >> We found one issue. Not yet PR bit you can apply patch for you to test
> >>
> >> ble_adv_copy_to_ext_param(struct ble_gap_ext_adv_params *ext_param,
> >> const struct ble_gap_adv_params *param)
> >> @@ -510,6 +522,7 @@ ble_adv_copy_to_ext_param(struct
> ble_gap_ext_adv_params
> >> *ext_param,
> >>   ext_param->itvl_min = param->itvl_min;
> >>   ext_param->channel_map = param->channel_map;
> >>   ext_param->high_duty_directed = param->high_duty_cycle;
> >> +ext_param->own_addr_type = g_mesh_addr_type;
> >> }
> >>
> >>
> >> This is not yet solving the issue but you should see adv going out from
> >> Device which uses BLE_EXT_ADV and uses non public address.
> >>
> >>
> >>> Also, do you recommend I submit a new Issue on Github for the same ?
> >>>
> >>
> >> Please do it.
> >>
> >> \Łukasz
> >>
> >>
> >>> From my testing its pretty apparent that BLE_EXT_ADV does not allow
> >>> bt_mesh_model_send  ( mesh_init.c Line 155 ) to work anymore.
> >>>
> >>> Regarding the issue of Device B not receiving messages till around
> 15-50
> >>> attempts, I believe it requires further deep dive.
> >>>
> >>> Am under the assumption that BLE_EXT_ADV does not actually require BLE
> to
> >>> be used and just Mesh to be configured.
> >>>
> >>> Do let me know if there are any issues in the code / my thought
> process.
> >>>
> >>> Thanks,
> >>> Aditya Xavier.
> >>>
> >>>
> >>>
> >>>> On 19-May-2018, at 12:23 PM, Aditya Xavier <adityaxav...@me.com>
> wrote:
> >>>>
> >>>> Hi Michał,
> >>>>
> >>>> Sorry fo the confusion. I have done some more testing on the same,
> >>> please find the test results in the xl file.
> >>>>
> >>>> Please note, the test results are of Device A; wherein the Device B is
> >>> kept in the same state ( with all the mentioned flags turned off)
> >>>>
> >>>> Also, test cases 2 - 5 have an issue wherein right after loading the
> >>> firmware Device A would receive Messages from Dev B.
> >>>>
> >>>> However, Device A would not be able to send messages to Dev B, till
> >>> around 15-50 attempts. A restart of Dev B helps.
> >>>>
> >>>> The initial delay to receive messages was what I thought not working
> >>> earlier.
> >>>> 
> >>>>
> >>>> Thanks,
> >>>> Aditya Xavier.
> >>>>
> >>>>
> >>>>> On 18-May-2018, at 6:27 PM, Michał Narajowski <
> >>> michal.narajow...@codecoup.pl> wrote:
> >>>>>
> >>>>> Hi Aditya,
> >>>>>
> >>>>> BLE_ROLE_BROADCASTER should not have an impact on this. There is only
> >>> one
> >>>>> place in the code where this

Re: [RFC] Mesh uses multi advertising instances.

[Łukasz Rymanowski]

ith only BLE_ROLE* flags disabled on Device B and all three flags
> >>> disabled on Device B, and unique node_address.
> >>>> Device A ( button Pressed )-> Device B should say in the Log Received.
> >>>> Device B ( button Pressed )-> Device A will not receive any message.
> >>>>
> >>>> Thanks,
> >>>> Aditya Xavier.
> >>>>
> >>>>
> >>>>> On 18-May-2018, at 3:23 PM, Michał Narajowski <
> >>> michal.narajow...@codecoup.pl> wrote:
> >>>>>
> >>>>> Hi Aditya,
> >>>>>
> >>>>> I enabled these flags:
> >>>>>
> >>>>> BLE_ROLE_BROADCASTER: 1
> >>>>> BLE_ROLE_PERIPHERAL: 1
> >>>>> BLE_EXT_ADV: 1
> >>>>>
> >>>>> And this is what i see after pushing the button a few times:
> >>>>>
> >>>>> 045120 #mesh-onoff STATUS
> >>>>> 045121 #mesh-onoff STATUS: Sent !
> >>>>> 045123 Received
> >>>>> 045263 #mesh-onoff STATUS
> >>>>> 045264 #mesh-onoff STATUS: Sent !
> >>>>> 045266 Received
> >>>>> 045402 #mesh-onoff STATUS
> >>>>> 045402 #mesh-onoff STATUS: Sent !
> >>>>> 045404 Received
> >>>>> 045535 #mesh-onoff STATUS
> >>>>> 045536 #mesh-onoff STATUS: Sent !
> >>>>> 045538 Received
> >>>>> 046559 #mesh-onoff STATUS
> >>>>> 046559 #mesh-onoff STATUS: Sent !
> >>>>> 046561 Received
> >>>>> 046601 #mesh-onoff STATUS
> >>>>> 046602 #mesh-onoff STATUS: Sent !
> >>>>> 046604 Received
> >>>>> 046627 #mesh-onoff STATUS
> >>>>> 046628 #mesh-onoff STATUS: Sent !
> >>>>> 046630 Received
> >>>>> 046656 #mesh-onoff STATUS
> >>>>> 046656 #mesh-onoff STATUS: Sent !
> >>>>> 046658 Received
> >>>>>
> >>>>>
> >>>>>
> >>>>> Is this what I should see? What are your symptoms?
> >>>>>
> >>>>> Best regards
> >>>>> Michał Narajowski
> >>>>>
> >>>>> pt., 18 maj 2018 o 11:47 Aditya Xavier <adityaxav...@me.com>
> >>> napisał(a):
> >>>>>
> >>>>>> Hi Łukasz,
> >>>>>>
> >>>>>> Disabling only the following flags in syscfg.yml allows the device
> to
> >>>>>> receive but not send mesh messages.
> >>>>>>
> >>>>>> BLE_ROLE_BROADCASTER: 1
> >>>>>> BLE_ROLE_PERIPHERAL: 1
> >>>>>>
> >>>>>> Disabling BLE_EXT_ADV: 1, flag allows the device to send and receive
> >>> mesh
> >>>>>> messages.
> >>>>>>
> >>>>>> And as I said earlier enabling all three of them, does not allow the
> >>>>>> device to send / receive mesh messages.
> >>>>>>
> >>>>>> It is quite possible its a mistake on my end. Would be grateful if
> you
> >>> let
> >>>>>> me know what am I doing wrong :)
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Aditya Xavier.
> >>>>>>
> >>>>>>
> >>>>>>> On 18-May-2018, at 2:59 PM, Aditya Xavier <adityaxav...@me.com>
> >>> wrote:
> >>>>>>>
> >>>>>>> Hi Łukasz,
> >>>>>>>
> >>>>>>> Am actually sending it to the Group Address.
> >>>>>>>
> >>>>>>> In main.c :- Line 27
> >>>>>>> void button_cb(struct os_event *ev)
> >>>>>>> {
> >>>>>>> mesh_msg_send(MODEL_ID_CBOR_ACTION, GROUP_ADDR, "HELLO WORLD", 12);
> >>>>>>>
> >>>>>>> }
> >>>>>>>
> >>>>>>> And its relevant method :-
> >>>>>>>
> >>>>>>> In mesh_init.c :- Line 138.
> >>>>>>> void mesh_msg_send(uint16_t model_id, uint16_t target_address, char
> >>>>>> *tmsg, uint16_t tlen)
> >>>>>>> {
> >>>>>>> st

Re: New to community

[Łukasz Rymanowski]

Hi,

Did you mean Mynewt? If so and you don't mind Eclipse then here it is:
https://www.codecoup.pl/blog/hacking-mynewt-in-eclipse/

If you meant newt then I don't have a tutorial for this.

Best
Łukasz

On Sun, 13 May 2018 at 01:27, Naasik Hendricks 
wrote:

> Hi all
>
> Thank you for the great platform. I wanted to ask if anyone has a tutorial
> for settings up IDE for newt?
>
> Kind regards
>
> Naasik
>

Re: [RFC] Mesh uses multi advertising instances.

[Łukasz Rymanowski]

Hi,

We found the issue which was related to latest controller changes.
Basically controller does not allow now to mix legacy HCI with ext adv HCI
which of course is good. The PR
https://github.com/apache/mynewt-nimble/pull/8  is fixed now.
I removed RFC and I plan to merge it soon.

@Aditya - feedback very welcome.

\Łukasz

On Mon, 7 May 2018 at 13:41, Łukasz Rymanowski <
lukasz.rymanow...@codecoup.pl> wrote:

> Hi Aditya,
>
> Sorry for late answer.
>
> Could you please provide btmon logs along with console logs so we can help
> you to analyze what is going on?
> Here is instruction how to get btmon logs:
> https://www.codecoup.pl/blog/support-for-btmon-in-mynewt/
>
> Thanks and best regards
> Łukasz
>
>
> On Fri, 27 Apr 2018 at 11:48, Aditya Xavier <adityaxav...@me.com> wrote:
>
>> Hi Łukasz,
>>
>> Any update on it? Were you able to check this ?
>>
>> Bt_mesh_model_send does not work after enabling BLE_EXT_ADV..
>>
>> Or, can you give me a sample code where it works so that I can check if
>> there is something am doing wrong.
>>
>> Thanks,
>> Aditya Xavier.
>>
>>
>> > On 20-Apr-2018, at 3:56 PM, Aditya Xavier <adityaxav...@me.com> wrote:
>> >
>> > Hi Łukasz,
>> >
>> > Thanks, was able to build btshell + blemesh into nrf52832.
>> >
>> > I think I found an issue with regards to bt_mesh_model_send method.
>> >
>> > It seems bt_mesh_model_send is no longer working.
>> >
>> > In my test app, I have remove all ble code, and using only blemesh (
>> auto provisioning ) and send a message to another device over mesh on a
>> press of a button.
>> >
>> > When I disable BLE_EXT_ADV and BLE_MULTI_ADV_INSTANCES, it works.
>> >
>> > Can you try and confirm it works ?
>> >
>> > Thanks,
>> > Aditya Xavier
>> >
>> >> On 19-Apr-2018, at 2:00 PM, Łukasz Rymanowski <
>> lukasz.rymanow...@codecoup.pl <mailto:lukasz.rymanow...@codecoup.pl>>
>> wrote:
>> >>
>> >> Hi Aditya,
>> >>
>> >> I suggest to hack around flash map instead of removing code.
>> >>
>> >> I would do something like this (hopefully calculations are OK).
>> >>
>> >> +++ b/hw/bsp/nrf52dk/bsp.yml
>> >> @@ -41,11 +41,11 @@ bsp.flash_map:
>> >>FLASH_AREA_IMAGE_0:
>> >>device: 0
>> >>offset: 0x8000
>> >> -size: 232kB
>> >> +size: 462kB
>> >>FLASH_AREA_IMAGE_1:
>> >>device: 0
>> >> -offset: 0x00042000
>> >> -size: 232kB
>> >> +offset: 0x0007B800
>> >> +size: 2kB
>> >>FLASH_AREA_IMAGE_SCRATCH:
>> >>device: 0
>> >>offset: 0x0007c000
>> >> diff --git a/hw/bsp/nrf52dk/nrf52xxaa.ld b/hw/bsp/nrf52dk/nrf52xxaa.ld
>> >> index 9433e37fd..55e293da1 100644
>> >> --- a/hw/bsp/nrf52dk/nrf52xxaa.ld
>> >> +++ b/hw/bsp/nrf52dk/nrf52xxaa.ld
>> >> @@ -17,7 +17,7 @@
>> >> */
>> >> MEMORY
>> >> {
>> >> -  FLASH (rx) : ORIGIN = 0x8000, LENGTH = 0x3a000
>> >> +  FLASH (rx) : ORIGIN = 0x8000, LENGTH = 0x73800
>> >>  RAM (rwx) : ORIGIN = 0x2000, LENGTH = 0x1
>> >> }
>> >>
>> >>
>> >> Make sure to rebuild boot and app and then try.
>> >>
>> >> Best
>> >> Łukasz
>> >>
>> >> On 19 April 2018 at 07:30, Aditya Xavier <adityaxav...@me.com > adityaxav...@me.com> <mailto:adityaxav...@me.com > adityaxav...@me.com>>> wrote:
>> >>
>> >>> Hi Łukasz,
>> >>>
>> >>> PFA the app I used to test Mesh using multi advertising instances.
>> >>>
>> >>> I get the following error.
>> >>> [ts=275343728ssb, mod=4 level=3] adv_send: Advertising failed: err 3
>> >>>
>> >>>
>> >>>
>> >>> I had to comment out a lot of code to get it in a flash-able size.
>> >>>
>> >>> Thanks,
>> >>> Aditya Xavier.
>> >>>
>> >>>
>> >>> On 18-Apr-2018, at 1:13 PM, Aditya Xavier <adityaxav...@me.com
>> <mailto:adityaxav...@me.com>> wrote:
>> >>>
>> >>> Hi Łukasz,
>> >>>
&

Re: [RFC] Mesh uses multi advertising instances.

[Łukasz Rymanowski]

Hi Aditya,

Sorry for late answer.

Could you please provide btmon logs along with console logs so we can help
you to analyze what is going on?
Here is instruction how to get btmon logs:
https://www.codecoup.pl/blog/support-for-btmon-in-mynewt/

Thanks and best regards
Łukasz


On Fri, 27 Apr 2018 at 11:48, Aditya Xavier <adityaxav...@me.com> wrote:

> Hi Łukasz,
>
> Any update on it? Were you able to check this ?
>
> Bt_mesh_model_send does not work after enabling BLE_EXT_ADV..
>
> Or, can you give me a sample code where it works so that I can check if
> there is something am doing wrong.
>
> Thanks,
> Aditya Xavier.
>
>
> > On 20-Apr-2018, at 3:56 PM, Aditya Xavier <adityaxav...@me.com> wrote:
> >
> > Hi Łukasz,
> >
> > Thanks, was able to build btshell + blemesh into nrf52832.
> >
> > I think I found an issue with regards to bt_mesh_model_send method.
> >
> > It seems bt_mesh_model_send is no longer working.
> >
> > In my test app, I have remove all ble code, and using only blemesh (
> auto provisioning ) and send a message to another device over mesh on a
> press of a button.
> >
> > When I disable BLE_EXT_ADV and BLE_MULTI_ADV_INSTANCES, it works.
> >
> > Can you try and confirm it works ?
> >
> > Thanks,
> > Aditya Xavier
> >
> >> On 19-Apr-2018, at 2:00 PM, Łukasz Rymanowski <
> lukasz.rymanow...@codecoup.pl <mailto:lukasz.rymanow...@codecoup.pl>>
> wrote:
> >>
> >> Hi Aditya,
> >>
> >> I suggest to hack around flash map instead of removing code.
> >>
> >> I would do something like this (hopefully calculations are OK).
> >>
> >> +++ b/hw/bsp/nrf52dk/bsp.yml
> >> @@ -41,11 +41,11 @@ bsp.flash_map:
> >>FLASH_AREA_IMAGE_0:
> >>device: 0
> >>offset: 0x8000
> >> -size: 232kB
> >> +size: 462kB
> >>FLASH_AREA_IMAGE_1:
> >>device: 0
> >> -offset: 0x00042000
> >> -size: 232kB
> >> +offset: 0x0007B800
> >> +size: 2kB
> >>FLASH_AREA_IMAGE_SCRATCH:
> >>device: 0
> >>offset: 0x0007c000
> >> diff --git a/hw/bsp/nrf52dk/nrf52xxaa.ld b/hw/bsp/nrf52dk/nrf52xxaa.ld
> >> index 9433e37fd..55e293da1 100644
> >> --- a/hw/bsp/nrf52dk/nrf52xxaa.ld
> >> +++ b/hw/bsp/nrf52dk/nrf52xxaa.ld
> >> @@ -17,7 +17,7 @@
> >> */
> >> MEMORY
> >> {
> >> -  FLASH (rx) : ORIGIN = 0x8000, LENGTH = 0x3a000
> >> +  FLASH (rx) : ORIGIN = 0x8000, LENGTH = 0x73800
> >>  RAM (rwx) : ORIGIN = 0x2000, LENGTH = 0x1
> >> }
> >>
> >>
> >> Make sure to rebuild boot and app and then try.
> >>
> >> Best
> >> Łukasz
> >>
> >> On 19 April 2018 at 07:30, Aditya Xavier <adityaxav...@me.com  adityaxav...@me.com> <mailto:adityaxav...@me.com  adityaxav...@me.com>>> wrote:
> >>
> >>> Hi Łukasz,
> >>>
> >>> PFA the app I used to test Mesh using multi advertising instances.
> >>>
> >>> I get the following error.
> >>> [ts=275343728ssb, mod=4 level=3] adv_send: Advertising failed: err 3
> >>>
> >>>
> >>>
> >>> I had to comment out a lot of code to get it in a flash-able size.
> >>>
> >>> Thanks,
> >>> Aditya Xavier.
> >>>
> >>>
> >>> On 18-Apr-2018, at 1:13 PM, Aditya Xavier <adityaxav...@me.com
> <mailto:adityaxav...@me.com>> wrote:
> >>>
> >>> Hi Łukasz,
> >>>
> >>> Am using nrf52832, hence the problem of flash overflow.
> >>>
> >>> Would create a test app, using btshell + blemesh + the flags which you
> >>> recommended, and test again.
> >>>
> >>> Thanks,
> >>> Aditya Xavier.
> >>>
> >>> On 18-Apr-2018, at 12:29 PM, Łukasz Rymanowski <
> >>> lukasz.rymanow...@codecoup.pl <mailto:lukasz.rymanow...@codecoup.pl>>
> wrote:
> >>>
> >>> Hi Aditya,
> >>>
> >>> If there is flash overflow consider removing some features from the
> >>> configuration.
> >>> What HW are you using? We are running on nrf52840
> >>>
> >>> BTW There is no special application. It is btshell plus those 4 flags (
> >>> BLE_EXT_ADV, BLE_MULTI_ADV

Re: [RFC] Mesh uses multi advertising instances.

[Łukasz Rymanowski]

Hi Aditya,

I suggest to hack around flash map instead of removing code.

I would do something like this (hopefully calculations are OK).

+++ b/hw/bsp/nrf52dk/bsp.yml
@@ -41,11 +41,11 @@ bsp.flash_map:
 FLASH_AREA_IMAGE_0:
 device: 0
 offset: 0x8000
-size: 232kB
+size: 462kB
 FLASH_AREA_IMAGE_1:
 device: 0
-offset: 0x00042000
-size: 232kB
+offset: 0x0007B800
+size: 2kB
 FLASH_AREA_IMAGE_SCRATCH:
 device: 0
 offset: 0x0007c000
diff --git a/hw/bsp/nrf52dk/nrf52xxaa.ld b/hw/bsp/nrf52dk/nrf52xxaa.ld
index 9433e37fd..55e293da1 100644
--- a/hw/bsp/nrf52dk/nrf52xxaa.ld
+++ b/hw/bsp/nrf52dk/nrf52xxaa.ld
@@ -17,7 +17,7 @@
  */
 MEMORY
 {
-  FLASH (rx) : ORIGIN = 0x8000, LENGTH = 0x3a000
+  FLASH (rx) : ORIGIN = 0x8000, LENGTH = 0x73800
   RAM (rwx) : ORIGIN = 0x2000, LENGTH = 0x1
 }


Make sure to rebuild boot and app and then try.

Best
Łukasz

On 19 April 2018 at 07:30, Aditya Xavier <adityaxav...@me.com> wrote:

> Hi Łukasz,
>
> PFA the app I used to test Mesh using multi advertising instances.
>
> I get the following error.
> [ts=275343728ssb, mod=4 level=3] adv_send: Advertising failed: err 3
>
>
>
> I had to comment out a lot of code to get it in a flash-able size.
>
> Thanks,
> Aditya Xavier.
>
>
> On 18-Apr-2018, at 1:13 PM, Aditya Xavier <adityaxav...@me.com> wrote:
>
> Hi Łukasz,
>
> Am using nrf52832, hence the problem of flash overflow.
>
> Would create a test app, using btshell + blemesh + the flags which you
> recommended, and test again.
>
> Thanks,
> Aditya Xavier.
>
> On 18-Apr-2018, at 12:29 PM, Łukasz Rymanowski <
> lukasz.rymanow...@codecoup.pl> wrote:
>
> Hi Aditya,
>
> If there is flash overflow consider removing some features from the
> configuration.
> What HW are you using? We are running on nrf52840
>
> BTW There is no special application. It is btshell plus those 4 flags (
> BLE_EXT_ADV, BLE_MULTI_ADV_INSTANCES, BLE_MESH,  BLE_MESH_SHELL) . Of
> course you need my PR. I did not test it personally, but  I know it worked
> for Michal.
>
> Please share your target configuration,
>
> Best
> Łukasz
>
> On 17 April 2018 at 12:04, Aditya Xavier <adityaxav...@me.com  adityaxav...@me.com <adityaxav...@me.com>>> wrote:
>
> Hi Łukasz,
>
> Been trying to join both blemesh_shell and bt_shell, but there is a
> problem of flash overflow.
>
> Created another app, which basically is btshell and some portions of
> blemesh, but that didn’t work.
>
> Is it possible for you to share a sample / test app ?
>
> Thanks,
> Aditya Xavier.
>
> On 10-Apr-2018, at 1:09 PM, Łukasz Rymanowski <
>
> lukasz.rymanow...@codecoup.pl> wrote:
>
>
> Hi Michał, Aditya,
>
> I just upload a new version of PR:
> https://github.com/apache/mynewt-nimble/pull/8
> It contains fixes for the problem mentioned above, however solution is
>
> bit
>
> different from what Michał suggested.
> @MIchał, could you take a look?
>
> @Aditya, Could you be able to test it and give us a feedback on this?
>
> Best
> Łukasz
>
>
>
> On 6 April 2018 at 14:08, Michał Narajowski <
>
> michal.narajow...@codecoup.pl>
>
> wrote:
>
> Hi Aditya,
>
> Mesh is using Adv extensions under the hood if you have Łukasz's patch
> and enable BLE_EXT_ADV and set BLE_MULTI_ADV_INSTANCES to at least 1.
> Blemesh_shell has a command "init" which initializes mesh stack and
> starts advertising Unprovisioned Mesh Beacon.
>
> I tested this now and I noticed a bug. Here is a patch for that bug:
> https://pastebin.com/gbyX8H56
> Please apply it on top of Łukasz's branch.
>
> Hope that helps. Let us know how it works for you.
>
> BR,
> Michał
>
> 2018-04-06 11:09 GMT+02:00 Aditya Xavier <adityaxav...@me.com>:
>
> Hi Michał / Łukasz,
>
> I have been trying to understand the blemesh_shell, and I fail to
>
> understand how / where it is using the Advertisement extensions.
>
>
> Basically, could you point me towards the difference if I need to
>
> implement, in order to use blemesh instead.
>
>
> From what I gathered / understood after going through the code is that
>
> blemesh_shell basically allows various functions to be triggered through
> shell commands.
>
>
> Thanks,
> Aditya Xavier.
>
>
> On 03-Apr-2018, at 3:54 PM, Michał Narajowski <
>
> michal.narajow...@codecoup.pl> wrote:
>
>
> Hi Aditya,
>
> Please set BLE_MESH: 1 and BLE_MESH_SHELL: 1 and you should be able to
> use both btshell and mesh shell. Let us know how that wor

Re: [RFC] Mesh uses multi advertising instances.

[Łukasz Rymanowski]

Hi Aditya,

If there is flash overflow consider removing some features from the
configuration.
What HW are you using? We are running on nrf52840

BTW There is no special application. It is btshell plus those 4 flags (
BLE_EXT_ADV, BLE_MULTI_ADV_INSTANCES, BLE_MESH,  BLE_MESH_SHELL) . Of
course you need my PR. I did not test it personally, but  I know it worked
for Michal.

Please share your target configuration,

Best
Łukasz

On 17 April 2018 at 12:04, Aditya Xavier <adityaxav...@me.com> wrote:

> Hi Łukasz,
>
> Been trying to join both blemesh_shell and bt_shell, but there is a
> problem of flash overflow.
>
> Created another app, which basically is btshell and some portions of
> blemesh, but that didn’t work.
>
> Is it possible for you to share a sample / test app ?
>
> Thanks,
> Aditya Xavier.
>
> > On 10-Apr-2018, at 1:09 PM, Łukasz Rymanowski <
> lukasz.rymanow...@codecoup.pl> wrote:
> >
> > Hi Michał, Aditya,
> >
> > I just upload a new version of PR:
> > https://github.com/apache/mynewt-nimble/pull/8
> > It contains fixes for the problem mentioned above, however solution is
> bit
> > different from what Michał suggested.
> > @MIchał, could you take a look?
> >
> > @Aditya, Could you be able to test it and give us a feedback on this?
> >
> > Best
> > Łukasz
> >
> >
> >
> > On 6 April 2018 at 14:08, Michał Narajowski <
> michal.narajow...@codecoup.pl>
> > wrote:
> >
> >> Hi Aditya,
> >>
> >> Mesh is using Adv extensions under the hood if you have Łukasz's patch
> >> and enable BLE_EXT_ADV and set BLE_MULTI_ADV_INSTANCES to at least 1.
> >> Blemesh_shell has a command "init" which initializes mesh stack and
> >> starts advertising Unprovisioned Mesh Beacon.
> >>
> >> I tested this now and I noticed a bug. Here is a patch for that bug:
> >> https://pastebin.com/gbyX8H56
> >> Please apply it on top of Łukasz's branch.
> >>
> >> Hope that helps. Let us know how it works for you.
> >>
> >> BR,
> >> Michał
> >>
> >> 2018-04-06 11:09 GMT+02:00 Aditya Xavier <adityaxav...@me.com>:
> >>> Hi Michał / Łukasz,
> >>>
> >>> I have been trying to understand the blemesh_shell, and I fail to
> >> understand how / where it is using the Advertisement extensions.
> >>>
> >>> Basically, could you point me towards the difference if I need to
> >> implement, in order to use blemesh instead.
> >>>
> >>> From what I gathered / understood after going through the code is that
> >> blemesh_shell basically allows various functions to be triggered through
> >> shell commands.
> >>>
> >>> Thanks,
> >>> Aditya Xavier.
> >>>
> >>>
> >>>> On 03-Apr-2018, at 3:54 PM, Michał Narajowski <
> >> michal.narajow...@codecoup.pl> wrote:
> >>>>
> >>>> Hi Aditya,
> >>>>
> >>>> Please set BLE_MESH: 1 and BLE_MESH_SHELL: 1 and you should be able to
> >>>> use both btshell and mesh shell. Let us know how that works for you.
> >>>> av...@gmail.com
> >>>> Best regards
> >>>> Michał
> >>>>
> >>>> 2018-04-03 7:56 GMT+02:00 Aditya Xavier <adityaxav...@me.com>:
> >>>>> Hi Łukasz,
> >>>>>
> >>>>> Any pointers, as to what needs to be implemented from the
> >> blemesh_shell app ?
> >>>>>
> >>>>>
> >>>>> Thanks,
> >>>>> Aditya Xavier.
> >>>>>
> >>>>>> On 02-Apr-2018, at 11:34 PM, Łukasz Rymanowski <
> >> lukasz.rymanow...@codecoup.pl> wrote:
> >>>>>>
> >>>>>> Second thought
> >>>>>> av...@gmail.com
> >>>>>> Aditya,
> >>>>>> Since I did not test it a lot, would it be possible to give us
> >> feedback how
> >>>>>> it works for you?
> >>>>>>
> >>>>>> Best
> >>>>>> Lukasz
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Apr 2, 2018, 20:01 Łukasz Rymanowski <
> >> lukasz.rymanow...@codecoup.pl>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi Aditya.
> >>>>>>>

Re: [RFC] Mesh uses multi advertising instances.

[Łukasz Rymanowski]

Hi Michał, Aditya,

I just upload a new version of PR:
https://github.com/apache/mynewt-nimble/pull/8
It contains fixes for the problem mentioned above, however solution is bit
different from what Michał suggested.
@MIchał, could you take a look?

@Aditya, Could you be able to test it and give us a feedback on this?

Best
Łukasz



On 6 April 2018 at 14:08, Michał Narajowski <michal.narajow...@codecoup.pl>
wrote:

> Hi Aditya,
>
> Mesh is using Adv extensions under the hood if you have Łukasz's patch
> and enable BLE_EXT_ADV and set BLE_MULTI_ADV_INSTANCES to at least 1.
> Blemesh_shell has a command "init" which initializes mesh stack and
> starts advertising Unprovisioned Mesh Beacon.
>
> I tested this now and I noticed a bug. Here is a patch for that bug:
> https://pastebin.com/gbyX8H56
> Please apply it on top of Łukasz's branch.
>
> Hope that helps. Let us know how it works for you.
>
> BR,
> Michał
>
> 2018-04-06 11:09 GMT+02:00 Aditya Xavier <adityaxav...@me.com>:
> > Hi Michał / Łukasz,
> >
> > I have been trying to understand the blemesh_shell, and I fail to
> understand how / where it is using the Advertisement extensions.
> >
> > Basically, could you point me towards the difference if I need to
> implement, in order to use blemesh instead.
> >
> > From what I gathered / understood after going through the code is that
> blemesh_shell basically allows various functions to be triggered through
> shell commands.
> >
> > Thanks,
> > Aditya Xavier.
> >
> >
> >> On 03-Apr-2018, at 3:54 PM, Michał Narajowski <
> michal.narajow...@codecoup.pl> wrote:
> >>
> >> Hi Aditya,
> >>
> >> Please set BLE_MESH: 1 and BLE_MESH_SHELL: 1 and you should be able to
> >> use both btshell and mesh shell. Let us know how that works for you.
> >>
> >> Best regards
> >> Michał
> >>
> >> 2018-04-03 7:56 GMT+02:00 Aditya Xavier <adityaxav...@me.com>:
> >>> Hi Łukasz,
> >>>
> >>> Any pointers, as to what needs to be implemented from the
> blemesh_shell app ?
> >>>
> >>>
> >>> Thanks,
> >>> Aditya Xavier.
> >>>
> >>>> On 02-Apr-2018, at 11:34 PM, Łukasz Rymanowski <
> lukasz.rymanow...@codecoup.pl> wrote:
> >>>>
> >>>> Second thought
> >>>>
> >>>> Aditya,
> >>>> Since I did not test it a lot, would it be possible to give us
> feedback how
> >>>> it works for you?
> >>>>
> >>>> Best
> >>>> Lukasz
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Mon, Apr 2, 2018, 20:01 Łukasz Rymanowski <
> lukasz.rymanow...@codecoup.pl>
> >>>> wrote:
> >>>>
> >>>>> Hi Aditya.
> >>>>>
> >>>>> On Mon, Apr 2, 2018, 19:14 Aditya Xavier <adityaxav...@me.com>
> wrote:
> >>>>>
> >>>>>> Hi Łukasz,
> >>>>>>
> >>>>>> Is there anything special required to get this working along with
> BLE ?
> >>>>>
> >>>>>
> >>>>>> For e.g. would the btshell app code for ADV_EXT work along with
> mesh with
> >>>>>> the provided patches ?
> >>>>>>
> >>>>>
> >>>>> In addition to configuration mentioned in PR commit message, the
> btshell
> >>>>> app would have to enable ble mesh and ble mesh shell (check
> blemesh_shell
> >>>>> app for that)
> >>>>>
> >>>>>>
> >>>>>> Mesh and BLE seems to compile however, am currently unable to get
> Mesh
> >>>>>> working.
> >>>>>>
> >>>>>> Also, any reason why this was not accepted yet ?
> >>>>>>
> >>>>>
> >>>>> People are busy with other stuff I guess. I think it will be merged
> >>>>> eventually.
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Aditya Xavier.
> >>>>>>
> >>>>>
> >>>>> Best
> >>>>> Lukasz
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>> On 20-Mar-2018, at 12:57 AM, Sterling Hughes <
> >>>>>> sterling.hughes.pub...@gmail.com> wrote:
> >>>>>>>
> >>>>>>> +1 - this is great, thanks Lukasz!
> >>>>>>>
> >>>>>>> On 19 Mar 2018, at 6:36, Łukasz Rymanowski wrote:
> >>>>>>>
> >>>>>>>> Hi All,
> >>>>>>>>
> >>>>>>>> I saw people asking around about possibility to advertise with
> non-mesh
> >>>>>>>> data while mesh is running on Mynewt.  Well this is possible to
> do but
> >>>>>> of
> >>>>>>>> course it brings a lot of risk for mesh operations and especially
> for
> >>>>>>>> friendship scenario. However I went ahead and added support for
> this in
> >>>>>>>> Mynewt and I'm interested in how it works for you.
> >>>>>>>>
> >>>>>>>> So here is a PR which makes use of multi instances from BT5
> Advertising
> >>>>>>>> extensions and basically allows you to create additional instances
> >>>>>> which
> >>>>>>>> contains non-mesh data.
> >>>>>>>>
> >>>>>>>> https://github.com/apache/mynewt-nimble/pull/8
> >>>>>>>>
> >>>>>>>> Instructions on how to enable it you can find in the commit
> message.
> >>>>>>>>
> >>>>>>>> Comments are welcome
> >>>>>>>>
> >>>>>>>> Best
> >>>>>>>> Łukasz
> >>>>>>
> >>>>>>
> >>>
> >
>

Re: [RFC] Mesh uses multi advertising instances.

[Łukasz Rymanowski]

Hi Aditya.

On Mon, Apr 2, 2018, 19:14 Aditya Xavier <adityaxav...@me.com> wrote:

> Hi Łukasz,
>
> Is there anything special required to get this working along with BLE ?


> For e.g. would the btshell app code for ADV_EXT work along with mesh with
> the provided patches ?
>

In addition to configuration mentioned in PR commit message, the btshell
app would have to enable ble mesh and ble mesh shell (check blemesh_shell
app for that)

>
> Mesh and BLE seems to compile however, am currently unable to get Mesh
> working.
>
> Also, any reason why this was not accepted yet ?
>

People are busy with other stuff I guess. I think it will be merged
eventually.

>
>
>
> Thanks,
> Aditya Xavier.
>

Best
Lukasz


>
> > On 20-Mar-2018, at 12:57 AM, Sterling Hughes <
> sterling.hughes.pub...@gmail.com> wrote:
> >
> > +1 - this is great, thanks Lukasz!
> >
> > On 19 Mar 2018, at 6:36, Łukasz Rymanowski wrote:
> >
> >> Hi All,
> >>
> >> I saw people asking around about possibility to advertise with non-mesh
> >> data while mesh is running on Mynewt.  Well this is possible to do but
> of
> >> course it brings a lot of risk for mesh operations and especially for
> >> friendship scenario. However I went ahead and added support for this in
> >> Mynewt and I'm interested in how it works for you.
> >>
> >> So here is a PR which makes use of multi instances from BT5 Advertising
> >> extensions and basically allows you to create additional instances which
> >> contains non-mesh data.
> >>
> >> https://github.com/apache/mynewt-nimble/pull/8
> >>
> >> Instructions on how to enable it you can find in the commit message.
> >>
> >> Comments are welcome
> >>
> >> Best
> >> Łukasz
>
>

Re: Ble mesh questions

[Łukasz Rymanowski]

Hi,

On 29 March 2018 at 14:16, Li-Chun Ko <littleb...@gmail.com> wrote:
> I hope it works this time!
>
> https://imgur.com/ZsqnidG

Thanks. Well this looks good to me. You can verify with Mesh Profile
Specification chapter 3.9.2 Unprovisioned Device beacon
Probably Wireshark does not decode it well, but I have not clue why it
does not work with Nordic.
Will try to find some time to test it against Nordic stack ...

>
> Cheers,
> Lichun
>

Best
Łukasz

> 2018-03-29 19:39 GMT+08:00 Michał Narajowski <michal.narajow...@codecoup.pl>
> :
>
>> Hi Li-Chun,
>>
>> We still didn't get the picture. Please try using some hosting website
>> like Imgur and send us the link to the picture.
>>
>> Best regards
>> Michał Narajowski
>>
>> 2018-03-29 13:20 GMT+02:00 Li-Chun Ko <littleb...@gmail.com>:
>> > Attached it again here.
>> >
>> > Łukasz Rymanowski <lukasz.rymanow...@codecoup.pl> 於 2018年3月29日 週四
>> 下午6:33 寫道：
>> >>
>> >> Hi Lichun
>> >>
>> >> On 29 March 2018 at 12:28, Li-Chun Ko <littleb...@gmail.com> wrote:
>> >> > Hi Łukasz,
>> >> >
>> >> > I am using the ADV bearer.
>> >> >
>> >> > I don't have the log at hand but you should get all the information
>> from
>> >> > the picture I attached in my previous email. It was captured by a low
>> >> > cost
>> >> > Nordic sniffer.
>> >>
>> >> Could you resend picture you mentioned? It looks like it is missing in
>> >> your first email (at least I did not get it)
>> >>
>> >> >
>> >> > I used bascally the same steps that were mentioned in the BLE mesh
>> >> > tutroial
>> >> > except I changed the UUID and I also built the bootloader at the same
>> >> > time
>> >> > (I don't know why without compiling the bootloader the serial
>> interface
>> >> > of
>> >> > the mesh node doesn't seem to work; I haven't got a chance to take a
>> >> > further look so now I always compile them together).
>> >> > Below are the detailed steps. I will share the configuration with you
>> >> > once
>> >> > I can reach my computer.
>> >> >
>> >> > Cheers,
>> >> > Lichun
>> >> > __
>> >> > newt new my_mesh
>> >> > cd my_mesh/
>> >> > newt install -v
>> >> > newt target create blemesh
>> >> > newt target set blemesh app=@apache-mynewt-core/apps/blemesh
>> >> > newt target set blemesh bsp=@apache-mynewt-core/hw/bsp/nrf52dk
>> >> > newt target set blemesh build_profile=optimized
>> >> > newt target set blemesh syscfg=BLE_MESH_PB_GATT=1:BLE_
>> >> > MESH_DEV_UUID='(uint8_t[16]){0x33, 0x19, 0}'
>> >> > newt target create nrf52_boot
>> >> > newt target set nrf52_boot app=@apache-mynewt-core/apps/boot
>> >> > newt target set nrf52_boot bsp=@apache-mynewt-core/hw/bsp/nrf52dk
>> >> > newt target set nrf52_boot build_profile=optimized
>> >> > newt build nrf52_boot
>> >> > newt build blemesh
>> >> > newt create-image blemesh 1.0.0
>> >> > newt load blemesh
>> >> >
>> >> > Łukasz Rymanowski <lukasz.rymanow...@codecoup.pl> 於 2018年3月29日 週四
>> 下午5:02
>> >> > 寫道：
>> >> >
>> >> >> Hi Lichun,
>> >> >>
>> >> >> On 29 March 2018 at 10:42, Li-Chun Ko <littleb...@gmail.com> wrote:
>> >> >> > Hi all,
>> >> >> >
>> >> >> > I am running blemesh with mynewt  1.3.0 on Nordics pca 10040. Here
>> >> >> > are
>> >> >> two
>> >> >> > questions I have:
>> >> >> >
>> >> >> > 1. Is it correct that the current mynewt release doesn't support
>> the
>> >> >> > Provisioner's role? I wasn't able to find a way to do so.
>> >> >> >
>> >> >>
>> >> >> This is correct. Provisioner is not supported in Mynewt. However if
>> >> >> you want to test mesh wit two Mynewt devices, I suggest to use
>> >> >> blemesh_shell application which gives you a way to hardcode mesh
>> >> >> credentians by using "provision" command.
>> >> >>
>> >> >> > 2. I tried to use the mesh stack from Noridc to play the
>> >> >> > Provisioner's
>> >> >> role
>> >> >> > but it seems the device cannot decode the unprovisioning beacon
>> >> >> generated by
>> >> >> > mynewt's mesh stack correctly. I captured the beacon with wireshark
>> >> >> > 2.5.1
>> >> >> > and noticed that the tool cannot parse the beacon correctly either.
>> >> >> > The
>> >> >> > AdvData can be recognized as mesh beacon but the content is showed
>> as
>> >> >> > "unknown data". I am thinking there might be some PDU format issues
>> >> >> > (I
>> >> >> > suspect the length field of the mesh beacon which is 24 bytes is
>> >> >> incorrect)
>> >> >> > but I am not sure. I have attached a photo as the reference and
>> >> >> > hopefully
>> >> >> > someone can help check.
>> >> >> >
>> >> >>
>> >> >> That is interesting. I did not test against Nordic stack but was
>> >> >> testing against PTS tool and some other implementation and have not
>> >> >> seen such issue.
>> >> >> Could you share your target configuration ("newt target show > >> >> name>") and wireshark logs?
>> >> >>
>> >> >> BTW What bearer uses Nordic stack?
>> >> >>
>> >> >> > Br,
>> >> >> > Lichun
>> >> >>
>> >> >> Thanks
>> >> >> Łukasz
>> >> >>
>> >>
>> >>
>> >> Best
>> >> Łukasz
>>

Re: Ble mesh questions

[Łukasz Rymanowski]

Hi Lichun,

On 29 March 2018 at 10:42, Li-Chun Ko  wrote:
> Hi all,
>
> I am running blemesh with mynewt  1.3.0 on Nordics pca 10040. Here are two
> questions I have:
>
> 1. Is it correct that the current mynewt release doesn't support the
> Provisioner's role? I wasn't able to find a way to do so.
>

This is correct. Provisioner is not supported in Mynewt. However if
you want to test mesh wit two Mynewt devices, I suggest to use
blemesh_shell application which gives you a way to hardcode mesh
credentians by using "provision" command.

> 2. I tried to use the mesh stack from Noridc to play the Provisioner's role
> but it seems the device cannot decode the unprovisioning beacon generated by
> mynewt's mesh stack correctly. I captured the beacon with wireshark 2.5.1
> and noticed that the tool cannot parse the beacon correctly either. The
> AdvData can be recognized as mesh beacon but the content is showed as
> "unknown data". I am thinking there might be some PDU format issues (I
> suspect the length field of the mesh beacon which is 24 bytes is incorrect)
> but I am not sure. I have attached a photo as the reference and hopefully
> someone can help check.
>

That is interesting. I did not test against Nordic stack but was
testing against PTS tool and some other implementation and have not
seen such issue.
Could you share your target configuration ("newt target show ") and wireshark logs?

BTW What bearer uses Nordic stack?

> Br,
> Lichun

Thanks
Łukasz

Re: Sample apps in mynewt-core

[Łukasz Rymanowski]

Hi Łukasz,

If your application supports pairing (like btshell for example), you
will get Secure Connections  by setting MYNEWT_VAL BLE_SM_SC to 1.
It is stack who handles it for you then.

Hope that helps.

Best regards
Łukasz

On 20 March 2018 at 19:11, aditi hilbert  wrote:
> Lukasz,
>
> Yes - great addition!
>
> thanks,
> aditi
>
>> On Mar 20, 2018, at 8:16 AM, Lukasz Wolnik  wrote:
>>
>> Hi Aditi,
>>
>> Could we also add a sample app that uses NimBLE's Secure Connections please?
>>
>> Kind regards,
>> Lukasz
>>
>> On Tue, Mar 20, 2018 at 1:11 AM, aditi hilbert  wrote:
>>
>>> Hi all,
>>>
>>> We have been adding a lot of features and functionality in Apache Mynewt
>>> recently. Sample apps make it easy to see how to use them; so adding some
>>> sample apps would be much appreciated. Here's an initial list of sample
>>> apps that we could add. Please respond if you wish to contribute one or add
>>> to the list. And I think we should add a README.md for every app in the
>>> repo.
>>>
>>> * PWM - control LED brightness
>>> * ADC, UART - read voltage on ADC, print value to UART
>>> * ADC, I2C - read out an ADC over I2C
>>> * Expose a resource by enabling a CoAP server
>>> * CoAP, LoRa - enable CoAP client on one LoRa node, CoAP server on
>>> another, retrieve a resource value
>>> * Cycle through available power states (deep sleep, low power etc.)
>>> * Sensor - change sampling rate
>>> * Sensor - read multiple I2C sensors simultaneously
>>> * Sensor - trigger a notification when a threshold is crossed
>>> * Logging, Sensor - enable FCB to log timestamped sensor data
>>> * MMC, SPI, stats - write system stats to the card, read back
>>> * testutil - adding a test for a package in sim using the testutil
>>> framework
>>> * sensor, testutil - how to add a test for a sensor HW using the testutil
>>> framework
>>>
>>> thanks,
>>> Aditi
>

[RFC] Mesh uses multi advertising instances.

[Łukasz Rymanowski]

Hi All,

I saw people asking around about possibility to advertise with non-mesh
data while mesh is running on Mynewt.  Well this is possible to do but of
course it brings a lot of risk for mesh operations and especially for
friendship scenario. However I went ahead and added support for this in
Mynewt and I'm interested in how it works for you.

So here is a PR which makes use of multi instances from BT5 Advertising
extensions and basically allows you to create additional instances which
contains non-mesh data.

https://github.com/apache/mynewt-nimble/pull/8

Instructions on how to enable it you can find in the commit message.

Comments are welcome

Best
Łukasz

Re: Multicast messaging and group messaging

[Łukasz Rymanowski]

Hi Aditiya,

Alright, there is no really documentation but you can try it out on our
btmesh_shell app.

There is shell.c file which expose configuration client which you can use
for testing - e.g. you can subscribe virtual address.
You can also trigger sending messages to devices. By playing with "dst"
command you probably should be able to set destination to some group.

Btw.  Since we do not support provisioner role, there is command
"provision" which sets fixed keys so you can create mesh network out of
couple of nodes without the actuall provisioner.

Best
Łukasz


On 8 March 2018 at 12:25, Aditya Xavier <adityaxav...@me.com> wrote:

> Thanks Łukasz,
>
> Yes I am aware its possible as per the ble mesh spec, wanted to know if
> there is any documentation / example of using and registering a group
> address.
>
> Thanks,
> Aditya Xavier
>
>
>
>
> > On 08-Mar-2018, at 4:37 PM, Łukasz Rymanowski <
> lukasz.rymanow...@codecoup.pl> wrote:
> >
> > Hello Aditya,
> >
> > It should be possible to do so with a publish model. Group address or
> > virtual address should help here (see Mesh spec)
> >
> > Best
> > Łukasz
> >
> > On 8 March 2018 at 10:39, Aditya Xavier <adityaxav...@me.com> wrote:
> >
> >> Hello Mynewt Team,
> >>
> >>
> >> Is it possible to send a broadcast message by one of the devices present
> >> in the mesh ?
> >>
> >> For e.g. to broadcast a event which happened ? Something like push
> >> notification instead of continuously polling for it by a client.
> >>
> >> Thanks,
> >> Aditya Xavier.
>
>

Re: Multicast messaging and group messaging

[Łukasz Rymanowski]

Hello Aditya,

It should be possible to do so with a publish model. Group address or
virtual address should help here (see Mesh spec)

Best
Łukasz

On 8 March 2018 at 10:39, Aditya Xavier  wrote:

> Hello Mynewt Team,
>
>
> Is it possible to send a broadcast message by one of the devices present
> in the mesh ?
>
> For e.g. to broadcast a event which happened ? Something like push
> notification instead of continuously polling for it by a client.
>
> Thanks,
> Aditya Xavier.

Re: Information regarding blemesh implementation

[Łukasz Rymanowski]

Hi,

On 2 January 2018 at 11:30, Aditya Xavier <adityaxav...@me.com> wrote:
> Thanks, I think I have a better understanding of how this works now.
>
> So, in order to receive a String / byte array instead of a single byte; am I 
> correct that I would need to make the following changes ?

As you probably know, you should create own model and define own
operation opcodes instead of using on/off model, but I understand you
are doing some experiments which is fine
>
> 1.  In Status function..
>
> Line :- 172
> struct os_mbuf *msg = NET_BUF_SIMPLE(3); // Change this to a higher 
> number ?

Function gen_onoff_status() (refered above)  shows how to send message
 over the model as a response to some device (address already in ctx)
In on/off model we have there 2 octets for opcode and one for status.
So you can play around here as you suggested above.

>
> 2.  In Set Function
>
> Line :- 203
> gen_on_off_state = buf->om_data[0]; // Retrieve more data than only 
> the 0th position in the array ?

Buf is struct os_mbuf * and to see how to use it I recommend to read
this  https://mynewt.apache.org/v1_0_0/os/core_os/mbuf/mbuf/
In general buf->om_data points to data sent by remote device.

>
> 3.  Am not sure whats the purpose of net_buf_simple_pull_le16 etc are.. 
> Would I need that for e.g. being utilised in Level..
> level = (int16_t) net_buf_simple_pull_le16(buf);

Level is 2 octet value and according to Mesh spec it is sent in LE
order. This helper decodes this and also moves data pointer in buf by
2.

>
> If I did miss something or completely wrong about it.. please do let me know.
>
> Thanks,
> Aditya Xavier.
>

Best
\Łukasz
>
>
>
>> On 29-Dec-2017, at 5:34 PM, Łukasz Rymanowski 
>> <lukasz.rymanow...@codecoup.pl> wrote:
>>
>> Hi,
>>
>> On 29 December 2017 at 07:22, Aditya Xavier <adityaxav...@me.com> wrote:
>>> Hello, am I correct in my understanding that the BLE Mesh implementation 
>>> would require us to follow one of the Models as specified?
>> You need to create model, but you are not limited to the one specified by BT 
>> SIG
>>
>>>
>>> For e.g. in my case I need to implement a REST client over BLE Mesh. I 
>>> believe this can be easily on Bluetooth, however am not sure how to do so 
>>> on blemesh.
>>
>> Probably you need to design your own model for this. In blemesh
>> application in main.c you can find example of vendor model which
>> implements generic on/off but you can implement your own one.
>>
>>>
>>> Please do point me in the right direction if I missed something.
>>>
>>> Thanks,
>>> Aditya Xavier.
>>
>> Hope that helps
>>
>> Łukasz
>

Re: Discussion around usefulness of os_dev abstraction, especially around sensors

[Łukasz Rymanowski]

Hi Jacob

On 20 December 2017 at 07:15, Jacob Rosenthal <jakerosent...@gmail.com> wrote:
>>
>> As Vipul mentioned those shells are used only for sensor testing. As
>> you probably noticed it will not use sensor API at all but instead it
>> uses direct access to the sensor_driver. If you want to use sensors
>> via sensor API you should look into sensor_shell from sensor_test
>
>
> I guess I just dont agree that upstreamed code can be considered 'or
> testing only' especially when shell is about to be hooked up to coap
> access. (which I support)
> https://github.com/apache/mynewt-newtmgr/pull/55
>

Well, I'm fine having shell test code for specific sensor driver as it is now.
If I want to use given sensor via sensor API I use sensor_test
application which gives reference and it seems to support coap as well

Regarding PR you mentioned: Well maybe I should not use "shell" in
this PR. In fact this is interactive mode for newtmgr coap operations,
which I'm not sure will get into upstream.
However, glad that somebody is looking into it, comments are welcome.

> Upstream code should be reference material and idiomatic.
>
>

Łukasz

> On Tue, Dec 19, 2017 at 7:17 AM, Łukasz Rymanowski <
> lukasz.rymanow...@codecoup.pl> wrote:
>
>> Hi Jacob
>>
>> I've look around this code and here is my two cents to the topic :)
>>
>> On 18 December 2017 at 23:58, Jacob Rosenthal <jakerosent...@gmail.com>
>> wrote:
>> > Im trying to wrap my head around os devices and sensors and am finding
>> the
>> > current implementations odd.
>> >
>> > From what I can gather, os_dev_create creates an os device which mainly
>> > provides the benefit of being able to open,suspend, resume,close a
>> > resource. It does this by calling a callback (device init) function after
>> > it finishes whom it expects to register the handler functions
>> >
>> > But oddly NOTHING in mynewt utilizes suspend or resume functionality, and
>> > only adc, uart and pwm even register open/close handlers.
>> >
>> > Even more odd is that none of the slew of sensors registers ANY handlers
>> > with os_device, and are therefore completely wasting the memory
>> associated.
>>
>> Yup, we are missing suspend/resume support as for now. Meaning,
>> suspend/resume will not be never called and sadly we are missing even
>> API to set suspend/resume callbacks as Vipul mentioned.
>>
>> However if you build new driver for something what can sleep, it is
>> probably good idea to add struct *os_dev  to your driver struct and be
>> prepared for using it.
>>
>> >
>> > Proof of this lies in the fact that only one out of the six upstream
>> sensor
>> > implementations (the shell implementations) even bothers to find and open
>> > its existing device
>> > https://github.com/apache/mynewt-core/blob/master/hw/
>> drivers/sensors/bma253/src/bma253_shell.c
>> >
>> > The other five leave the os device closed and they make a fresh
>> interface.
>> > https://github.com/apache/mynewt-core/blob/master/hw/
>> drivers/sensors/bmp280/src/bmp280_shell.c#L39
>> > https://github.com/apache/mynewt-core/blob/master/hw/
>> drivers/sensors/bno055/src/bno055_shell.c#L45
>> > https://github.com/apache/mynewt-core/blob/master/hw/
>> drivers/sensors/bno055/src/bno055_shell.c#L45
>> > https://github.com/apache/mynewt-core/blob/master/hw/
>> drivers/sensors/tcs34725/src/tcs34725_shell.c#L38
>> > https://github.com/apache/mynewt-core/blob/master/hw/
>> drivers/sensors/tsl2561/src/tsl2561_shell.c#L55
>> >
>>
>> As Vipul mentioned those shells are used only for sensor testing. As
>> you probably noticed it will not use sensor API at all but instead it
>> uses direct access to the sensor_driver. If you want to use sensors
>> via sensor API you should look into sensor_shell from sensor_test
>> application
>>
>> > Which as I said, actually makes sense since opening doesnt do anything
>> >
>> > Which isnt to tear down any work by anyone involved, Its not like I
>> offered
>> > any input when this was all being merged originally :)
>> >
>> > Thoughts on what the usefulness of os_dev is and should be and thus how
>> > sensors should or shouldn't be built on top of them?
>>
>> Sensors now uses os_dev  and this is good approach as we want them to
>> be aware of power state eventually. There is still lot to do, along
>> with full suspend/resume support and patches are always welcome.
>>
>> hth
>>
>> Best
>> Łukasz
>>

Re: [VOTE] Release Apache Mynewt 1.3.0-rc3

[Łukasz Rymanowski]

+1 (binding)

On Dec 10, 2017 8:31 PM, "aditi runtime"  wrote:

> +1 binding
>
> On Sun, Dec 10, 2017 at 11:12 AM, Sterling Hughes <
> sterling.hughes.pub...@gmail.com> wrote:
>
> > +1 binding
> >
> > On 10 Dec 2017, at 11:11, Christopher Collins wrote:
> >
> > > On Thu, Dec 07, 2017 at 07:27:45PM -0200, Fabio Utzig wrote:
> > >> [X] +1 Release this package
> > >> [ ]  0 I don't feel strongly about it, but don't object
> > >> [ ] -1 Do not release this package because...
> > >
> > > +1 (binding).
> > >
> > > Chris
> >
>

Re: [BLE central] Getting mfg data from advertisement packets

[Łukasz Rymanowski]

Hi again,

On 14 November 2017 at 21:53, Łukasz Rymanowski
<lukasz.rymanow...@codecoup.pl> wrote:
> Hi Jitesh,
>
> On 14 November 2017 at 20:42, Jitesh Shah <jit...@liveathos.com> wrote:
>>
>> Hi Andrej,
>>
>> >
>> > Are you sure that you parse data from packet which has mfg data? With
>> > active scan and scannable packets you will have ADV_IND and SCAN_RSP
>> > as separate events so mfg data may be in the other one - you need to
>> > parse both.
>> >
>>
>> Thank you for the response. I am parsing both ADV_IND and SCAN_RSP packets.
>> I believe I made some headway though.
>>
>> filter_duplicates seems to do something strange. When filter_duplicates is
>> turned on, I don't get SCAN_RSP packets. Execution won't even
>> reach ble_ll_hci_send_adv_report:ble_ll_scan.c.
>>
>> With filter_duplicates turned off, I can get SCAN_RSP packets up to the
>> application layer and manuf data seems alright.
>>
>> Is it possible that filter_duplicate is filtering out SCAN_RSP packet
>> thinking its a dup?
>
>
> Indeed in Mynewt version you refer to it is broken. Not sure when it
> was fixed but master should works fine.

Ah this is actually something what Andrzej fixed in patch:

commit 7ea097f3e1944c51e17a9d2a9f89b4c845652711
Author: Andrzej Kaczmarek <andrzej.kaczma...@codecoup.pl>
Date:   Wed Sep 6 10:55:47 2017 +0200

nimble/ll: Fix duplicates filtering in scanner

With duplicates filtering enabled, we will filter out scan response
from advertiser if we already sent advertising report for the same
device. However, Core specification (Vol 6, Part B, section 4.4.3.5)
states:

"For each non-duplicate advertising or scan response PDU from an
advertiser, the Link Layer shall send an advertising report to the
Host."

This patch fixes this by tracking advertising reports and scan
responses separately for duplicates filtering.


>
>
>>
>> Jitesh
>>
>>
>>
>> > If this is not the problem, can you share raw data from advertising
>> > and scan response packets to see what could go wrong parsing them?
>> >
>> > > Jitesh
>> >
>> > Best regards,
>> > Andrzej
>> >
>> >
>> > > On Tue, Nov 14, 2017 at 12:30 AM, Jitesh Shah <jit...@liveathos.com>
>> > wrote:
>> > >
>> > >> Hey guys,
>> > >> I have a peripheral running Nordic softdevice (BLE 4.0 protocol).
>> > Central
>> > >> is running nimBLE stack 1.0 (0db6321a75deda126943aa187842da6b977cd1c1).
>> > >>
>> > >> The peripheral advertises manufacturing data. I am trying to get to it
>> > >> from the central. I never get the mfg data though. The advertisement
>> > packet
>> > >> looks like this at the central:
>> > >>
>> > >>> (gdb) p/x *fields
>> > >>> $1 = {flags = 0x6, uuids16 = 0x0, num_uuids16 = 0x0,
>> > uuids16_is_complete
>> > >>> = 0x0, uuids32 = 0x0, num_uuids32 = 0x0, uuids32_is_complete = 0x0,
>> > >>>   uuids128 = 0x20006750, num_uuids128 = 0x1, uuids128_is_complete =
>> > 0x1,
>> > >>> name = 0x0, name_len = 0x0, name_is_complete = 0x0, tx_pwr_lvl = 0x0,
>> > >>>   tx_pwr_lvl_is_present = 0x0, slave_itvl_range = 0x0, svc_data_uuid16
>> > =
>> > >>> 0x0, svc_data_uuid16_len = 0x0, public_tgt_addr = 0x0,
>> > >>>   num_public_tgt_addrs = 0x0, appearance = 0x0, appearance_is_present =
>> > >>> 0x0, adv_itvl = 0x0, adv_itvl_is_present = 0x0, svc_data_uuid32 = 0x0,
>> > >>>   svc_data_uuid32_len = 0x0, svc_data_uuid128 = 0x0,
>> > svc_data_uuid128_len
>> > >>> = 0x0, uri = 0x0, uri_len = 0x0, mfg_data = 0x0, mfg_data_len = 0x0}
>> > >>
>> > >>
>> > >> Everything else adds up, except no mfg data. Worth noting that I can see
>> > >> the mfg data if I use another BLE central to scan.
>> > >>
>> > >> My discovery parameters are as follows:
>> > >> disc_params.filter_duplicates = 1;
>> > >> disc_params.passive = 0; // active scan
>> > >> /* Use defaults for the rest of the parameters. */
>> > >> disc_params.itvl = 0;
>> > >> disc_params.window = 0;
>> > >> disc_params.filter_policy = 0;
>> > >> disc_params.limited = 0;
>> > >>
>> > >> Any ideas or hints as to how I can debug?
>> > >>
>

Re: [BLE central] Getting mfg data from advertisement packets

[Łukasz Rymanowski]

Hi Jitesh,

On 14 November 2017 at 20:42, Jitesh Shah  wrote:
>
> Hi Andrej,
>
> >
> > Are you sure that you parse data from packet which has mfg data? With
> > active scan and scannable packets you will have ADV_IND and SCAN_RSP
> > as separate events so mfg data may be in the other one - you need to
> > parse both.
> >
>
> Thank you for the response. I am parsing both ADV_IND and SCAN_RSP packets.
> I believe I made some headway though.
>
> filter_duplicates seems to do something strange. When filter_duplicates is
> turned on, I don't get SCAN_RSP packets. Execution won't even
> reach ble_ll_hci_send_adv_report:ble_ll_scan.c.
>
> With filter_duplicates turned off, I can get SCAN_RSP packets up to the
> application layer and manuf data seems alright.
>
> Is it possible that filter_duplicate is filtering out SCAN_RSP packet
> thinking its a dup?


Indeed in Mynewt version you refer to it is broken. Not sure when it
was fixed but master should works fine.


>
> Jitesh
>
>
>
> > If this is not the problem, can you share raw data from advertising
> > and scan response packets to see what could go wrong parsing them?
> >
> > > Jitesh
> >
> > Best regards,
> > Andrzej
> >
> >
> > > On Tue, Nov 14, 2017 at 12:30 AM, Jitesh Shah 
> > wrote:
> > >
> > >> Hey guys,
> > >> I have a peripheral running Nordic softdevice (BLE 4.0 protocol).
> > Central
> > >> is running nimBLE stack 1.0 (0db6321a75deda126943aa187842da6b977cd1c1).
> > >>
> > >> The peripheral advertises manufacturing data. I am trying to get to it
> > >> from the central. I never get the mfg data though. The advertisement
> > packet
> > >> looks like this at the central:
> > >>
> > >>> (gdb) p/x *fields
> > >>> $1 = {flags = 0x6, uuids16 = 0x0, num_uuids16 = 0x0,
> > uuids16_is_complete
> > >>> = 0x0, uuids32 = 0x0, num_uuids32 = 0x0, uuids32_is_complete = 0x0,
> > >>>   uuids128 = 0x20006750, num_uuids128 = 0x1, uuids128_is_complete =
> > 0x1,
> > >>> name = 0x0, name_len = 0x0, name_is_complete = 0x0, tx_pwr_lvl = 0x0,
> > >>>   tx_pwr_lvl_is_present = 0x0, slave_itvl_range = 0x0, svc_data_uuid16
> > =
> > >>> 0x0, svc_data_uuid16_len = 0x0, public_tgt_addr = 0x0,
> > >>>   num_public_tgt_addrs = 0x0, appearance = 0x0, appearance_is_present =
> > >>> 0x0, adv_itvl = 0x0, adv_itvl_is_present = 0x0, svc_data_uuid32 = 0x0,
> > >>>   svc_data_uuid32_len = 0x0, svc_data_uuid128 = 0x0,
> > svc_data_uuid128_len
> > >>> = 0x0, uri = 0x0, uri_len = 0x0, mfg_data = 0x0, mfg_data_len = 0x0}
> > >>
> > >>
> > >> Everything else adds up, except no mfg data. Worth noting that I can see
> > >> the mfg data if I use another BLE central to scan.
> > >>
> > >> My discovery parameters are as follows:
> > >> disc_params.filter_duplicates = 1;
> > >> disc_params.passive = 0; // active scan
> > >> /* Use defaults for the rest of the parameters. */
> > >> disc_params.itvl = 0;
> > >> disc_params.window = 0;
> > >> disc_params.filter_policy = 0;
> > >> disc_params.limited = 0;
> > >>
> > >> Any ideas or hints as to how I can debug?
> > >>
> > >> Jitesh
> > >>
> > >
> > > --
> > > This email including attachments contains Mad Apparel, Inc. DBA Athos
> > > privileged, confidential, and proprietary information solely for the use
> > > for the addressed recipients. If you are not the intended recipient,
> > please
> > > be aware that any review, disclosure, copying, distribution, or use of
> > the
> > > contents of this message is strictly prohibited. If you have received
> > this
> > > in error, please delete it immediately and notify the sender. All rights
> > > reserved by Mad Apparel, Inc. 2012. The information contained herein is
> > the
> > > exclusive property of Mad Apparel, Inc. and should not be used,
> > > distributed, reproduced, or disclosed in whole or in part without prior
> > > written permission of Mad Apparel, Inc.
> >
>
> --
> This email including attachments contains Mad Apparel, Inc. DBA Athos
> privileged, confidential, and proprietary information solely for the use
> for the addressed recipients. If you are not the intended recipient, please
> be aware that any review, disclosure, copying, distribution, or use of the
> contents of this message is strictly prohibited. If you have received this
> in error, please delete it immediately and notify the sender. All rights
> reserved by Mad Apparel, Inc. 2012. The information contained herein is the
> exclusive property of Mad Apparel, Inc. and should not be used,
> distributed, reproduced, or disclosed in whole or in part without prior
> written permission of Mad Apparel, Inc.



Best
Łukasz

Re: Inconsistent HAL GPIO semantics

[Łukasz Rymanowski]

Hi,

On 14 November 2017 at 03:16, will sanfilippo  wrote:

> +1 Sounds good to me.
>
> > On Nov 13, 2017, at 5:24 PM, Christopher Collins 
> wrote:
> >
> > On Mon, Nov 13, 2017 at 04:32:58PM -0800, will sanfilippo wrote:
> >> Chris:
> >>
> >> Personally, I think there should be separate API as it is more flexible
> and the API names more accurately describe what the API is doing.
> >>
> >> I do realize that this is more work and given that there currently is
> no API to clear a pending interrupt, I suspect that everyone who used the
> enable API expected the interrupt to be cleared prior to enabling.
> >>
> >> Another possible solution (and yes, I suspect folks might think this
> crazy):
> >>
> >> * Rename the API to something like: hal_gpio_irq_clear_and_enable()
> >> * Make all implementations consistent and use this API.
> >>
> >> This way we could add the separate API over time and the code will work
> as expected. Yeah, I know, crazy thought :-)
> >
> > I don't think that is crazy, but I think it might be a bit disruptive
> > for some users.  Any code that calls `hal_gpio_irq_enable()` will fail
> > to build after the rename.  I assume that is the point: make sure things
> > break loudly if they are going to break.  At the risk of sounding lazy,
> > that seems like it could be a lot of work for everyone :).  Especially
> > if we plan on ultimately deprecating `hal_gpio_irq_clear_and_enable()`.
> >
> > Here is an alternative plan for introducing the API change:
> >
> >v1.3:
> >- Don't change any implementations of `hal_gpio_irq_enable()`
> >- Add the `hal_gpio_set/clear` to the API
> >- Notify users that the behavior of `hal_gpio_irq_enable()` will
> >  be changing in the future (for some MCUs).
> >- Modify code in apache-mynewt-core such that it doesn't assume
> >  that `hal_gpio_irq_enable()` clears the pending interrupt.
> >  That is, explicitly call the new `clear` function prior to
> >  enabling the interrupt.
> >
>

That looks good. What I would add here is some kind of compiler warning or
similar saying that this is going to change.
I know this is not easy however we have some idea here but requires some
changes in newt:

e.g.
1. We could add special MYNEWT_VAL e.g HAL_GPIO_LEGACY_IRQ_ENABLE) for 1.3
release which would guard clearing interrupt if set to 1 and not clear if
0.
2. This value would have to be set by user so we make sure user is aware
knows. Default would be -1 and  #error would be propagated if it is -1.
3. In future release we would remove this MYNEWT_VAL and start use new
behavior. In this place we need newt change so it notifies that there is
MYNEWT_VAL used by user which is not defined.

Hope that makes sens :)




> >v1.x [not sure if this is v1.4 or a later release]:
> >- Modify implementations of `hal_gpio_irq_enable()` such that
> >  they only enable the interrupt (don't clear it).
> >
> > Chris
>
>
Łukasz

Re: BLE Host - Removing the BLE_GAP_EVENT_CONN_CANCEL event type

[Łukasz Rymanowski]

On 26 October 2017 at 06:55, will sanfilippo  wrote:
> +1 Sounds good to me.
>
>> On Oct 25, 2017, at 9:53 PM, aditi hilbert  wrote:
>>
>>
>>> On Oct 25, 2017, at 6:46 PM, Christopher Collins  wrote:
>>>
>>> On Thu, Oct 19, 2017 at 12:07:58PM -0700, Christopher Collins wrote:
 On Fri, Oct 13, 2017 at 10:18:14AM -0700, Christopher Collins wrote:
> * Because this is an API change, it would be best to introduce it
> slowly.  The `BLE_GAP_CONN_CANCEL` event would be marked deprecated in
> the next release, and then removed entirely in the one after that.

 After some discussion in the pull request page
 (https://github.com/apache/mynewt-core/pull/632), I'm not sure it makes
 sense to try to slowly "phase out" this behavior.  Since this change
 represents a change in behavior, rather than the removal of
 functionality, I don't think there is a good way to deprecate it.  The
 two basic options are:

 1. Keep deprecated symbols in the code base, but stop using them.  Apps
 will continue to build without errors, but any app relying on the old
 behavior will silently break.

 2. Remove unused symbols.  This may introduce build errors for some
 apps, but at least there is no silent breakage.

 We could also try some hybrid approach, e.g., send both types of GAP
 events when a connection is cancelled.  However, I think this would do
 more harm than good (and probably introduce some new bugs!).

 The release policy document's section on backwards compatibility
 (https://cwiki.apache.org/confluence/display/MYNEWT/Release+and+Support+Policy#ReleaseandSupportPolicy-BackwardsCompatibility)
 is pretty clear - if an API change has the potential to break builds,
 deprecate the old behavior for at least six months before removing it.
 I think this text needs some additional language for changes such as
 this one that can't be reasonably phased in.
>>>
>>> I propose we add the following text to the release policy:
>>>
>>>   Sometimes it is impossible or impractical to retain a deprecated
>>>   version of an API alongside the new one.  For example, a change to
>>>   a callback function's type, such as the addition of a new parameter,
>>>   is difficult to introduce while still maintaining the old API.  For
>>>   these types of changes, the `deprecated` state can be bypassed.
>>>   Such changes must be voted on by the community before they are
>>>   implemented.
>>>
>>
>> +1

+1

>>
>>> If there are no objections, I will make this addition to the wiki.
>>>
>>> Thanks,
>>> Chris
>>
>

Re: Bluetooth mesh on nrf51822 possible ?

[Łukasz Rymanowski]

Hi Jehudi,

I'm afraid it is not possible to fit into 110kB flash.
Current Mesh configuration supports both PB-GATT and PB-ADV and with
this settings we need 53k flash and 3.7k RAM. When we remove PB-GATT
and Friend support I see it drops to 46k flash. Further optimization
is possible but should be done carefully and I doubt it will gives us
much more.
Anyway, to this number you need to add Nimble stack (~70kB), drivers,
app ...and we are over 110kB

But for nrf51 you can play a bit with a bsp.flash_map and configure
slot1 to make it bigger - at least for testing should be good.

Hope that helps

Best
Łukasz

On 11 September 2017 at 17:47, Laczen JMS  wrote:
> Hi,
>
> I am trying to build the bluetooth mesh example for a nrf51822 with
> 32kb ram. I fail to get it inside the 110kb flash limit. Is it
> possible to build the example for nrf51822 ? How can I make it as
> small as possible ?
>
> Kind regards,
>
> Jehudi

Re: [VOTE] Release Apache Mynewt 1.2.0-rc1

[Łukasz Rymanowski]

+1 (binding)

Łukasz

On 10 September 2017 at 20:49, aditi hilbert  wrote:
> +1
>
> thanks,
> aditi
>
>> On Sep 8, 2017, at 11:54 AM, Szymon Janc  wrote:
>>
>> Hello all,
>>
>> I am pleased to be calling this vote for the source release of
>> Apache Mynewt 1.2.0.
>>
>> Apache Mynewt is a community-driven, permissively licensed open source
>> initiative for constrained, embedded applications. Mynewt provides a
>> real-time operating system, flash file system, network stacks, and
>> support utilities for real-world embedded systems.
>>
>> For full release notes, please visit the Apache Mynewt Wiki:
>> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
>>
>> This release candidate was tested as follows:
>>  1. Manual execution of the Mynewt test plan:
>> 
>> https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan
>> The test results can be found at:
>> https://cwiki.apache.org/confluence/display/MYNEWT/1.2.0+Test+Results
>>  2. The full unit test suite for this release was executed via "newt
>> test all" with no failures.  This testing was performed on the
>> following platforms:
>>   * OS X 10.11.5
>>   * Ubuntu Linux 17.04
>>
>> The release candidate to be voted on is available at:
>> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.2.0/rc1/
>>
>> The commits under consideration are as follows:
>> blinky:
>>  repos: https://github.com/apache/mynewt-blinky
>>  commit 5ade7990e81ebfb6b9801fd56b7ea32774747ced
>> core:
>>  repos: https://github.com/apache/mynewt-core
>>  commit e511aa733ee0d5740484738036618332ed45475b
>> newt:
>>  repos: https://github.com/apache/mynewt-newt
>>  commit 3a3e87d754e63cbcf2e49b49c20847dc3c19e655
>> newtmgr:
>>  repos: https://github.com/apache/mynewt-newtmgr
>>  commit 8bc55635bbac12c036b25b4968ee0f48c1f06e52
>>
>> In addition, the following newt convenience binaries are available:
>>  linux: 
>> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.2.0/rc1/apache-mynewt-bin-linux-1.2.0.tgz
>>  osx: 
>> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.2.0/rc1/apache-mynewt-bin-osx-1.2.0.tgz
>>
>> The release candidate is signed with a GPG key available at:
>> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
>>
>> The vote is open for at least 72 hours and passes if a majority of at
>> least three +1 PMC votes are cast.
>>
>> [ ] +1 Release this package
>> [ ]  0 I don't feel strongly about it, but don't object
>> [ ] -1 Do not release this package because...
>>
>> Anyone can participate in testing and voting, not just committers,
>> please feel free to try out the release candidate and provide your
>> votes.
>>
>> A separate [DISCUSS] thread will be opened to talk about this release
>> candidate.
>>
>> Thanks,
>> Szymon Janc
>>
>

Re: Change in active ble_gap_disc behaviour in 1_2_0_dev

[Łukasz Rymanowski]

Hi Simon,

On 7 September 2017 at 02:11, Simon Ratner  wrote:
>
> > MSYS_1_BLOCK_SIZE=80 by itself is not sufficient
>
> Actually, it is sufficient, I was just setting it wrong.

Ok I know what is happening. Basically controller code assumed that
adv packet will fit into one msys block size. With BLE_EXT_ADV we
extended struct ble_mbuf_hdr which decrease space for adv data and we
end up with chain of os_mbufs. Which is fine, but when preparing event
to host it was not taken into account.

Have a look on this PR: https://github.com/apache/mynewt-core/pull/537

We plan to deliver it to 1.2

Best
Łukasz

Re: Premature supervision timeout

[Łukasz Rymanowski]

Hi,

On Sep 5, 2017 8:15 PM, "Simon Ratner" <si...@proxy.co> wrote:

On Tue, Sep 5, 2017 at 11:01 AM, Łukasz Rymanowski <
lukasz.rymanow...@codecoup.pl> wrote:

>
> Note that this is how BLE works. Master sends LE Create Connection on
> Advertising event and assumes connection is created. In this point of time
> host gets Connection Complete Event according to BT spec. However, for the
> reasons Will described, it might happen that peer will not answer on any
of
> the first 6 connection events. In this case connection is considered as
> dropped and  Disconnect Complete Event will come with "Connection failed
to
> be established" goes to host


Got it, thanks Łukasz! I am sure that the timeout is happening in exactly
this place.Since it seems that in all cases the times are very close, i
think i can increase connection interval to make this significantly less
frequent.


Please let us know the result.
BTW Air logs would help to confirm what is happening.

\Łukasz

Re: Premature supervision timeout

[Łukasz Rymanowski]

Hi Simon,

On 5 September 2017 at 19:40, Simon Ratner <si...@proxy.co> wrote:

> Just found this thread, which has come up a couple of times before (I think
> that's what you were referring to last time we spoke, Will?)
> https://www.mail-archive.com/dev@mynewt.incubator.apache.org/msg02454.html


AFAIK it is not valid anymore as Nimble now exchange features first as
well. After that Nimble takes decision to send LL_LENGTH_REQ or not.
I believe Andrzej fixed that some time ago.


>
> Could this be related, in a sense that the peer is sending some stray
> rejection frame that is causing connection to not be established? I do see
> this with both Android and iOS, for what it's worth (and both iOS10 and
> iOS11). What would be an easy way for me to confirm?
>
>
> On Tue, Sep 5, 2017 at 10:34 AM, Simon Ratner <si...@proxy.co> wrote:
>
> > Indeed that would be an improvement in error reporting :)
>

PR is in place for that. With this we will be sure if connection is
established or not in your scenario.

Note that this is how BLE works. Master sends LE Create Connection on
Advertising event and assumes connection is created. In this point of time
host gets Connection Complete Event according to BT spec. However, for the
reasons Will described, it might happen that peer will not answer on any of
the first 6 connection events. In this case connection is considered as
dropped and  Disconnect Complete Event will come with "Connection failed to
be established" goes to host


> However i am not convinced this is what i am seeing here - see my other
> > response.
> >
> > On Tue, Sep 5, 2017 at 10:28 AM, Łukasz Rymanowski <
> > lukasz.rymanow...@codecoup.pl> wrote:
> >
> >> Hi
> >>
> >> On 5 September 2017 at 19:08, will sanfilippo <wi...@runtime.io> wrote:
> >>
> >> > I do not think this is really an answer but it is the best I can do
> >> > without more information.
> >> >
> >> > When a device initially “connects” the state of the connection is not
> >> > considered established until a data frame is received from the other
> >> device
> >> > in the connection. The initial supervision timeout is 6 connection
> >> > intervals and is not based on the supervision timeout. That is why you
> >> see
> >> > the disconnect in 6 connection intervals.
> >>
> >>
> >> Actually I had plan some time ago to fix the error code on such event,
> >> because in this case we should use CONNECTION FAILED TO BE ESTABLISHED
> >> 0x3e
> >> Will put it on my todo list :)
> >>
> >>
> >> > So either the connect request from the master to the peripheral was
> not
> >> > received by the peripheral or it was received but no further data
> >> packets
> >> > were transferred and that is why the connection dropped.
> >> >
> >> > What version of code are you using? When I did the anchor point/last
> rxd
> >> > cputime math I see the difference between the two is 301889. This
> >> implies
> >> > to me that cputime is counting at 1 MHz and not at 32.768kHz. Which
> also
> >> > implies that you are not using the latest code.
> >> >
> >> > NOTE: I would expect this to happen occasionally, and more
> occasionally
> >> if
> >> > there are alot of devices transmitting in close proximity or if the
> two
> >> > devices connecting dont have a great RF link.
> >> >
> >> >
> >> Łukasz
> >>
> >>
> >> > > On Sep 4, 2017, at 5:50 PM, Simon Ratner <si...@proxy.co> wrote:
> >> > >
> >> > > Hi devs,
> >> > >
> >> > > I am tracking a nimble issue (on nrf52) that seems to surface
> >> > > intermittently - a supervision timeout when i am not expecting one.
> >> Below
> >> > > is a section of the log, nimble is the master here and as you can
> see,
> >> > the
> >> > > time between connection being established and the tmo error is
> ~260ms:
> >> > >
> >> > > 007734 [ts=60421848ssb, mod=4 level=1] GAP procedure initiated:
> >> connect;
> >> > > peer_addr_type=1 peer_addr=73:a0:1a:2e:b1:df scan_itvl=16
> >> scan_window=16
> >> > > itvl_min=24 itvl_max=40 latency=1 supervision_timeout=512
> >> min_ce_len=16
> >> > > max_ce_len=768 own_addr_ty
> >> > > 007760 [ts=60624960ssb, mod=64 level=1] peer: connected;
> >> conn_handle=14
> >> &

Re: Premature supervision timeout

[Łukasz Rymanowski]

Hi

On 5 September 2017 at 19:08, will sanfilippo  wrote:

> I do not think this is really an answer but it is the best I can do
> without more information.
>
> When a device initially “connects” the state of the connection is not
> considered established until a data frame is received from the other device
> in the connection. The initial supervision timeout is 6 connection
> intervals and is not based on the supervision timeout. That is why you see
> the disconnect in 6 connection intervals.


Actually I had plan some time ago to fix the error code on such event,
because in this case we should use CONNECTION FAILED TO BE ESTABLISHED 0x3e
Will put it on my todo list :)


> So either the connect request from the master to the peripheral was not
> received by the peripheral or it was received but no further data packets
> were transferred and that is why the connection dropped.
>
> What version of code are you using? When I did the anchor point/last rxd
> cputime math I see the difference between the two is 301889. This implies
> to me that cputime is counting at 1 MHz and not at 32.768kHz. Which also
> implies that you are not using the latest code.
>
> NOTE: I would expect this to happen occasionally, and more occasionally if
> there are alot of devices transmitting in close proximity or if the two
> devices connecting dont have a great RF link.
>
>
Łukasz


> > On Sep 4, 2017, at 5:50 PM, Simon Ratner  wrote:
> >
> > Hi devs,
> >
> > I am tracking a nimble issue (on nrf52) that seems to surface
> > intermittently - a supervision timeout when i am not expecting one. Below
> > is a section of the log, nimble is the master here and as you can see,
> the
> > time between connection being established and the tmo error is ~260ms:
> >
> > 007734 [ts=60421848ssb, mod=4 level=1] GAP procedure initiated: connect;
> > peer_addr_type=1 peer_addr=73:a0:1a:2e:b1:df scan_itvl=16 scan_window=16
> > itvl_min=24 itvl_max=40 latency=1 supervision_timeout=512 min_ce_len=16
> > max_ce_len=768 own_addr_ty
> > 007760 [ts=60624960ssb, mod=64 level=1] peer: connected; conn_handle=14
> > status=0 addr=73:a0:1a:2e:b1:df
> > 007763 [ts=60648396ssb, mod=4 level=1] GATT procedure initiated: exchange
> > mtu
> > 007765 [ts=60664020ssb, mod=4 level=1] GATT procedure initiated: discover
> > service by uuid; uuid=..
> > 007793 *** ble_ll_conn.c:2160 *** cputime=61336489 anchor_point=61386140
> > last_rxd_pdu_cputime=61084251 tmo=30
> > 007795 [ts=60898380ssb, mod=64 level=1] peer: updated; conn_handle=14
> > status=520 itvl=40 latency=1 tmo=512
> > 007800 [ts=60937440ssb, mod=64 level=1] peer: disconnected;
> conn_handle=14
> > reason=520
> >
> >
> > The line marked with *** is in `ble_ll_conn_event_end`, just before it
> > reports `BLE_ERR_CONN_SPVN_TMO`. The time of last PDU seems to match the
> > time when I see the "connected" host event (line #7760), and the anchor
> > point is presumably the time of the next scheduled conn event. What I
> > thought was interesting is that the tmo value is 300ms, i.e.
> > conn_itvl(50ms) * 6 rather than the supervision timeout. The connection
> sm
> > is in `BLE_LL_CONN_STATE_CREATED` state, and not
> > `BLE_LL_CONN_STATE_ESTABLISHED` as I would've expected, having already
> > received the "connected" event from the host.
> >
> > Any ideas what could be going on here?
> >
> > cheers,
> > simon
>
>