> MSYS_1_BLOCK_SIZE=80 by itself is not sufficient Actually, it is sufficient, I was just setting it wrong.
On Wed, Sep 6, 2017 at 4:49 PM, Simon Ratner <[email protected]> wrote: > This actually works correctly with the default bletiny sysconfig. > After a bit more digging, this is the config that makes it fail: > > (simon/mynewt-1_2_0_rc1) ~> > $ newt target show bletiny > targets/bletiny > app=@apache-mynewt-core/apps/bletiny > bsp=@apache-mynewt-core/hw/bsp/rb-nano2 > build_profile=optimized > syscfg=BLE_MAX_CONNECTIONS=32:MSYS_1_BLOCK_COUNT=96:MSYS_1_ > BLOCK_SIZE=80 > > Note that MSYS_1_BLOCK_SIZE=80 by itself is not sufficient to trigger the > problem, the other two values are needed as well. Not sure what's going on. > > > > > On Wed, Sep 6, 2017 at 10:24 AM, Simon Ratner <[email protected]> wrote: > >> Not an off-by-one: for a 29-byte adv packet, the last byte is corrupted, >> for a 31-byte adv packet, the last 3 bytes are corrupted, so it seems to be >> capping the adv data at 28 bytes regardless of actual length. >> >> Confirmed with bletiny: >> >> 011335 received advertisement; event_type=3 rssi=-92 addr_type=1 >> addr=3a:7b:80:88:44:77 length_data=31 data=0x1e:0xff:0x06:0x00:0x01: >> 0x09:0x20:0x00:0xd5:0x27:0x09:0x02:0xe2:0x4b:0x7d:0xf0:0xd8: >> 0xa6:0x95:0xa1:0x46:0xde:0x09:0xde:0x71:0x94:0x38:0xe9:0x04:0x1a:0x00 >> >> 011348 received advertisement; event_type=3 rssi=-93 addr_type=1 >> addr=3a:7b:80:88:44:77 length_data=31 data=0x1e:0xff:0x06:0x00:0x01: >> 0x09:0x20:0x00:0xd5:0x27:0x09:0x02:0xe2:0x4b:0x7d:0xf0:0xd8: >> 0xa6:0x95:0xa1:0x46:0xde:0x09:0xde:0x71:0x94:0x38:0xe9:0x74:0x19:0x00 >> >> The last three bytes of that packet should be "2a a7 30": >> >> [image: Inline image 1] >> >> >> On Wed, Sep 6, 2017 at 9:55 AM, Simon Ratner <[email protected]> wrote: >> >>> Eliminated one more variable -- it isn't the fault of >>> ble_hs_adv_parse_fields, event->disc->data itself seems to be wrong. Given >>> that this is the last byte, perhaps an off-by-one in calculating the size >>> of the hci packet? >>> >>> scan: event_type=0 addr=6a:be:ca:d3:09:68 data=02 01 02 04 ff 04 03 03 >>> 02 0a f9 11 07 bd 7e 63 a8 e9 03 62 ad 26 4d ae 2a 00 01 04 5c >>> scan: event_type=0 addr=6a:be:ca:d3:09:68 data=02 01 02 04 ff 04 03 03 >>> 02 0a f9 11 07 bd 7e 63 a8 e9 03 62 ad 26 4d ae 2a 00 01 04 9b >>> scan: event_type=0 addr=6a:be:ca:d3:09:68 data=02 01 02 04 ff 04 03 03 >>> 02 0a f9 11 07 bd 7e 63 a8 e9 03 62 ad 26 4d ae 2a 00 01 04 0c >>> >>> >>> On Wed, Sep 6, 2017 at 9:24 AM, Simon Ratner <[email protected]> wrote: >>> >>>> 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 >>>>> >>>>> >>>>> >>>> >>> >> >
