Re: FCC Pre-scan

[Sterling Hughes]

Hi Jitesh,


On 9 Jun 2017, at 7:27, Jitesh Shah wrote:

> Great!
> So then ble_ll_reset() followed by ble_phy_disable() should take care of
> most cases, right?
>
> As far as giving back control to the nimBLE stack is concerned - that
> probably won't be necessary. FCC is a pretty controlled environment, so you
> could get away with manually resetting your device after every test.
>
> If all goes well, would you guys be interested in patches/mechanisms that
> help people with the FCC test?
>

That would be great!

Sterling

Re: FCC Pre-scan

[will sanfilippo]

Jitesh:

Sorry, I probably did not explain myself all that well.

1) The ble_ll_reset() call was mentioned in case you wanted to do something 
after the FCC test. This way you could be sure that the radio registers are all 
initialized properly after your special FCC test code messes with them (if 
indeed it does).

2) You should never have to issue ble_phy_disable() yourself. I am not sure how 
you are going to execute your FCC test code but certainly you could call 
ble_ll_reset() and once that happened (and you did not tell the controller to 
do anything else) you would have control of the radio. If your app has stopped 
advertising, scanning, initiating and has no connections, the radio will be 
free and you can mess with it to your hearts content. You would not even have 
to issue ble_ll_reset() in that case. Like I said, there are a number of 
different ways to do this… it all depends on the rest of your code and where 
you intend to call the function that will perform your FCC test code.

> On Jun 8, 2017, at 5:27 PM, Jitesh Shah  wrote:
> 
> Great!
> So then ble_ll_reset() followed by ble_phy_disable() should take care of
> most cases, right?
> 
> As far as giving back control to the nimBLE stack is concerned - that
> probably won't be necessary. FCC is a pretty controlled environment, so you
> could get away with manually resetting your device after every test.
> 
> If all goes well, would you guys be interested in patches/mechanisms that
> help people with the FCC test?
> 
> Jitesh
> 
> On Thu, Jun 8, 2017 at 4:40 PM, will sanfilippo  wrote:
> 
>> Question 2: Unless it got added recently and I did not catch it, currently
>> the nimble stack does not provide support for the FCC test.
>> 
>> Question 1: I guess it depends what you mean by take over control. The
>> call to ble_phy_disable() will certainly halt anything going on in the
>> radio. However, that is a pretty low-layer call and if the link layer is
>> doing something it could grab control again. As long as you are sure the
>> device is not advertising, scanning or in a connection that radio should
>> not be used and the link layer should not try to start using it.
>> 
>> There are a number of ways you could “hack” this into the code and I could
>> help with more information if you need it. And btw: if you do take control
>> of the radio and then want to return it to the nimble stack you should
>> perform a link-layer reset of the controller. The reason being is that
>> there are some radio registers that are only written once and if you change
>> them the device may no longer operate correctly.
>> 
>> Awesome that you are doing this! Let us know how it goes.
>> 
>> Will
>> 
>>> On Jun 8, 2017, at 3:23 PM, Jitesh Shah  wrote:
>>> 
>>> Hey all,
>>> We'll be going through the FCC pre-scan soon with 1.0 version of the
>> nimBLE
>>> stack. yay!
>>> 
>>> Of all the things needed for pre-scan the two which are the most
>> important
>>> are:
>>> 1) Ability to blast packets on only one of the 40 channels (and the
>> ability
>>> to choose which channel)
>>> 2) Ability to shut off the radio
>>> (Others like transmit power, connection interval are trivial to achieve)
>>> 
>>> *Question 1: *When we were using the softdevice, we disabled the
>> softdevice
>>> and took over the radio. With nimBLE, is ble_phy_disable() enough to take
>>> over the radio control from nimBLE?
>>> 
>>> *Question 2: *Optionally, does nimBLE provide any support for the FCC
>> test?
>>> I scoured the source, but didn't find any. Have any of you guys been
>>> through the FCC pre-scan using nimBLE?
>>> 
>>> Thanks,
>>> 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 
> 

Re: FCC Pre-scan

[will sanfilippo]

Question 2: Unless it got added recently and I did not catch it, currently the 
nimble stack does not provide support for the FCC test.

