Checking my understanding of the -e and -H behavior

[XenoKovah]

I just got a pair of Creative Zen Air Plus headphones since they advertised LE audio, and I wanted to poke around with standards-based LE audio rather than whatever custom thing Apple came up with. (FYI they advertise both CIS and BIS in their manual, using those exact terms from the BT spec, albeit without spelling them out. So they may be appropriate for broadcast exploration too.)

These also seem to turn out to be the first devices around me which advertise ADV_EXT_INDs (15s after opening the case.) However, when I add the -e and optionally the -H, to try and see what extended data they're advertising, I don't get anything.

E.g. based on this packet:

I would expect it would go to channel 15 and capture an AUX_ADV_IND. However I don't see anything ~570us later, just more ADV_EXT_INDs.

Am I correct in thinking that if the -e option is given, Sniffle should be picking up some extra advertising packets between the ADV_EXT_INDs?

Also, am I understanding correctly that if one is specifically only looking for extended advertisements and their followup data, there's no need to use -H? (I.e. that -H is only for if you want to follow both legacy and extended advertisements, watching for a connection which could come in after advertisement on either of those channels?)

Also FYI this capture was done w/ fw 1.10.0

[sultanqasim]

It should be picking up the AUX_ADV_IND packets when you specify -e. The -H option should be unnecessary. My guess is that the process of receiving the ADV_EXT_IND, processing it, then retuning to channel 15 is too slow. For reference, for your ADV_EXT_IND, the preamble is 1 byte, access address is 4 bytes, header is 2 bytes, body 7 bytes, and CRC 3 bytes. That's a total of 17 bytes, so 136 us on the 1M PHY. The packet making its way from the radio CPU to the main CPU for processing takes ~200 us, the processing may take around 50-100 us, and then the time from issuing the retune command to actually listening on the new channel takes ~200 us. Combined, it might just be a few microseconds too slow to catch the AUX_ADV_IND whose preamble starts 570 us after the ADV_EXT_IND's preamble.

I made some recent changes to the firmware to reduce some latencies, so you can try the latest master branch of the firmware to see if it succeeds. You can also try the active scanning mode (using the -A flag in conjunction with -e) since it lets the radio CPU process the aux pointer and retune independently without needing the main CPU to tell it what to do.

[XenoKovah]

No luck with the latest firmware either, with or without -A in conjunction with -e.

[sultanqasim]

Hmm, I wonder what's going on then. If some of the packets have longer aux offsets (for example 870 us), that should be sufficient time for the firmware to hop. If you use something like nRF Connect on an Android device, does it see the auxiliary advertising data?

Another thing you could try is getting the sniffer to just sit on one of the secondary advertising channels (for example 10) and seeing if it catches any auxiliary advertisements that way. For this device, auxiliary advertisements should also be on the 1M PHY. You could do this by calling hw.cmd_chan_aa_phy(10, 0x8E89BED6, PhyMode.PHY_1M) for staying on channel 10 after the call to hw.setup_sniffer.

[sultanqasim]

If you want to see how this should normally work, use the Nordic nRF Connect Android app to set up an extended advertiser and sniff it with Sniffle. I'm not yet sure what your Creative headphones are doing differently.

[XenoKovah]

I confirmed that I can capture the nRF connect Android extended advertisements out of the box with Sniffle. And then I went and confirm the same version still didn't catch the AUX_ADV_IND follow ups to the ADV_EXT_INDs.

I then also confirmed the suggestion to add a hw.cmd_chan_aa_phy(10, 0x8E89BED6, PhyMode.PHY_1M) after hw.setup_sniffer() did allow me to capture the AUX_ADV_IND packets! (Which had a lot of extra data in them.)

[sultanqasim]

I finally got a chance to try out the Creative headphones you sent me, and the current Sniffle firmware seems to be picking up the AUX_ADV_IND PDUs just fine. See below for an example:

$ ./version_check.py    
Sniffle Firmware 1.10.0, API Level 0

$ ./sniff_receiver.py -e
...
Timestamp: 4.968195  Length:  9  RSSI: -47  Channel: 37  PHY: 1M  CRC: 0x519D75
Ad Type: ADV_EXT_IND
ChSel: 0 TxAdd: 0 RxAdd: 0 Ad Length: 7
AuxPtr Chan: 9 PHY: 1M Delay: 570 us
AdvMode: Connectable
AdvDataInfo DID: 0x5ba SID: 0x0
0x0000:  07 07 46 18 ba 05 09 13  00                       ..F......

Timestamp: 4.968793  Length: 96  RSSI: -50  Channel:  9  PHY: 1M  CRC: 0x5BC55E
Ad Type: AUX_ADV_IND
ChSel: 0 TxAdd: 0 RxAdd: 0 Ad Length: 94
AdvMode: Connectable
AdvA: 00:02:3C:BB:9B:A0 (Public) AdvDataInfo DID: 0x5ba SID: 0x0
0x0000:  07 5e 49 09 a0 9b bb 3c  02 00 ba 05 02 01 1c 03  .^I....<........
0x0010:  19 41 09 11 09 5a 65 6e  20 41 69 72 20 50 6c 75  .A...Zen Air Plu
0x0020:  73 2d 4c 45 41 05 16 55  18 2a 00 04 16 53 18 00  s-LEA..U.*...S..
0x0030:  11 16 4e 18 01 27 00 27  00 08 03 01 27 00 03 02  ..N..'.'....'...
0x0040:  27 00 03 16 4f 18 07 2e  53 20 62 b4 32 49 11 02  '...O...S b.2I..
0x0050:  4e 18 50 18 46 18 4d 18  44 18 45 18 43 18 4f 18  N.P.F.M.D.E.C.O.

I wonder why it wasn't working for you.

[sultanqasim]

Thanks for sending those headphones by the way, they'll be very helpful for testing when I get around to implementing isochronous stream support (for LE Audio).

[XenoKovah]

That's strange. I'll retry when I get done with some of the BTIDES work.

Out of curiosity are you using a TI dev board or a Sonoff?

[sultanqasim]

I don't remember for sure what I used at the time; probably a Sonoff dongle.

[XenoKovah]

I can confirm I can see AUX_ADV_IND with a Sonoff and the release version of firmware 1.10.0 (with or without -m filter). ¯_(ツ)_/¯

So I'll try and figure out what I was doing different before (starting with using the 2Mbaud firmware instead of the 921600 baud fw. (Though it's possible it could also be down to letting the headphones sit for a long time and their battery completely draining to the point where any issues they themselves were having were reset.)

[XenoKovah]

OK, I think I may have identified the issue. Didn't you release a prebuilt firmware version 1.10.1 at some point? I don't see it on the releases page currently, but the version I was using is labeled "2M_1.10.1". So either it's a custom version I compiled or it's a version you released but then removed?

[sultanqasim]

I never released a 1.10.1, so it’s a custom build from somewhere

[XenoKovah]

OK, closing this then as the release firmware seems to be working as expected. Thanks!