hop stoped at its second step

[863356170]

I'm working on BTLE with bladeRF xA9 on Ubuntu 22.04, using newest BTLE, libbladeRF and .rbf file, and met a problem on hopping.
Firstly, sorry for my poor English.
The problem is, when I use btle_rx with -o, seeing "track start" in terminal when bladeRF catches AUX_CONNECT_REQ, it could catch some packeges on one channel, but when it says next state 2, it stops working while not exiting. I tried at least five times with the same problem.

That's my input:
./btle_rx -c 37 -s test -o

That's what I get before it stop (hide some data because I don't know if it is needed):
0028557us Pkt080 Ch37 AA:hide ADV_PDU_t0:ADV_IND T1 R0 PloadL24 AdvA:hide Data:hide CRC0
0000032us Pkt081 Ch37 AA:hide ADV_PDU_t5:CONNECT_REQ T1 R1 PloadL34 InitA:hide AdvA:hide AA:hide CRCInit:hide WSize:02 WOffset:0011 Itrvl:0018 Ltncy:0000 Timot:01f4 ChM:1fffffffff Hop:10 SCA:5 CRC0
Hop: track start ...
Hop: next ch 10 freq 2424MHz access hide crcInit hide
Hop: next state 1
0266259us Pkt082 Ch10 AA:hide LL_PDU_t1:LL_DATA1 NESN1 SN1 MD0 PloadL0 CRC0
0000036us Pkt083 Ch10 AA:hide LL_PDU_t3:LL_CTRL NESN0 SN1 MD1 PloadL24 Op10(LL_RESERVED) Byte:hide CRC0
0000014us Pkt084 Ch10 AA:hide LL_PDU_t1:LL_DATA1 NESN0 SN0 MD0 PloadL0 CRC0
0000011us Pkt085 Ch10 AA:hide LL_PDU_t2:LL_DATA2 NESN1 SN0 MD0 PloadL9 LL_Data:hide CRC0
Hop: 1st data pdu
Hop: next state 2
0941868us Pkt086 Ch34 AA:hide LL_PDU_t1:LL_DATA1 NESN1 SN1 MD0 PloadL0 CRC1
^CCaught signal 2 (here I use ctrl+C after waiting for 1 or 2 minutes)
Exit main loop ...
bladerf_deinit_stream.
enable module false: Success
bladerf_close.
bladeRF rx thread quit.

I'd like to know why this happenes and how can I fix it. Thanks for any suggestion.

[863356170]

About my BLE equipment, they are a pad as master and a phone as slave. I used an app named BLE Debugging Assistant to make the phone work as slave, it could be seen on pad, connect with it and get simple data from it. Don't know if this has effected anything.

[863356170]

I found something strange when checking packets with wireshark.
I start rx at channel 37 ,in the terminal, I get:
Cmd line input: chan 37, freq 2402MHz, ...
When I check ADV_IND packet in wireshark, I found:
RF Channel: 37, 2476 MHz, Data channel 35
And as the same, when it start hopping I get:
Hop: next ch 12 freq 2430MHz ...
Following packet in wireshark:
RF Channel: 12, 2426 MHz, Data channel 38

I don't know if it's normal, cause it looks like the real freqency is wrongly setted. I read btle_rx.c to find out which frequency it will set but it seems correctly. So is this just a specially expression or there is a problem?

[863356170]

Partly solve the problem. That's it:
I found out that BLE 5.x uses different hop mode, and my phone and pad support 5.0, so I got a old phone with only BT4.1 (guess it supports BLE at the same time) and let it be master. Then I got data packet during hopping.

However, there are a few of problems I still don't understand: why wireshark shows different frequency from it should be? why the order of hopping is like this (just copy channel part from terminal):

Hop: track start ...
Hop: next ch 13 freq 2432MHz ...
Hop: next state 1
1073199us Pkt035 Ch13
0000034us Pkt036 Ch13
Hop: 1st data pdu
Hop: next state 2
2080630us Pkt037 Ch34
2469888us Pkt038 Ch33
0000029us Pkt039 Ch33
2478129us Pkt040 Ch32
0000034us Pkt041 Ch32
2473990us Pkt042 Ch31
0000030us Pkt043 Ch31
0810932us Pkt044 Ch30
0000030us Pkt045 Ch30
3313649us Pkt046 Ch17
0003895us Pkt047 Ch17
1646765us Pkt048 Ch4
0000035us Pkt049 Ch4
0811003us Pkt050 Ch3
0000042us Pkt051 Ch3
2473848us Pkt052 Ch2
0000089us Pkt053 Ch2
0811006us Pkt054 Ch1
0000030us Pkt055 Ch1
2473885us Pkt056 Ch0
0000031us Pkt057 Ch0
0823387us Pkt058 Ch12
0000031us Pkt059 Ch12
0811066us Pkt060 Ch11
0003970us Pkt061 Ch11
...

I thought it should be something like:
Ch13
Ch26
Ch2
Ch15
...