Hi Simon,
On Wed, Sep 6, 2017 at 5:06 AM, Simon Ratner wrote:
>
> Hi devs,
>
> I am seeing a change in behaviour when performing active scan, compared to
> pre-1.1. Previously, BLE_GAP_EVENT_DISC event would be reported for both
> the original advertising packet (BLE_HCI_ADV_RPT_EVTYPE_ADV_IND),
Hi Simon,
On 6 September 2017 at 05:33, Simon Ratner wrote:
> Hi Szymon,
>
> I'd like to take you up on that offer of docs, or at least a pointer in the
> right direction of where to find the new multi-adv hci commands.
Those are standard HCI commands and events from Bluetooth Core Spec 5.0 :
L
Hi Szymon,
I'd like to take you up on that offer of docs, or at least a pointer in the
right direction of where to find the new multi-adv hci commands.
Cheers,
simon
On Tue, Jul 18, 2017 at 3:48 PM, Szymon Janc
wrote:
> Hi Simon,
>
> On Wednesday, 19 July 2017 00:31:55 CEST Simon Ratner wrote
Hi devs,
I am seeing a change in behaviour when performing active scan, compared to
pre-1.1. Previously, BLE_GAP_EVENT_DISC event would be reported for both
the original advertising packet (BLE_HCI_ADV_RPT_EVTYPE_ADV_IND), and the
scan response (BLE_HCI_ADV_RPT_EVTYPE_SCAN_RSP), in close successio
I think you need a newer version of newt. The syscfg override rules
were relaxed in newt 1.1. Now, a package can override its own settings.
Unfortunately, it looks like we failed to add the necessary newt
compatibility rules to the core repo in 1.1. You should have gotten a
clearer error messag
Never mind, upgrading newt tool to 1_2_0_dev did the trick (wasn't there a
warning at some point to tell us that the toolchain is outdated?)
On Tue, Sep 5, 2017 at 7:16 PM, Simon Ratner wrote:
> Got the following trying to build my app on 1.2 (moving from pre-1.1):
>
> Error: Priority violation
Got the following trying to build my app on 1.2 (moving from pre-1.1):
Error: Priority violations detected (Packages can only override settings
defined by packages of lower priority):
Package: net/nimble/controller overriding setting:
BLE_LL_CFG_FEAT_LE_CSA2 defined by net/nimble/controller
So just increasing the conn itvl hasn't solved it, which makes me suspect
it isn't simply a timing thing, but rather a peer not responding to the
request (or responding in an unexpected way). I tried up to 180ms, which
should give it a full second to receive the first data frame.
014762 [ts=115328
Glad other folks were answering you Simon; I was away for a bit.
I do not have anything else to add. The only thing is that if you do not have a
sniffer one (possible) way to determine what is going on is to look at
statistics. You need to look at the stats directly before and after the issue
w
Hi,
On Sep 5, 2017 8:15 PM, "Simon Ratner" 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
> h
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 sp
Hi Simon,
On 5 September 2017 at 19:40, Simon Ratner 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
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
Could this be related, in a sense that the peer is sending some stray
rejection frame
Indeed that would be an improvement in error reporting :)
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 wrote:
>
>
Thanks Will,
I am indeed running pre-1.1 code at 1MHz. Planning to move to 1.1/1.2
shortly; if you think this is something that would behave better in the new
codebase, that would accelerate that process ;)
I see this happening regularly with just three devices (one nimble, two
phones), with the
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 oth
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
17 matches
Mail list logo