Question 1: I guess it depends what you mean by take over control. The call to 
ble_phy_disable() will certainly halt anything going on in the radio. However, 
that is a pretty low-layer call and if the link layer is doing something it 
could grab control again. As long as you are sure the device is not 
advertising, scanning or in a connection that radio should not be used and the 
link layer should not try to start using it.

There are a number of ways you could “hack” this into the code and I could help 
with more information if you need it. And btw: if you do take control of the 
radio and then want to return it to the nimble stack you should perform a 
link-layer reset of the controller. The reason being is that there are some 
radio registers that are only written once and if you change them the device 
may no longer operate correctly.

Awesome that you are doing this! Let us know how it goes.

Will

> On Jun 8, 2017, at 3:23 PM, Jitesh Shah  wrote:
> 
> Hey all,
> We'll be going through the FCC pre-scan soon with 1.0 version of the nimBLE
> stack. yay!
> 
> Of all the things needed for pre-scan the two which are the most important
> are:
> 1) Ability to blast packets on only one of the 40 channels (and the ability
> to choose which channel)
> 2) Ability to shut off the radio
> (Others like transmit power, connection interval are trivial to achieve)
> 
> *Question 1: *When we were using the softdevice, we disabled the softdevice
> and took over the radio. With nimBLE, is ble_phy_disable() enough to take
> over the radio control from nimBLE?
> 
> *Question 2: *Optionally, does nimBLE provide any support for the FCC test?
> I scoured the source, but didn't find any. Have any of you guys been
> through the FCC pre-scan using nimBLE?
> 
> Thanks,
> 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.

FCC Pre-scan

[Jitesh Shah]

Hey all,
We'll be going through the FCC pre-scan soon with 1.0 version of the nimBLE
stack. yay!

Of all the things needed for pre-scan the two which are the most important
are:
1) Ability to blast packets on only one of the 40 channels (and the ability
to choose which channel)
2) Ability to shut off the radio
(Others like transmit power, connection interval are trivial to achieve)

*Question 1: *When we were using the softdevice, we disabled the softdevice
and took over the radio. With nimBLE, is ble_phy_disable() enough to take
over the radio control from nimBLE?

*Question 2: *Optionally, does nimBLE provide any support for the FCC test?
I scoured the source, but didn't find any. Have any of you guys been
through the FCC pre-scan using nimBLE?

Thanks,
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.

Re: [JIRA-MYNEWT-384] Query

[amit mehta]

On Thu, Jun 8, 2017 at 3:30 AM, Justin Mclean  wrote:
> Hi,
>
>> 1: Is this approach correct to integrate the Eclipse Paho's Library
>> to implement MQTT client ? It is distributed under both EPL[3] and
>> EDL[4] licensing models and is left on the user to decide, which
>> one to pick.
>
> EDL is a category A license i.e. It's compatible with Apache [1], EPL is not, 
> can’t be included in a source release, but could be included in a binary. [2]
>
> Given it dual licensed and if you select the EDL licensed version (and 
> mention that in LICENSE) then it’s fine. [3]
>
> Also I’ve used Paho before and it’s a nice easy to use library.
>
> Thanks,
> Justin
>
> 1. https://www.apache.org/legal/resolved.html#category-a
> 2. https://www.apache.org/legal/resolved.html#category-b
> 3. https://www.apache.org/legal/resolved.html#mutually-exclusive

Thanks a lot Justin for summarizing the Licensing model. So
EDL, it is.

-- 
Sent from Bahamas, while drinking chi-chi and piña colada.

Re: Host Only Project

[Khaled Elsayed]

Hi Chris,

Thanks very much for this useful information about the initialization
sequence and how newt handles that. This is really awesome and flexible but
as you remarked, developers might feel losing control to the generated code
:)

I am still unclear about some issues, will really appreciate if you clarify:

1) using  transport package as example, so the controller pkg.yml says:
pkg.req_apis:
- ble_transport

and then the uart pkg.yml says:
pkg.apis:
- ble_transport

This is clear and seems like just a definition that package x supports the
API that y needs. But where is the ble_transport api itself? Who says which
functions are part of this specific API? Does it take whatever is in the
include folder in the uart package as the ble_transport API?

2) In many cases known to all developers working in protocol stacks,
initialization typically involves one layer passing pointers to callback
functions to the lower layer. How is this handled in the Nimble stack or
mynewt in general?

