Found the culprit, and it is something else - the adv packet data itself. scan: event_type=0 addr_type=1 addr=4b:41:99:63:b4:e4 uuids128=1 (cc040100-2aae-4d26-ad62-03e9a8637ebd) mfg_data_len=3 scan: event_type=0 addr_type=1 addr=4b:41:99:63:b4:e4 uuids128=1 (6c040100-2aae-4d26-ad62-03e9a8637ebd) mfg_data_len=3 scan: event_type=4 addr_type=1 addr=4b:41:99:63:b4:e4 uuids128=0 () mfg_data_len=10
I see both types of reports, but note the uuid128: the first byte of it appears to be corrupted (should be 0x03). On Wed, Sep 6, 2017 at 8:43 AM, Simon Ratner <[email protected]> wrote: > Interesting, I will investigate more today and let you know. > > Maybe something to do with how the reports are prioritized onto HCI? We > have iOS apps advertising in the foreground which can be very aggressive > (sub-100ms) so a change in how the reports are ordered or stored may have > resulted in unfair starving of other advertisers when it comes to grabbing > an HCI event? > > > On 5 Sep. 2017 23:57, "Andrzej Kaczmarek" <[email protected]> > wrote: > > Hi Simon, > > On Wed, Sep 6, 2017 at 5:06 AM, Simon Ratner <[email protected]> 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 succession. > > > > With 1_2_0_dev, I no longer see the advertising packet data, only the > scan > > responses. > > > > This is my scan parameters: > > > > const struct ble_gap_disc_params scan_params_dflt = { > > .itvl = 0, /* use default */ > > .window = 0, /* use default */ > > .filter_policy = BLE_HCI_SCAN_FILT_NO_WL, > > .filter_duplicates = 0, > > .limited = 0, > > .passive = 0, > > }; > > > > Is this an intentional change, and if so, any way to get at the actual > adv > > packet data? > > I'm not aware of any change in this code, but I've just done a quick > test using bletiny and for me it works just fine: > > [08:50:23:504] 093668 received advertisement; event_type=0 <cut> fields: > [08:50:23:600] 093672 flags=0x1a: > [08:50:23:600] 093672 General discoverable mode > [08:50:23:600] 093673 tx_pwr_lvl=-7 > [08:50:23:600] 093674 > [08:50:23:600] 093674 received advertisement; event_type=4 <cut> fields: > [08:50:23:600] 093680 uuids16(complete)=0x180d > [08:50:23:600] 093681 name(complete)=andk xperia z5 > > I used 'b scan' which uses default parameters so the same as you quoted. > > Can you see the advertising reports in HCI trace? If so, can you show > them perhaps to check if they are correct? > > Best regards, > Andrzej > > >
