Re: Merging bluetooth5 branch into master

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

Change in active ble_gap_disc behaviour in 1_2_0_dev

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

Re: Priority violation in syscfg building 1_2_0_dev

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

Re: Priority violation in syscfg building 1_2_0_dev

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 in syscfg building 1_2_0_dev

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

Re: Premature supervision timeout

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

Re: Premature supervision timeout

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

Re: Premature supervision timeout

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

Re: Premature supervision timeout

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

Re: Premature supervision timeout

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

Re: Premature supervision timeout

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

Re: Premature supervision timeout

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

Re: Premature supervision timeout

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

Re: Premature supervision timeout

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

Re: Premature supervision timeout

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