3) Regarding the syscfg.defs is there a document with categorized list of
the available parameters? Of particular importance are BLE specific
parameters, e.g. MAX number of connections, MAX PDU size, etc.

For the flow control at the host, thanks for the tip. Will take note.

Best regards

Khaled




On Wed, Jun 7, 2017 at 1:37 PM, Christopher Collins 
wrote:

> Hi Khaled,
>
> On Wed, Jun 07, 2017 at 04:26:01PM +0200, Khaled Elsayed wrote:
> [...]
> > So, it has the controller and uart only. My questions are:
> >
> > 1) What glues the different parts together? How does the code identify
> that
> > when I include the transport/ram that host and link layer will
> communicate
> > via RAM not uart. Where in the code is this handled?
> > Similarly, if host, gap, gatt, etc are missing from pkg.yml where in the
> > code are these modules avoided to be initialized or loaded (or more
> clearly
> > where in the code are they loaded and initialized when they exist in the
> > dependency)?
>
> The answer to both questions lies in the sysinit() call.  The code that
> ultimately gets executed by sysinit() is magically generated by newt
> each time you build a target.  The sysinit function initializes each
> package in the project.  Each package specifies zero or more "init"
> functions, each with a corresponding stage number.  The generated
> sysinit function is a flat sequence calls to each of these init
> functions, ordered by stage.
>
> The benefits of this mechanism are:
> 1. Apps can be configured and re-used without needing code
>modifications.
> 2. App code is simplified by the elimination of boilerplate
>initialization code.
>
> The downside is, of course, generated code, which everyone hates :).
>
> This is discussed in more detail at:
> http://mynewt.apache.org/latest/os/modules/sysinitconfig/sysinitconfig/
>
> This explains the initialization of the host, gap, and gatt packages.
> If these packages get pulled in to your project, newt generates calls to
> their initialization function in sysinit().
>
> The BLE transport case is slightly more complicated.  Here, another
> Mynewt concept is required: APIs.
>
> When a package declares that it supports a particular API, it promises
> to the rest of the system that it exposes a set of functions and global
> variables.  This allows another package to express an "abstract
> dependency."  That is, a package depends on a particular interface, but
> it doesn't care which package actually provides that interface.  The
> collection of bluetooth HCI transports packages is an example of this.
> The host and controller code is written such that they don't know the
> specific transport being used; they just use the abstract API provided
> by all the HCI transport packages.
>
> The host package doesn't have a hard dependency on a specific transport
> package.  Instead, it requires the "ble_transport" API.  At build time,
> newt ensures that one (and only one) package provides the required API,
> and it gives the host code access to the transport package's header
> files.
>
> Note: The newt tool doesn't verify that a package actually implements
> the APIs is claims to.  The newt tool just makes sure that for each
> required API, one and only one package that supplies the API gets pulled
> in to the build.
>
> At init time, the host package configures the transport package
> (whichever one it may be) with function pointer callbacks.  In this way,
> the host doesn't need to know which transport is actually being used,
> and the transport doesn't need to depend on the host or controller.
>
> > 2)  If one wants to use mynewt as host only with nordic soft device as
> is,
> > certainly pkg.yml will not include net/nimble/controller. So, how to tell
> > the build system to load or leave nordic controller in place?
>
> You need to make sure your project does not depend on the controller
> package.  Generally, there are two changes you would make to an app's

Re: [JIRA-MYNEWT-384] Query

[marko kiiskila]

Hi Amit,

On Wed, Jun 7, 2017 at 17:28 amit mehta  wrote:

> ...


> 2: If the answer for Q1 is 'yes', then should the MQTT library be put
> under 'net' directory; same place where nimble, Wifi etc are located
> in the apache-mynewt-core directory structure ?
>

Yes, that seems like the most appropriate spot


> 3: To avoid duplication of work, Is there someone already working on
> MYNEWT-384 jira task ?
>


I have not heard that anyone would've picked this up yet. So I think you
can go ahead with it.


> [1] https://issues.apache.org/jira/browse/MYNEWT-384
> [2] https://eclipse.org/paho/
> [3] http://www.eclipse.org/legal/epl-v10.html
> [4] http://www.eclipse.org/org/documents/edl-v10.php
>
> Thanks,
> Amit
> --
> Sent from Bahamas, while drinking chi-chi and piña colada.
>